WO2017141546A1

WO2017141546A1 - Redundant communication system and redundant communication system restoration method

Info

Publication number: WO2017141546A1
Application number: PCT/JP2016/088562
Authority: WO
Inventors: 遠藤　英樹; 広行久保; 幹雄片岡; 長田　健一
Original assignee: 日立オートモティブシステムズ株式会社
Priority date: 2016-02-19
Filing date: 2016-12-22
Publication date: 2017-08-24
Also published as: JP2017147680A

Abstract

In the present invention, a first GW and a second GW transmit and receive, via a management network, management frames notifying each other of each other's communication state. When a first ECU transmits a frame to a second ECU, the first ECU transmits the same frame to the first GW and the second GW. The first GW and the second GW receive the frame and, in accordance with the communication state of each, either the first GW or the second GW destroys the received frame and the other one of the first GW and the second GW transmits the received frame to the second ECU via a second network. Consequently, changes are freely made to a new network type, such as adding an Ethernet network, in conjunction with an increase in ECU data volume or the like, while ensuring network safety, regardless of the type of network for each ECU domain.

Description

Redundant communication system and recovery method of redundant communication system

The present invention relates to a redundant communication system and a recovery method of the redundant communication system, and more particularly, to a redundant communication system suitable for use in an in-vehicle communication system that improves the safety of network communication between electronic control units of automobiles, and the redundant communication system. The present invention relates to a communication system recovery method.

In recent years, the progress of car electronics has been remarkable, and a wide variety of electronic control units (ECUs) have been installed. In order to exchange information with such an ECU, the in-vehicle network forms a closed network for each domain, such as a control system that controls the engine and brakes, a safety system that performs peripheral recognition by sensors, an information system such as car navigation, etc. is doing. This is because a necessary bandwidth and an allowable cost are different for each domain, and a method suitable for each domain is selected. For example, the standard proposed for each domain is that the control domain is LIN (LOCAL Interconnect Network) or CAN (Controller Area Network), the safety domain is CAN or CAN FD (CAN with Flexible Data Rate), Information systems include MOST (MEDIA Oriented Systems Transport). Since each conventional ECU has a low necessity for cooperation between domains, the domains have been connected to each other (normal operation can be guaranteed even if disconnected).

However, with the rapid increase in attention to automatic driving in recent years, cooperation between the domains of the control system ECU and the safety system ECU has become essential. Simple automation such as ADAS (ADVANCED Driving Assistant System) has already begun to spread. In the future, with the advancement of automated driving, it is predicted that the amount of information from safety cameras, sensors, lasers, etc. will increase. Since conventional LIN and CAN are bus connection networks, the data rate is as low as several Mbps or less, and in order to meet such a demand, the price has been rapidly reduced and the reliability has been rapidly increased due to the explosive spread in recent years. The application of Ethernet (registered trademark) to automobiles is attracting attention. Automatic driving that evolves in this way is ultimately expected to realize fully automatic driving without a driver. For fully automatic operation, it is necessary to recover even if a failure occurs in the network connecting the control system ECU and the safety system ECU and to continue the automatic operation. Therefore, it is conceivable to configure a redundant communication system by duplicating a gateway device (GW: GateWay) that performs in-vehicle communication, and connecting each ECU to two GWs by bus connection. Patent Document 1 describes a technology for bus-connecting such ECUs to two GWs (NIM: Network Interface Module in Patent Document 1).

According to the interconnection method described in Patent Document 1, data from the ECU is transmitted to two GWs at the same time using the broadcast property of the bus connection, and even if a GW failure occurs, arbitration is performed between the GWs. By doing so, it is possible to select data to be transferred. Also during the arbitration between GWs, the broadcast of the bus connection is used, and regular communication is performed between the GWs to check the normality in the bus connection network to which the ECU is connected. Determine and switch GW.

Japanese Patent Laid-Open No. 3-106144

In the above-mentioned patent document, each ECU is connected to two GWs by bus, and regular communication is performed between the GWs by a bus connection network to which the ECU is connected for normality check.

However, for fully automatic operation, in addition to the existing bus connection network, it is necessary to connect a point-to-point connection network such as Ethernet with high reliability. It was impossible to perform recovery including point-to-point connection networks. In addition, the bus connection network has a low speed and cannot cope with an explosive increase in the amount of information due to processing such as automatic driving.

The present invention has been made to solve the above-mentioned problems, and its purpose is to ensure the safety of the network regardless of the network type for each ECU domain, and to reduce the amount of ECU data, such as the addition of an Ethernet network. It is an object of the present invention to provide an in-vehicle redundant communication system that can freely change a new network type accompanying an increase or the like.

In order to solve the above problems, a redundant communication system according to the present invention is a redundant communication system including a GW (GateWay) for controlling a path of a frame and an ECU (Electronic Control Unit) for transmitting and receiving the frame. It consists of GW, 2nd GW, 1st ECU, and 2nd ECU, and 1st ECU is connected to both 1st GW and 2nd GW by the 1st network. The second ECU is connected to both the first GW and the second GW by a second network, and the first GW and the second GW are connected by a management network. Then, the first GW and the second GW transmit and receive a management frame for notifying each other's communication state via the management network. When the first ECU transmits a frame to the second ECU, the first ECU transmits the same frame to the first GW and the second GW, and the first GW and the second GW The GW receives the frame, and according to each communication state, one of the first GW and the second GW discards the received frame, and the other of the first GW and the second GW has received it. The frame is transmitted to the second ECU via the second network.

According to the present invention, regardless of the network type for each ECU domain, a new network type can be freely changed due to an increase in the amount of data of the ECU, such as addition of an Ethernet network, while ensuring the safety of the network. It is possible to provide a vehicle-mounted redundant communication system.

It is a block diagram explaining the function and structure of an apparatus relevant to ECU. It is the figure which showed the structure and data flow of the in-vehicle redundant communication system. It is a figure which shows the format of the CAN frame 41 which vehicle-mounted GW transmits / receives with ECU-B (10b). It is a figure which shows the format of the Ethernet frame 40 which vehicle-mounted GW transmits / receives with ECU-A (10a) or another vehicle-mounted GW. It is a figure which shows the format of OEM payload. It is a sequence diagram which shows the process which transmits a flame | frame between ECUs. It is a sequence diagram which shows the process which transmits an OAM frame between vehicle-mounted GW. It is a sequence diagram which shows the process which transmits the OAM frame when switching a selection path | route between vehicle-mounted GW (the 1). It is a sequence diagram which shows the process which transmits the OAM frame when switching a selection path | route between vehicle-mounted GW (the 2). It is a block diagram which shows the structure of vehicle-mounted GW. It is a figure which shows the format of the header in an apparatus. It is a figure which shows an Ethernet reception table. It is a figure which shows a CAN reception table. It is a figure which shows a switching table. It is a figure which shows a CAN transmission table. It is a figure which shows an OAM table. It is a flowchart which shows Ethernet reception process S100. It is a flowchart which shows CAN reception process S200. It is a flowchart of CAN transmission processing S300. It is a flowchart of OAM reception processing S400. It is a flowchart of OAM polling processing S500. It is a flowchart of opposing GW failure determination processing S600. It is a flowchart of ECU port failure determination processing S700. It is a figure which shows the state selection table used for the switching process state by OAM polling process S500, and the update of a selection path.

Hereinafter, each embodiment according to the present invention will be described with reference to FIGS.

First, the function and configuration of equipment related to the ECU will be described with reference to FIG.
FIG. 1 is a block diagram illustrating functions and configurations of devices related to the ECU.
In the car electronics mechanism, ECU 1000 has a function of receiving input from sensors 2000 and performing information processing based on the input to operate actuators 3000 and transmit information.

The ECU 1000 includes an input processing circuit 1001, an A / D conversion circuit 1002, a power supply circuit 1003, a microcomputer 1100, an in-vehicle network I / F (InterFace) circuit 1004, a transceiver 1005, an output processing circuit 1006, and a power device 1007.

Sensors 2000 include a sensor element 2001, a sensor circuit 2002, and a switch 2003.

Sensor element 2001 is a sensor element that measures, for example, position / angle, acceleration / vibration, flow velocity / flow rate, temperature, and the like.

The measurement result of the sensor element 2001 is input to the sensor circuit 2002, and a signal is input from the sensor circuit 2002 to the input processing circuit 1001 of the ECU 1000. Then, the signal from the input processing circuit 1001 is subjected to analog-digital conversion by the AD conversion circuit 1002 and input to the microcomputer 1100.

The microcomputer 1100 includes a CPU (Central Processing Unit) 1101, a memory 1102, an I / O circuit 1103, and a timer 1104, refers to data stored in the memory 1102, executes a program, performs information processing, and results thereof Is transmitted to the output processing circuit 1006, the in-vehicle communication I / F circuit 1004, and the transceiver 1005.

The output result of the output processing circuit 1006 is input to the power device 1007 that controls power, and a signal that controls the operation of the actuator 3003 is transmitted from the power device 1007.

Actuator 3002 is an operation element such as a motor, a solenoid, a piezoelectric element, an ignition coil, a lamp, and a display.

Data transmitted to the in-vehicle communication I / F circuit 1004 and the transceiver 1005 is converted into a signal that conforms to a wired / wireless prescribed communication protocol, and is transmitted to another ECU 3001 or a smart actuator 3002 that is an intelligent actuator.

Next, an outline of the configuration and operation of the in-vehicle redundant communication system will be described with reference to FIG.
FIG. 2 is a diagram showing the configuration and data flow of an in-vehicle redundant communication system.
In this embodiment, the ECU-A (10a) is connected to two in-vehicle GW-1 (20-1) and in-vehicle GW-2 (20-2) by Ethernet ETH-1 and Ethernet ETH-2.

ECU-B1 (10b1), ECU-B2 (10b2), ECU-B3 (10b3) (hereinafter referred to as ECU-B (10b) when one of them is shown) is connected to a CAN bus (CAN). -B) to the CAN buses (CAN-1, CAN-2) branched from the CAN bus (CAN-b), the in-vehicle GW-1 (20-1) and the in-vehicle GW-2 (20- 2) is connected.

The ECU-A (10a), the ECU-B1 (10b1), the ECU-B2 (10b2), and the ECU-B3 (10b3) are composed of two in-vehicle GW-1 (20-1) and in-vehicle GW-2 (20 -2) A case where data is transmitted and received as a frame will be described. However, the connection method between each ECU and the in-vehicle GW is not limited to this, and the same method can be applied to other point-to-point connection networks such as MOST and other bus connection networks such as LIN. Further, as described above, the combination of ECUs that transmit and receive data is also different from that of the in-vehicle GW such as ECU-A, ECU-B1 (10b1), ECU-B2 (10b2), and ECU-B3 (10b3). , Ethernet point-to-point connection, not only when one is connected by bus, but also between other ECUs connected to in-vehicle GW by point-to-point connection network, or other ECUs connected to in-vehicle GW by bus connection network Even between them, the idea of the present invention is applicable.

The transmission frame from the ECU-A (10a) is copied inside the ECU-A (10a), and with the same contents, the frame Et1 and the frame Et2 are the in-vehicle GW-1 (20-1) and the in-vehicle GW-2. (20-2), respectively. On the other hand, the transmission frame from the ECU-B (10b) is copied when branching from the CAN bus (CAN-b) as the CAN bus (CAN-1, CAN-2), and the frame Ct1 has the same contents. The frame Ct2 is transmitted to the in-vehicle GW-1 (20-1) and the in-vehicle GW-2 (20-2), respectively.

The in-vehicle GW-1 (20-1) and the in-vehicle GW-2 (20-2) are connected to each other by Ethernet ETH-11 and Ethernet ETH-12 which are management Ethernet lines different from the connection to the ECU. It is connected.

An in-vehicle GW-1 (20-1), an in-vehicle GW-2 (20-2), and a management frame (hereinafter referred to as “OAM”) storing a frame transfer path (path) using the management Ethernet line. By sending / receiving (Operation, “Administration” and “Maintenance) frames”), one of the copy frames received from each ECU is discarded as a frame from a path (non-selected path) where no frame transfer is performed. As a result, the frame Cr1 and the frame Er1 for only the frame transfer path (selected path) are transmitted to each ECU.

From the above, it is assumed that the in-vehicle GW or the connection network (Ethernet ETH-1, Ethernet ETH-2, CAN bus (CAN-1), CAN bus (CAN-2)) between each ECU and the in-vehicle GW has failed. When detected, the information is shared between the in-vehicle GW-1 and the in-vehicle GW-2, and when the selected path is affected, the unselected path is changed to the selected path and the frame is transferred to recover from the failure. It is possible.

Next, a data format transmitted over the network will be described with reference to FIGS.
FIG. 3 is a diagram showing a format of a CAN frame 41 transmitted and received by the in-vehicle GW with the ECU-B (10b).
FIG. 4 is a diagram showing the format of the Ethernet frame 40 that the in-vehicle GW transmits / receives to / from the ECU-A (10a) or another in-vehicle GW.
FIG. 5 is a diagram showing the format of the OEM payload.

As shown in FIG. 3, the CAN frame 41 includes an SOF (Start of Frame) 411, an arbitration 412, a control 413, data 414, a CRC (Cyclic Redundancy Check) 415, an ACK (Acknowledgement) 416, and an EOF (End of Frame). 417.

Arbitration 412 is an area for storing network control information, and has a CAN ID value (CAN ID #) serving as a flow identifier. The control 413 is an area for storing frame information, and stores the field length of data 414 transmitted and received by the ECU-b (10b).

As shown in FIG. 4, the Ethernet frame 40 includes a MAC header including a destination MAC address 401, a transmission source MAC address 402, a VLAN tag 403, a type value 404 indicating the type of the subsequent header, a payload 405, and a frame check sequence. (FCS) 406.

In the destination MAC address 401 and the source MAC address 402, the destination of the frame and the MAC address of the source ECU or the in-vehicle GW are stored. The VLAN tag 403 has a VLAN ID value (VID #) as a flow identifier. In the payload 405, in the case of the frame 40 transmitted and received between the in-vehicle GW and the ECU-A (10a), data and the like transmitted and received between each ECU and the ECU are stored. Further, a frame 40 transmitted and received between the in-vehicle GW and the ECU-B (10b) and data 414 of the CAN frame 41 from the ECU-B (10b) are stored. An OAM payload 4051 described below is stored in the payload 405 of the frame 40 transmitted and received between the in-vehicle GWs.

The OAM payload 4051 includes a flow ID 40511 and a switching processing state 40512 as shown in FIG.

The flow ID 40511 is a flow identifier in the in-vehicle GW that is the transmission source of the OAM frame 40. The switching process state 40512 stores a value of a switching process state indicating a state related to the selected path of the flow ID 40511 (detailed later).

Note that the flow ID is an identifier of a network flow used for both the user frame and the management frame, and the method of assigning the flow ID needs to maintain consistency in all in-vehicle GWs. For example, in the example of the communication system of FIG. 1, the Ethernet frame 40 or the CAN frame 41 transmitted / received between the ECU-A (10a) and the ECU-B (10b) is an all-vehicle GW (GW-1, GW-2). Then, the flow ID 40511 should use the ID of the same number for uniquely identifying.

Next, the communication operation of the redundant communication system will be described with reference to FIGS.
FIG. 6 is a sequence diagram illustrating a process of transmitting a frame between ECUs.
FIG. 7 is a sequence diagram showing processing for transmitting an OAM frame between in-vehicle GWs.
8A and 8B are sequence diagrams illustrating a process of transmitting an OAM frame when switching a selected path between in-vehicle GWs.

First, processing for transmitting a frame between ECUs will be described with reference to FIG.
First, in the ECU-A (10a), the Ethernet frame 40 is copied and transmitted to each of the in-vehicle GW-1 (20-1) and the in-vehicle GW-2 (20-2) for transmission to two routes. (Frame Et1 and Frame Et2). The in-vehicle GW-1 (20-1) that has received the frame 40 determines whether or not to transfer depending on whether or not the frame 40 (frame Et1) is transmitted / received on the selected path (P101- 1). In this example, since the path on the in-vehicle GW-1 side is a selection path to the ECU-B (10b), the in-vehicle GW-1 (20-1) converts the frame 40 into the format of the CAN frame 41, Transfer as a frame (frame Cr1) of the selected path (P102-1). As a result, the frame 41 (frame Cr1) is transferred to the ECU-B (10b).

On the other hand, the in-vehicle GW-2 (20-2) that has received the frame 40 also determines whether or not to transfer depending on whether or not the frame 40 (frame Et2) is transmitted / received on the selected path ( P101-2). In this case, since the path on the in-vehicle GW-2 side is a non-selected path to the ECU-B (10b), the frame 40 (frame Et2) is discarded.

Next, the frame transmission process from the ECU-B (10b) to the ECU-A (10a) will be described.

The CAN frame 41 from the ECU-B (10b) is copied to all the in-vehicle GWs (the in-vehicle GW-1 and the in-vehicle GW-2) connected to the bus (frame Ct1 and frame Ct2). In this case, since it is a bus connection, no special processing is required in the ECU-B (10b), and a frame is simply flowed to the bus.

The in-vehicle GW-1 (20-1) that has received the frame 41 (frame Ct1) determines whether to transfer the frame 41 according to whether or not the frame 41 is transmitted / received on the selected path (P103-1). . In this example, since the path on the in-vehicle GW-1 side is a selection path to the ECU-A (10a), the in-vehicle GW-1 converts the frame 41 into the format of the Ethernet frame 40, and the frame of the selected path (frame The data is transferred as Er1) (P104-1). As a result, the frame 40 is transferred to the ECU-A (10a).

On the other hand, the in-vehicle GW-2 (20-2) that has received the frame 41 (frame Ct2) determines whether or not to transfer depending on whether or not the frame 41 is transmitted / received on the selected path (P103- 2). In this example, the on-vehicle GW-2 side path is a non-selected path to the ECU-A (10a), so the frame 41 (frame Ct2) is discarded.

Next, processing for transmitting an OAM frame between in-vehicle GWs will be described with reference to FIG.
The in-vehicle GWs (in-vehicle GW-1 and in-vehicle GW-2) periodically transmit the OAM frame 40 according to the transmission period (period CYC-1 and period CYC-2) of the OAM frame 40 (P201-1 and P201). -2). In this example, the length and timing of the OAM transmission cycle (cycle CYC-1 and cycle CYC-2) are the same, but they are not necessarily the same. At this time, if each in-vehicle GW (in-vehicle GW-1 and in-vehicle GW-2) has not detected a failure, an OAM frame (frame ON-1 and frame ON-2) for notifying the state of each in-vehicle GW is transmitted. Is done. Each in-vehicle GW that has received the OAM frame (frame ON-1 and frame ON-2) performs reception processing such as extraction of necessary information from the OAM payload 4051 shown in FIG. 5 (P202-1 and P202-). 2).

By performing the above transmission / reception processing according to the OAM transmission cycle (cycle CYC-1 and cycle CYC-2), it is possible to share the state of the in-vehicle GW facing each other between the in-vehicle GWs.

Next, processing for transmitting an OAM frame when switching a selected path between in-vehicle GWs when a failure occurs will be described with reference to FIGS. 8A and 8B.

As a first case when a failure occurs, as shown in FIG. 8A, the Ethernet ETH-1 between the ECU-A (10a) and the vehicle-mounted GW-1 (20-1) is disconnected (DEF-1). There is a case.

When the Ethernet ETH-1 between the ECU-A (10a) and the in-vehicle GW-1 is disconnected (DEF-1), the in-vehicle GW-1 (20-1) recognizes that no frame is transmitted for a certain period of time, and the link is disconnected. Is detected (P301). After detecting link disconnection, in the regular OAM transmission process (P302-1), the in-vehicle GW-1 (20-1) requests switching instead of the normal status notification OAM frame (frame ON-1). An OAM frame (frame OR-1) is transmitted. Up to this point, since the on-vehicle GW-2 (20-2) on the opposite side has not detected a failure, the status notification by the normal transfer determination (P100-2) and OAM transmission processing (P201-2) OAM frame (frame ON-2) is transmitted.

The in-vehicle GW-2 (20-2) that has received the OAM frame (frame OR-1) requesting the switching performs the reception process (P303-2) of the OAM frame (frame OR-1), The in-vehicle GW-1 (20-1) recognizes that there is a switching request, and transmits an OAM frame (frame OA-2) indicating a switching response in the next OAM transmission processing (P304-2). During this time, the in-vehicle GW-1 (20-1) that has detected the link disconnection (DEF-1) performs the normal OAM reception process (P202-1) and the opposite in-vehicle GW-2 (20-). Until the OAM frame (frame OA-2) indicating the switching response from 2) is received, the OAM frame (frame OR-1) requesting switching is continuously transmitted (P304-1).

The in-vehicle GW-1 that has received the OAM frame (frame OA-2) indicating the switching response performs the reception process (P305-1) of the OAM frame (frame OA-2), and as a result, the in-vehicle GW-2 that faces the in-vehicle GW-2 Recognizing that there is a switching response from (20-2), the selected path is changed to a non-selected path. Further, in the next OAM transmission process (P306-1), an OAM frame (frame OS-1) indicating completion of switching is transmitted. During this time, the opposite in-vehicle GW-2 (20-2) performs reception processing (P305-2) and also displays an OAM frame (frame OS-) indicating a switching notification from the opposite in-vehicle GW-1 (20-1). Until 1) is received, the OAM frame (frame OA-2) responding to the switching is continuously transmitted (P306-2).

The in-vehicle GW-2 (20-2) that has received the OAM frame (frame OS-1) indicating the completion of switching performs the reception process (P306-2) of the OAM frame (frame OS-1), The in-vehicle GW-1 (20-1) recognizes that the switching has been completed, switches the non-selected path to the selected path, and in the next OAM transmission processing (P307-2), the OAM frame (frame OS indicating the switching completion) -2) is transmitted.

Thereafter, both in-vehicle GWs periodically transmit and receive OS-1 and OS-2, which are OAM frames for which switching has been completed.

Note that when the in-vehicle GW-1 (20-1) receives the OAM frame indicating the switching response from the opposite in-vehicle GW-2 (20-2), the in-vehicle GW-1 (20-1) transmits the switching request. Immediately, the state may be shifted to a switching completion state.

The above selected path switching process sequence (P300) is the same when the CAN bus (CAN-1) between the ECU-B (10b) and the in-vehicle GW-1 is disconnected, except for the failure detection method. . When the CAN bus (CAN-1) is disconnected, a period in which one frame is transmitted / received for each flow of the CAN frame 41 is determined from the viewpoint of system specifications. When 41 is not received, it shall be regarded as a disconnection. That is, in this case, from the viewpoint of this system specification, the transmission period (period CYC-1 and period CYC-2) of the OAM frame 40 is determined for the CAN frame 41 in accordance with the period during which one frame is transmitted and received for each flow. It shall be.

As the second case when a failure occurs, as shown in FIG. 8B, there is a case where the in-vehicle GW-1 has failed (DEF-2).

If the in-vehicle GW-1 (20-1) fails (DEF-2), the status notification OAM frame (frame ON-1) from the opposite side cannot be received. The in-vehicle GW-2 (20-2) monitors whether or not the OAM frame 40 is received every OAM transmission cycle (CYC-2). If no frame can be received during that period, no OAM reception ( 1st period) is detected (P402-2). Although it is possible to immediately determine a failure as a result of this, in order to prevent erroneous determination as a failure in the case of a slight shift or fluctuation in the transmission timing of the OAM frame 40, in this embodiment, a certain number of times, for example, 3 Without receiving the OAM frame 40 in a continuous cycle, the failure (DEF-2) of the opposite in-vehicle GW-1 (20-1) is determined, and the unselected path is switched to the selected path (P406-2). Thereafter, in the periodic OAM transmission process (P407-2), the OAM frame (frame OS-2) for which switching has been completed is transmitted, and thereafter the frame (frame OS-2) is periodically transmitted.

As described above, the path switching process can be performed as described above when a failure or disconnection occurs in the Ethernet line, the CAN bus, and the in-vehicle GW in which the selected path is conducted.

Next, a data structure related to the configuration of the in-vehicle GW will be described with reference to FIGS. 9 to 15.
FIG. 9 is a block diagram showing the configuration of the in-vehicle GW.
FIG. 10 is a diagram showing the format of the in-device header.
FIG. 11 is a diagram illustrating an Ethernet reception table.
FIG. 12 is a diagram illustrating a CAN reception table.
FIG. 13 is a diagram illustrating a switching table.
FIG. 14 is a diagram illustrating a CAN transmission table.
FIG. 15 is a diagram illustrating an OAM table.

First, the data structure (frame header and tables) related to the in-vehicle GW will be described with reference to FIGS.

The in-device header 45 is a header added in the device for frame processing inside the in-vehicle GW. As shown in FIG. 10, the flow ID 451, the input port ID 452, the OAM flag 453, the frame length 454, It consists of multiple fields that indicate

The flow ID 451 stores an identifier for identifying the flow. The input port ID 452 stores whether the input port of the frame is an Ethernet frame or a CAN frame. The OAM flag 453 stores whether the frame is an OAM (management) frame or a user frame. Here, it is assumed that “1” is a management frame and “0” is a user frame. The frame length 454 stores the frame length of the frame in bytes.
The in-device header 45 is deleted when output from the output port.

The Ethernet reception table 21 is a table that uses the VLAN ID as a search key to determine the processing contents of the input frame to the Ethernet port, the flow ID, and the like. As shown in FIG. 11, the VLAN ID 211, the discard flag 212, It consists of a tag process 213, a new VLAN ID 214, a CoS process 215, a new CoS 216, and a flow ID 217.

Here, the discard flag 212 is a flag indicating whether to transmit or discard the frame of the entry. The tag processing 213 and the CoS processing 215 specify VLAN tag processing for the input frame, and tag information necessary for the VLAN tag processing is set in the new VLAN ID 214 and the new CoS 216. In this embodiment, the tag process 213 and the CoS process 215 are set to “transparent”, and invalid values are set to the new VLAN ID 214 and the new CoS 216, because it is only necessary to transmit without change. Further, the flow ID 217 stores a value indicating the flow ID to which the entry belongs. Here, a dedicated VLAN ID is assigned for transmission / reception of the OAM frame 40 between the vehicle-mounted GWs, and is registered as an entry different from the frame 40 from the ECU-A (10a).

Note that information (VLAN ID, port ID to which the in-vehicle GW is connected, flow ID, etc.) regarding the OAM frame 40 transmission / reception VLAN between the in-vehicle GW is held in a register 107 (described later).

The CAN reception table 23 is a table for determining the processing contents of the input frame to the CAN port, the flow ID, and the like using the CAN ID 231 as a search key. As shown in FIG. 12, the CAN ID 231, the discard flag 232, It consists of tag processing 233, new VLAN ID 234, CoS processing 235, new CoS 236, flow ID 237, and number of received frames 238. Here, the discard flag 232 indicates whether the frame of the entry is to be transmitted or discarded. It is a flag to show. Further, the tag processing 233 and the CoS processing 235 specify VLAN tag processing for the input frame, and tag information necessary for this is set in the new VLAN ID 234 and the new CoS 236. In this embodiment, in order to delete the header of the normal CAN frame and add the header of the Ethernet frame, the tag processing 233 and the CoS processing 235 are set to “add”, and valid values are set to the new VLAN ID 234 and the new CoS 236. Is done. Further, the flow ID 237 stores the flow ID to which the entry belongs. Further, the number of received frames 238 stores the number of frames received by the flow in a certain period (OAM transmission cycle CYC in this embodiment).

The switching table 22 is a table for defining the switching operation of the in-vehicle GW, and includes a flow ID 221, an input port ID 222, and an output port ID 223 as shown in FIG. The in-vehicle GW searches the value of the output port ID 223 from the switching table 22 using the combination of the flow ID 221 and the input port ID 222 as a search key.

Here, the input port ID 222 is physically fixedly assigned to each communication port, and can be uniquely determined depending on from which communication port the input frame is received. The switch processing unit 104 (described later) thereby searches the switching table 22.

The CAN transmission table 25 is a table for determining a CAN ID assigned to an output frame to the CAN port, and includes a flow ID 251 and a CAN ID 252 as shown in FIG. The in-vehicle GW searches for the value of the CAN ID 252 using the flow ID 251 as a search key. The CAN ID 252 stores the CAN ID of the arbitration 412 necessary when converting from the Ethernet frame 40 to the CAN frame 41.

The OAM table 24 is a table for searching for information related to OAM using the flow ID as a search key. As shown in FIG. 15, the flow ID 2401, the valid flag 2402, the number of OAM receptions 2403, and the OAM not received. From the number of times 2404, the opposite GW failure 2405, the ECU port ID 1 (2406), the ECU port ID 2 (2407), the switching process state 2408, the opposite GW switching process state 2409, the path setting 2410, and the selected path 2411 Become.

Here, the valid flag 272 is a flag indicating the validity of this entry. When this flag is invalid (the entry is not used), the processing related to the OAM frame is not performed. Further, the number of OAM received stores the number of OAM frames received in CYC during the OAM transmission period. The OAM non-reception count 2404 is counted up when no OAM frame is received in the CYC during the OAM transmission period, and is cleared to “0” when any OAM frame is received. The opposite GW failure 2403 is normally “0” (normal), but when the OAM non-reception frequency 2404 is equal to or greater than a certain number (3 in the present embodiment), the failure of the opposite in-vehicle GW is determined. 1 '(failure) is set. ECU port ID1 (2406) and ECU port ID2 (2407) are connected to ECUs that communicate with each other, and store ports for transmitting and receiving frames. The port ID to be set includes information on the type of communication port when the port ID is assigned (for example, an ID starting with 'E' is an Ethernet port, and an ID starting with 'C' is a CAN port From the setting value, it can be seen whether the communication port is the Ethernet port 101 or the CAN port 102. In this embodiment, the Ethernet port 101 connected to the ECU-A (10a) is connected to the ECU port ID1 (2406), and the CAN port 102 connected to the ECU-B (10b) is connected to the ECU port ID2 (2407). Although registered, the reverse setting may be used. Furthermore, the switching processing state 2408 holds the state of the switching processing of the flow, and holds “status notification”, “switching request”, “switching response”, or “switching complete”. The opposite GW switching processing state 2409 holds the latest switching processing state 40512 stored in the OAM frame 40 of FIG. 5 received from the opposite vehicle-mounted GW. The path setting 2410 indicates the path setting of the flow, and is used when there is no failure if it is “active”, and is used when a failure occurs in the “active” path if it is “standby”. Indicates the path. The selected path 2411 holds the currently selected path, and holds “working” or “reserve”.

Next, the configuration and operation of the in-vehicle GW will be described with reference to FIG.

The in-vehicle GW includes a plurality of Ethernet ports 101 (101-1 to 101-n) serving as input / output interfaces with Ethernet (registered trademark) and a plurality of CAN ports 101 (102-1 to 102-1 serving as input / output interfaces with CAN). 102-n) and are connected to each ECU via these communication ports. In this embodiment, the ECU-A (10a) is connected via the Ethernet port 101 and the ECU-B (10b) is connected via the CAN port 102.

The in-vehicle GW is connected to the Ethernet processing unit 103 (103-1 to 103-n) connected to the Ethernet port 101, the switch processing unit 104 connected to the Ethernet processing unit 103, and the switch processing unit 104. An OAM processing unit 106 and a CAN processing unit 105 (105-1 to 105-n), and a register 107 that holds setting information of each block and notification information from each block. The CAN processing unit 105 is connected to the CAN port 102.

When the in-vehicle GW receives the Ethernet frame 40 from the communication port, the in-device header 45 shown in FIG. 10 is added to the received frame.

When the in-device header 45 adds the in-device header 45 to the received frame, the in-vehicle GW stores the port ID acquired from the register 107 in the input port ID 452 and the frame length counted during reception in the frame length 454. On the other hand, the flow ID 451 and the OAM flag 453 are blank. As described later, an effective value is set in this field by the Ethernet processing unit 103 or the CAN processing unit 105.

The Ethernet processing unit 103 performs an Ethernet reception process S100 described later, refers to the following Ethernet reception table 21, and sets the flow ID 451 and the OAM flag 453 in the in-device header 45 of the input frame from each Ethernet port 101. In addition to adding, perform other header processing. As a result of the Ethernet reception process S100, the input frame is transferred to the switch processing unit 104 or discarded.

The CAN processing unit 105 performs a CAN reception process S200 described later, adds a flow ID 451 to the in-device header 45 of the input frame from each CAN port 102 with reference to the CAN reception table 23 shown in FIG. In addition, other header processing is performed. As a result of the CAN reception process S200, the input frame is transferred to the switch processing unit 104 or discarded.

The switch processing unit 104 receives an input frame from each Ethernet processing unit 103 and each CAN processing unit 105, specifies an output port ID from the switching table 22, and sends it to the corresponding Ethernet processing unit 103 or CAN processing unit 105 as an output frame. Forward. However, when “1” (management frame) is set in the OAM flag 453 of the in-device header 45, the frame is an OAM frame to be terminated in the in-vehicle GW, and therefore the OAM processing unit 106 is referred to. Forward.

The output frames received by the switch processing unit 104 that are user frames are sequentially supplied to the Ethernet processing unit 103 or the CAN processing unit 105.

The Ethernet processing unit 103 outputs the received output frame to the Ethernet port 101.

The CAN processing unit 105 performs CAN transmission processing S300, which will be described later, and refers to the CAN transmission table 25 shown in FIG. 14 by the flow ID 451 of the in-device header 45 of each output frame, and performs header processing. . As a result of the CAN transmission process S300, the output frame is output to the CAN port 102.

On the other hand, the OAM processing unit 106 that has received the OAM frame from the switch processing unit 104 refers to the OAM table 24 shown in FIG. 15 and performs OAM reception processing S400 on the received OAM frame.

Next, processing performed in the in-vehicle GW will be described with reference to FIGS.
FIG. 16 is a flowchart showing the Ethernet reception process S100.
FIG. 17 is a flowchart showing the CAN reception process S200.
FIG. 18 is a flowchart of the CAN transmission process S300.
FIG. 19 is a flowchart of the OAM reception process S400.
FIG. 20 is a flowchart of the OAM polling process S500.
FIG. 21 is a flowchart of the facing GW failure determination process S600.
FIG. 22 is a flowchart of ECU port failure determination processing S700.
FIG. 23 is a diagram showing a switching process state by the OAM polling process S500 and a state selection table used for updating the selected path.

First, the Ethernet reception process S100 executed by the Ethernet processing unit 103 will be described with reference to FIG.

The Ethernet processing unit 103 acquires the VLAN ID from the VLAN tag 403 of the Ethernet frame 40 (FIG. 4) received from the Ethernet port 101, searches the Ethernet reception table 21 shown in FIG. And the flow ID 217 acquired from the Ethernet reception table 21 is overwritten on the flow ID 451, and the VLAN tag 403 is processed according to the tag processing 213 and the CoS processing 215 specified in the Ethernet reception table 21 (all “transparent” in this embodiment). (S102). Then, it is checked whether or not the discard flag 212 acquired from the Ethernet reception table 21 is “1” (discard) (S103). If it is not “1” (discard), the frame is transferred to the switch processing unit 104 (S104). The process is terminated (S108). If it is determined in S103 that it is “1” (discard), it is checked whether or not the Ethernet type 404 of the received frame is “for management” (S105). Since it is an OAM frame that terminates at “1”, “1” is overwritten in the OAM flag 453 of the in-device header 45 (S106), and the processing after S104 is executed.

If it is not “for management” in S105, the frame is discarded because it is a user frame of a non-selected path (S107), and the process is terminated (S108).

Next, the CAN reception process S200 executed by the CAN processing unit 105 will be described with reference to FIG.

The CAN processing unit 105 acquires the CAN ID from the arbitration 412 of the input CAN frame 41 (FIG. 3) received from the CAN port 102, searches the CAN reception table 23, and sets 1 to the value of the current number of received frames 238. The added value is stored in the number of received frames 238 (S201).

Next, it is checked whether or not the discard flag 232 acquired from the CAN reception table 23 is “1” (discard) (S202).

When it is determined in S202 that it is not '1' (discard), the CAN header other than the data 414 of the CAN frame 41 is deleted, and this data 414 is used as the payload 405, and other Ethernet headers (destination MAC address 401, transmission) Only the fields of the original MAC address 402, VLAN tag 403, Ethernet type 404 and FCS 406) are added, and an invalid value is input (S203).

Next, the flow ID 237 acquired from the CAN reception table 23 is overwritten on the flow ID 451 of the in-device header 45, and the VLAN tag 403 is processed according to the tag processing 233 and the CoS processing 235 specified in the CAN reception table 23 (this embodiment). In the form, all are “added.” In other fields, the holding value of the register 107 is added (S204).

When it is determined in S202 that the frame is '1' (discard), the frame is a non-selected path, so the frame is discarded (S206), and the process is terminated (S207).

Next, CAN transmission processing S300 executed by the CAN processing unit 105 will be described with reference to FIG.

The CAN processing unit 105 acquires the flow ID 451 of the in-device header 45 of the output Ethernet frame 40 (FIG. 3) received from the switch processing unit 104, and searches the CAN transmission table 25 shown in FIG. 14 (S301).

As a result of the search, the Ethernet header (destination MAC address 401, transmission source MAC address 402, VLAN tag 403, Ethernet type 404 and FCS 406) of the frame is deleted, and only the field of the CAN header (other than data 414) is added, Inputs an invalid value, and adds the acquired CAN ID 252 to the arbitration 412 (the other field adds the value held in the register 107) (S302). Then, the frame is transferred to the CAN port 102 (S303), and the process ends (S304).

Next, the OAM reception process S400 executed by the OAM processing unit 106 will be described with reference to FIG.

When receiving the OAM frame 40, the OAM processing unit 106 searches the OAM table shown in FIG. 15 by the flow ID 40511 of the OAM payload 4051 shown in FIG. 5 (S401), and adds “1” to the OAM reception number 2403. The OAM unreceived count 2404 is cleared to “0”, and the frame switching processing state 40512 received in the opposite GW switching processing state 2409 is written back to the same entry in the OAM table 25 (S402), and the packet is discarded ( The process is terminated (S404).

Next, the OAM polling process S500 executed by the OAM processing unit 106 will be described with reference to FIG.

The OAM processing unit 106 executes this polling process at an OAM frame transmission cycle CYC interval. At the polling timing, the OAM processing unit 106 initializes the internal parameter i to “0” (S501). Next, '1' is added to the stored internal parameter i (S502), the internal parameter i is set as an index, the OAM table 24 is searched, and the table value is acquired and stored (S503).

Then, it is checked whether or not the valid flag 252 of the OAM table 24 is “1” (valid) (S504). If the valid flag 252 of the OAM table 24 is not “1” (valid), the process goes to S507, If “1” (valid), the opposite GW failure determination process (S600) and the ECU port failure determination process (S700) are executed in parallel, and the held switching process state 2408 is set according to the state transition table 30 described later. The corresponding value and the value corresponding to the selected path 2411 are updated (S505) (detailed later).

Then, the flow ID 451, the input port ID 452, and the OAM flag 453 (for management) are set as the in-device header 45 shown in FIG. 10, and the destination MAC address 401, the source MAC address 402, the Ethernet type 403, As the VLAN tag 404, the value held in the register 107 is set as the VLAN setting for transmitting / receiving the OAM frame 40 between the in-vehicle GW described above, and the internal parameter i (that is, the flow ID is # is set in the flow ID 40511 of the OAM payload 4051). 1, # 2, # 3,...), An OAM frame 40 in which the switching processing state updated and held in the switching processing state 50512 in S 505 is generated and transmitted to the switch processing unit 104. (S506).

Then, it is checked whether i is equal to or greater than the maximum value of the OAM table 24 (S507), and if it is less than the maximum value, the polling process is continued, so the processes after S502 are continued.

If the internal parameter i is equal to or greater than the maximum value in the determination process of S507, the polling of all entries is completed, and the process ends (S508).
Next, the opposite GW failure determination process S600 executed by the OAM processing unit 106 will be described with reference to FIG.

The OAM processing unit 106 checks whether or not the opposite GW failure 2405 acquired from the OAM table 24 illustrated in FIG. 15 is “1” (failure) (S601), and if it is “1” (failure), the updated information. Is written back to the OAM table 24 (S607), and the process is terminated (S608).

In the determination process of S601, if it is not “1” (failure), it is checked whether the number of OAM receptions 2403 acquired from the OAM table 24 is “0” (S602), and if it is “0”, no OAM has been received. “1” is added to the number of times 2404 (S603), and it is checked whether or not the number of OAM not received after addition is “3” or more (S604). The opposite GW failure 2405 is overwritten with “1” (S605), and the processing after S607 is continued. On the other hand, if the OAM non-reception count after addition is not “3” or more, the processing from S607 is continued.

If the OAM reception number 2403 acquired from the OAM table 24 is not “0” in the determination process of S602, the OAM reception number 2403 and the OAM non-reception number 2404 acquired and held from the table are cleared to “0” (S606). ), The process from S607 is continued.

Next, the ECU port failure determination process S700 executed by the OAM processing unit 106 will be described with reference to FIG.

The OAM processing unit 106 checks whether the type of the communication port is Ethernet from the value of the ECU port ID 1 (2406) acquired from the OAM table 24 (S701), and if it is Ethernet, it corresponds to the ECU port ID 1 (2406). The presence or absence of link breakage is confirmed by the register 107 (S702). If link breakage is occurring, it is retained that the ECU port ID1 has failed (S703), and the process is terminated (S710).

In the determination process of S702, if no link break has occurred, the ECU port ID1 is maintained as having no failure (S704), and the process is terminated (S710).

In the determination process of S701, if the type of communication port is not Ethernet from the value of ECU port ID1 (2406), the CAN reception table 23 shown in FIG. 12 is searched with the internal parameter i (FIG. 20) (S705). It is checked whether or not the number of received frames 238 in the CAN reception table 23 is “0” (S706), and if it is “0”, it means that a failure has occurred and that the ECU port ID1 has failed (S707). The process is terminated (S710).

In the determination process of S706, if the number of received frames 238 in the CAN reception table 23 is not “0”, it is retained that the ECU port ID1 is not faulty (S704), and the number of received frames is cleared to “0”. Write back to the same entry in the reception table 23 (S709), and the process ends (S710).

The above S700 is described as ECU port ID1 (2407), but at the same time, the same processing is performed for ECU port ID2 (2407).

Next, the switching process state by the OAM polling process S500 and the state selection table used for updating the selected path will be described with reference to FIG.

The state transition table T30 includes a state number T301, a switching processing state T302, a path setting T303, a local input T304, a remote input T305, and a selected path T306. Here, the current state has eight states indicated by a state number T301, which is expressed by a combination of a switching processing state T302 and a path setting T303. When there are a local input T304 and a remote input T305 for this current state, the transition destination when each occurs is shown.

The local input T304 is a failure event that occurs in the in-vehicle GW determined in the opposing GW failure determination processing S600 and the ECU port failure determination processing S700, and the remote input T305 is an opposing in-vehicle GW failure event that can be acquired in the OAM frame 40 It is.

In the notation of the state transition table T30, “→ number” transitions to the state of the transition destination number, “−” maintains the current state, and “NA” (Non ”Analysis) indicates the state in the system specifications. Therefore, the state number T301, which is the default state, transitions to “1”. In the present embodiment, first, a transition according to the local input T304 is performed, and then a transition according to the remote input T305 is performed.

Hereinafter, the state transition in the processing in the case of FIGS. 8A and 8B will be described with reference to the state transition table T30.
In the example shown in FIG. 8A, the Ethernet ETH-1 path connected to the in-vehicle GW-1 is the active path, and the Ethernet ETH-2 path connected to the in-vehicle GW-2 is a spare. At this time, as shown in FIG. 8A, if the Ethernet ETH-1 is disconnected, the “ECU port failure 1” of the local input T304 occurs. Following this, the in-vehicle GW-1 whose switching process state is “status notification” transitions to the state number 3 and the switching process state of the related flow becomes “switching request”. A switching request is transmitted to the in-vehicle GW-2. In the in-vehicle GW-2, the event “switch request” of the remote input T305 has occurred, so the state transitions to the state number 6 and the switch processing state of the associated flow becomes “switch response”. The switch response is transmitted to the opposite on-vehicle GW-1.

Next, in the in-vehicle GW-1, since the “switch response” event of the remote input T305 has occurred, the state transitions to the state number 7, the switching process state of the related flow becomes “switch complete”, and thereafter the in-vehicle GW At -1, a switch completion is transmitted to the opposite onboard GW-2. Further, the selected path 306 becomes “reserve”.

Next, in the in-vehicle GW-2, since the “switching complete” event of the remote input T305 has occurred, the state transitions to the state number 8 and the switching process state of the related flow becomes “switching complete”. -2 transmits a switch completion to the opposite on-vehicle GW-1. Further, the selected path 306 becomes “reserve”.

As a result, thereafter, the in-vehicle GW-1 discards the frame of the related flow, and the in-vehicle GW-2 converts the frame format (mutual conversion between the Ethernet frame and the CAN frame) to the frame transmitted to itself. ) And transmitted to the connected ECU.

On the other hand, as shown in FIG. 8B, when a failure occurs in the in-vehicle GW-1, the subsequent operation is not guaranteed. In the opposite in-vehicle GW-2, since the “opposite GW failure” of the local input T304 has occurred, the state transitions to the state number 8, the switching processing state becomes “switching complete”, and the selected path 306 is “standby”. In the following, frame format conversion (mutual conversion between an Ethernet frame and a CAN frame) is performed on the frame transmitted to itself, and the frame is transmitted to the connected ECU.

Claims

A redundant communication system comprising a GW (GateWay) for controlling the path of a frame and an ECU (Electronic Control Unit) for transmitting / receiving the frame,
The first GW, the second GW, the first ECU, and the second ECU,
The first ECU is connected to both the first GW and the second GW by a first network;
The second ECU is connected to both the first GW and the second GW by a second network,
The first GW and the second GW are connected by a management network,
The first GW and the second GW transmit and receive a management frame for notifying each other's communication status through the management network,
When the first ECU transmits a frame to the second ECU, the first ECU transmits the same frame to the first GW and the second GW, and the first ECU One GW and the second GW receive the frame, and according to each communication state, one of the first GW and the second GW discards the received frame, and the first GW The redundant communication system, wherein the other of the GW and the second GW transmits the received frame to the second ECU via the second network.
The first network is a network different from the bus type,
The second network is a bus network;
The first GW and the second GW convert a frame transmitted from the first network into a frame having a format suitable for the second network, and transmit the frame to the second network. The frame transmitted from the second network is converted into a frame having a format suitable for the first network and transmitted to the first network. Redundant communication system.
The first GW and the second GW are:
Detects network failure of the network connected to its own GW,
A management frame for notifying the GW connected by the management network to that effect,
The GW that has received the management frame changes the communication state,
The GW that has received the management frame transmits the frame from the first network transmitted to the own GW to the second network, or from the second network transmitted to the own GW. The redundant communication system according to claim 1, wherein the frame is transmitted to the first network.
The first GW and the second GW are:
When a management frame from the opposite GW connected by the management network is not transmitted for a certain period of time,
The communication state of the own GW is switched, and the frame from the first network transmitted to the own GW is transmitted to the second network, or the frame from the second network transmitted to the own GW. 2. The redundant communication system according to claim 1, wherein the second communication system is transmitted to the first network.
The GW that has transmitted the management frame notifying that the network failure of the network connected to the own GW has been detected,
4. The redundant communication system according to claim 3, wherein the communication state is switched when a response notification is received from an opposing GW.
A method for recovering a redundant communication system comprising a GW (GateWay) for controlling a route of a frame and an ECU (Electronic Control Unit) for transmitting / receiving the frame,
The redundant communication system includes a first GW, a second GW, a first ECU, and a second ECU,
The first ECU is connected to both the first GW and the second GW by a first network;
The second ECU is connected to both the first GW and the second GW by a second network,
The first GW and the second GW are connected by a management network,
The first GW and the second GW transmit and receive a management frame for notifying each other's communication state through the management network;
When the first ECU transmits a frame to the second ECU, the first ECU transmits the same frame to the first GW and the second GW; and
The first GW and the second GW receive the frame, and according to each communication state, one of the first GW and the second GW discards the received frame;
The other of the first GW and the second GW includes a step of transmitting the received frame to the second ECU via the second network. Recovery method.
The first network is a network different from the bus type,
The second network is a bus network;
The first GW and the second GW convert a frame transmitted from the first network into a frame having a format suitable for the second network, and transmit the frame to the second network. And converting the frame transmitted from the second network into a frame having a format suitable for the first network and transmitting the frame to the first network. 6. The redundant communication system recovery method according to 6.
The first GW and the second GW detecting a network failure of a network connected to the GW;
The first GW and the second GW transmitting a management frame notifying the opposite GW connected by the management network;
The GW that has received the management frame changes the communication state;
The GW that has received the management frame transmits the frame from the first network transmitted to the own GW to the second network, or from the second network transmitted to the own GW. The method according to claim 6, further comprising a step of transmitting the first frame to the first network.
When the management frame from the opposite GW connected by the management network is not transmitted for a certain period, the first GW and the second GW switch the communication state of the own GW, and the own GW The frame from the first network transmitted to the second network is transmitted to the second network, or the frame from the second network transmitted to the own GW is transmitted to the first network. 7. The redundant communication system recovery method according to claim 6, further comprising steps.
The GW that has transmitted the management frame notifying that the network failure of the network connected to the own GW has been detected,
7. The method for recovering a redundant communication system according to claim 6, further comprising a step of switching a communication state when a response notification is received from an opposing GW.