Communication system and communication device

Abstract

According to the present invention, in a first mode, a transmitting side communication device uses a first communication path to transmit first data designated to use a first communication protocol, and uses a second communication path to transmit second data designated to use a second communication protocol. In a second mode, at least a portion of the first data is protocol-converted from the first communication protocol to the second communication protocol and is transmitted using the second communication path. Upon receiving a protocol-converted communication frame via the second communication path, a receiving side communication device converts the protocol to the first communication protocol and executes processing in accordance with the first communication protocol.

Description

Communication System and Communication Device Cross - reference to Related Applications

[0001] This international application claims the benefit of Japanese Patent Application No. 2024 - 191833, filed with the Japan Patent Office on October 31, 2024, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates to a technique for performing communication between electronic control devices connected by a plurality of networks.

[0003] Patent Document 1 below describes a technique for providing redundancy in a network by using two physical transmission channels connecting network devices as one logical transmission channel with a high transmission rate or two logical transmission channels with a low transmission rate.

[0004] Japanese Patent Application Laid - Open No. 2015 - 050775

[0005] However, as a result of the inventors' detailed examination, it has been found that the conventional technique has a problem that it cannot be applied to a network that fixedly uses a communication protocol for each physical transmission channel.

[0006] One aspect of the present disclosure provides a technique for redundantizing a network in a communication system that uses a plurality of networks with different communication protocols.

[0007] One embodiment of the present disclosure is a communication system including a first communication path, a second communication path, a transmission - side communication device, and a reception - side communication device. The transmission - side communication device and the reception - side communication device are connected via the first communication path and the second communication path. The first communication path is a physical communication path that performs data transmission according to a first communication protocol. The second communication path is a physical communication path that performs data transmission according to a second communication protocol.

[0008] The transmitting communication device switches the transmission mode, which represents the method of data transmission using the first and second communication paths, to either the first mode or the second mode, depending on the status of the first communication path. In the first mode, the transmitting device transmits first data, which is specified to use the first communication protocol, using the first communication path. The transmitting device also transmits second data, which is specified to use the second communication protocol, using the second communication path. Furthermore, in the second mode, the transmitting communication device performs protocol conversion on at least a portion of the first data, from the first communication protocol to the second communication protocol, and transmits it using the second communication path.

[0009] When the receiving communication device receives a communication frame via the first communication path, it performs processing according to the first communication protocol. Furthermore, when the receiving communication device receives a communication frame that has not been protocol-converted via the second communication path, it performs processing according to the second communication protocol. Additionally, when the receiving communication device receives a protocol-converted communication frame via the second communication path, it performs protocol conversion to the first communication protocol and then performs processing according to the first communication protocol.

[0010] With this configuration, under normal circumstances, setting to the first mode allows the first data to be transmitted using the first communication path, while the second data is transmitted using the second communication path. Furthermore, if the first communication path is interrupted or becomes congested, setting to the second mode allows at least a portion of the first data to be protocol-converted and transmitted using the second communication path. Therefore, the network connecting the transmitting and receiving communication devices can be made redundant, improving network reliability and mitigating the effects of congestion.

[0011] One aspect of the present disclosure is a communication device comprising a first communication unit, a second communication unit, a mode switching unit, and a transmission processing unit.

[0012] The first communication unit is configured to transmit data using a first communication protocol via a physical first communication path. The second communication unit is configured to transmit data using a second communication protocol via a physical second communication path. The mode switching unit is configured to switch the transmission mode, which represents the method of data transmission using the first and second communication paths, between the first mode and the second mode depending on the status of the first communication path. In the first mode, the transmission processing unit is configured to transmit first data, which is specified to use the first communication protocol, using the first communication path, and second data, which is specified to use the second communication protocol, using the second communication path. In the second mode, the transmission processing unit is configured to perform protocol conversion on at least a portion of the first data from the first communication protocol to the second communication protocol and transmit it using the second communication path.

[0013] With this configuration, it can be used as a transmitting communication device in a communication system, which is one aspect of the present disclosure described above.

[0014] One aspect of the present disclosure is a communication device comprising a first communication unit, a second communication unit, and a receiving processing unit. The first communication unit is configured to perform data transmission according to a first communication protocol via a physical first communication path. The second communication unit is configured to perform data transmission according to a second communication protocol via a physical second communication path. The receiving processing unit is configured to perform processing according to the first communication protocol when it receives a communication frame via the first communication path. Furthermore, the receiving processing unit is configured to perform processing according to the second communication protocol when it receives a communication frame that has been protocol converted via the second communication path. In addition, the receiving processing unit is configured to perform protocol conversion to the first communication protocol and processing according to the first communication protocol when it receives a protocol converted communication frame via the second communication path.

[0015] With this configuration, it can be used as a receiving communication device in a communication system, which is one aspect of the present disclosure described above.

[0016] This is a block diagram showing the configuration of an in-vehicle system. This is an explanatory diagram illustrating the contents of a route map. This is a flowchart of the map update process performed by the route determination unit. This is an explanatory diagram showing the structure of an Ethernet frame encapsulating a CAN packet. This is an explanatory diagram showing the structure of a CAN frame encapsulating a TCP packet. This is a sequence diagram showing the operation of each part in the transmitting ECU. This is a sequence diagram showing the operation of each part in the receiving ECU that receives a CAN over Ethernet frame. This is a sequence diagram showing the operation of each part in the receiving ECU that receives an Ethernet over CAN frame. This is a sequence diagram showing the operation related to updating the route map.

[0017] Embodiments of this disclosure will be described below with reference to the drawings.

[0018] [1. Configuration] The in-vehicle system 1 of this embodiment, shown in Figure 1, is mounted on a vehicle. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as the driving source. The vehicle is not limited to a vehicle with an automatic driving function or a hybrid vehicle; it may be a vehicle with only a manual driving function, or a vehicle having only an engine or only an electric motor as the driving source. Hereinafter, a vehicle on which the in-vehicle system 1 is mounted will simply be referred to as a vehicle.

[0019] The in-vehicle system 1 includes a plurality of electronic control units (hereinafter referred to as ECUs) 10. ECU stands for Electronic Control Unit.

[0020] Each ECU 10 is connected via multiple communication networks. These communication networks may include Ethernet (hereinafter referred to as Ethernet) and CAN. Ethernet is a registered trademark. CAN stands for Controller Area Network.

[0021] In Figure 1, for simplicity, the first ECU 10 (hereinafter referred to as ECU-A) and the second ECU 10 (hereinafter referred to as ECU-B), which constitute the in-vehicle system 1, are shown connected via Ethernet and CAN.

[0022] The ECU 10 has a microcomputer equipped with a CPU, ROM, RAM, etc. The various functions of the microcomputer are realized by the CPU executing a program stored in a non-transitional physical recording medium. In this example, the ROM corresponds to the non-transitional physical recording medium that stores the program. Furthermore, the execution of this program realizes a method corresponding to the program. Note that some or all of the functions performed by the CPU may be configured in hardware by one or more ICs, etc. Also, the number of microcomputers constituting the ECU may be one or more.

[0023] [2. Functional Configuration] The ECU 10 comprises, as functional blocks, a service execution unit 11, an application / vehicle control unit 12, an API 13, a route control unit 14, a protocol conversion unit 15, and a communication control unit 16.

[0024] The service execution unit 11 provides various services without going through the API 13 by executing a program that is originally built into the ECU 10.

[0025] The application / vehicle control unit 12 executes an application program (hereinafter referred to as "app") that utilizes the functions provided by the API 13, thereby realizing data collection and vehicle control, etc., in accordance with the purpose of the app creator.

[0026] API 13 is an interface for the application / vehicle control unit 12 to utilize functions provided by the vehicle. API 13 provides at least the function of exchanging information through communication with other ECUs 10.

[0027] The communication control unit 16 includes an Ethernet communication unit 31 and a CAN communication unit 32.

[0028] The Ethernet communication unit 31 includes a transceiver (hereinafter referred to as PHY) that implements the physical layer of Ethernet and a controller (hereinafter referred to as MAC) that implements the MAC layer. The Ethernet communication unit 31 performs processing to realize data transmission in accordance with the Ethernet protocol for communication frames transmitted and received via Ethernet. PHY is an abbreviation for Physical, and MAC is an abbreviation for Media Access Control.

[0029] The CAN communication unit 32 includes a CAN transceiver and a CAN controller, and performs processing to realize data transmission in accordance with the CAN protocol for communication frames transmitted and received via CAN. The CAN communication unit 32 also supports multi-frame transmission protocols (e.g., ISO 15765-2) that transmit long messages using multiple CAN frames.

[0030] The route control unit 14 includes a communication monitoring unit 21, a route determination unit 22, and a route map 23.

[0031] The route map 23 is a table that shows information such as the standard route used under normal circumstances and the temporary route used when there is an abnormality in the standard route, associated with each type of information transmitted and received via the communication control unit 16.

[0032] As shown in Figure 2, the route map 23 includes items such as "Information Name," "Route Category," "Priority Category," "Standard Route," and "Temporary Route."

[0033] The "Information Name" field lists the names of information (hereinafter referred to as parameters) that are transmitted and received between ECUs 10 via the communication network, such as control vehicle speed, vehicle speed exceeding limit, camera malfunction status, brake correction value, S / W configuration information, and microphone audio.

[0034] The "routing category" indicates whether the parameter specified by the "information name" is transmitted using the standard route or the provisional route. The initial value of the "routing category" is set to "standard," indicating the use of the standard route, and is updated as needed by the communication monitoring unit 21.

[0035] The "priority classification" indicates the priority of each parameter in transmission using the standard route. When the standard route is CAN, the priority classification is represented as CAN-1, CAN-2, ..., and when the standard route is Ether, the priority classification is represented as Ether-1, Ether-2, ... Furthermore, a smaller number in the priority classification indicates a higher priority. For example, if the standard route is congested, this information is referenced when switching to transmission via an interim route in stages, starting with the parameters with the lowest priority.

[0036] The reason why higher-priority parameters are prioritized for transmission via the standard route is as follows: Each parameter is designed to meet the specifications of the standard route (e.g., communication speed, reachability, acceptable communication delay, etc.), and therefore, the more important a parameter is, the more likely it is that the standard route should be used.

[0037] Parameters whose "Priority Classification" is set to Unavailable indicate that transmission will not be performed via the temporary route; in other words, they will not be included in the redundancy of the communication path. This is because, in the case of large data such as voice and video information, switching communication paths could disrupt the system balance, and switching to a particularly slow temporary route could render the application unusable. This is to avoid such situations. Also, if the data size of a parameter whose standard path is Ethernet exceeds the maximum data size that can be transmitted in CAN multi-frame mode, switching to the temporary route will result in a transmission error. Therefore, parameters that result in such transmission errors may also have their "Priority Classification" set to Unavailable.

[0038] Prioritization may be set according to the following considerations. For example, information related to dynamic systems (i.e., control systems related to driving, turning, and stopping) may be given a high priority. Also, information related to OTA may be given a high priority because the reliability and immediate effectiveness of patching are necessary when a software bug occurs. OTA stands for Over The Air. In addition, information with large data volumes, such as video, images, and audio, where communication delays significantly affect service quality, may be given a high priority.

[0039] The priority hierarchy can be arbitrarily designed, taking into account the trade-off between the efficiency of congestion suppression and the increased communication load on the temporary path. For example, there may be three levels (upper, middle, and lower) or two levels (high and low).

[0040] The "standard route" is a set of information about the standard route used when the "route classification" is set to standard.

[0041] "Provisional routes" are a set of information about provisional routes used when the "route classification" is set to provisional.

[0042] Both "Standard Route" and "Provisional Route" include items such as "Line Classification," "CANID," "Destination IP Address," and "Destination Port Number."

[0043] The "Track Classification" will be set to either CAN or Ether. Note that the "Track Classification" for the "Standard Route" and the "Track Classification" for the "Temporary Route" must be set to different values. However, if the "Priority Classification" is Unavailable, all items, including the "Track Classification" for the "Temporary Route," will be set to Null, indicating that no specification is given.

[0044] "CAN ID" is set when the "line segment" is CAN, and Null is set when the "line segment" is Ether. Also, for the value of "CAN ID", in the "standard route", the CAN ID (hereinafter, normal CID) defined in association with the parameter is used, and in the "provisional route", a specific CAN ID (hereinafter, specific CID) defined so as not to overlap with the normal CID is used. The specific CID is defined in association with the IP address or Port number used in the Ether frame so that the destination ECU can be specified. Also, the specific CID is used for the purpose of indicating that the CAN frame requires protocol conversion processing.

[0045] "Destination IP address" and "destination Port number" are set when the "line segment" is Ether, and Null is set when the "line segment" is CAN. Also, for the "destination Port number", in the "standard route", the Port number defined in association with each application is used, and in the "provisional route", a specific Port number (for example, 8000) indicating that protocol conversion processing is necessary is used. Note that the destination IP address may be a multicast IP address or a broadcast IP address.

[0046] The communication monitoring unit 21 monitors CAN and Ether, which are in-vehicle networks to which the own ECU 10 is connected, and generates communication status information representing the communication status. The communication status information may include information indicating the presence or absence of communication path interruption and the congestion status of the communication bandwidth (that is, the presence or absence or degree of congestion).

[0047] When the monitoring target is Ether, the communication monitoring unit 21 may determine, by the Ether communication unit 31, that the state in which link down is detected is a communication path interruption. Link down may include a state where signals cannot be physically transmitted and received (that is, interruption at the physical layer level) and a state where signals are passing through but frame transmission and reception are impossible. Also, the communication monitoring unit 21 may determine that the state where there is no response from the communication partner even when the number of TCP retries detected by the Ether communication unit 31 reaches the threshold value (for example, 4 times) is congestion.

[0048] If the monitored target is a CAN bus, the communication monitoring unit 21 may determine that a state in which a bus off is detected by the CAN communication unit 32 is a communication path interruption. The communication monitoring unit 21 may also determine that a state in which the amount of communication data (i.e., bus load) detected by the CAN communication unit 32 exceeds a threshold (for example, 40% of the maximum data transfer rate) is congestion.

[0049] Furthermore, the communication monitoring unit 21 may determine that congestion occurs if the turnaround time or round trip time measured by the application executed by the application / vehicle control unit 12 exceeds a threshold (for example, 100 ms), regardless of whether the monitored target is Ethernet or CAN. In addition, the communication monitoring unit 21 may determine not only whether congestion occurs but also the degree of congestion from the turnaround time and round trip time.

[0050] The communication monitoring unit 21 executes a map update process to update the setting value of the "route classification" in the route map 23 according to the communication status information separately generated by the communication monitoring unit 21.

[0051] The map update process performed by the communication monitoring unit 21 will be explained using the flowchart in Figure 3.

[0052] The map update process is executed repeatedly while ECU10 is running.

[0053] In S110, the communication monitoring unit 21 determines, based on the communication status information, whether or not a line in a state of communication interruption (hereinafter referred to as an interrupted line) has been detected. If the communication monitoring unit 21 determines that an interrupted line has been detected, it proceeds to S120; if it determines that no interrupted line has been detected, it proceeds to S150.

[0054] In S120, the communication monitoring unit 21 refers to the route map 23 and provisionally changes the route classification of all parameters to a standard route, with the disconnected route being the standard route.

[0055] In S130, the communication monitoring unit 21 determines whether the disconnection state of the disconnected line has been resolved based on the communication status information. If the disconnection state has been resolved, it proceeds to S140. If the disconnection state has not been resolved, it waits by repeating the same step.

[0056] In S140, the communication monitoring unit 21 refers to the route map 23 and, for all parameters where the line classification is set to provisional, returns the line classification from provisional to standard and returns the process to S110.

[0057] In S150, the communication monitoring unit 21 determines whether or not a congested line (hereinafter referred to as a congested line) has been detected based on the communication status information. If no congested line is detected, the process returns to S110. If a congested line is detected, the process proceeds to S160.

[0058] In S160, the communication monitoring unit 21 refers to the route map 23 and provisionally changes the line classification of the parameters with lower priority (i.e., CAN-2 or Ether-2) among the parameters that designate a congested line as a standard line.

[0059] In S170, the communication monitoring unit 21 determines whether the congestion on the congested line has been resolved based on the communication status information. If the congestion has been resolved, the process moves to S140; otherwise, the process moves to S180. The determination of whether the congestion has been resolved may be made, for example, by checking if the parameter used to determine the congestion state (e.g., TCP retry count, bus load, etc.) becomes smaller than a threshold value set to be smaller than the threshold used to determine if a congestion state exists.

[0060] In S180, the communication monitoring unit 21 determines whether the response enhancement conditions are met based on the communication status information. The response enhancement conditions may include, for example, that the congestion state has continued for a certain period of time or longer, and that the degree of congestion is large. If the communication monitoring unit 21 determines that the response enhancement conditions are met, it proceeds to S190; if it determines that the response enhancement conditions are not met, it returns to S170.

[0061] In S190, the communication monitoring unit 21 refers to the route map 23 and provisionally changes the line classification of the parameter with the highest priority (i.e., CAN-1 or Ether-1) among the parameters that designate a congested line as a standard line.

[0062] In S200, the communication monitoring unit 21 determines whether the congestion on the congested line has been resolved based on the communication status information. If the congestion has been resolved, it proceeds to S210. If the congestion has not been resolved, it waits by repeating the same step. The determination of whether the congestion has been resolved in this step may be made under the same conditions as the determination in S170, or it may be made under different conditions than the determination in S170.

[0063] In S210, the communication monitoring unit 21 changes the line classification of high-priority parameters whose line classification is currently set to provisional from provisional to standard, and returns the process to S170.

[0064] Returning to Figure 1, the route determination unit 22 refers to the route map 23 and determines whether to use the standard route or the provisional route for transmitting parameters via the communication control unit 16, and whether or not protocol conversion processing is necessary for the communication frames received via the communication control unit 16.

[0065] The protocol conversion unit 15 transmits and receives communication frames, and encapsulates and deencapsulates communication frames, according to the decision made by the route determination unit 22.

[0066] For a message that is the subject of an information request via API 13, if the route classification shown in the route map 23 is standard, the protocol conversion unit 15 creates and transmits a communication frame to be used on the standard route. In other words, if the route classification of the standard line is Ethernet, the protocol conversion unit 15 generates an Ethernet frame using the destination IP address and destination port number of the standard line shown in the route map 23. The protocol conversion unit 15 then supplies the generated Ethernet frame to the Ethernet communication unit 31 to perform communication according to the Ethernet protocol. If the route classification of the standard line is CAN, the protocol conversion unit 15 generates a CAN frame using the normal CID of the standard line shown in the route map 23 and supplies it to the CAN communication unit 32 to perform communication according to the CAN protocol.

[0067] If the routing classification shown in the routing map 23 is provisional for a message that is the subject of an information request via API 13, the protocol conversion unit 15 generates a packet consisting of the main parts of a communication frame used for the standard route. Furthermore, the protocol conversion unit 15 transmits the generated packet by placing it in a communication frame used for the provisional route.

[0068] Specifically, if the standard route's line classification is CAN and the provisional route's line classification is Ethernet, the protocol conversion unit 15 generates an Ethernet frame (hereinafter also referred to as a CAN over Ethernet frame) as shown in Figure 4.

[0069] In other words, the protocol conversion unit 15 generates a CAN packet that combines the CANID (i.e., the usual CID) of the standard route extracted from the route map 23 and a DataField representing the instructions from the API 13, according to the parameters specified in the API 13. The DataField may also contain information for multi-frame transmission. The protocol conversion unit 15 then generates an Ethernet frame in which this CAN packet is embedded in the TCP payload (i.e., encapsulated). At this time, the IP header and TCP header of the Ethernet frame are set with the destination IP address and destination Port number (i.e., specific Port number) of the provisional route extracted from the route map 23. The source MAC address and destination MAC address are assigned according to the usual address resolution procedure that forms the ARP table.

[0070] In the above explanation, considering transmission efficiency, the CAN packet to be encapsulated is usually composed of a CID and DataField containing the minimum necessary information. However, the entire CAN frame may also be treated as a CAN packet and targeted for encapsulation.

[0071] Furthermore, if the line classification of the standard route is Ether and the line classification of the provisional route is CAN, the protocol conversion unit 15 generates a CAN frame (hereinafter also referred to as an Ether over CAN frame) as shown in Figure 5.

[0072] In other words, the protocol conversion unit 15 generates a TCP packet that combines the TCP header and the TCP payload according to the parameters specified in the API 13. The TCP header is generated using the destination Port number on the standard route extracted from the routing map 23. The TCP payload represents the instructions from the API 13. The protocol conversion unit 15 then generates a CAN frame in which this TCP packet is embedded in the Datafield (i.e., encapsulated). At this time, the CANID of the CAN frame is set to the CANID of the provisional route shown in the routing map 23 (i.e., the specific CID). In addition to the TCP packet, the DataField of the CAN frame may also contain information for multi-frame transmission.

[0073] In the above explanation, TCP packets containing only the minimum necessary information are targeted for encapsulation to optimize transmission efficiency; however, IP packets or entire Ethernet frames may also be targeted for encapsulation.

[0074] Next, we will explain the overview of the processing performed by the receiving ECU 10 after it receives the communication frame.

[0075] When the Ethernet communication unit 31 receives an Ethernet frame from another ECU 10, it uses the information in the Ethernet header, IP header, and TCP header to perform processing according to the Ethernet protocol. If the TCP header contains a normal Port number, the Ethernet communication unit 31 forwards the TCP payload data to the application via the service or API 13 associated with the Port number. If the TCP header contains a specific Port number, the Ethernet communication unit 31 provides the TCP payload data to the protocol conversion unit 15. The protocol conversion unit 15 extracts (i.e., deencapsulates) the CAN packets embedded in the TCP payload and provides them to the CAN communication unit 32. The CAN communication unit 32 performs processing according to the CAN protocol based on the information shown in the extracted CAN packets and returns the result to the protocol conversion unit 15. The protocol conversion unit 15 forwards the data indicated in the DataField of the CAN packet to the application or the like that is associated with the normal CID indicated in the CAN packet.

[0076] When the CAN communication unit 32 receives a CAN frame from another ECU 10, it uses information such as the CANID and ControlField to perform processing according to the CAN protocol. If the CANID is a normal CID, the CAN communication unit 32 forwards the data shown in DataField to the application or other device associated with the normal CID. If the CANID is a specific CID, the CAN communication unit 32 provides DataField to the protocol conversion unit 15. The protocol conversion unit 15 extracts (i.e., deencapsulates) the TCP packets embedded in DataField and provides them to the Ethernet communication unit 31. Based on the information shown in the extracted TCP packets, the Ethernet communication unit 31 performs processing according to the Ethernet protocol. Then, if the destination port number indicated in the TCP packet is a normal port, the Ethernet communication unit 31 forwards the data indicated in the TCP payload of the TCP packet to the appropriate application, etc., based on the destination port number and source port number indicated in the TCP header. Also, if the destination port number indicated in the TCP packet is a specific port, the Ethernet communication unit 31 provides the TCP packet to the protocol conversion unit 15.

[0077] The protocol conversion unit 15 may also establish its own Ethernet port to which a specific port number is assigned, and use the established Ethernet port to perform communication between functional blocks within the ECU using its own communication sequence (for example, HTTP / 2).

[0078] [3. Sequence] Next, the operation of each part of the ECU 10 when the route division is set to a provisional value will be explained using the sequence diagrams shown in Figures 6 to 8.

[0079] [3-1. Transmitter-side sequence] First, the sequence of the transmitter-side ECU 10 that transmits the communication frame will be explained using Figure 6.

[0080] In S1, the application / vehicle control unit 12 makes an information request using the API 13. The information request specifies "request information" which represents the information to be requested (i.e., parameters). The "request information" is associated with the parameters shown in the "information name" of the route map 23.

[0081] When API 13 receives an information request, it forwards the received information request to the route determination unit 22 in S2.

[0082] In S3, the route determination unit 22 obtains information from the route map 23 that corresponds to the "request information" (i.e., parameters) indicated by the information request.

[0083] In S4, the route determination unit 22 sends a transmission request to the protocol conversion unit 15 that includes the information obtained from the route map 23 and the "request information".

[0084] If the standard route is CAN and the provisional route is Ether, that is, if a CAN over Ether frame is used, follow the steps in S5 to S6. If the standard route is Ether and the provisional route is CAN, that is, if a TCP over CAN frame is used, follow the steps in S7 to S8.

[0085] When using CAN over Ethernet frames, the protocol conversion unit 15 generates a CAN packet in S5 based on the information of the standard route (i.e., CAN). Furthermore, the protocol conversion unit 15 generates a CAN over Ethernet frame that encapsulates the CAN packet using the information of the provisional route (i.e., Ethernet).

[0086] In step S6, the protocol conversion unit 15 transmits the generated CAN over Ethernet frame to the ECU 10, which is identified by the destination IP address, via the Ethernet communication unit 31.

[0087] When using TCP over CAN frames, the protocol conversion unit 15 generates a TCP packet in S7 based on the information of the standard route (i.e., Ethernet). Furthermore, the protocol conversion unit 15 generates an Ethernet over CAN frame that encapsulates the TCP packet using the information of the provisional route (i.e., CAN).

[0088] In step S8, the protocol conversion unit 15 transmits the generated Ethernet over CAN frame to the ECU 10, which is identified by the CANID, via the CAN communication unit 32.

[0089] Furthermore, when transmitting parameters specified in the standard routing classification, S5 generates a normal Ethernet frame in which CAN information is not packetized, and S7 generates a normal CAN frame in which Ethernet information is not packetized.

[0090] [3-2. Receiving Side Sequence] Next, we will explain using the sequence of the receiving side ECU 10 that receives the communication frame.

[0091] First, the procedure when the Ethernet communication unit 31 receives a CAN over Ethernet frame will be explained using Figure 7.

[0092] First, we will explain the case when the Ethernet communication unit 31 receives a CAN over Ethernet frame.

[0093] When the Ethernet communication unit 31 receives an Ethernet frame, in S21 it performs reception processing according to the Ethernet protocol and forwards it to the protocol conversion unit 15. At this time, although not shown in the diagram, a response to the received Ethernet frame may be sent back to the source ECU 10.

[0094] In S22, the protocol conversion unit 15 checks the destination Port number in the TCP header. If a specific Port number is set as the destination Port number, the protocol conversion unit 15 determines that protocol conversion is necessary and performs decapsulation to extract the encapsulated CAN packet from the TCP payload.

[0095] In S23, the protocol conversion unit 15 forwards the extracted CAN packets to the CAN communication unit 32.

[0096] The CAN communication unit 32 uses the extracted CAN packets to perform receiving-side processing in accordance with the CAN protocol, and forwards the DataField to the destination associated with the CANID indicated in the extracted CAN packets. At this time, if the CAN packets are multi-frame, the processing from S21 to S23 described above is repeated until all CAN packets constituting the multi-frame have been received. Then, the CAN communication unit 32 forwards the DataField that has been extracted from each CAN packet constituting the multi-frame and combined into one.

[0097] If the CANID is a normal CID and is associated with a service, the CAN communication unit 32 forwards the DataField to the service belonging to the service execution unit 11, as shown in S24. If the CANID is a normal CID and is associated with an application, the CAN communication unit 32 forwards the DataField to the application belonging to the application / vehicle control unit 12 via the API 13, as shown in S25 and S26. If the CANID is a specific CID defined to use a predetermined proprietary protocol, the CAN communication unit 32 forwards the DataField to the protocol conversion unit 15, as shown in S27.

[0098] As shown in S28-30, the protocol conversion unit 15 uses its own protocol (e.g., HTTP / 2) to transfer the DataField to the relevant application via the route determination unit 22 and API 13.

[0099] Next, the procedure when the CAN communication unit 32 receives an Ethernet over CAN frame will be explained using Figure 8.

[0100] When the CAN communication unit 32 receives a CAN frame, in S31 it performs reception processing according to the CAN protocol and forwards the processing result to the protocol conversion unit 15. At this time, although not shown in the diagram, a response to the received CAN frame may be sent back to the sender. If the received CAN frame is a multi-frame, the CAN communication unit 32 receives all the CAN frames constituting the multi-frame and then forwards the DataField to the protocol conversion unit 15 all at once. Note that, not limited to multi-frames, if a series of communication procedures according to the CAN protocol are required, the DataField may be forwarded all at once after receiving all the CAN frames constituting the series of communication procedures.

[0101] In S32, the protocol conversion unit 15 checks the CANID. If a specific CID is set as the CANID, the protocol conversion unit 15 determines that protocol conversion is necessary and performs decapsulation, extracting the encapsulated TCP packet from the DataField of the CAN frame. If the CAN frame is multi-frame, the data extracted from the DataField is concatenated to generate a single TCP packet.

[0102] In S33, the protocol conversion unit 15 forwards the extracted TCP packets to the Ethernet communication unit 31.

[0103] The Ethernet communication unit 31 performs receiving-side processing on the extracted TCP packets in accordance with the Ethernet protocol. Then, in S34, the Ethernet communication unit 31 confirms the destination port number indicated in the TCP packet and forwards the TCP data to the application or service associated with the destination port number.

[0104] Furthermore, if a series of communication procedures following TCP / IP communication procedures is required, the Ethernet communication unit 31 may repeat the above procedure (i.e., S31 to S33) and, after receiving all TCP packets related to the series of communication procedures, transfer the TCP payload all at once.

[0105] If the destination Port number is a normal Port number and is associated with a service, the Ethernet communication unit 31 transfers the TCP payload to the relevant service belonging to the service execution unit 11, as shown in S34. If the destination Port number is a normal Port number and is associated with an application, the Ethernet communication unit 31 transfers the TCP payload to the relevant application belonging to the application / vehicle control unit 12 via the API 13, as shown in S35 and S36. If the destination Port number is a specific Port number defined to use a predetermined proprietary protocol, the Ethernet communication unit 31 transfers the TCP payload to the protocol conversion unit 15, as shown in S37.

[0106] As shown in S38 to S40, the protocol conversion unit 15 uses its own protocol (for example, HTTP / 2, etc.) to forward the data to the application via the route determination unit 22 and API 13.

[0107] [3-3. Map Change Sequence] The procedure for updating the route divisions of the route map 23 according to the communication status will be explained using the sequence diagram shown in Figure 9.

[0108] In S41, the communication monitoring unit 21 inquires about the communication status from the Ethernet communication unit 31, and in S42, it receives a response regarding the communication status from the Ethernet communication unit 31.

[0109] In S43, the communication monitoring unit 21 inquires about the communication status from the CAN communication unit 32, and in S44, it receives a response regarding the communication status from the CAN communication unit 32.

[0110] In S45, the communication monitoring unit 21 checks the communication status of Ethernet and CAN by confirming the response content.

[0111] The processes S41 to S45 are executed repeatedly at regular intervals.

[0112] If an abnormal situation is detected as a result of checking the communication status in S45, the process will be carried out according to the procedures in S46 to S48. If recovery from the abnormal situation is detected, the process will be carried out according to the procedures in S49 to S51.

[0113] If an abnormal situation is detected in S45, the communication monitoring unit 21 notifies the route determination unit 22 in S46 of the route on which the abnormal situation was detected (i.e., the route where it occurred) and the details of the abnormal situation (i.e., disconnection or congestion) via an abnormality notification.

[0114] In S47, the route determination unit 22 generates update information for the route map 23 in accordance with the abnormality notification, and in S38, it updates the route map 23 using the generated update information.

[0115] In S39, the communication monitoring unit 21 notifies the route determination unit 22 of the route that has recovered from the abnormal situation (i.e., the route that occurred) via a recovery notification.

[0116] In S40, the route determination unit 22 generates update information for the route map 23 in accordance with the recovery notification, and in S41, it updates the route map 23 using the generated update information.

[0117] The generation of update information in the route determination unit 22 follows the map update process described using the flowchart in Figure 3.

[0118] [4. Correspondence of Terms] In this embodiment, the in-vehicle system 1 corresponds to the communication system of this disclosure, and the ECU 10 corresponds to the communication device, transmitting communication device, and receiving communication device of this disclosure. In this embodiment, one of the Ethernet protocol and the CAN protocol corresponds to the first communication protocol, and the other corresponds to the second communication protocol. Also, one of Ethernet and CAN corresponds to the first communication path, and the other corresponds to the second communication path. In this embodiment, the communication monitoring unit 21 corresponds to the mode switching unit of this disclosure, and the protocol conversion unit 15 corresponds to the transmission processing unit and receiving processing unit of this disclosure. In this embodiment, standard and provisional, which represent line divisions, correspond to the transmission modes of this disclosure, with standard in particular corresponding to the first mode of this disclosure and provisional corresponding to the second mode of this disclosure. In this embodiment, parameters transmitted in a communication frame according to the communication protocol of the standard path correspond to the first data of this disclosure, and parameters transmitted in a communication frame according to the communication protocol of the provisional path correspond to the second data of this disclosure. In this embodiment, the specific Port number and the specific CANID correspond to the conversion information in this disclosure.

[0119] [5. Effects] The embodiments described in detail above produce the following effects.

[0120] (5a) In the in-vehicle system 1, a standard route and a provisional route are defined for each parameter to be transmitted using the route map 23. If the standard route is interrupted or congested, at least some of the parameters that would normally be transmitted using the standard route are transmitted using the provisional route. Therefore, the in-vehicle system 1 makes it possible to make the network connecting the ECUs 10 redundant, improving network reliability and mitigating the effects of congestion.

[0121] (5b) In the in-vehicle system 1, when transmission is routed to a temporary route, packets containing the minimum information necessary for communication control of the standard route are embedded (i.e., encapsulated) in the data portion of the communication frame used in the temporary route and transmitted. Therefore, the reduction in transmission efficiency of the temporary route due to the routed communication frame can be kept to a minimum.

[0122] (5c) In the in-vehicle system 1, it is indicated that a CAN packet or TCP packet is encapsulated by using a specific port number and a specific CID. Therefore, there is no need to modify the communication frame to determine whether or not a communication frame requires protocol conversion, and it can be easily applied to existing systems.

[0123] (5d) In the in-vehicle system 1, priority is set for each parameter so that the transmission of important data is maintained via the standard route. In addition, if it is difficult to complete the application using a transmission route other than the standard route, the system is configured not to switch to a provisional route. Therefore, if a communication error occurs, it is possible to suppress abnormalities in the operation of the in-vehicle system 1.

[0124] [6. Other Embodiments] Although embodiments of the present disclosure have been described above, the present disclosure is not limited to the embodiments described above and can be implemented in various modified forms.

[0125] (6a) In the above embodiment, Ethernet and CAN are used, but a route using a communication protocol other than Ethernet and CAN may be adopted. Also, there may be three or more routes that can be used as provisional routes.

[0126] (6b) In the above embodiment, each ECU 10 has both the functions of a transmitting communication unit and a receiving communication unit as disclosed herein, but there may be ECU 10 configured to have only the functions of a transmitting communication unit or a receiving communication unit. For example, the transmitting side may transmit a CAN over Ethernet frame by multicast, and the receiving side may, upon receiving an Ethernet frame transmitted by multicast, extract the CAN signal from the received frame.

[0127] (6c) The ECU 10 and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the ECU 10 and its method described herein may be implemented by a dedicated computer provided by configuring a processor by one or more dedicated hardware logic circuits. Alternatively, the ECU 10 and its method described herein may be implemented by one or more dedicated computers configured by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. The computer program may also be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium. The method for implementing the functions of each part included in the ECU 10 does not necessarily have to include software, and all of its functions may be implemented using one or more hardware components.

[0128] (6d) Multiple functions of one component in the above embodiment may be realized by multiple components, or one function of one component may be realized by multiple components. Also, multiple functions of multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Furthermore, some of the configurations of the above embodiment may be omitted. Furthermore, at least some of the configurations of the above embodiment may be added to or replaced with the configurations of other above embodiments.

[0129] (6e) In addition to the ECU 10 as a communication device and the in-vehicle system 1 as a communication system described above, the present disclosure can also be realized in various forms, such as a program for making the computer function as the communication device, a non-transitional physical recording medium such as a semiconductor memory on which this program is recorded, and a method for making the communication system redundant.

[0130] [7. Technical Concept Disclosed in This Specification] [Item 1] A transmitting communication device and a receiving communication device are connected via a physical first communication path for transmitting data according to a first communication protocol and a physical second communication path for transmitting data according to a second communication protocol, wherein the transmitting communication device switches a transmission mode representing a method of data transmission using the first communication path and the second communication path to either a first mode or a second mode depending on the status of the first communication path, in the first mode, transmits first data designated to use the first communication protocol using the first communication path and transmits second data designated to use the second communication protocol using the second communication path, in the second mode, at least a portion of the first data is protocol-converted from the first communication protocol to the second communication protocol and transmitted using the second communication path, the receiving communication device is configured to A communication system configured to perform processing according to the first communication protocol when a communication frame is received via the first communication path, to perform processing according to the second communication protocol when a communication frame that has not been protocol-converted is received via the second communication path, and to perform protocol conversion to the first communication protocol and processing according to the first communication protocol when a communication frame that has been protocol-converted is received via the second communication path.

[0131] [Item 2] A communication device comprising: a first communication unit configured to transmit data according to a first communication protocol via a physical first communication path; a second communication unit configured to transmit data according to a second communication protocol via a physical second communication path; a mode switching unit configured to switch a transmission mode representing a method of data transmission using the first communication path and the second communication path to either a first mode or a second mode, depending on the status of the first communication path; and a transmission processing unit configured to transmit, in the first mode, first data designated to use the first communication protocol via the first communication path and second data designated to use the second communication protocol via the second communication path, and in the second mode, protocol conversion of at least a portion of the first data from the first communication protocol to the second communication protocol and transmission using the second communication path.

[0132] [Item 3] A communication device as described in Item 2, wherein the transmission processing unit is configured to generate a communication frame in accordance with the second communication protocol, in which, in the protocol conversion, data necessary for processing in accordance with the first communication protocol is encapsulated together with the first data.

[0133] [Item 4] A communication device according to Item 2 or Item 3, wherein the transmission processing unit is configured to add conversion information indicating that the protocol has been converted to a communication frame in accordance with the second communication protocol during the protocol conversion.

[0134] [Item 5] A communication device according to any one of items 2 to 4, wherein the status of the first communication path includes abnormal conditions indicating the presence or absence of a physical layer level interruption and the presence or absence of communication bandwidth congestion, and the mode switching unit is configured to switch from the first mode to the second mode in response to the occurrence of the abnormal condition, and to switch from the second mode to the first mode in response to recovery from the abnormal condition.

[0135] [Item 6] A communication device as described in Item 5, wherein the transmission processing unit is configured to increase the amount of the first data subject to protocol conversion in the second mode as the degree of congestion of the communication bandwidth increases.

[0136] [Item 7] A communication device according to any one of items 2 to 6, wherein priority is set for the first data, and the transmission processing unit is configured to make the first data with the lower priority the target of the protocol conversion in the second mode.

[0137] [Item 8] A communication device comprising: a first communication unit configured to transmit data according to a first communication protocol via a physical first communication path; a second communication unit configured to transmit data according to a second communication protocol via a physical second communication path; and a receiving processing unit configured to perform processing according to the first communication protocol when a communication frame is received via the first communication path, to perform processing according to the second communication protocol when a communication frame that has not been protocol converted is received via the second communication path, and to perform protocol conversion to the first communication protocol and processing according to the first communication protocol when a protocol converted communication frame is received via the second communication path.

[0138] [Item 9] A communication device as described in Item 8, wherein the receiving processing unit is configured to determine whether or not a communication frame has been protocol converted, according to conversion information attached to the communication frame at the source of the communication frame.

[0139] [Item 10] A communication device as described in Item 9, wherein the receiving processing unit is configured to perform a process to extract data from the communication frame containing information necessary for processing according to the first communication protocol, as the protocol conversion, when the conversion information is attached to the communication frame received by the second communication unit.

Claims

1. The system comprises a transmitting communication device and a receiving communication device connected via a physical first communication path for transmitting data according to a first communication protocol and a physical second communication path for transmitting data according to a second communication protocol, wherein the transmitting communication device switches a transmission mode representing the method of data transmission using the first and second communication paths to either a first mode or a second mode depending on the status of the first communication path, in the first mode it transmits first data designated to use the first communication protocol using the first communication path and second data designated to use the second communication protocol using the second communication path, in the second mode it is configured to perform protocol conversion on at least a portion of the first data from the first communication protocol to the second communication protocol and transmit it using the second communication path, and the receiving communication device is configured A communication system configured to perform processing according to the first communication protocol when a communication frame is received via the first communication path, to perform processing according to the second communication protocol when a communication frame that has not been protocol-converted is received via the second communication path, and to perform protocol conversion to the first communication protocol and processing according to the first communication protocol when a communication frame that has been protocol-converted is received via the second communication path.

2. A communication device comprising: a first communication unit (31 or 32) configured to transmit data according to a first communication protocol via a physical first communication path; a second communication unit (32 or 31) configured to transmit data according to a second communication protocol via a physical second communication path; a mode switching unit (14) configured to switch a transmission mode representing a method of data transmission using the first and second communication paths to either a first mode or a second mode depending on the status of the first communication path; and a transmission processing unit (15) configured to transmit, in the first mode, first data designated to use the first communication protocol via the first communication path and second data designated to use the second communication protocol via the second communication path, and in the second mode, protocol-converting at least a portion of the first data from the first communication protocol to the second communication protocol and transmitting it via the second communication path.

3. A communication device according to claim 2, wherein the transmission processing unit is configured to generate a communication frame in accordance with the second communication protocol, in which, in the protocol conversion, data is encapsulated together with the first data that contains information necessary for processing in accordance with the first communication protocol.

4. A communication device according to claim 2, wherein the transmission processing unit is configured to add conversion information indicating that a protocol conversion has been performed to a communication frame in accordance with the second communication protocol during the protocol conversion.

5. A communication device according to claim 2, wherein the status of the first communication path includes abnormal conditions indicating the presence or absence of a physical layer level interruption and the presence or absence of communication bandwidth congestion, and the mode switching unit is configured to switch from the first mode to the second mode in response to the occurrence of the abnormal conditions, and to switch from the second mode to the first mode in response to recovery from the abnormal conditions.

6. A communication device according to claim 5, wherein the transmission processing unit is configured to increase the amount of the first data subject to protocol conversion in the second mode as the degree of congestion of the communication bandwidth increases.

7. A communication device according to claim 2, wherein a priority is set for the first data, and the transmission processing unit is configured to make the first data with the lower priority the target of the protocol conversion in the second mode.

8. A communication device comprising: a first communication unit (31 or 32) configured to transmit data according to a first communication protocol via a physical first communication path; a second communication unit (32 or 31) configured to transmit data according to a second communication protocol via a physical second communication path; and a receiving processing unit (15) configured to perform processing according to the first communication protocol when it receives a communication frame via the first communication path, to perform processing according to the second communication protocol when it receives a communication frame that has not been protocol converted via the second communication path, and to perform protocol conversion to the first communication protocol and processing according to the first communication protocol when it receives a protocol converted communication frame via the second communication path.

9. A communication device according to claim 8, wherein the receiving processing unit is configured to determine whether or not a communication frame has been protocol converted, according to conversion information attached to the communication frame at the source of the communication frame.

10. A communication device according to claim 9, wherein the receiving processing unit is configured to perform, as protocol conversion, a process of extracting data from the communication frame in which information necessary for processing according to the first communication protocol is encapsulated, when the conversion information is attached to the communication frame received by the second communication unit.

Images