RELAY SYSTEM, RELAY DEVICE AND PROGRAM

The relay system addresses inefficiencies in vehicle networks by converting and packaging messages across multiple protocols, improving diagnostic communication efficiency.

DE102025110285A1Pending Publication Date: 2025-09-25DENSO CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
DE102025110285
Authority / Receiving Office
DE · DE
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-03-21
Filing Date
2025-03-18
Publication Date
2025-09-25

AI Technical Summary

Technical Problem

Existing relay systems face inefficiencies in communication due to the use of multiple types of lower protocols with different communication speeds and the need for higher protocol conversion, particularly when diagnosing ECUs with external Ethernet tools using DoIP, as conventional technologies only convert lower-layer protocols.

Method used

A relay system comprising a first relay device and a second relay device that perform protocol conversion, packaging, and unpackaging to handle messages using different higher and lower protocols, allowing efficient communication between electronic devices.

Benefits of technology

Improves communication efficiency by enabling seamless conversion and packaging of messages across diverse protocols, enhancing diagnostic capabilities in vehicle networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A relay system includes: a first relay device (2) connected to a first electronic device (5) by a first lower protocol, sending and receiving data to and from the first electronic device by a first higher protocol, and sending and receiving data to and from a second electronic device (4) by a second higher protocol; and a second relay device (3) connected to the second electronic device by a second lower protocol and connected to the first relay device by a third lower protocol.The first relay device includes: a protocol conversion unit (21, 24) configured to perform a conversion between a first message and a second message; a first packaging unit (22) configured to send a combined message obtained by a second message through the third lower protocol; and a first unpacking unit (23) configured to extract and deliver the extracted second message. The second relay device includes: a second packaging unit (32) configured to send the combined message; a second unpacking unit (31) configured to send the second message obtained by unpacking the combined message.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present disclosure relates to a technology for forwarding data between multiple electronic control units.

[0002] In an in-vehicle network employing a zone architecture, ECUs using CAN communication are connected under a zone ECU, and the zone ECUs and the central ECU are connected by a bus that is faster than CAN, such as Ethernet or CAN FD. CAN and Ethernet are registered trademarks. If CAN communication frames, which are slow and have small message sizes, are forwarded sequentially over Ethernet or CAN FD, communication efficiency decreases.

[0003] The following Patent Document 1 describes a technology for packaging multiple CAN messages into an Ethernet frame and forwarding the messages.

[0004] Patent Document 1: JP 2022-91585 A

[0005] Meanwhile, DoIP, a diagnostic communication solution based on Ethernet, is becoming more widespread. However, many ECUs currently use only CAN as a communication interface. CAN is a registered trademark. Therefore, to diagnose an ECU with an external Ethernet tool that uses DoIP, a protocol conversion between DoIP and DoCAN is required.

[0006] However, based on the inventors' detailed analysis, the conventional technology described in Patent Document 1 simply packages messages and converts lower-layer protocols (hereinafter referred to as lower-layer protocols). Therefore, when the conventional technology is applied to a relay system using various higher-layer protocols (hereinafter referred to as higher-layer protocols), a difficulty was found in that the functionality is insufficient.

[0007] One aspect of the present disclosure provides a technology for improving communication efficiency in a relay system that uses multiple types of lower protocols with different communication speeds and involves conversion of a higher protocol.

[0008] According to one aspect of the present disclosure, a relay system relays communication between a first electronic device and a second electronic device and includes a first relay device and a second relay device. The first relay device is connected to the first electronic device through a first lower-level protocol, configured to send and receive data to and from the first electronic device using a first higher-level protocol, and configured to send and receive data to and from the second electronic device using a second higher-level protocol.The second relay device is connected to a second electronic device by a second lower protocol and is connected to the first relay device by a third lower protocol that uses a frame with a longer payload than the second lower protocol.

[0009] The first relay device includes a protocol conversion unit, a first packing unit, and a first unpacking unit. The protocol conversion unit is configured to perform mutual conversion between a first message using the first higher protocol and the first lower protocol and a second message using the second higher protocol and the second lower protocol. The first message is sent to and received by the first electronic device. The first packing unit is configured to send a combined message obtained by combining at least one second message supplied from the protocol conversion unit to the second relay device through the third lower protocol.The first unpacking unit is configured to extract the at least one second message from the combined message received from the second relay device through the third lower protocol and supply the at least one extracted second message to the protocol conversion unit.

[0010] The second relay device includes a second packaging unit and a second unpacking unit. The second packaging unit is configured to transmit the combined message obtained by combining the at least one second message received from the second electronic device to the first relay device through the third lower protocol. The second unpacking unit is configured to individually transmit to the second electronic device the at least one second message obtained by unpacking the combined message received from the first relay device through the third lower protocol.

[0011] According to such a configuration, it is possible to improve communication efficiency in a relay system that uses multiple types of lower-level protocols with different communication speeds and involves the conversion of higher-level protocols. One aspect of the present disclosure is a relay device. The relay device configures a relay system for relaying communication between a first electronic device and a second electronic device, along with a sub-relay device connected to a first electronic device through a first lower-level protocol and to a second electronic device through a second lower-level protocol.

[0012] The relay device includes a protocol conversion unit, a packing unit, and an unpacking unit. The protocol conversion unit is configured to perform a mutual conversion between a first message using the first higher protocol and the first lower protocol and a second message using the second higher protocol and the second lower protocol. The first message is sent to and received by the first electronic device.The packing unit is configured to send a combined message obtained by combining at least one second message supplied from the protocol conversion unit to the sub-relay device through the third protocol using a frame with a longer payload than the second lower protocol, and the unpacking unit is configured to extract the at least one second message from the combined message received from the sub-relay device through the third lower protocol and supply the at least one extracted second message to the protocol conversion unit.

[0013] The relay device configured in this way can be used as the first relay device constituting the relay system described above. One aspect of the present disclosure is a program that causes a computer to function as a first relay device and a second relay device constituting the relay system described above.

[0014] By executing such a program, it is possible to achieve the same effect as the relay system described above.

[0015] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description made with reference to the accompanying drawings, in which like parts are designated by like reference numerals. Fig. 1 is a block diagram showing a configuration of an in-vehicle system. Fig. 2 is an explanatory diagram showing a combination of communication protocols used in the in-vehicle system. Fig. 3 is an explanatory diagram showing an outline of processings in a central ECU and a zone ECU. Fig. 4 is an explanatory diagram showing a configuration of a communication frame. Fig. 5 is a sequence diagram of communication from an external tool to an end ECU in a first embodiment in which a plurality of messages concerning the end ECU are packed in the same frame. Fig. 6 is a sequence diagram of communication from an end ECU to an external tool in the first embodiment. Fig. 7 is a sequence diagram for controlling the transmission interval of frames addressed to an end ECU. Fig. Figure 8 is a sequence diagram for controlling the number of frames that can be sent to an end ECU without acknowledgment. Fig. 9 is a sequence diagram of communication from an external tool to an end ECU in a second embodiment in which a plurality of messages relating to a plurality of end ECUs are packed into the same frame. Fig. 10 is a sequence diagram of communication from the end ECU to the external tool in the second embodiment.

[0016] Hereinafter, embodiments of the present disclosure will be described with reference to drawings. (1. First Embodiment)(1-1. Configuration)

[0017] As in Fig. As shown in Figure 1, an in-vehicle system 1 of the present embodiment is mounted on a vehicle. The vehicle may have an automated driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an internal combustion engine and an electric motor as a power source. The vehicle is not limited to the vehicle with the automated driving function or the hybrid vehicle, but may be a vehicle with only a manual driving function, or a vehicle with only an internal combustion engine or only an electric motor as the power source. Hereinafter, the vehicle equipped with the in-vehicle system 1 will be simply referred to as a vehicle.

[0018] The in-vehicle system 1 includes a relay device (hereinafter a central ECU) 2, a plurality of relay devices (hereinafter zone ECUs) 3, and a plurality of ECUs (hereinafter end ECUs) 4. ECU is an abbreviation for Electronic Control Unit.

[0019] The central ECU 2 controls the multiple zone ECUs 3 to implement coordinated control of the entire vehicle. The central ECU 2 is connected to multiple zone ECUs 3 via a higher-layer network. The higher-layer network may be, for example, Ethernet. Ethernet is a registered trademark. The central ECU 2 has a port for connecting an external tool 5. The external tool 5 diagnoses, for example, ECUs 2 to 4. The central ECU 2 and the external tool 5 are connected to each other using, for example, Ethernet.

[0020] The zone ECU 3 is dedicated to each zone dividing the area within the vehicle and primarily controls multiple end ECUs 4 that exist within that zone. Each zone ECU 3 is connected to a subordinate end ECU 4 via a lower-layer network dedicated to each zone ECU 3. The lower-layer network can be, for example, CAN. CAN is a registered trademark and is an abbreviation for Controller Area Network.

[0021] The maximum data length of a frame is 8 bytes for CAN and 1500 bytes for Ethernet. If Ethernet supports jumbo frames, the maximum data length of a frame is 9216 bytes.

[0022] The central ECU 2 is an electronic control unit mainly including a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, and the like. Various functions of the microcomputer are implemented by the CPU 2a executing programs stored in a non-volatile physical storage medium. In this example, the ROM 2b corresponds to a non-volatile physical storage medium that stores a program. Further, by executing this program, a process corresponding to the program is executed. Note that some or all of the functions performed by the CPU 2a may be implemented by a hardware circuit such as one or more ICs. Furthermore, the number of microcomputers constituting the central ECU 2 may be one or more.

[0023] Hereinafter, the protocol used to connect the central ECU 2 and the external tool 5 is referred to as a first lower protocol, the protocol used to connect the zone ECU 3 and the end ECU 4 is referred to as a second lower protocol, and the protocol used to connect the central ECU 2 and the zone ECU 3 is referred to as a third lower protocol. The protocol used to send and receive data between the central ECU 2 and the external tool 5 is referred to as a first higher protocol. The protocol used to send and receive data between the central ECU 2 and the end ECUs is referred to as a second higher protocol.Hereinafter, the first lower protocol and the first higher protocol are collectively referred to as external protocols, and the second lower protocol and the second higher protocol are collectively referred to as terminal protocols.

[0024] As in Fig. As shown in Figure 2, in the present embodiment, the first lower-level protocol is TCP, IP, and Ethernet, the second lower-level protocol is CAN, and the third lower-level protocol is TCP / UDP, IP, and Ethernet. The payload of the third lower-level protocol uses AUTOSAR's IPduM, and one or more frames sent and received between the zone ECU 3 and the end ECU 4 are encapsulated. The first higher-level protocol is UDS and DoIP. The second higher-level protocol is UDS or DoCAN.

[0025] UDS is an abbreviation for Unified Diagnostic Services, a unified diagnostic service for automobiles standardized by ISO 14229. DoIP is an abbreviation for Diagnostics over Internet Protocol, an Ethernet-based diagnostic protocol standardized by ISO 13400. DoCAN is an abbreviation for Diagnostic Communication over Controller Area Network, a CAN-based diagnostic protocol standardized by ISO 15765. AUTOSAR is an abbreviation for AUTomotive Open System ARchitecture, a platform specification that aims to standardize in-vehicle software. IPduM is an abbreviation for Interaction Layer Protocol Data Unit Multiplexer. (1-2. Overview of processing by central ECU and zone ECU)

[0026] The processings performed by the central ECU 2 and the zone ECU 3 are described with reference to Fig. 3 and Fig. 4 outlined.

[0027] The central ECU 2 receives a DoIP message from the external tool 5. As in Fig. As shown in Figure 4, the DoIP message is transmitted in a TCP frame and includes a DoIP header and DoIP data. Fig. 4, descriptions regarding protocols lower than TCP are omitted.

[0028] When the DoIP message is received from the external tool 5, the central ECU 2 executes protocol conversion processing 21 and packaging processing 22. The protocol conversion processing 21 is processing for converting the DoIP message into the DoCAN message. Specifically, when the central ECU 2 receives the DoIP message, it divides the DoIP data into N data pieces, each of which has a length that can be transmitted by CAN, which is the second lower protocol. N is an integer of 1 or more. Hereinafter, the divided DoIP data is referred to as divided data. The data length of the divided data is set to, for example, a length obtained by subtracting the area length of the N_AE / NPCI described later (for example, 1 byte in the case of a CF in a normal fixed addressing format) from the data length of the CAN data (i.e., 8 bytes).The central ECU 2 converts the information in the DoIP header into PduID and N_AE / NPCI, which are header information used in the second protocol. Furthermore, the central ECU 2 generates N DoCAN messages by adding the converted header information to each of the N pieces of split data and stores the generated messages in a transmit buffer.

[0029] The PduID is set based on the message type contained in the DoIP header. The PduID can be linked to the CAN ID on a one-to-one basis. The PduID can be the CAN ID itself.

[0030] If N_AE is used, it may include address information contained in the DoIP header. NPCI includes identification information that indicates whether the DoCAN message is SF, FF, CF, or FC. Whether N_AE is used and the format of N_AE and NPCI depend on the addressing used in DoCAN. SF indicates that the message is the DoCAN message used when sending data that is terminated in a frame. FF indicates that this is the first DoCAN message to be sent and is used when sending data that is not terminated in a frame. CF is used when sending data that is not terminated in a frame and indicates that there is a subsequent DoCAN message following FF.FC is used when receiving data that is not completed within a frame and indicates that the message is a DoCAN message sent by the receiver to decide whether to exchange subsequent DoCAN messages. Hereinafter, a DoCAN message that specifies SF is referred to as an SF message. The same applies to FF, CF, and FC.

[0031] If the DoIP data division number N is 1 (for example, if the DoIP data length is 7 bytes or less), the SF message is used. If the DoIP data division number N is 2 or more (that is, if the DoIP data length is 8 bytes or more), the FF message is used for the first DoCAN message, and a CF message is used for subsequent DoCAN messages.

[0032] The packaging processing 22 is processing for packaging one or more DoCAN messages generated by the protocol conversion processing 21 into a frame (hereinafter, packaged frame) of the third lower protocol (ie, TCP / UDP) and sending the packaged frame to the zone ECU 3. Specifically, for the SF message, the FF message, and the FC message, the central ECU 2 generates a packaged frame in which the DoCAN message is packaged alone. For the CF message, the central ECU 2 generates the packaged frames in which the CF message is packaged, as many as the data area of ​​the packaged frame allows, or generates a specified number of packaged frames. In other words, the packaged frame in which multiple CF messages are packaged can be generated from one DoIP message.

[0033] When the zone ECU 3 receives the packaged frame from the central ECU 2, the zone ECU 3 executes unpacking processing 31. The unpacking processing 31 is processing for unpacking one or more DoCAN messages packaged in the packaged frame to extract the messages and send the messages to the end ECU 4. The zone ECU 3 performs ID conversion for each of the extracted DoCAN messages to convert the PduID into the CAN ID and sends the message to the end ECU 4. When multiple CF messages are extracted, each CF message is sent in turn at a preset transmission interval.

[0034] When the zone ECU 3 receives the DoCAN message from the end ECU 4, the zone ECU 3 executes packaging processing 32. The packaging processing 32 is processing for packaging one or more DoCAN messages received from the end ECU 4 into a data area of ​​a packaged frame and transmitting the packaged frame to the central ECU 2. Specifically, when the received DoCAN message is the SF message, the FF message, or the FC message, the zone ECU 3 generates the packaged frame in which the DoCAN message is packaged alone. When the received DoCAN message is the CF message, or when a wait time has elapsed, or the number of received CF messages has reached an upper limit, the packaged frame in which all the CF messages received by the end ECU 4 during this time are packaged is generated.If a subsequent CF message is received during the wait time, the wait time can be updated or extended. In other words, CF messages received consecutively at intervals within the wait time can be packed within the range of the maximum data length that can be sent in a lower frame of the third lower protocol.

[0035] When the central ECU 2 receives the packaged frame from the zone ECU 3, it executes unpacking processing 23 and protocol conversion processing 24. The unpacking processing 23 is processing for extracting individual packaged DoCAN messages by unpacking the packaged frames.

[0036] The protocol conversion processing 24 is processing for converting the DoCAN message into the DoIP message. Specifically, when the extracted DoCAN message is the SF message, the central ECU 2 generates the DoIP message using the CAN data extracted from the SF message as DoIP data and sends the DoIP message to the external tool 5. When the extracted DoCAN message is the FF message or the CF message, the central ECU 2 sequentially stores the DoCAN data extracted from the FF message and the CF message in a message buffer. When a message sending condition is met, the central ECU 2 generates the DoIP message in which the CAN data stored in the message buffer is DoIP data, and sends the DoIP message to the external tool 5.The message sending condition may include a condition that an upper limit time has elapsed since the start of storing DoCAN data in the message buffer, and a condition that the data length of the CAN data stored in the message buffer has reached an upper limit of the TCP segment for sending the DoIP message.

[0037] Zone ECU 3 only packages and unpacks the DoCAN message and transmits it. DoCAN-related protocol processing between Zone ECU 3 and End ECU 4 is performed by Central ECU 2.

[0038] In the present embodiment, the central ECU 2 and the zone ECU 3 individually execute the above-described processing for each end ECU 4 identified by the DoIP header, CAN-ID / PdulD, N_AE, and the like. (1-4. Overall operation)(1-4-1. Communication from external tool to final ECU)

[0039] Next, an operation of the in-vehicle system 1 when the DoIP message is sent from the external tool 5 to the end ECU 4 will be explained with reference to a sequence diagram of Fig. 5 described.

[0040] At S10, the external tool 5 sends the DoIP message to the central ECU 2.

[0041] When the central ECU 2 receives the DoIP message, it splits the DoIP data at S11 to generate one or more DoCAN messages and stores the generated DoCAN messages in a transmit buffer. If the DoCAN message stored at the top of the transmit buffer is an SF or FF message, the central ECU 2 generates the encapsulated frame containing only the FF or SF message at S12 and sends the encapsulated frame to the zone ECU 3.

[0042] When Zone ECU 3 receives the packaged frame, it extracts the DoCAN message from the packaged frame at S13 and converts the PduID into the CAN ID. At S14, Zone ECU 3 sends the ID-converted DoCAN message to End ECU 4.

[0043] If the DoCAN message received by the zone ECU 3 is an FF message, the end ECU 4 generates the FC message and transmits the FC message to the zone ECU 3 at S15. Note that if the DoCAN message received by the zone ECU 3 is an SF message, there is no need to transmit the FC message. Therefore, the following description is given of the operation when the end ECU 4 receives the FF message.

[0044] When the zone ECU 3 receives the FC message from the end ECU 4, the zone ECU 3 generates the packaged frame containing only the FC message at S16. At S17, the zone ECU 3 sends the generated packaged frame to the central ECU 2.

[0045] When the central ECU 2 receives the packaged frame in which the FC message is packaged, the central ECU 2 generates the packaged frame in which one or more CF messages are packaged at S18.

[0046] At S19, the central ECU 2 sends the generated packaged frame to the zone ECU 3. When the zone ECU 3 receives the packaged frame, at S20 it extracts several CF messages from the packaged frame and converts the CAN ID of each CF message into a PduID.

[0047] At S21, the zone ECU 3 sends the ID-converted CF frames sequentially to the end ECU 4 at a set transmission interval. If a continuation transmission condition is satisfied, at S22, the center ECU 2 generates the wrapped frame through the same processing as at S18 and sends the generated wrapped frame to the zone ECU 3 as at S19. The continuation transmission condition may include a condition that CF remains in the transmission buffer despite the result that the wrapped frame was transmitted at the previous S19 and also a certain time has elapsed since the previous transmission of the wrapped frame.

[0048] The central ECU 2 repeatedly executes the processing of S22 until there are no more CF messages in the transmit buffer. The processing in the zone ECU 3 that receives this packaged frame is similar to the processing of S20 and S21 described above. (1-4-2. Communication from final ECU to external tool)

[0049] Next, an operation of the in-vehicle system 1 when the DoCAN message is sent from the end ECU 4 to the external tool 5 will be described with reference to a sequence diagram of Fig. 6 described.

[0050] When there is data to be sent to the external tool 5, the end ECU 4 divides the data into parts of a size that can be sent via a DoCAN message and generates the DoCAN message. If the divided transmission data can be sent in a single DoCAN message, the SF message is generated. If it is necessary to send the data in multiple DoCAN messages, the initial FF message and one or more subsequent CF messages are generated and stored in the transmission buffer.

[0051] At S30, the end ECU 4 sends the DoCAN message stored above in the transmission buffer, that is, the FF or SF message, to the zone ECU 3. When the zone ECU 3 receives the FF or SF message from the end ECU 4, the zone ECU 3 generates the packaged frame in which the FF or SF message alone is packaged at S31.

[0052] At S32, the zone ECU 3 sends the generated packaged frame to the central ECU 2. When the central ECU 2 receives the packaged frame from the zone ECU 3, it extracts the DoCAN message from the packaged frame at S33. If the extracted DoCAN message is the SF message, the central ECU 2 converts the DoCAN message into the DoIP message. Then, the central ECU 2 sends the DoIP message to the external tool 5 at S34, as indicated by the dashed arrow in Fig. 6 is specified.

[0053] If the extracted DoCAN message at the previous S33 is an FF message, the central ECU 2 starts generating DoIP data (i.e., restoring the transmission data) by storing the DoCAN data included in the FF message in a message buffer. Furthermore, the central ECU 2 generates the FC message, which is a response to the FF message, and generates the encapsulated frame in which the FC message alone is encapsulated.

[0054] At S35, the central ECU 2 sends the generated packaged frame to the zone ECU 3. When the zone ECU 3 receives the packaged frame from the central ECU 2, at S36 it extracts the FC message from the packaged frame and converts the PduID into the CAN ID.

[0055] At S37, the zone ECU 3 sends the ID-converted FC message to the end ECU 4. When the end ECU 4 receives the FC message from the zone ECU 3, at S38, it continuously sends the DoCAN message stored in the transmission buffer, that is, the CF message, to the zone ECU 3 at the set transmission interval.

[0056] When the zone ECU 3 receives the CF message from the end ECU 4, it waits until a frame transmission condition is met. If the frame transmission condition is met, at S39 it generates the packaged frame in which one or more CF messages received at that time are packaged. The frame transmission condition may include, for example, a condition that a wait time has elapsed since receiving the first CF frame and a condition that the total length of multiple received CF messages reaches the upper limit of the data length that can be transmitted in the packaged frame.

[0057] At S40, the zone ECU 3 sends the generated packaged frame to the central ECU 2. When the central ECU 2 receives the packaged frame from the zone ECU 3, the central ECU 2 extracts a plurality of CF messages from the packaged frame at S41. Furthermore, the central ECU 2 extracts DoCAN data contained in each of the plurality of CF messages and stores the data in a message buffer. If the message transmission condition is met, the central ECU 2 further generates a DoIP message that converts all DoCAN data stored in the message buffer into DoIP data.The message sending conditions may include a condition that the total data length of the data stored in the message buffer reaches an upper limit of the TCP segment for sending the DoIP message, and a condition that a predetermined time has elapsed since receiving an FF message or sending the previous DoIP message related to the FF message.

[0058] At S42, the central ECU 2 sends the DoIP message generated at S41 to the external tool 5. If the zone ECU 3 continues to receive CF messages from the end ECU 4 even after sending the packaged frame at the previous S40, the zone ECU 3 repeats the processing described at the previous S39 and S40. Accordingly, the central ECU 2 also repeats the processing described above at S41 and S42. (1-4-3. Control of transmission interval of CF message addressed to end ECU)

[0059] Next, an operation of the end ECU 4 in the in-vehicle system 1 when the end ECU 4 uses the FC message to control the reception interval of the CF message will be explained with reference to a sequence diagram of Fig. 7. Basically, the operation is the same as that shown in the sequence diagram of Fig. 5, so that the same processings and procedures are designated by the same reference numerals and the description thereof is omitted.

[0060] When the end ECU 4 receives the FF message from the zone ECU 3 at S14, the end ECU 4 sets an STmin parameter that specifies the transmission interval of the CF message in the FC message that the end ECU 4 sends to the zone ECU 3 at S15.

[0061] When the central ECU 2 receives the packaged frame in which the CF message is packaged via the zone ECU 3, it extracts the CF message from the packaged frame to generate a setting message at S181, and also generates the packaged frame in which one or more CF messages are packaged.

[0062] The setting message is a message that instructs the zone ECU 3 to set the CF message transmission interval according to the STmin parameter specified in the FC message. The central ECU 2 sends a setting message to the zone ECU 3 at S182. Afterward, when a sufficient time required for the setting message to be reflected in the zone ECU 3 has elapsed, the central ECU 2 sends the packaged frame containing one or more CF messages to the zone ECU 3 at S19.

[0063] When the zone ECU 3 receives the setting message from the central ECU 2, the zone ECU 3 sets the transmission interval to be used for transmitting the CF message according to the content of the setting message at S183. The set transmission interval is shown below as STmin.

[0064] When the zone ECU 3 receives the packaged frame in which one or more CF messages are packaged from the central ECU 2, it extracts the CF messages from the packaged frame at S21 and sequentially transmits the extracted one or more CF messages at the set transmission interval STmin at S211.

[0065] The initial value of STmin can be set arbitrarily. (1-4-4. Control of number of consecutive receptions of CF messages addressed to end ECU)

[0066] Next, an operation of the end ECU 4 in the in-vehicle system 1 when the end ECU 4 uses the FC message to control the number of consecutively received CF messages will be explained with reference to the sequence diagram of Fig. 8. Basically, the operation is the same as that shown in the sequence diagram of Fig. 5, so that the same processings and procedures are designated by the same reference numerals and the description thereof is omitted.

[0067] When the end ECU 4 receives the FF message from the zone ECU 3 at S14, the end ECU 4 sets a BS parameter that specifies the number of consecutive CF messages to be received in the FC message to be sent to the zone ECU 3 at S15. Here, a relationship of BS = 2 is set.

[0068] When the central ECU 2 receives a packaged frame enclosing the FC message via the zone ECU 3 at S17, the central ECU 2 extracts the FC message from the packaged frame at S184 and stores the value of the BS parameter specified in the FC message. The central ECU 2 then generates the packaged frame enclosing the number of CF messages specified by the BS parameter.

[0069] At S19, the central ECU 2 sends the packaged frame generated at S184 to the zone ECU 3. When the zone ECU 3 receives the packaged frame, it extracts the CF messages from the packaged frame at S20 and sends all extracted CF messages (i.e., two) in sequence at S212 to the end ECU 4.

[0070] When the end ECU 4 receives the number of CF messages specified by the BS parameter of the previously transmitted FC message, it sends the FC messages to the zone ECU 3 at S151. Here, it is assumed that the value of the BS parameter is changed to 3.

[0071] After that, the processing of S16, S17, S184, S19, S20, and S212 is the same. However, since BS is changed to 3, at S19, three CF messages are packaged into the packaged frame sent from the central ECU 2 to the zone ECU 3, and at S212, three CF messages are sequentially sent from the zone ECU 3 to the terminal ECU 4. In addition, the terminal ECU 4, which has received the three CF messages, sends the FC message to the zone ECU 3. Subsequently, the same processing is repeated. The initial values ​​of the BS parameters can be set arbitrarily. (1-5. Correspondence of concepts)

[0072] In the present embodiment, the central ECU 2 corresponds to a first relay device and a relay device of the present disclosure, the zone ECU 3 corresponds to a second relay device and a sub-relay device, the end ECU 4 corresponds to a second electronic device, and the external tool 5 corresponds to a first electronic device. In the present embodiment, the central ECU 2 that executes the protocol conversion processings 21 and 24 corresponds to a protocol conversion unit of the present disclosure, the central ECU 2 that executes the packing processing 22 corresponds to a first packing unit of the present disclosure, and the central ECU 2 that executes the unpacking processing 23 corresponds to a first unpacking unit of the present disclosure.In the present embodiment, the zone ECU 3 that executes the unpacking processing 31 corresponds to a second unpacking unit of the present disclosure, and the zone ECU 3 that executes the packing processing 32 corresponds to a second packing unit of the present disclosure. In the present embodiment, the second message packaged by the packing processings 22 and 32 corresponds to a combined message of the present disclosure. (1-6. Effects)

[0073] According to a first embodiment described above in detail, the following effects are achieved. (1a) In the in-vehicle system 1, the central ECU 2 performs protocol conversion between the DoIP message used for data exchange with the external tool 5 and the DoCAN message used for data exchange with the end ECU 4. Communication is performed between the central ECU 2 and the zone ECU 3, which uses a lower protocol with a faster communication speed than between the zone ECU 3 and the end ECU 4, using a packaged frame in which one or more DoCAN messages are packaged. Therefore, the in-vehicle system 1 can improve communication efficiency with respect to ECU diagnosis. (1b) The zone ECU 3 only packages and unpacks the DoCAN data, and the central ECU 2 performs processing according to the DoCAN protocol, such as deciding on control contents or allocating control contents using FC messages. Therefore, it is possible to easily configure the zone ECU 3. (2. Second Embodiment)(2-1. Difference from the First Embodiment)

[0074] The basic configuration of a second embodiment is similar to that of the first embodiment. The difference between them will be described below. The same reference numerals as in the first embodiment denote the same elements, and reference is made to the previous description.

[0075] In the first embodiment described above, the packaged frame is generated using the DoCAN message transmitted and received by one end ECU 4. In contrast, the second embodiment differs from the first embodiment in that the packaged frame is generated using the DoCAN message transmitted and received by different end ECUs 4. (2-2. Communication from external tool to multiple end ECUs)

[0076] The operation of the in-vehicle system 1 when the DoIP message is sent from the external tool 5 to a plurality of end ECUs 4 under the same zone ECU 3 will be explained with reference to the sequence diagram of Fig. 9. In the following description, a plurality of end ECUs 4 connected to the same zone ECU 3 are referred to as a target ECU group.

[0077] At S50, the external tool 5 sends several DoIP messages with different destinations to the central ECU 2. Here, a case is described in which all end ECUs 4 belong to the target ECU group.

[0078] At S51, the central ECU 2 executes the protocol conversion processing 21 for each received DoIP message to generate the DoCAN message and stores the DoCAN message in the transmission buffer provided for each destination end ECU 4.

[0079] When the FF message or SF message is stored above in a transmission buffer addressed to the destination ECU group, the central ECU 2 extracts the FF message or SF message and generates the packaged frame by packaging one or more of the collected FF messages or SF messages. Fig. 9 shows a case where FF messages are extracted from three end ECUs 4 identified as A, B and C belonging to the target ECU group.

[0080] At S52, the central ECU 2 sends the packaged frame to the zone ECU 3. When the zone ECU 3 receives the packaged frame from the central ECU 2, the zone ECU 3 extracts several FF messages from the packaged frame at S53 and converts the PduID of each FF frame into a CAN ID.

[0081] At S54, the zone ECU 3 sends each of the extracted FF messages to each of the end ECUs 4 that are destinations. When each end ECU 4 receives the FF message, it generates an FC message and sends it to the zone ECU 3 at S55.

[0082] When the zone ECU 3 receives the FC message, the zone ECU 3 generates the packaged frame at S56, which encapsulates all FC messages received during a predetermined waiting time. If another FC frame is received during the waiting time, the waiting time can be updated or extended.

[0083] At S57, the zone ECU 3 sends the packaged frame generated at S56 to the central ECU 2. When the central ECU 2 receives the packaged frame from the zone ECU 3, it extracts one or more FC frames from the packaged frame at S58. The central ECU 2 sequentially extracts CF frames from a transmission buffer associated with the extracted FC frame according to a predetermined extraction rule. When a frame transmission condition is met, the central ECU 2 generates the packaged frame in which all the extracted CF data are packaged. The frame transmission conditions are the same as those described in the first embodiment. The extraction rule may be, for example, to extract a specified number (e.g., two) of CF messages from all transmission buffers (hereinafter, the destination transmission buffer group) associated with the destination ECU group and in which CF messages are stored.Alternatively, the extraction rule may be to extract CF buffers one by one from the destination send buffer group and repeat this processing until the total length of the extracted CF messages reaches the upper limit data length.

[0084] At S59, the central ECU 2 sends the packaged frame generated at S58 to the zone ECU 3. When the zone ECU 3 receives the packaged frame, it extracts several CF messages from the packaged frame at S60 and converts the PduID into the CAN ID.

[0085] At S61, the extracted CF messages are sequentially transmitted to the end ECUs 4, which are the destinations. Thereafter, while the CF message remains in the transmission buffer of the central ECU 2, the processing from S58 to S61 is repeatedly executed each time the continuation transmission condition is met. (2-3. Communication from multiple end ECUs to external tools)

[0086] The operation of several end ECUs 4 under the control of the same zone ECU 3 in the in-vehicle system 1 when each of them sends a DoCAN message to the external tool 5 will be explained with reference to the sequence diagram of Fig. 10 described.

[0087] At S70, each end ECU 4 sends the FF message to each zone ECU 3.

[0088] When the zone ECU 3 receives an FF message from any of the end ECUs 4, the zone ECU 3 generates a packed frame at S71 by packing all FF frames received during a predetermined waiting time. If the zone ECU 3 receives another FF frame during the waiting time, the zone ECU 3 can update or extend the waiting time.

[0089] At S72, the zone ECU 3 sends the packaged frame generated at S71 to the central ECU 2. When the central ECU 2 receives the packaged frame from the zone ECU 3, the central ECU 2 extracts multiple FF messages from the packaged frame at S73. The central ECU 2 stores the DoCAN data contained in each extracted FF message in the message buffer provided for each end ECU 4 that is the transmission source of the FF message. Furthermore, the central ECU 2 generates the FC message in response to each FF message and generates the packaged frame in which all the generated FC messages are packaged.

[0090] At S74, the central ECU 2 sends the packaged frame generated at S73 to the zone ECU 3. When the zone ECU 3 receives the packaged frame from the central ECU 2, it extracts several FC frames from the packaged frame at S75.

[0091] At S76, the zone ECU 3 sends each FC frame to the end ECU 4, which is the destination.

[0092] When the end ECU 4 receives the FC message from the zone ECU 3, it starts sending the CF message at S77.

[0093] When the zone ECU 3 receives the CF message from the end ECU 4, it generates the packaged frame at S78, which packages all CF messages received from the end ECUs 4 belonging to the target ECU group until the transmission condition is met. The transmission condition may be that a predetermined waiting time has elapsed or that the total length of the received CF messages has reached the upper limit of the data length of the packaged frame. If another CF message is received during the waiting time, the waiting time may be updated or extended.

[0094] At S79, the zone ECU 3 transmits the packaged frame generated at S78 to the central ECU 2. When the central ECU 2 receives the packaged frame from the zone ECU 3, at S80, it extracts multiple CF frames from the packaged frame and stores the DoCAN data included in each CF frame in a message buffer prepared for each end ECU 4 that is the transmission source of the packaged frame. Further, the central ECU 2 determines for each message buffer whether a message transmission condition is satisfied. If the message transmission condition is satisfied, the central ECU 2 generates the DoIP message that treats the DoCAN data stored in the message buffer as DoIP data. The message transmission conditions are the same as those described in the first embodiment.

[0095] At S81, the central ECU 2 sends the DoIP message generated at S80 to the external tool 5. Thereafter, as long as the CF message remains in the message buffer, the processings from S80 to S81 are repeatedly executed each time the continuation sending condition is satisfied. (2-4. Effects)

[0096] According to the second embodiment described above in detail, in addition to the effects (1a) and (1b) of the first embodiment described above, the following effects are also obtained.

[0097] (2a) In the present embodiment, the packaging of DoCAN messages is not performed for each end ECU 4, but DoCAN messages regarding a plurality of end ECUs 4 connected to the same zone ECU 3 are packaged into a packaged frame.

[0098] Therefore, it is possible to further improve the efficiency of diagnostic communication. (3. Further embodiments)

[0099] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and various modifications may be made to implement the present disclosure.

[0100] (3a) In the above embodiment, the central ECU 2 checks the settings of the BS parameter and the STmin parameter included in the FC message and performs the necessary processing. For example, the zone ECU 3, instead of the central ECU 2, may check the contents of the FC message before executing the packaging processing 32 and perform the necessary processing without passing through the central ECU 2.

[0101] (3b) In the above embodiment, an example was shown in which Ethernet is used as the third lower protocol and CAN is used as the second lower protocol. However, the third lower protocol only needs to have a faster communication speed than the second lower protocol. For example, when CAN is used as the second lower protocol, CAN FD, CAN XL, or Ethernet and IEEE 1722 and the like can be used as the third lower protocol. When Ethernet or CAN XL is used as the third lower protocol, CAN FD can additionally be used as the second lower protocol. CAN FD is an abbreviation for CAN with Flexible Data Rate. CAN XL is an abbreviation for CAN with Extended Length. IEEE 1722 is a transport protocol for time-sensitive applications. The data length of one frame is a maximum of 64 bytes for CAN FD and a maximum of 2048 bytes for CAN XL.

[0102] (3c) The ECUs 2 to 4 and the methods described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor and a memory programmed to perform one or more functions embodied by a computer program. Alternatively, the ECUs 2 to 4 and the methods described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits.Alternatively, the ECUs 2 to 4 and the methods described in the present disclosure may be implemented by one or more dedicated computers configured by combinations of processors and memories programmed to perform one or more functions, and processors configured by one or more hardware logic circuits. The computer program may be stored in a computer-readable non-transitory physical storage medium as instructions to be executed by a computer. The method for implementing the functions of the respective units included in the ECUs 2 to 4 does not necessarily have to involve software, and all of the functions may be implemented using one or more pieces of hardware.

[0103] (3d) The multiple functions of one component in the above embodiment may be implemented by multiple components, or one function of one component may be implemented by multiple components. In addition, multiple functions of multiple components may be implemented by one component, or a single function implemented by multiple components may be implemented by one component. Part of the configuration of the above-described embodiment may be omitted. At least part of the configuration in one embodiment may be added to or replaced by the configuration of another embodiment.

[0104] (3e) In addition to the relay system constituted by the central ECU 2 as the first relay device and the zone ECU 3 as the second relay device described above, the present disclosure can also be implemented in various forms such as a program for causing a computer to function as a relay system, a non-volatile physical storage medium such as a semiconductor memory on which this program is recorded, and a relay method. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] JP 2022-91585 A

[0004]

Claims

[1] A relay system for relaying communication between a first electronic device (5) and a second electronic device (4), the system comprising: a first relay device (2) which is connected to the first electronic device by a first lower protocol, configured to send and receive data to and from the first electronic device using a first higher protocol, and configured to send and receive data to and from the second electronic device using a second higher-level protocol; and a second relay device (3) which is connected to the second electronic device by a second lower protocol, and is connected to the first relay device by a third lower protocol using a frame with a longer payload than the second lower protocol, where the first relay device includes: a protocol conversion unit (21, 24) configured to perform a mutual conversion between a first message using the first higher protocol and the first lower protocol and a second message using the second higher protocol and the second lower protocol, the first message being sent to and received by the first electronic device; a first packaging unit (22) configured to send a combined message obtained by combining at least a second message supplied from the protocol conversion unit to the second relay device through the third lower protocol; and a first unpacking unit (23) configured to extract the at least one second message from the combined message received by the second relay device through the third lower protocol, and to feed the extracted second message to the protocol conversion unit, and the second relay device includes: a second packaging unit (32) configured to send the combined message obtained by combining the at least one second message received from the second electronic device to the first relay device through the third lower protocol; and a second unpacking unit (31) configured to individually send to the second electronic device the at least one second message obtained by unpacking the combined message received from the first relay device through the third lower protocol. [2] Relay system according to claim 1, wherein the first higher protocol is Diagnostics over Internet Protocol (DoIP), and the second higher protocol is Diagnostic Communication over Controller Area Network (DoCAN). [3] Relay system according to claim 1 or claim 2, wherein the first lower protocol is Ethernet (registered trademark), the second lower protocol is Control Area Network (CAN, registered trademark) or CAN FD, and the third lower protocol of one of CAN Flexible Data Rate (FD), CAN Extended Length (XL), Ethernet and Interaction Layer Protocol Data Unit Multiplexer (IPduM) of Automotive Open System Architecture (AUTOSAR) and Ethernet and IEEE (registered trademark) 1722. [4] The relay system according to any one of claims 1 to 3, wherein the first packaging unit and the second packaging unit are configured to determine whether the second message needs to be combined according to identification information identifying a type of the second message. [5] The relay system according to any one of claims 1 to 4, wherein the second unpacking unit is configured to change a transmission interval used when transmitting a plurality of recovered second messages to the second electronic device based on information transmitted from the first relay device. [6] The relay system according to any one of claims 1 to 5, wherein the second packaging unit is configured to execute transmission to the first relay device when a condition that a total length of the combined second message reaches an upper limit and / or a condition that a certain time has elapsed since a previous transmission is satisfied. [7] A relay device configuring a relay system for relaying communication between a first electronic device and a second electronic device together with a sub-relay device connected to the first electronic device by a first lower protocol and to the second electronic device by a second lower protocol, the relay device comprising: a protocol conversion unit configured to perform a mutual conversion between a first message using a first higher protocol and the first lower protocol and a second message using a second higher protocol and the second lower protocol, the first message being sent to and received by the first electronic device; a first packaging unit configured to send a combined message obtained by combining at least a second message supplied from the protocol conversion unit to the sub-relay device through a third lower protocol using a frame with a longer payload than the second lower protocol; and a first unpacking unit configured to extract the at least one second message from the combined message received by a second relay device through the third lower protocol, and to supply the at least one extracted second message to the protocol conversion unit. [8] Program that causes a computer to function as: a first relay device which connected to a first electronic device by a first lower protocol, configured to send and receive data to and from the first electronic device using a first higher-level protocol, and configured to send and receive data to and from a second electronic device using a second higher-level protocol; and a second relay device which is connected to the second electronic device by a second lower protocol, and is connected to the first relay device by a third lower protocol that uses a frame with a longer payload than the second lower protocol, and together with the first relay device forms a relay system for forwarding communication between the first electronic device and the second electronic device, where the first relay device includes: a protocol conversion unit configured to perform mutual conversion between a first message using the first higher protocol and the first lower protocol and a second message using the second higher protocol and the second lower protocol, the first message being sent to and received by the first electronic device; a first packaging unit configured to send a combined message obtained by combining at least one second message supplied from the protocol conversion unit to the second relay device through the third lower protocol; and a first unpacking unit configured to extract the at least one second message from the combined message received by the second relay device through the third lower protocol, and to feed the extracted second message to the protocol conversion unit, and the second relay device includes: a second packaging unit configured to send the combined message obtained by combining the at least one second message received from the second electronic device to the first relay device through the third lower protocol; and a second unpacking unit configured to individually send to the second electronic device the at least one second message obtained by unpacking the combined message received from the first relay device through the third lower protocol.

Citation Information

Patent Citations

  • Relay device for vehicle communication, relay method for vehicle communication and program

    JP2022091585A