JP2007038904A - Car-mounted gateway device and message forwarding method used in gateway device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To suppress the rise of a load on a bus (vehicle-mounted electronic control network) by allowing a gateway ECU to exclude such an erroneous message as to be revoked even if it is received by an ECU node. <P>SOLUTION: A vehicle-mounted gateway device 1 is equipped with a message normality confirming means 61 to check and confirm the normality of contents of the message received from a first vehicle-mounted electronic control network CAN1 or a second vehicle-mounted electronic control network CAN2 and a message forwarding control means 62 to make control so that a message determined to be abnormal normal by the message normality confirming means 61 is not forwarded to the second or the first vehicle-mounted electronic control network CAN2/CAN1. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an in-vehicle gateway device and a message relay method in the same device, and more particularly to a technique suitable for reducing the load on an in-vehicle electronic control network.

Conventionally, in a vehicle such as an automobile, a communication system using a CAN (Controller Area Network) or the like is often provided. An example of such a vehicle communication system is an in-vehicle LAN (Local Area Network), which is very useful for controlling vehicles and in-vehicle devices.
When constructing such a communication system, prepare multiple networks (buses) according to the type of message to be transmitted / received, purpose, frequency of transmission / reception, etc., and connect these networks so that they can communicate with each other by a gateway device. Is often performed as one aspect of the system configuration. For example, taking an in-vehicle LAN using CAN as an example, an information system network for navigation system control, a body control system network for headlamp control, a safety network for air bag control, engine control, etc. For example, a communication system is constructed by connecting an engine / power train network and the like by a gateway device [gateway ECU (Electrical Control Unit)].

  Here, in the gateway ECU that relays between two networks (buses) using CAN, the communication protocol and architecture of a frame (message) received from the transmission-side ECU node that constitutes one network are set to the other network. The received message is transferred after performing protocol conversion or the like so as to conform to the communication protocol and architecture of the receiving ECU node constituting the. At this time, the gateway ECU transmits (transfers) as it is regardless of the message content of the received frame from the idea of the wire harness.

  For example, as shown in Patent Documents 1 and 3 to be described later, a frame transmitted / received in a CAN includes a CRC (Cyclic Redundancy Check) code and check data (a predetermined part of a message in units of 1 byte) in order to increase reliability. In many cases, error detection data such as a sum value obtained by addition in (5) is added. Then, the receiving ECU node determines whether a reception data error has occurred based on the CRC code or the sum value, and discards the frame determined to have an error (internal control RAM of the controller). Is not reflected in this).

There is also a technique in which a reception error can be determined by comparing message lengths of received frames in a frame configuration in which a data field storing a message body is variable length and the message length is added (see Patent Document 2 below). ).
For example, as described in Paragraph 0018 of Patent Document 1 below, a frame transmitted and received by the ECU node includes an SOF (Start of Frame) indicating a data head, an ID field indicating its own ECU identification number, data A DLC (Data Length Code) field indicating the length, the data field, and the like are included.
JP 2003-273950 A JP-A-10-233789 JP 2000-293442 A

  Currently, the bus load tends to increase due to an increase in communication data in proportion to the complexity of the vehicle system. As the bus load increases, the probability of occurrence of transmission omissions and reception omissions at each ECU node increases, so it is necessary to keep the bus load within the design value. Since data is transferred without checking normality, abnormal data that is discarded even if received at the receiving ECU node is also transferred on the bus, and it is difficult to suppress the bus load. Further, as a method for communicating a large amount of data, an improvement in communication speed can be mentioned, but it cannot be easily changed in a vehicle system from the viewpoint of reliability of communication data.

  The present invention has been devised in view of such a problem, and an abnormal message that is discarded even if received by an ECU node can be eliminated by the gateway ECU, thereby reducing the load on the bus (vehicle-mounted electronic control network). The purpose is to be able to suppress the rise.

In order to achieve the above object, the present invention is characterized by using the following in-vehicle gateway device and a message relay method in the same device.
(1) That is, the in-vehicle gateway device of the present invention is used in an in-vehicle electronic control communication system including a first in-vehicle electronic control network and a second in-vehicle electronic control network, and the first in-vehicle electronic control network And the second on-vehicle electronic control network, which are communicably interconnected, a message for checking normality by checking the content of the message received from the first or second on-vehicle electronic control network It is characterized by comprising normality confirmation means and message relay control means for controlling not to relay a message judged abnormal by the message normality confirmation means to the second or first in-vehicle electronic control network. .

(2) Here, the message normality confirmation means confirms the content of the received message, and if the checksum added to the message is invalid, the checksum confirmation determines that the message is abnormal It may be configured with parts.
(3) Further, the message normality confirmation means includes a data length confirmation unit that determines that the message is abnormal when the data length of the received message is shorter than the predetermined data length. May be.

(4) Further, the data length confirmation unit is configured to determine that a message having a predetermined data length or more is normal, and the message relay control unit determines that the data length confirmation unit is normal. The determined message may be configured to be relayed to the second or first in-vehicle electronic control network.
(5) In addition, the in-vehicle gateway device may further include a presentation unit that presents the fact to the outside when the data length confirmation unit determines that there is an abnormality.

  (6) Furthermore, the message relay method in the in-vehicle gateway device according to the present invention is used in an in-vehicle electronic control communication system including a first in-vehicle electronic control network and a second in-vehicle electronic control network. In the in-vehicle gateway device that interconnects the in-vehicle electronic control network and the second in-vehicle electronic control network so that they can communicate with each other, the content of the message received from the first or second in-vehicle electronic control network is checked and the normality A message normality confirmation step, and a message relay control step for controlling so that a message determined to be abnormal is not relayed to the second or first in-vehicle electronic control network.

(7) Here, in the message normality confirmation step, the content of the received message is confirmed, and when the checksum added to the message is invalid, it may be determined that the message is abnormal. .
(8) In the message normality confirmation step, when the data length of the received message is shorter than the predetermined data length, it may be determined that the message is abnormal.

(9) Further, in the message normality confirmation step, it is determined that a message having a predetermined data length or more is normal, and in the message relay control step,
The message determined to be normal in the message normality confirmation step can be relayed to the second or first in-vehicle electronic control network.
(10) Further, in the message normality confirmation step, when it is determined that the data length of the received message is shorter than the data length decided in advance, an abnormality can be presented to the outside.

According to the present invention, the following effects and advantages can be obtained.
(1) Check the content of the message received by the in-vehicle gateway device and check its normality (checksum value and / or data length), and check for an abnormal message (invalid checksum value or data length) (When the data length is shorter than the received data length) is not relayed, so that an increase in the on-vehicle electronic control network load can be reduced.

(2) In addition, since the message length of the message received by the in-vehicle gateway device can be relayed beyond the predetermined data length, the version of the electronic control device constituting the in-vehicle electronic control network is upgraded. Even if the number of message data is added, a normal vehicle system can be established.
(3) Furthermore, when the data length is shorter than the predetermined data length, it is confirmed that the wrong electronic control device (low-version electronic control device) is connected to the vehicle-mounted electronic control network (that is, the vehicle). By determining, it is possible to prevent a troubled vehicle from flowing out of the market.

  FIG. 1 is a block diagram showing a configuration of an in-vehicle electronic control communication system (in-vehicle LAN) according to an embodiment of the present invention. The in-vehicle LAN shown in FIG. 1 is a first one in which one or more ECU nodes 2 are connected. In-vehicle electronic control network (bus) CAN1, a second in-vehicle electronic control network (bus) CAN2 to which one or more ECU nodes 3 are connected, and these in-vehicle electronic control networks (hereinafter simply referred to as “network or bus”) ) It is configured with a gateway ECU (vehicle gateway device) 1 that interconnects CAN1 and CAN2 so that they can communicate with each other.

  Note that the in-vehicle LAN of this example applies CAN as a communication protocol. CAN is a multi-master type communication protocol that can transmit messages from all ECU nodes 2 and 3 connected to the networks CAN1 and CAN2 when the networks CAN1 and CAN2 exist, and the networks CAN1 and CAN2 The ECU node that has previously accessed can obtain the transmission right. When a plurality of ECU nodes 2 and 3 transmit a message at the same time and these messages are received at the gateway ECU 1 at the same time, for example, a priority is determined based on an ID of the message, and a message having an ID with a high priority. Are controlled so that the ECU nodes 2 and 3 that transmit the transmission right.

  Here, the networks CAN1 and CAN2 are both bus-type networks, and are configured to be able to communicate according to the CAN protocol. The ECU nodes 2 and 3 connected to the networks CAN1 and CAN2 are communication devices capable of transmitting and receiving messages in a predetermined frame format, for example, a CPU (Central Processing Unit) and a ROM (Read It consists of required electronic components such as only memory (RAM), random access memory (RAM), communication controller, etc., and communicates with other ECU nodes (not shown) and gateway ECU 1 via networks CAN1 and CAN2 to which it is connected. Sending and receiving is possible.

  In FIG. 1, messages A, B, and C are transmitted from the ECU node 2 to the ECU node 3, and messages D, E, and F are transmitted from the ECU node 3 to the ECU node 2. Yes. However, the number of messages is not limited to these six types, and an arbitrary number of messages can be used. Normally, a larger number of messages are transmitted and received between the ECU nodes 2 and 3. For example, messages transmitted to the first network CAN1 and the second network CAN2 include messages that are periodically transmitted at a constant period, messages that are irregularly generated due to the occurrence of a certain event, and the like.

  The gateway ECU 1 is a communication device that connects the networks CAN1 and CAN2, and includes, for example, required electronic components such as a CPU, a ROM, and a RAM. Focusing on the configuration of the main part, as shown in FIG. 1, the gateway ECU 1 includes reception buffers 4A to 4F prepared for each message A to F and a transmission buffer 5A prepared for each message A to F. And 5F and a controller 6 that controls the entire gateway ECU 1. The reception buffers 4A to 4F and the transmission buffers 5A to 5F are configured using, for example, the RAM, and the controller 6 is configured using the CPU, ROM, RAM, and the like.

Thereby, in gateway ECU1, according to control of controller 6, messages A to F received by reception buffers 4A to 4F are transferred to corresponding transmission buffers 5A to 5F, and the destination ECU node is transmitted from transmission buffers 5A to 5F. Sent to 2 or 3 via network CAN1 or CAN2.
However, the gateway ECU 1 of the present embodiment is configured such that the controller 6 checks the content of the received message to determine whether message relay is necessary. That is, even if the ECU nodes 2 and 3 receive it, they are discarded (discarded at the hardware level but not reflected at the control application level), and relaying is not performed (transmitted from the reception buffers 4A to 4F). The data is not transferred to the buffers 5A to 5F).

  In communication using the CAN protocol, as described above in the prior art, the data length is added as a DLC field for each ID of the messages A to F, and the data value of each field of the frame is used to improve the reliability of communication data. May be added to the message as error detection data. In the present embodiment, the message does not depend on the hardware communication protocol.

  For example, as shown in FIG. 3, the data frame used in the present embodiment has a start of frame (SOF) field 11 indicating the start of the frame, an arbitration field 12 in which the ID (2 bytes) is set, and the DLC. Control field 13, data field 14 in which the message body (DATA0, DATA1, DATA2,...) Is set, CRC field 15 for checking frame transmission errors, ACK field 16, and end-of-frame (EOF) field indicating the end of the frame. When the checksum value is added, the checksum value is the lower 1 byte of the calculation result according to the following equation (1).

ID upper byte + ID lower byte + DLC + ΣDATAn (n is variable according to DLC, and Σ represents the sum of 1 to n) (1)
More specifically, for example, when ID = 0x123, DLC = 3, DATA0 = 0x11, and DATA1 = 0x22, the checksum value = 0x01 + 0x23 + 0x03 + 0x11 + 0x22 = 0x5A. This checksum value is set as the last field of the data field 14, that is, DATA2 in the case of FIG. Therefore, the receiving side (gateway ECU 1) calculates the checksum value by the above calculation, and if the checksum value is different from the checksum value stored in DATA2, the data value can be determined to be abnormal.

In the controller 6 of this embodiment, the necessity of relaying the received message is determined by confirming the data length and checksum value of the received message. That is, the gateway ECU 1 (controller 6) of the present embodiment operates according to the flowchart (message relay method) shown in FIG. 2 to avoid useless message relay.
First, when receiving a message, the controller 6 confirms, for example, the DLC field and checks whether the received message indicates a data length that is predefined (arranged) in the specification or the like (step S1: message). Normality confirmation step). Note that the data length of the received message may be confirmed by counting the actual data length instead of the DLC field. As a result, if the data length of the received message is greater than or equal to the data length defined in the specification or the like (predetermined), the controller 6 next determines whether or not a checksum value is added to the received message. Is confirmed (from the YES route of step S1 to step S2), and if not added (NO in step S2), the received message is relayed as it is (step S3). That is, the controller 6 can deal with both a message with a checksum value added and a message with no checksum value added.

  On the other hand, if a checksum value is added to the received message (YES in step S2), the controller 6 calculates the same checksum value as the transmission side for the received message (adds one byte at a time for a predetermined field). ) To confirm whether or not it matches the checksum value added to the received message (step S4: message normality confirmation step).

  As a result, if the checksum values match (if YES in step S4), the controller 6 relays the received message as it is (step S3), and if it does not match (if invalid), the received message is relayed. No (no transfer to the corresponding transmission buffers 5A to 5F: NO route from step S4 to step S6: message relay control step).

  When the data length of the received message is less than the predefined data length (NO in step S1), the controller 6 determines that the wrong ECU node 2 or 3 is connected to the network CAN1 or CAN2. This is detected and detected (step S5), and the received message is not relayed (not transferred to the corresponding transmission buffers 5A to 5F: step S6). This is because when the number of data of one frame is added due to version upgrades of ECU nodes 2 and 3, the received message is relayed if the data length is longer than the specification definition so that upward compatibility is maintained. However, if it is less than the data length of the specification definition, it can be determined that the ECU nodes 2 and 3 that have been downgraded (versioned) are connected, which means that the received message is not relayed. At this time, the controller 6 can display (present) on the outside (for example, a maintenance terminal, an indicator on the front panel of the vehicle, or the like) that the wrong ECU nodes 2 and 3 are connected.

  That is, the controller 6 of the present embodiment checks the content of the message received from the network CAN1 or CAN2 by executing the above steps S1 and S4, and the normality (in the receiving ECU nodes 2 and 3). The message normality confirmation unit 61 determines that the message is abnormal by executing the function of the message normality confirmation unit 61 for confirming whether or not the message is a target of reception cancellation and the above steps S3 and S6. The message has a function as message relay control means 62 for controlling not to relay to the destination network CAN2 or CAN1.

  In particular, the controller 6 (message normality confirmation means 61) confirms the content of the received message by executing the above step S4, and when the checksum added to the message is invalid, When the data length of the received message is shorter than the predetermined data length by performing the above-described step S1 while having the function as the checksum confirmation unit 611 that determines that the message is abnormal, It has a function as the data length confirmation unit 612 that determines that the message is abnormal.

In addition, by executing step S5 described above, the controller 6 additionally has a function as a presentation unit 63 that presents the fact to the outside when the data length confirmation unit 611 determines that an abnormality has occurred. You can have it.
As described above, according to the present embodiment, the gateway ECU 1 checks the content of the received message, and the message whose checksum value does not match or the message whose data length is shorter than the predetermined data length, , Because there is an error in the message (not a legitimate message), a useless message that is discarded even if it is received by the receiving ECU nodes 2 and 3 is not relayed, thus reducing the increase in network (bus) load be able to.

  In addition, since a message having a data length longer than that determined in advance is relayed as it is, the ECU nodes 2 and 3 are replaced with upgraded nodes and the number of data in the message is added. However, it can be established as a normal vehicle system. Further, when a message having a data length shorter than the predetermined data length is received, it is possible to detect that the wrong ECU nodes 2 and 3 are connected to the vehicle. Can be prevented in advance.

Needless to say, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the spirit of the present invention.
For example, in the above-described example, both the reception data length and the checksum value are the check targets in the gateway ECU 1, but only one of them may be the check target.

  As described above, according to the present invention, since an abnormal message that is discarded even if it is received on the receiving side can be eliminated by the in-vehicle gateway device, an increase in bus (in-vehicle electronic control network) load can be suppressed. Therefore, it is considered extremely useful in the field of in-vehicle electronic control communication technology.

It is a block diagram which shows the structure of the vehicle-mounted electronic control communication system (vehicle-mounted LAN) which concerns on one Embodiment of this invention. It is a flowchart for demonstrating operation | movement (message relay method) of gateway ECU shown in FIG. It is a figure which shows an example of the data frame structure used by this embodiment.

Explanation of symbols

1 Gateway ECU (Automotive gateway device)
2,3 ECU node 4A-4F Reception buffer 5A-5F Transmission buffer 6 Controller 11 Start of frame (SOF) field 12 Arbitration field 13 Control field 14 Data field 15 CRC field 16 ACK field 17 End of frame (EOF) field 61 Message normal Confirmation means 611 Checksum confirmation section 612 Data length confirmation section 62 Message relay control means 63 Presentation means
CAN1 First in-vehicle electronic control network (bus)
CAN2 Second in-vehicle electronic control network (bus)

Claims (10)

Used in an in-vehicle electronic control communication system having a first in-vehicle electronic control network and a second in-vehicle electronic control network, and capable of communicating between the first in-vehicle electronic control network and the second in-vehicle electronic control network An in-vehicle gateway device interconnected with
Message normality confirmation means for confirming normality by checking the content of a message received from the first or second in-vehicle electronic control network;
An in-vehicle gateway device comprising message relay control means for controlling not to relay a message judged abnormal by the message normality confirmation means to the second or first in-vehicle electronic control network. The message normality confirmation means
The in-vehicle gateway device according to claim 1, further comprising a checksum confirmation unit that determines that the message is abnormal when the checksum added to the received message is invalid. The message normality confirmation means
3. A data length confirmation unit configured to determine that the message is abnormal when the data length of the received message is shorter than a predetermined data length. The in-vehicle gateway device described in 1. The data length confirmation unit
It is configured to determine that a message longer than the data length agreed in advance is normal,
The message relay control means
4. The in-vehicle gateway device according to claim 3, wherein the message determined to be normal by the data length confirmation unit is configured to be relayed to the second or first in-vehicle electronic control network.   5. The in-vehicle gateway device according to claim 3, further comprising presentation means for presenting the fact to the outside when it is determined that the data length confirmation unit is abnormal. Used in an in-vehicle electronic control communication system having a first in-vehicle electronic control network and a second in-vehicle electronic control network, and capable of communicating between the first in-vehicle electronic control network and the second in-vehicle electronic control network In-vehicle gateway device interconnected with
A message normality confirmation step for checking normality by checking the content of the message received from the first or second in-vehicle electronic control network;
A message relaying method in an in-vehicle gateway device, comprising: a message relay control step for controlling so that a message determined to be abnormal is not relayed to the second or first in-vehicle electronic control network. In the message normality confirmation step,
7. The message relay method in the in-vehicle gateway device according to claim 6, wherein when the checksum added to the received message is invalid, it is determined that the message is abnormal. In the message normality confirmation step,
The message relay method in the in-vehicle gateway device according to claim 6 or 7, wherein when the data length of the received message is shorter than a predetermined data length, the message is determined to be abnormal. . In the message normality confirmation step,
A message longer than the data length decided in advance is judged normal,
In the message relay control step,
9. The message relay method in an in-vehicle gateway device according to claim 8, wherein the message determined to be normal in the message normality confirmation step is relayed to the second or first in-vehicle electronic control network. In the message normality confirmation step,
The in-vehicle gateway device according to claim 8 or 9, wherein when it is determined that the data length of the received message is shorter than a predetermined data length, an abnormality is presented to the outside. Message relay method.

Images