WO2017037982A1 - ゲートウェイ装置、車載ネットワークシステム及び転送方法 - Google Patents

ゲートウェイ装置、車載ネットワークシステム及び転送方法 Download PDF

Info

Publication number
WO2017037982A1
WO2017037982A1 PCT/JP2016/003145 JP2016003145W WO2017037982A1 WO 2017037982 A1 WO2017037982 A1 WO 2017037982A1 JP 2016003145 W JP2016003145 W JP 2016003145W WO 2017037982 A1 WO2017037982 A1 WO 2017037982A1
Authority
WO
WIPO (PCT)
Prior art keywords
frame
bus
transfer
mac
verification
Prior art date
Application number
PCT/JP2016/003145
Other languages
English (en)
French (fr)
Inventor
芳賀　智之
中野　稔久
安齋　潤
松島　秀樹
良浩 氏家
勇二 海上
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2016119773A external-priority patent/JP6787697B2/ja
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN202110623085.9A priority Critical patent/CN113300947B/zh
Priority to CN202110629451.1A priority patent/CN113300927B/zh
Priority to CN201680016304.4A priority patent/CN107431625B/zh
Priority to EP19180080.4A priority patent/EP3562103B1/en
Priority to EP20182263.2A priority patent/EP3734911B1/en
Priority to EP16841029.8A priority patent/EP3346646B1/en
Publication of WO2017037982A1 publication Critical patent/WO2017037982A1/ja
Priority to US15/881,826 priority patent/US10525911B2/en
Priority to US16/664,192 priority patent/US10974669B2/en
Priority to US17/194,701 priority patent/US11529914B2/en

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H04L12/40176—Flexible bus arrangements involving redundancy
    • H04L12/40182—Flexible bus arrangements involving redundancy by using a plurality of communication lines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present disclosure relates to a gateway device that transfers a frame in a network in which an electronic control unit communicates.
  • ECUs electronice control units
  • in-vehicle network A network connecting these ECUs.
  • in-vehicle networks There are many standards for in-vehicle networks. Among them, one of the most mainstream in-vehicle networks is a standard called CAN (Controller Area Network) defined by ISO11898-1.
  • a communication path is composed of two buses, and an ECU connected to the bus is called a node.
  • Each node connected to the bus transmits and receives a message called a frame.
  • a transmission node that transmits a frame applies a voltage to two buses to generate a potential difference between the buses, thereby transmitting a value of “1” called recessive and a value of “0” called dominant.
  • the dominant is transmitted with priority.
  • the receiving node transmits a frame called an error frame.
  • An error frame is a notification of frame abnormality to a transmitting node or another receiving node by transmitting dominants continuously for 6 bits.
  • CAN there is no identifier indicating a transmission destination or a transmission source, and the transmission node transmits an ID (frame identifier) called a message ID for each frame (that is, sends a signal to the bus), and each reception node. Receives only a frame with a predetermined ID (that is, reads a signal from the bus).
  • a CSMA / CA Carrier Sense Multiple Access / Collision Avoidance
  • arbitration is performed using a message ID when multiple nodes transmit simultaneously, and a frame with a small message ID value is transmitted preferentially.
  • a gateway device which is a type of ECU connected to a plurality of buses in an in-vehicle network, has a function of transferring frames between buses.
  • a gateway device is a gateway device connected to one or more buses used by a plurality of electronic control units for communication, and is received by a receiving unit that receives a frame and the receiving unit Delete verification information used for verification of the frame from the contents of the frame and transfer the frame to the transfer destination bus, which is one of the buses, or add verification information to the content of the frame And a transfer unit that transfers the frame to the transfer destination bus.
  • a recording medium such as an apparatus, a system, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • the apparatus, system, method, computer program, and You may implement
  • FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system according to Embodiment 1.
  • FIG. It is a figure which shows the format of the data frame prescribed
  • FIG. 1 is a configuration diagram of a MAC-compatible ECU (ECU having a function of processing a MAC) according to Embodiment 1.
  • FIG. 2 is a configuration diagram of a gateway according to Embodiment 1.
  • FIG. It is a figure which shows an example of the bus information which the gateway which concerns on Embodiment 1 hold
  • FIG. 12 is a sequence diagram illustrating an operation example related to frame transfer by the gateway according to the first embodiment (continuing from FIG. 11).
  • FIG. 11 is a sequence diagram illustrating an operation example related to frame transfer by the gateway according to the first embodiment (continuing from FIG. 10);
  • FIG. 12 is a sequence diagram illustrating an operation example related to frame transfer by the gateway according to the first embodiment (continuing from FIG. 11).
  • FIG. 11 is a sequence diagram illustrating an operation example related to frame transfer by the gateway according to the first embodiment (continuing from FIG. 10);
  • FIG. 15 is a sequence diagram illustrating an operation example related to frame transfer by the gateway according to the second embodiment (continuing from FIG. 14).
  • FIG. 20 is a sequence diagram showing an operation example related to frame transfer by the gateway according to the second embodiment (continuing from FIG. 13). It is a figure which shows the standard format and extended format of a data frame. It is a figure which shows an example of the bus information which the gateway which concerns on Embodiment 3 hold
  • FIG. 10 is a diagram illustrating an example of format conversion by a gateway according to Embodiment 3.
  • FIG. 10 is a diagram illustrating another format conversion example by the gateway according to the third embodiment.
  • a gateway device is a gateway device connected to one or more buses used by a plurality of electronic control units for communication, and is received by a receiving unit that receives a frame and the receiving unit Delete verification information used for verification of the frame from the contents of the frame and transfer the frame to the transfer destination bus, which is one of the buses, or add verification information to the content of the frame And a transfer unit that transfers the frame to the transfer destination bus.
  • verification information is added or deleted at the time of transfer, so that efficient frame transfer can be realized in a network system partially including an electronic control unit (ECU) that does not have a verification function for verification information. .
  • ECU electronice control unit
  • the transfer unit when a predetermined deletion condition for deleting the verification information is satisfied with respect to the first frame including the verification information received by the reception unit, the transfer unit, the content of the first frame The transfer may be performed by generating a second frame including information based on the content excluding the verification information and transmitting the second frame to the transfer destination bus.
  • the traffic amount of the transfer destination bus when the verification information is deleted and transferred can be suppressed.
  • the ECU connected to the transfer destination bus does not need to process the verification information. This can lead to, for example, realizing efficient ECU organization in the network system.
  • the plurality of electronic control units communicate via the bus in accordance with a Controller Area Network (CAN) protocol
  • the verification information is a message authentication code arranged in a data field in a frame
  • the transfer unit When the predetermined deletion condition is satisfied, a second frame including the contents of the data field other than the message authentication code in the first frame and not including the message authentication code may be transmitted to the transfer destination bus. good.
  • the predetermined deletion condition is satisfied when the message authentication code is unnecessary in the ECU to which the frame is transferred.
  • the gateway device is connected to a plurality of buses, and the gateway device selects a reference destination for selecting the transfer destination bus that is a transfer destination of a frame received by the receiving unit from the plurality of buses.
  • the bus is connected to a verification compatible bus to which an electronic control unit having a frame verification function based on the verification information is connected, or an electronic control unit having the verification function is connected.
  • a transfer rule holding unit that holds bus information indicating whether there is no verification-incompatible bus, and the transfer unit selects the transfer destination bus based on the transfer rule information during the transfer, and the transfer destination bus is not verified.
  • the transfer may be performed assuming that the predetermined deletion condition is satisfied.
  • the bus information distinguishes between a verification message identifier that is an identifier of a frame that is verified by the electronic control unit having the verification function connected to the verification-compatible bus and a non-verification message identifier that is an identifier of a frame that is not verified.
  • the transfer unit includes the predetermined deletion condition when the identifier of the frame received by the receiving unit is a non-verification message identifier when the transfer destination bus is a verification compatible bus. If it is satisfied, the transfer may be performed.
  • the transfer unit may perform the transfer when the predetermined deletion condition is satisfied when the bus occupancy rate of the transfer destination bus is higher than a predetermined value.
  • a predetermined value for example, when the traffic amount of the transfer destination bus exceeds a certain amount, it is possible to prioritize the suppression of the bus occupancy over ensuring the execution of frame verification by the ECU connected to the transfer destination bus.
  • the transfer unit may include information indicating whether or not verification information is included in the frame in the frame transmitted to the transfer destination bus.
  • the ECU connected to the transfer destination bus can easily confirm whether or not the verification information is included in the received frame without measuring the bus occupancy rate, for example.
  • the gateway device holds information indicating whether or not the electronic control unit has a frame verification function based on the verification information for each electronic control unit connected to the one or more buses.
  • the unit deletes the predetermined deletion when the electronic control unit that is connected to the transfer destination bus that is a transfer destination of the frame received by the receiving unit and executes processing according to the frame does not have the verification function.
  • the transfer may be performed assuming that the condition is satisfied.
  • the gateway device includes a verification message identifier that is an identifier of a frame to be verified by an electronic control unit that is connected to the one or more buses and has a frame verification function based on the verification information, and a frame that is not verified.
  • Message identifier information for distinguishing the identifier from the non-verified message identifier that is an identifier of the frame, and the transfer unit satisfies the predetermined deletion condition when the identifier of the frame received by the receiving unit is a non-verified message identifier As described above, the transfer may be performed.
  • the transfer unit may not perform the transfer when it is determined that the frame is invalid by verification based on the verification information of the frame received by the reception unit. As a result, transfer of illegal frames is suppressed, and the processing load for dealing with illegal frames in the transfer destination ECU is reduced.
  • the gateway device is connected to a plurality of buses, and the gateway device selects a reference destination for selecting the transfer destination bus that is a transfer destination of a frame received by the receiving unit from the plurality of buses.
  • a transfer rule holding unit that holds the transfer rule information indicating the bus and the bus information that associates the bus with the frame format for each bus, and the transfer unit transfers the transfer destination bus based on the transfer rule information during the transfer.
  • the transfer destination bus is associated with a predetermined frame format by the bus information, the transfer may be performed assuming that the predetermined deletion condition is satisfied. This is useful, for example, in a system configuration in which an ECU having a verification function based on frame verification information is not connected to a bus of a predetermined frame format.
  • the gateway device may perform frame format conversion during transfer when the frame formats corresponding to the transfer source bus and the transfer destination bus are different.
  • the gateway device is connected to a plurality of buses, and the gateway device selects a reference destination for selecting the transfer destination bus that is a transfer destination of a frame received by the receiving unit from the plurality of buses.
  • a transfer rule holding unit that holds the transfer rule information that indicates the type of the communication protocol used for communication on the bus for each bus, and the transfer unit stores the transfer rule information in the transfer rule information during the transfer.
  • the transfer destination bus is selected based on the bus information, and when the transfer destination bus is associated with a predetermined communication protocol by the bus information, the transfer may be performed assuming that the predetermined deletion condition is satisfied. .
  • efficient frame transfer can be performed for a system in which the ECU is organized so that verification based on verification information is not performed on a bus used for communication using a predetermined communication protocol.
  • the transfer unit may Generating a second frame including information based on the content excluding the verification information, and verification information generated using a key shared with the electronic control unit connected to the transfer destination bus Then, the second frame may be transmitted to the transfer destination bus. As a result, the security of the frame can be increased.
  • the transfer unit receives information based on the content of the frame Then, the transfer may be performed by generating a frame including the verification information and transmitting the generated frame to the transfer destination bus.
  • the verification information can be added to the frame and transferred. It may be possible to increase security by verification based on the above.
  • the transfer unit deletes the verification information from the decrypted frame content after decrypting the frame or decrypts the frame.
  • the verification information may be added to the contents of the frame and the transfer of the frame may be performed.
  • decoding is performed when the frame is transferred, so that the transfer destination ECU can appropriately process the received frame without having a decoding function, for example.
  • the transfer unit includes, for the first frame including the verification information received by the reception unit, information based on the content of the first frame excluding the verification information and the verification information.
  • Information based on the contents excluding the verification information from the contents of the first frame by generating the second frame not included and transmitting the second frame to the transfer destination bus to perform the transfer.
  • a verification information, and a third frame having a frame identifier different from the second frame may be transmitted.
  • An in-vehicle network system is an in-vehicle network system including a plurality of electronic control units that communicate via one or more buses and a gateway device connected to the bus, and the gateway device Deletes the verification information used for verification of the frame from the content of the frame received by the receiving unit that receives the frame and the frame to the transfer destination bus that is one of the buses of the frame Or a transfer unit for transferring the frame to the transfer destination bus by adding verification information to the contents of the frame.
  • the verification information is added or deleted when the frame received from any communication path (for example, one bus) is transferred to the transfer destination bus.
  • the in-vehicle network system includes a plurality of buses to which an electronic control unit is connected, the gateway device is connected to the plurality of buses, and the gateway device is connected to the plurality of buses by the receiving unit.
  • a transfer rule holding unit that holds transfer rule information indicating a criterion for selecting the transfer destination bus that is a transfer destination of the received frame, and the transfer unit transfers the frame received by the receiving unit;
  • the transfer destination bus is selected based on the transfer rule information, and the transfer destination bus is a bus to which an electronic control unit having a frame verification function based on verification information is connected.
  • the transfer may be performed by deleting or adding the verification information for the frame.
  • a transfer method is a transfer method used in an in-vehicle network system including a plurality of electronic control units that communicate via one or more buses, and includes a reception step of receiving a frame, A transfer step of transferring a frame to the transfer destination bus, which is one of the buses, after deleting or adding verification information used for verification of the frame when a frame is received in the reception step. And a transfer method including: As a result, verification information is added or deleted when the frame is transferred to the transfer destination bus. Therefore, the efficiency is improved in an in-vehicle network system that partially includes an electronic control unit (ECU) that does not have a verification function for verification information. Frame transfer can be realized.
  • ECU electronice control unit
  • the gateway device uses a predetermined transfer method to transfer a received frame (also referred to as a message) to a transfer destination bus.
  • a message authentication code which is verification information for verifying the frame, is deleted under a certain condition or added under a certain condition.
  • the gateway device receives the MAC from the received frame. Transfer is performed by deleting and sending to the transfer destination bus. For this reason, it is possible to reduce the traffic volume of the transfer destination bus, and the ECU connected to the bus does not need to perform processing related to the MAC.
  • FIG. 1 is a diagram showing an overall configuration of an in-vehicle network system 1 according to the first embodiment.
  • the in-vehicle network system 1 is an example of a network communication system that performs communication according to a CAN protocol, and is a network communication system in an automobile on which various devices such as a control device and a sensor are mounted.
  • the in-vehicle network system 1 includes a plurality of ECUs (ECUs 100, 101, 200, 201, 300, 301, 400, 401, 500, 600, 700) and gateways 90 connected by CAN buses 10 to 70. Consists of including. Although omitted in FIG.
  • the in-vehicle network system 1 can include more ECUs.
  • the ECU is a device including, for example, a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like.
  • the memory is a ROM, a RAM, or the like, and can store a control program (computer program) executed by the processor.
  • the processor operates according to a control program (computer program)
  • the ECU realizes various functions.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the processor in order to achieve a predetermined function.
  • an ECU for a drive system related to “running” (running) of the vehicle such as motor, fuel, and battery control, including an ECU 100 and an ECU 101 connected to the engine 110 and the transmission 111, respectively.
  • the bus 20 is connected to a chassis type ECU related to the control of the vehicle behavior such as “turn”, “stop”, etc., including the ECU 210 and the ECU 201 connected to the brake 210 and the steering 211, respectively.
  • the bus 30 is connected with an ECU for a safety and comfort function system related to an inter-vehicle distance maintenance function, a collision prevention function, an airbag, etc., including an ECU 300 and an ECU 301 connected to an automatic brake 310 and a lane keeping device 311 respectively. Yes.
  • the bus 40 is connected to a body system ECU related to the control of vehicle equipment such as an air conditioner and a winker, which includes an ECU 400 and an ECU 401 connected to the door 410 and the light 411, respectively.
  • vehicle equipment such as an air conditioner and a winker
  • the bus 50 is connected to an infotainment ECU related to car navigation, audio, etc., including an ECU 500 (head unit) connected to the instrument panel 510.
  • ECU 500 head unit
  • an ITS system ECU Connected to the bus 60 is an ITS system ECU corresponding to an intelligent transportation system such as an ETC (Electronic Toll Collection System) including an ECU 600 connected to an ITS (Intelligent Transport Systems) device 610.
  • ETC Electronic Toll Collection System
  • ITS Intelligent Transport Systems
  • an ECU 700 Connected to the bus 70 is an ECU 700 connected to a diagnosis port 710 which is an interface for communicating with an external failure diagnosis tool, such as OBD2 (On-Board Diagnostics 2).
  • the diagnostic port 710 may be connected to the bus 70 except for the ECU 700.
  • the devices connected to the ECUs connected to the buses shown here are merely examples, and may be replaced with, for example, one or more other devices, or may be omitted.
  • Each of the ECUs acquires the state of the connected device (engine 110, brake 210, etc.) and periodically transmits a frame indicating the state to the network (that is, the CAN bus). Yes.
  • the ECUs 100 and 101 connected to the bus 10, the ECUs 200 and 201 connected to the bus 20, and the ECUs 300 and 301 connected to the bus 30 are MAC-compatible ECUs and function to process a message authentication code (MAC). (MAC generation function, MAC verification function).
  • the ECUs 400 and 401 connected to the bus 40, the ECU 500 connected to the bus 50, the ECU 600 connected to the bus 60, and the ECU 700 connected to the bus 70 are non-MAC-compliant ECUs. It does not have processing functions (MAC generation function, MAC verification function).
  • the gateway 90 is a gateway device that connects a plurality of different communication paths and transfers data between the communication paths.
  • the gateway 90 is connected to the bus 10, the bus 20, the bus 30, the bus 40, the bus 50, the bus 60, and the bus 70. That is, the gateway 90 is a kind of ECU having a function of transferring a frame (data frame) received from one bus to another bus (that is, a transfer destination bus selected according to the condition) under a certain condition.
  • the gateway 90 transfers a frame including the MAC received from one bus.
  • this transfer is a transmission frame including information based on the contents of the frame including the received MAC, and includes the MAC (for example, the same MAC as the received MAC or a newly generated MAC).
  • the gateway 90 transfers the frame including the MAC received from one bus after deleting the MAC under a certain condition. Specifically, deleting the MAC from the frame and transferring it means generating a transmission frame including information based on a part other than the MAC in the contents of the frame including the received MAC, and transferring it to the transmission frame. It is to transmit to the transfer destination bus without including the MAC. Further, the gateway 90 transfers the frame received from one bus without adding the MAC after adding the MAC under a certain condition.
  • the gateway 90 can switch whether the received frame is transferred or not for each connected bus.
  • the in-vehicle network system 1 may include a bus not shown in FIG. 1, and may include one or more gateway devices other than the gateway 90.
  • each ECU exchanges frames according to the CAN protocol.
  • Frames in the CAN protocol include a data frame, a remote frame, an overload frame, and an error frame.
  • description will be given mainly focusing on the data frame.
  • FIG. 2 is a diagram showing a data frame format defined by the CAN protocol. This figure shows a data frame in a standard format (standard ID format) defined by the CAN protocol.
  • Data frame is SOF (Start Of Frame), ID field, RTR (Remote Transmission Request), IDE (Identifier Extension), reserved bit “r”, DLC (Data Length Code), data field, CRC (Cyclic Redundancy Check) sequence , A CRC delimiter “DEL”, an ACK (Acknowledgement) slot, an ACK delimiter “DEL”, and an EOF (End Of Frame) field.
  • SOF is composed of 1-bit dominant. When the bus is idle, it is recessive, and the start of frame transmission is notified by changing to dominant by SOF.
  • the ID field is a field for storing an ID that is a value indicating the type of data (that is, a message ID that is an identifier in a frame) composed of 11 bits.
  • RTR is a value for identifying a data frame and a remote frame, and is composed of a dominant 1 bit in the data frame.
  • IDE and “r” are both composed of dominant 1 bit.
  • DLC is composed of 4 bits and is a value indicating the length of the data field. IDE, “r”, and DLC are collectively referred to as a control field.
  • the data field is a value indicating the content of data to be transmitted composed of a maximum of 64 bits.
  • the length can be adjusted every 8 bits.
  • the specification of data to be sent is not defined by the CAN protocol, but is determined by the in-vehicle network system 1. Therefore, the specification depends on the vehicle type, manufacturer (manufacturer), and the like.
  • CRC sequence consists of 15 bits. It is calculated from the transmission values of the SOF, ID field, control field and data field.
  • CRC delimiter is a delimiter representing the end of a CRC sequence composed of 1-bit recessive.
  • the CRC sequence and the CRC delimiter are collectively referred to as a CRC field.
  • ACK slot consists of 1 bit.
  • the transmitting node performs transmission with the ACK slot being recessive.
  • the receiving node transmits an ACK slot as a dominant if reception is successful up to the CRC sequence. Since dominant is given priority over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that any receiving node has received successfully.
  • ACK delimiter is a delimiter representing the end of ACK composed of 1-bit recessive.
  • EOF is composed of 7 bits recessive and indicates the end of the data frame.
  • 2A shows an example of the contents of a data field of a frame transmitted and received by a non-MAC-compliant ECU, and the data field includes only data 80a without including the MAC.
  • FIG. 2B shows an example of the contents of a data field of a frame transmitted and received by the MAC-compatible ECU.
  • the data field includes data 80b and MAC81.
  • the gateway 90 receives the frame having the content exemplified in (b) and transfers the frame to the transfer destination bus to which the MAC-incompatible ECU is not connected and the MAC-incompatible ECU is connected, for example, The frame from which the MAC is deleted is transferred.
  • data and MAC are each 32 bits, but this is only an example, and other sizes may be used.
  • the MAC size may be determined in advance for each message ID. Alternatively, the MAC size may be determined for each bus.
  • the data and the MAC are included in one frame, but the data and the MAC may be included in a data field in each separate frame and transmitted. In this case, for example, when transferring to a transfer destination bus to which a MAC non-compliant ECU is not connected and a MAC non-compliant ECU is connected, the gateway 90 transfers a frame containing data to a frame containing the MAC. You may control not to transfer.
  • FIG. 3 is a configuration diagram of an ECU 400 that is a MAC non-compliant ECU.
  • the ECU 400 does not have a configuration related to a function of processing a MAC (MAC generation function, MAC verification function), and includes a frame transmission / reception unit 800, a frame interpretation unit 801, a reception ID determination unit 802, and a reception ID list holding 803, a frame processing unit 804, a frame generation unit 805, and a data acquisition unit 806.
  • Each function of these components is realized by, for example, a communication circuit in ECU 400, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 800 transmits / receives a frame according to the CAN protocol to / from the bus 40.
  • a frame is received bit by bit from the bus 40 and notified to the frame interpretation unit 801. Further, the content of the frame notified from the frame generation unit 805 is transmitted to the bus 40.
  • the frame interpretation unit 801 receives the frame value from the frame transmission / reception unit 800, and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the value determined as the ID field is notified to the reception ID determination unit 802.
  • the frame interpretation unit 801 notifies the frame processing unit 804 of the value of the ID field and the data field appearing after the ID field according to the determination result notified from the reception ID determination unit 802, or displays the determination result.
  • After receiving the frame it is determined whether to stop receiving the frame (that is, stop the interpretation as the frame). If the frame interpretation unit 801 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 801 notifies the frame generation unit 805 to transmit an error frame. If the frame interpreter 801 receives an error frame, that is, if it interprets that the value in the received frame is an error frame, the frame interpreter 801 discards the frame thereafter, that is, stops interpreting the frame. To do.
  • the reception ID determination unit 802 receives the value of the ID field notified from the frame interpretation unit 801, and receives each field of the frame after the ID field according to the list of message IDs held by the reception ID list holding unit 803. Judge whether to do. The reception ID determination unit 802 notifies this determination result to the frame interpretation unit 801.
  • the reception ID list holding unit 803 holds a reception ID list that is a list of IDs (message IDs) received by the ECU 400. For example, when the ECU 400 receives and processes messages having IDs of 0x100 and 0x200, these ID lists of 0x100 and 0x200 are registered in advance in the reception ID list.
  • the frame processing unit 804 performs processing related to different functions for each ECU according to the received frame data.
  • the ECU 400 connected to the door 410 has a function of sounding an alarm sound when the door is opened in a state where the brake is not applied.
  • ECU 400 has, for example, a speaker for sounding an alarm sound.
  • the frame processing unit 804 of the ECU 400 manages data received from other ECUs, and performs a process of sounding an alarm sound under certain conditions based on the open / closed state of the door acquired from the door 410.
  • the frame processing unit 804 may perform processing related to frame data other than those exemplified here.
  • the data acquisition unit 806 acquires data indicating the state of devices, sensors, and the like connected to the ECU, and notifies the frame generation unit 805 of the data.
  • the frame generation unit 805 configures an error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 801, and notifies the frame transmission / reception unit 800 to transmit the error frame.
  • the frame generation unit 805 forms a frame by attaching a predetermined message ID to the data value notified from the data acquisition unit 806 and notifies the frame transmission / reception unit 800 of the frame.
  • the ECUs 401, 500, 600, and 700 are also non-MAC-compliant ECUs and have basically the same configuration as the ECU 400 described above.
  • the reception ID list held in the reception ID list holding unit 803 may have different contents for each ECU.
  • the processing contents of the frame processing unit 804 are different for each ECU.
  • the frame transmission / reception unit 800 of the ECU 401 transmits / receives a frame to / from the bus 40
  • the frame transmission / reception unit 800 of the ECU 500 transmits / receives a frame to / from the bus 50
  • the frame transmission / reception unit 800 of the ECU 600 transmits to the bus 60.
  • the frame transmitting / receiving unit 800 of the ECU 700 transmits / receives a frame to / from the bus 70.
  • FIG. 4 is a configuration diagram of the ECU 100 that is a MAC-compatible ECU.
  • the ECU 100 has a configuration related to a function of processing a MAC (MAC generation function, MAC verification function), a frame transmission / reception unit 810, a frame interpretation unit 811, a reception ID determination unit 812, and a reception ID list holding unit. 813, a frame processing unit 814, a frame generation unit 815, a data acquisition unit 816, a MAC control unit 820, a MAC key storage unit 821, and a counter storage unit 822.
  • Each function of these constituent elements is realized by, for example, a communication circuit in the ECU 100, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 810, the frame interpretation unit 811, the reception ID determination unit 812, the reception ID list holding unit 813, the frame processing unit 814, the frame generation unit 815, and the data acquisition unit 816 are non-MAC-compliant ECUs.
  • the frame transmission / reception unit 810 transmits / receives a frame according to the CAN protocol to / from the bus 10.
  • the MAC control unit 820 generates a MAC (see FIG. 2B) arranged in the data field of the CAN data frame and verifies the MAC.
  • the MAC control unit 820 When receiving a data frame by the frame transmission / reception unit 810, the MAC control unit 820 combines the message ID and data value, which are the contents of the frame acquired from the frame interpretation unit 811, and the counter value held by the counter holding unit 822. With respect to the value, the MAC value is calculated using the MAC key held by the MAC key holding unit 821, and the calculated MAC value is compared with the MAC value that is the content of the frame acquired from the frame interpretation unit 811. .
  • the MAC control unit 820 determines that the message is invalid, stops the processing of the frame, and notifies the frame generation unit 815 to transmit, for example, an error frame.
  • the MAC control unit 820 holds the message ID and data values, which are the contents of the frame formed by the frame generation unit 815 based on the data from the data acquisition unit 816, and the counter holding The MAC value is calculated using the MAC key held by the MAC key holding unit 821 for the value combined with the counter value held by the unit 822, and the MAC value as the calculation result is notified to the frame generation unit 815. To set the frame for transmission.
  • the MAC control unit 820 calculates the MAC using the MAC key, and uses, for example, the top 4 bytes of the calculated result as the MAC value.
  • the MAC key uses, for example, the top 4 bytes of the calculated result as the MAC value.
  • the MAC value uses, for example, the top 4 bytes of the calculated result as the MAC value.
  • an example has been described in which three of the message ID, the data value, and the counter value held by the counter holding unit 822 are used to calculate the MAC, but any one or two of them is used. May be used for MAC calculation, or the contents of other fields in the frame (eg, DLC) may be used for MAC calculation.
  • As a MAC calculation method for example, HMAC (Hash-based Message Authentication Code), CBC-MAC (Cipher Block Chaining Message Authentication Code), or the like can be used.
  • the MAC key holding unit 821 holds a MAC key necessary for calculating a MAC value.
  • the counter holding unit 822 holds a counter value required for calculating the MAC value.
  • the counter value of the counter holding unit 822 is incremented by 1 (incremented).
  • the counter value is held for each message ID of a frame to be transmitted / received, for example.
  • the frame generation unit 815 configures an error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 811 and notifies the frame transmission / reception unit 810 to transmit the error frame.
  • the frame generation unit 815 forms a frame by attaching a predetermined message ID to the data value notified from the data acquisition unit 816, and the MAC value notified from the MAC control unit 820 to the frame. Is sent to the frame transmission / reception unit 810.
  • ECU101,200,201,300,301 is also MAC corresponding
  • the reception ID list held in the reception ID list holding unit 813 may have different contents for each ECU.
  • the processing content of the frame processing unit 814 differs for each ECU.
  • the MAC key holding unit 821 of each MAC-compatible ECU holds, for example, a different MAC key for each message ID processed by the ECU.
  • the MAC key holding unit 821 of each MAC-compatible ECU may hold a MAC key that is unified for each bus to which the ECU is connected regardless of the message ID, and both hold the same MAC key. It is also good.
  • the frame transmission / reception unit 810 of the ECU 101 transmits / receives a frame to / from the bus 10
  • the frame transmission / reception unit 810 of the ECUs 200, 201 transmits / receives a frame to / from the bus 20
  • the frame transmission / reception unit 810 of the ECUs 300, 301 Frames are transmitted to and received from the bus 30.
  • FIG. 5 is a configuration diagram of the gateway 90.
  • the gateway 90 includes a frame transmission / reception unit 901, a frame interpretation unit 902, a reception ID determination unit 903, a reception ID list holding unit 904, a frame generation unit 905, a transfer control unit 906, a transfer rule holding unit 907, A MAC control unit 920, a MAC key holding unit 921, and a counter holding unit 922 are included.
  • Each function of these components is realized by, for example, a communication circuit in the gateway 90, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 901 transmits / receives a frame according to the CAN protocol to each of the bus 10, the bus 20, the bus 30, the bus 40, the bus 50, the bus 60, and the bus 70.
  • the frame transmission / reception unit 901 functions as a reception unit that receives a frame from the bus bit by bit and notifies the frame interpretation unit 902 of the frame. Further, based on the transfer destination bus information indicating the transfer destination bus and the frame received from the frame generation unit 905, the contents of the frame are changed to bus 10, bus 20, bus 30, bus 40, bus 50, bus 60. And one bit at a time to the transfer destination bus of the bus 70.
  • the frame interpretation unit 902 receives a frame value from the frame transmission / reception unit 901 and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the value determined as the ID field is notified to the reception ID determination unit 903.
  • the frame interpretation unit 902 notifies the transfer control unit 906 of the value of the ID field and the data field (data) appearing after the ID field according to the determination result notified from the reception ID determination unit 903, or After receiving the determination result, it is determined whether to stop receiving the frame. If the frame interpretation unit 902 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 902 notifies the frame generation unit 905 to transmit an error frame. In addition, when the frame interpretation unit 902 receives an error frame, that is, when it is interpreted that the value in the received frame is an error frame, the frame is discarded after that, that is, the interpretation of the frame is stopped. To do.
  • the reception ID determination unit 903 receives the value of the ID field notified from the frame interpretation unit 902, and receives each field of the frame after the ID field according to the list of message IDs held by the reception ID list holding unit 904. Judge whether to do. The reception ID determination unit 903 notifies this determination result to the frame interpretation unit 902.
  • the reception ID list holding unit 904 holds a reception ID list that is a list of message IDs received by the gateway 90. In the reception ID list, message IDs of frames to be received by the gateway 90 from each bus (buses 10 to 70) are registered.
  • the reception ID list holding unit 904 may hold a separate reception ID list for each bus, or may hold one reception ID list as a whole.
  • the transfer control unit 906 sets the transfer destination bus according to the received frame ID (message ID) and the transfer source bus (that is, the bus that received the frame).
  • the frame generation unit 905 is notified of the transfer destination bus information indicating the transfer destination bus, the message ID and data (data field contents) notified from the frame interpretation unit 902, and the DLC (data length).
  • the transfer control unit 906 refers to the bus information held by the transfer rule holding unit 907 (information indicating whether each bus is a MAC-compatible bus or a MAC-incompatible bus) and transfer rule information, and determines the transfer source bus of the received frame. It is confirmed whether or not the transfer destination bus is a MAC compatible bus.
  • the MAC compatible bus is a bus to which a MAC compatible ECU is connected
  • the non-MAC compatible bus is a bus to which a MAC compatible ECU is not connected.
  • a MAC non-compliant ECU can be connected to the MAC non-compliant bus.
  • the transfer control unit 906 requests the MAC control unit 920 to perform MAC verification, and when the MAC control unit 920 succeeds in MAC verification (that is, When the MAC in the frame received from the transfer source bus matches the calculated MAC), the frame generation unit 905 is notified to transfer the data frame with the MAC deleted and determined as an appropriate frame (message), When the MAC verification fails, it is determined that the frame is invalid, and the frame transfer is stopped.
  • the transfer control unit 906 requests the MAC control unit 920 to perform MAC verification, and when the MAC control unit 920 succeeds in MAC verification.
  • the frame generation unit 905 is notified to determine that the frame is proper and to transfer the data frame without deleting the MAC.
  • the frame generation unit 905 determines that the frame is invalid and stops the frame transfer. In the case where the MAC is not deleted, if the MAC key is different for each bus, the frame is transferred by replacing the MAC with a MAC key generated according to the transfer destination bus.
  • the transfer control unit 906 requests the MAC control unit 920 to generate a MAC, and the MAC value generated by the MAC control unit 920 Is added to the data field to notify the frame generation unit 905 to transfer the frame.
  • the transfer control unit 906 transfers the frame without requesting the MAC control unit 920 to verify and generate the MAC.
  • the frame generation unit 905 is notified.
  • the MAC control unit 920 has a function of generating a MAC and verifying the MAC.
  • the MAC control unit 920 receives the message ID, data value, and counter stored in the counter holding unit 922 from the transfer control unit 906.
  • the MAC key held by the MAC key holding unit 921 (corresponding to the message ID in the MAC key list 9210) is combined with the value (counter value managed in the counter list 9220 corresponding to the message ID).
  • the MAC value is calculated using the managed MAC key, and the calculated MAC value is compared with the MAC value in the data field of the received frame notified from the transfer control unit 906.
  • the transfer control unit 906 is notified that the verification has succeeded, and if they do not match, the transfer control unit 906 is notified that the verification has failed.
  • the MAC control unit 920 holds the message ID, data value, and counter holding unit 922 notified from the transfer control unit 906.
  • the MAC key held by the MAC key holding unit 921 (the MAC key list corresponding to the message ID) with respect to the value obtained by combining the counter value (the counter value managed in the counter list 9220 corresponding to the message ID) MAC value is calculated using the MAC key managed in 9210), and the MAC value which is the calculation result is notified to the transfer control unit 906.
  • the MAC control unit 920 calculates the MAC using the MAC key, and uses, for example, the first 4 bytes of the calculated result as the MAC value.
  • the MAC key uses, for example, the first 4 bytes of the calculated result as the MAC value.
  • the MAC value uses, for example, the first 4 bytes of the calculated result as the MAC value.
  • an example has been described in which three of the message ID, the data value, and the counter value held by the counter holding unit 922 are used to calculate the MAC, but any one or two of them is used. May be used for MAC calculation, or the contents of other fields in the frame (eg, DLC) may be used for MAC calculation.
  • As a MAC calculation method for example, HMAC (Hash-based Message Authentication Code), CBC-MAC (Cipher Block Chaining Message Authentication Code), or the like can be used.
  • the MAC key holding unit 921 holds a MAC key list 9210 for managing MAC keys necessary for calculating a MAC value.
  • the MAC key list 9210 will be described later with reference to FIG.
  • the counter holding unit 922 holds a counter list 9220 that manages counter values necessary for calculating a MAC value.
  • the counter list 9220 will be described later with reference to FIG.
  • the counter value is held for each message ID of a frame to be transmitted / received, for example, for each bus.
  • the counter holding unit 922 increments the counter value of the corresponding message ID in the held counter list 9220 by one.
  • the counter holding unit 922 may hold a counter list 9220 for each bus, for example.
  • the transfer rule holding unit 907 holds transfer rule information, which is information indicating a rule for frame transfer for each bus, and bus information indicating whether each bus is a MAC-compatible bus or a MAC non-compatible bus.
  • FIG. 6 shows an example of bus information
  • FIG. 7 shows an example of transfer rule information.
  • the frame generation unit 905 configures an error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 902, and notifies the frame transmission / reception unit 901 to transmit the error frame.
  • the frame generation unit 905 configures a transmission frame using the message ID notified from the transfer control unit 906 and the contents of the data field in accordance with a transmission request from the transfer control unit 906, and Transfer destination bus information (a bus ID that is an identifier of the transfer destination bus) is notified to the frame transmission / reception unit 901.
  • FIG. 6 shows an example of bus information held by the transfer rule holding unit 907 of the gateway 90.
  • the bus information 9070 in FIG. 6 is information indicating whether each bus is a MAC-compatible bus or a MAC non-compatible bus for each bus.
  • the example of FIG. 6 is an example in which the code of each bus shown in FIG. 1 is the identifier (bus ID) of the bus.
  • the bus 10 whose bus ID is 10 is a MAC-compatible bus, and indicates that a MAC-compatible ECU is connected to the bus 10, that is, the ECU 100 connected to the bus 10,
  • Reference numeral 101 denotes a MAC-compatible ECU.
  • the bus 40 with the bus ID 40 is a non-MAC bus, and this indicates that no MAC compatible ECU is connected to the bus 40, that is, the ECUs 400 and 401 connected to the bus 40 are connected. This indicates that the ECU is not MAC-compatible.
  • FIG. 7 shows an example of transfer rule information held by the transfer rule holding unit 907 of the gateway 90.
  • the transfer rule information 9071 in FIG. 7 associates the transfer source bus, the transfer destination bus, and the ID (message ID) of the data frame (message) to be transferred.
  • the transfer rule information 9071 indicates a criterion for the gateway 90 to select a transfer destination bus that is a transfer destination of a received frame from a plurality of buses.
  • the transfer source bus ID in FIG. 7 is a bus ID indicating from which bus the frame received by the gateway 90 is received.
  • the transfer destination bus ID in FIG. 7 is a bus ID indicating a bus that is a transfer destination (that is, a transmission destination) of a frame received by the gateway 90.
  • this transfer destination bus ID is notified to the frame transmission / reception unit 901 as transfer destination bus information
  • the frame transmission / reception unit 901 transmits a frame to a bus corresponding to the transfer destination bus information.
  • the example of FIG. 7 is an example in which the code of each bus shown in FIG. 1 is the bus ID of the bus.
  • the gateway 90 determines whether or not to perform transfer and which bus is selected as the transfer destination bus.
  • FIG. 8 shows an example of a MAC key list held by the MAC key holding unit 921 of the gateway 90.
  • the MAC key list 9210 in FIG. 8 is a list in which MAC keys corresponding to message IDs are registered for each message ID, and is used in MAC generation and verification by the MAC control unit 920.
  • FIG. 8 shows an example in which a different MAC key is held for each message ID, but the MAC key holding unit 921 may hold an individual MAC key for each bus.
  • the bus ID and the key value corresponding to the bus ID are registered in the MAC key list 9210.
  • the gateway 90 sets a MAC generated by newly generating a MAC using a MAC key corresponding to the transfer destination bus to a transmission frame when transferring the frame. Then send.
  • FIG. 9 shows an example of a counter list held by the counter holding unit 922 of the gateway 90.
  • the counter list 9220 in FIG. 9 is a list in which counter values corresponding to message IDs are recorded as a list for each message ID, and is used in MAC generation and verification by the MAC control unit 920.
  • FIG. 9 shows an example in which individual counter values are held for each message ID, but the counter holding unit 922 may hold individual counter values for each bus.
  • a bus ID and a counter value corresponding to the bus ID are recorded in the counter list 9220.
  • FIGS. 10 and 11 show an operation example in which a frame transmitted by the transfer source ECU is received from one bus and the gateway 90 transfers the frame to another bus to which the transfer destination ECU is connected.
  • Each of the one bus and the other bus may be a MAC-compatible bus, or may be a non-MAC compatible bus.
  • both the MAC compatible ECU and the MAC non-compliant ECU can be the transfer source ECU and the transfer destination ECU.
  • the transfer source ECU transmits a frame (message) to the bus to which the transfer source ECU itself is connected (step S1001).
  • a frame message
  • transmission of a frame is broadcast, and each node connected to the bus can receive the frame.
  • the gateway 90 is also connected to the bus to which the transfer source ECU is connected, and the frame transmission / reception unit 901 of the gateway 90 receives the frame from the transfer source ECU (step S1002).
  • the reception ID determination unit 903 of the gateway 90 is such that the message ID of the received frame (message) notified from the frame interpretation unit 902 is described in the reception ID list held by the reception ID list holding unit 904. Whether or not it is a frame to be received (a frame including an ID to be received) is determined (step S1003). If it is not a frame to be received, the gateway 90 stops transferring the received frame (that is, does not transfer).
  • step S1003 If it is determined in step S1003 that the frame is to be received, the transfer control unit 906 of the gateway 90 refers to the transfer rule information 9071 held by the transfer rule holding unit 907 and transfers it to any bus. It is determined whether the frame has a message ID to be transferred, and if it is a frame to be transferred, a transfer destination bus is selected (step S1004). If it is not the frame of the message ID to be transferred, the gateway 90 stops transferring the received frame.
  • the transfer control unit 906 refers to the bus information 9070 held by the transfer rule holding unit 907, and is the transfer source that is the bus that has received the frame. It is determined whether the bus is a MAC-compatible bus (step S1005). If the bus is a MAC-compatible bus, the process proceeds to step S1006. If the bus is not a MAC-compatible bus (that is, a MAC-incompatible bus), the process proceeds to step S1006. The process is skipped and the process proceeds to step S1007.
  • step S1006 the MAC control unit 920 of the gateway 90 determines the MAC corresponding to the message ID of the received frame from the MAC key list 9210 held by the MAC key holding unit 921 and the counter list 9220 held by the counter holding unit 922.
  • the MAC value is calculated using the key and the counter, and the MAC value of the calculation result is compared with the MAC in the data field of the received frame to verify the received frame (MAC verification). If it is determined that the frame is an illegal frame as a result of the MAC verification (if verification fails), the gateway 90 stops the transfer of the frame. If it is determined that the frame is an appropriate frame as a result of the MAC verification (if verification is successful), the process proceeds to step S1007. When the verification is successful, the gateway 90 increments the counter value corresponding to the message ID of the frame in the counter list 9220 by 1 for subsequent MAC verification.
  • step S1007 the transfer control unit 906 refers to the bus information 9070 held by the transfer rule holding unit 907 and determines whether or not the transfer destination bus is a MAC-compatible bus. If it is determined in step S1007 that the transfer destination bus is a MAC-compatible bus, the process proceeds to step S1010. If it is determined that the transfer destination bus is not a MAC-compatible bus, the process proceeds to step S1008.
  • step S1008 the transfer control unit 906 deletes the MAC part from the data field of the frame. Subsequently, the transfer control unit 906 subtracts the size (data length) of the MAC deleted in step S1008 from the DLC value (step S1009), and proceeds to step S1013.
  • the MAC is not attached to the data field of the frame received by the gateway 90 (that is, when the transfer source bus is a non-MAC bus)
  • the MAC is deleted and the size of the MAC in steps S1008 and S1009. No subtraction from DLC.
  • step S1010 the transfer control unit 906 checks whether or not a MAC is attached to the frame received from the transfer source bus. If the MAC is not attached, the transfer control unit 906 requests the MAC control unit 920 to generate a MAC to be included in the transmission frame transmitted to the transfer destination bus, and the process proceeds to S1011. If MAC is attached, the process proceeds to step S1013.
  • step S1011 the MAC control unit 920 recalculates the size of the data field that increases due to the addition of the MAC, and sets the value in the DLC. Subsequently, the MAC control unit 920 combines a message ID notified from the transfer control unit 906, a data value, and a counter value corresponding to the message ID in the counter list 9220 held by the counter holding unit 922. On the other hand, the MAC value corresponding to the message ID in the MAC key list 9210 held by the MAC key holding unit 921 is calculated, and the MAC value as the calculation result is notified to the transfer control unit 906 ( Step S1012). Upon receiving this notification, the transfer control unit 906 adds a MAC to the data field.
  • step S1010 when the MAC is added to the received frame, or after the processing in step S1009 or step S1012, the transfer control unit 906 sends a message ID, a data field, a DLC, and a frame generation unit 905 to the frame ID. Transfer destination bus information (transfer destination bus ID) is notified. As a result, the frame generation unit 905 uses the message ID notified from the transfer control unit 906 and the data field to recalculate the CRC to form a transmission frame, and transfer destination bus information (transfer destination bus ID). Then, the transmission / reception unit 901 is notified of the transmission frame (step S1013).
  • the frame transmission / reception unit 901 of the gateway 90 transmits the transmission frame generated by the frame generation unit 905 to the bus indicated by the transfer destination bus information (that is, the transfer destination bus) (step S1014). Thereby, frame transfer between the buses is realized by the gateway 90.
  • the transfer destination ECU connected to the transfer destination bus receives the frame transmitted (transferred) by the gateway 90 (step S1015).
  • the transfer unit When the predetermined deletion condition for deleting the verification information is satisfied for the first frame (for example, the frame including the MAC) including the verification information received by the reception unit, the transfer unit is By generating a second frame including information based on the content of the frame excluding verification information (for example, a frame not including the MAC) and transmitting the second frame to the transfer destination bus, the frame is transferred. Can be done.
  • the transfer unit receives information based on the content of the frame. The frame can be transferred by generating a frame including the verification information and transmitting the generated frame to the transfer destination bus.
  • the transfer unit may transmit the second frame including the contents of the data field other than the MAC in the first frame and not including the MAC to the transfer destination bus.
  • the gateway 90 deletes the MAC when the MAC-compatible ECU is not connected to the transfer destination bus (that is, when the transfer destination bus is a non-MAC compatible bus), and transmits the frame.
  • the amount of traffic on the transfer destination bus can be reduced. That is, when a frame is transferred to a specific bus, the MAC can be deleted and transmitted, so that the ECU connected to the bus does not need to process the MAC. This can lead to the realization of efficient ECU organization in the in-vehicle network system.
  • the gateway 90 verifies the MAC at the time of transfer and stops the transfer of an illegal frame if the verification fails, the security can be improved to some extent even when the MAC is deleted and the frame is transferred. It becomes possible. Further, the gateway 90 does not transfer an illegal frame when the MAC verification fails, so that the processing load for dealing with the illegal frame for the ECU connected to the transfer destination bus can be reduced.
  • the above-described transfer unit in the gateway 90 when the predetermined deletion condition for deleting the verification information is not satisfied for the first frame including the verification information received by the receiving unit, Generate a second frame including information based on the content of the frame excluding the verification information and verification information generated using a key shared with the ECU connected to the transfer destination bus.
  • the second frame may be transmitted to the destination bus. This can increase the security of the frame.
  • the gateway device on the condition that the transfer destination bus is a non-MAC bus, deletes the MAC that is the verification information in the frame when transferring the frame.
  • a condition that the bus occupancy rate of the transfer destination bus is higher than a predetermined value is added as a predetermined deletion condition for deleting the MAC.
  • the gateway device detects the communication state of each bus connected to its own device, and measures or calculates the degree of occupancy of each bus (for example, the proportion of time not in the bus idle state), for example, As the bus occupancy rate for the bus, it is used for determining whether or not the MAC should be deleted during transfer.
  • the components of the in-vehicle network system including the gateway device in the present embodiment are generally the same as those in the first embodiment, the same reference numerals as those in the first embodiment are used here. Here, differences from the first embodiment will be described, and points not described here are the same as in the first embodiment.
  • the transfer rule holding unit 907 of the gateway 90 holds a MAC deletion condition list 9072 in addition to the bus information 9070 and the transfer rule information 9071.
  • FIG. 12 shows an example of the MAC deletion condition list held by the transfer rule holding unit 907 of the gateway 90.
  • the MAC deletion condition list 9072 in FIG. 12 is information in which a transfer destination bus ID (a bus ID of a transfer destination bus) and a MAC deletion condition are associated with each bus that is a MAC-compatible bus.
  • the example of FIG. 12 is an example in which the code of each bus shown in FIG. 1 is the identifier (bus ID) of the bus.
  • the gateway 90 deletes and transfers the MAC if the bus occupation rate of the bus 10 is 50% or more.
  • the bus occupancy rate of the bus 20 is 40% or more, which is the MAC deletion condition. ing.
  • the gateway 90 can determine the MAC deletion condition that the bus occupancy rate of the transfer destination bus is higher than a predetermined value (for example, 50%). However, this predetermined value may be different for each bus.
  • the transfer control unit 906 of the gateway 90 has a function of calculating the bus occupancy rate of the transfer destination bus, and implements the MAC deletion condition related to the bus occupancy rate indicated by the MAC deletion condition list 9072 according to the implementation. This is applied together with the MAC deletion condition that the transfer destination bus shown in mode 1 is a non-MAC bus. Note that the gateway 90 may determine whether or not to delete the MAC using only the MAC deletion condition related to the bus occupancy rate.
  • the frame transmission / reception unit 901 of the gateway 90 receives the frame transmitted by the transfer source ECU in step S2001 from the transfer source bus (step S2002).
  • the transfer control unit 906 of the gateway 90 refers to the transfer rule information 9071 to determine whether the frame has a message ID to be transferred to any bus. If the frame is to be transferred, the transfer destination bus is selected (step S2004).
  • step S2004 When it is determined in step S2004 that the frame is a message ID to be transferred, the transfer control unit 906 determines whether or not the frame includes a MAC (step S2005). If YES in step S2006, the process advances to step S2006. If the MAC is not included, the process in step S2006 is skipped, and the process advances to step S2007. For example, the transfer control unit 906 refers to the bus information 9070 held by the transfer rule holding unit 907 to determine whether the received frame contains a MAC. Judgment is made based on whether or not the bus.
  • the transfer source bus is a MAC-compatible bus
  • the received frame includes the MAC
  • the transfer source bus is a MAC-incompatible bus
  • the transfer control unit 906 may determine whether or not the MAC is added based on the DLC value if the size of data in the frame is predetermined for each message ID.
  • the gateway device in the in-vehicle network system 1 may include information indicating whether or not the MAC is included in the frame in the frame transmitted to the transfer destination bus. Based on this information, the transfer control unit 906 can determine whether or not the received frame includes a MAC.
  • step S2006 the MAC control unit 920 of the gateway 90 calculates a MAC value from the MAC key list 9210 and the held counter list 9220 using a MAC key and a counter corresponding to the message ID of the received frame.
  • the MAC value of the calculation result is compared with the MAC in the data field of the received frame, and the received frame is verified (MAC verification). If it is determined that the frame is an illegal frame as a result of the MAC verification (if verification fails), the gateway 90 stops the transfer of the frame. If it is determined that the frame is an appropriate frame as a result of the MAC verification (if verification is successful), the process proceeds to step S2007.
  • step S2007 the transfer control unit 906 refers to the bus information 9070 held by the transfer rule holding unit 907 and determines whether or not the transfer destination bus is a MAC-compatible bus. As a result of the determination in step S2007, if it is determined that the transfer destination bus is a MAC compatible bus, the process proceeds to step S2010, and if it is determined that the transfer destination bus is not a MAC compatible bus, the process proceeds to step S2008.
  • step S2008 the transfer control unit 906 deletes the MAC part from the data field of the frame. Subsequently, the transfer control unit 906 subtracts the size of the MAC deleted in step S2008 from the DLC value (step S2009), and proceeds to step S2014. Note that when the MAC is not attached to the data field of the frame received by the gateway 90, the MAC is not deleted and the MAC size is not subtracted from the DLC in steps S2008 and S2009.
  • step S2010 the transfer control unit 906 calculates the bus occupancy rate for the transfer destination bus and compares it with the conditions of the MAC deletion condition list 9072 held by the transfer rule holding unit 907, and the MAC deletion condition is satisfied. Determine whether or not. When the MAC deletion condition is satisfied, the process moves to step S2008 to delete the MAC.
  • step S2010 When it is determined in step S2010 that the MAC deletion condition is not satisfied, the transfer control unit 906 checks whether or not the MAC received from the transfer source bus is attached (step S2011). If the MAC is not attached, the transfer control unit 906 requests the MAC control unit 920 to generate a MAC to be included in the transmission frame transmitted to the transfer destination bus, and the process proceeds to S2012. If MAC is attached, the process proceeds to step S2014.
  • step S2012 the MAC control unit 920 recalculates the size of the data field that increases due to the addition of the MAC, and sets the value in the DLC. Subsequently, the MAC control unit 920 uses the MAC key list 9210 for the value obtained by combining the message ID notified from the transfer control unit 906, the data value, and the counter value corresponding to the message ID in the counter list 9220. The MAC value corresponding to the message ID is calculated, and the MAC value as the calculation result is notified to the transfer control unit 906 (step S2013). Upon receiving this notification, the transfer control unit 906 adds a MAC to the data field.
  • step S2011 when the received frame is attached with MAC, or after the processing in step S2009 or step S2013, the transfer control unit 906 sends a message ID, a data field, a DLC, and a message to the frame generation unit 905.
  • Transfer destination bus information (transfer destination bus ID) is notified.
  • the frame generation unit 905 uses the message ID notified from the transfer control unit 906 and the data field to recalculate the CRC to form a transmission frame, and transfer destination bus information (transfer destination bus ID). Then, the transmission / reception unit 901 is notified of the transmission frame (step S2014).
  • the frame transmission / reception unit 901 of the gateway 90 transmits the transmission frame generated by the frame generation unit 905 to the bus indicated by the transfer destination bus information (that is, the transfer destination bus) (step S2015). Thereby, frame transfer between the buses is realized by the gateway 90.
  • the transfer destination ECU connected to the transfer destination bus receives the frame transmitted (transferred) by the gateway 90 (step S2016).
  • the MAC may be deleted according to the bus occupancy rate from the contents of the data field in the received frame.
  • the data size of the frame of the message ID to be processed by the MAC-compatible ECU is determined in advance by the specification or the like, is the MAC added by the DLC value? It becomes possible to determine whether or not.
  • the frame includes information indicating whether the frame includes MAC (information for verification) (for example, a flag using a 1-bit area in the data field). If the gateway 90 deletes the MAC, information indicating that the MAC is not included can be included in the frame. In this case, the MAC-compatible ECU that has received the frame in step S2015 verifies the MAC if the MAC is included based on the information indicating whether or not the MAC is included, and the MAC is included. Otherwise, it is possible to take measures such as not performing MAC verification.
  • the gateway 90 transfers a frame (message)
  • the MAC-compatible ECU is not connected to the transfer destination bus (that is, the transfer destination bus is a non-MAC compatible bus).
  • the MAC is deleted and transmitted even if the bus occupancy of the transfer destination bus is high enough to satisfy the MAC deletion condition. The amount of traffic on the destination bus can be reduced.
  • the gateway 90 transfers a frame including the MAC, and therefore the MAC connected to the transfer destination bus For the corresponding ECU, it is possible to determine whether or not the frame is illegal by verifying the MAC, and security of the in-vehicle network can be ensured.
  • the third embodiment shows an example in which it is determined for each bus whether the CAN standard format or the extended format is used.
  • the extended format is a format defined by CAN-FD (CAN with Flexible Data Rate), which is a derived protocol of CAN.
  • the components of the in-vehicle network system including the gateway device in the present embodiment are generally the same as those in the first embodiment, the same reference numerals as those in the first embodiment are used here. Here, differences from the first embodiment will be described, and points not described here are the same as in the first embodiment.
  • FIG. 15 is a diagram showing a standard format and an extended format of a data frame.
  • 15A shows a CAN standard format similar to that shown in FIG. 2, and
  • FIG. 15B shows an extended format which is a format defined by CAN-FD.
  • the ID (message ID) is 11 bits and the data field is 64 bits, whereas in the extended format, the base ID of the ID field in the standard format is 11 bits, and the extended ID is 18 bits.
  • the ID (message ID) is represented by 29 bits and the data field is expanded to 512 bits.
  • the transfer rule holding unit 907 of the gateway 90 holds a corresponding format list 9073 as a kind of bus information.
  • FIG. 16 shows an example of a corresponding format list as a kind of bus information held by the transfer rule holding unit 907 of the gateway 90 according to the present embodiment.
  • the bus information 9070 (see FIG. 6) shown in the first embodiment is information indicating whether each bus is a MAC-compatible bus or a MAC-incompatible bus for each bus.
  • the list 9073 is information indicating, for each bus, whether the format of the data frame transmitted / received on each bus is a standard format or an extended format.
  • the example of FIG. 16 is an example in which the code of each bus shown in FIG. 1 is the identifier (bus ID) of the bus.
  • the bus 10 having a bus ID of 10 indicates that it supports transmission / reception of an extended format frame.
  • the bus 50 having the bus ID 50 corresponds to transmission / reception of a standard format frame, and does not correspond to transmission / reception of an extended format frame. Note that the contents of the corresponding format list 9073 may be included in the bus information 9070.
  • the bus connected to the MAC compatible ECU is made to correspond to the extended format
  • the bus connected to the non-MAC compatible ECU without connecting the MAC compatible ECU may be configured to correspond to the standard format.
  • the gateway 90 determines whether the transfer destination bus is a bus corresponding to a standard format or an extended format. It may be determined whether the bus is a compatible bus or a non-MAC compatible bus.
  • the gateway 90 satisfies the MAC deletion condition when it is associated with a predetermined frame format by a correspondence format list (information in which a bus and a frame format are associated with each bus), which is a type of bus information.
  • a correspondence format list information in which a bus and a frame format are associated with each bus
  • FIG. 17 is a diagram showing a format conversion example related to transfer when the frame transfer source bus is a MAC compatible bus corresponding to the standard format and the transfer destination bus is a MAC non-compatible bus compatible with the extended format.
  • the transfer control unit 906 of the gateway 90 determines that the transfer destination bus is a MAC non-compliant bus, deletes the MAC of the data field of the received frame, and changes the format from the standard format to the extended format. Change and control to forward.
  • the transfer control unit 906 instructs the frame generation unit 905 to integrate and transfer a plurality of received standard format data frames into one extended format frame, as shown in FIG. To do.
  • the frame generation unit 905 combines a plurality of data received from the transfer control unit 906 into one data to generate an extended format frame.
  • the frame transmission / reception unit 901 transmits the extended format frame generated by the frame generation unit 905 to the transfer destination bus.
  • the determination as to whether the gateway 90 adds or deletes a MAC when transferring a frame is the same as in the first embodiment (see FIGS. 10 and 11). This determination may be made based on the bus occupancy rate of the transfer destination bus as shown in the second embodiment (see FIGS. 13 and 14).
  • the gateway 90 When transferring from the bus corresponding to the standard format to the bus corresponding to the extended format, the gateway 90 does not immediately transfer the received data frame of the standard format, for example, but waits for a certain time and continues in the same time. If one or more frames of the message ID can be received, the converted frames are converted together and then the converted frames are transmitted (transferred) to the transfer destination bus. If a subsequent frame with the same message ID cannot be received while waiting for a certain time, only the data frame that has been received at the elapse of the certain time is converted into an extended format and transferred. Note that the gateway 90 does not have to integrate frames at the time of transfer. For example, each time a single standard format frame is received, the gateway 90 may transmit one extended format frame.
  • FIG. 18 is a diagram showing a format conversion example related to transfer when the frame transfer source bus is a MAC compatible bus corresponding to the extended format and the transfer destination bus is a MAC non-compatible bus compatible with the standard format.
  • the transfer control unit 906 of the gateway 90 determines that the transfer destination bus is a MAC non-compliant bus, deletes the MAC of the data field of the received frame, and changes the format from the extended format to the standard format. Change and control to forward.
  • the transfer control unit 906 may transfer the frame as one standard format frame according to the length of the data field of the received extended format data frame, as shown in FIG. If the data does not fit in the standard format data field, the frame generation unit 905 is instructed to divide and transfer the data into a plurality of standard format frames.
  • the frame generation unit 905 divides the data received from the transfer control unit 906 into a plurality of data as necessary, and generates each data frame in a standard format in which each data is stored in the data field. To do. Then, the frame transmission / reception unit 901 transmits each frame of the standard format generated by the frame generation unit 905 to the transfer destination bus.
  • the gateway 90 may perform transmission continuously when transmitting a plurality of frames by division, or may perform transmission intermittently with a predetermined transmission interval between frames, for example. .
  • the gateway 90 can convert the format when transferring the frame (message), and the MAC is used when the MAC-compatible ECU is not connected to the transfer destination bus. Since it is deleted and transmitted, the traffic volume of the transfer destination bus can be suppressed.
  • Embodiments 1 to 3 have been described as examples of the technology according to the present disclosure.
  • the technology according to the present disclosure is not limited to this, and can also be applied to embodiments in which changes, replacements, additions, omissions, and the like are appropriately performed.
  • the following modifications are also included in one embodiment of the present disclosure.
  • the MAC of a frame at the time of transfer is based on whether the transfer destination bus is a MAC-compatible bus, the bus occupation rate of the transfer destination bus, the format of the frame supported by the transfer destination bus, etc.
  • the gateway 90 determines whether or not to delete is shown, it may be determined using a combination of these, or may be determined using other conditions.
  • the gateway transfers the frame without deleting the MAC (or adding the MAC if it is not added).
  • a MAC non-compatible ECU may be connected to the MAC compatible bus. In this case, the MAC-incompatible ECU does not verify the MAC included in the frame, but the MAC-compatible ECU verifies the MAC, so that security can be ensured.
  • the gateway 90 when the gateway 90 transfers the frame including the MAC, when the bus occupancy of the transfer destination bus is lower than the occupancy determined as the MAC deletion condition, although an example in which the frame is transferred (transmitted) to the transfer destination bus without changing the contents of the data field of the frame including the MAC has been described, the frame may be transferred after being replaced.
  • the MAC key may be an individual MAC key for each ECU, or ECUs connected on the same bus may use the same MAC key.
  • the gateway 90 sets the contents of the data field of the frame.
  • a frame to which the MAC is added may be configured and transferred (transmitted) to the transfer destination bus.
  • the gateway 90 deletes the MAC from the data frame in the CAN standard format, and transmits a plurality of data frames as one CAN-FD extended format data frame.
  • the MAC may be added to the extended format data frame and transmitted.
  • the MAC included in the data frame of the extended format may be calculated based on the MAC in the data frame of the standard format (for example, by combining a plurality of MACs), or the plurality of data frames of the standard format
  • the MAC may be calculated based on the data included in the extended format data frame, which is a combination of the data in the above.
  • the gateway 90 may delete the MAC for a plurality of frames and transfer the frames together in one standard format.
  • the gateway 90 converts the 4 bytes of data in the data fields of two frames into one.
  • the data may be collectively stored as 8 bytes, stored in the data field, and transferred as a standard format data frame.
  • the gateway 90 may transfer the contents of a plurality of frames from which the MAC is deleted as one frame of the extended format.
  • an in-vehicle network system may be configured to include a plurality of gateway devices, and a plurality of gateway devices are connected to one bus. obtain.
  • Each gateway device can perform processing related to transfer similar to the gateway 90 described in each embodiment.
  • the gateway 90 is shown for each bus, which distinguishes whether the bus is a MAC-compatible bus and determines whether to delete or add a MAC when transferring a frame.
  • the MAC is an example of frame verification information, and may be information used for other verification. That is, the gateway 90 is a verification-compatible bus (for example, a MAC-compatible bus) to which an ECU having a frame verification function based on verification information (for example, MAC) is connected for each bus, or an ECU having a verification function. Based on the bus information indicating whether the bus is not connected to a verification non-compliant bus (for example, a MAC non-compliant bus), the determination regarding the deletion or addition of the verification information can be performed.
  • a verification non-compliant bus for example, a MAC non-compliant bus
  • the gateway 90 previously associates the message ID of the frame with whether the ECU that processes the frame of the message ID in the transfer destination bus is a MAC-compatible ECU or a MAC-incompatible ECU when transferring the frame. It is also possible to determine whether or not to delete a MAC or whether or not to add a MAC using the stored information. As a specific example, for each message ID, the gateway 90 distinguishes between a verification message identifier that is subject to processing such as verification by a MAC-compatible ECU and a non-verification message identifier that is not subject to processing such as verification. May be determined based on the message identifier information as to whether a deletion condition for deleting the MAC is satisfied according to the message ID of the received frame.
  • the gateway 90 can delete the MAC and transfer it, assuming that the MAC deletion condition is satisfied.
  • message identifier information may be included in the bus information, and the gateway 90 determines that the received frame identifier is a non-verification message identifier when the transfer destination bus is a verification compatible bus (for example, a MAC compatible bus).
  • the MAC may be deleted and transfer may be performed.
  • the gateway 90 holds, for each ECU, ECU information indicating whether the ECU is a MAC-compatible ECU (an ECU having a frame verification function based on the MAC), and there is a deletion condition for deleting the MAC. It may be determined based on this ECU information whether or not it is satisfied. For example, if the gateway 90 is connected to a transfer destination bus that is a transfer destination of a received frame and an ECU that executes processing according to the frame is not a MAC-compatible ECU, You can delete and transfer. When transferring a frame, the gateway 90 may store and use information indicating which ECU is connected to which bus, and which ECU includes a frame including which message ID. The information shown may be retained and used.
  • ECU information indicating whether the ECU is a MAC-compatible ECU (an ECU having a frame verification function based on the MAC), and there is a deletion condition for deleting the MAC. It may be determined based on this ECU information whether or not it is satisfied. For example,
  • the gateway 90 is processed by the MAC compatible ECU for each bus ID, a list indicating whether the bus is MAC compatible for each bus, a list indicating whether the ECU is a MAC compatible ECU for each ECU that can receive a frame, It is possible to determine whether or not to delete the MAC of the frame at the time of transfer by appropriately using a list indicating whether or not, and using the bus occupancy rate of the transfer destination bus as necessary.
  • the gateway 90 determines whether or not to delete the MAC when transferring a frame depending on whether or not the bus is a MAC-compatible bus (a bus to which a MAC-compatible ECU is connected). showed that.
  • a MAC-compatible ECU and a non-MAC-compatible ECU are connected to one bus
  • the gateway 90 receives the frame, the frame including the MAC for the MAC-compatible ECU and the frame
  • the frame transfer may be realized by transmitting a frame from which the MAC has been deleted for a non-MAC-compliant ECU having a different message ID.
  • the contents of the first frame A frame is transferred by generating a second frame including information based on the content excluding the verification information and not including the verification information, and transmitting the second frame to the transfer destination bus. It is also possible to transmit a third frame that includes information based on the content of the first frame excluding the verification information, includes verification information, and has a frame identifier different from the second frame.
  • the message ID of each of the two types of frames transmitted from the gateway 90 is determined in advance in the in-vehicle network system 1, and each ECU identifies and receives the necessary message ID.
  • the gateway 90 described in the above embodiment verifies the MAC at the time of transfer, for example, in step S1006.
  • the gateway 90 determines in advance a part of the frame to be transferred when the MAC verification is successful. Regardless of whether or not the MAC is deleted, a value indicating that the MAC verification is successful may be set in the flag area. In this case, when the ECU connected to the transfer destination bus receives a frame in which a value indicating that the MAC verification is successful is set in the flag area, the verification process of the MAC for the frame is omitted. Also good. Thereby, effects such as reduction in processing load on the ECU and power saving are produced.
  • the gateway 90 has stopped transferring the frame when the verification of the MAC of the received frame fails. However, when the verification of the MAC of the frame fails, the frame The gateway 90 may store the message ID of the message ID, and the gateway 90 may not receive the frame even if it receives the frame of the message ID thereafter.
  • the gateway 90 deletes the MAC for the frame.
  • addition may be performed.
  • the gateway 90 only needs to have a function of transferring a frame received from one network to another network, and transfers a frame received from a network other than the bus (for example, a wireless network) to the CAN bus. There may be.
  • the difference in the communication protocol type corresponding to each of the network that received the frame and the transfer destination network is, for example, a difference in the network type.
  • the type of communication protocol used for communication on the bus may be associated with each bus. For example, when the gateway 90 is connected to Ethernet (registered trademark) in addition to the CAN bus, and the transfer source network is Ethernet (registered trademark) and the transfer destination network is a CAN bus, the gateway 90 is It may be determined that the MAC deletion condition is satisfied, and the MAC may be deleted. Further, when the transfer source network is a CAN bus and the transfer destination network is Ethernet (registered trademark), the gateway 90 may add a MAC.
  • the network type (communication protocol) related to the transfer source network and the transfer destination network as conditions for MAC deletion or addition may be any network, for example, CAN, CAN-FD, Ethernet (registration). (Trademark), LIN (Local Interconnect Network), Flexray (registered trademark), or the like.
  • a MAC is added when a network whose frame length is longer than a certain value is set as a transfer destination, and when a network whose frame length is shorter than the certain value is set as a transfer destination. You may use the method of deleting.
  • the gateway 90 described in the above embodiment deletes the MAC from the content of the decrypted frame after decrypting the frame, Or it is good also as adding MAC to the content of the decoded flame
  • the contents of the frame may be encrypted again.
  • the gateway 90 may transmit the content of the frame in plain text by decryption when forwarding, such as when the transfer destination ECU does not have a decryption function.
  • the ECU that has received this frame can reduce the load of the decoding process.
  • the transfer destination ECU has a decryption function
  • the content of the frame may be encrypted and transmitted with a key corresponding to the ECU. At this time, if encrypted and transferred by the common key encryption method, re-encryption may be performed using a key shared between the gateway 90 and the transfer destination ECU.
  • the MAC-compatible bus shown in the above embodiment is a bus to which a MAC-compatible ECU is connected.
  • the MAC-compatible bus is, for example, a bus to which a frame including a MAC should flow. It is good to be.
  • the non-MAC compatible bus may be, for example, a bus through which a frame that does not include a MAC is to flow.
  • an ECU suitable for the bus can be added at any time.
  • the gateway 90 described in the above embodiment includes a function of deleting a MAC under a certain condition when transferring a frame and a function of adding a MAC under a certain condition. However, only one of the functions is included. May be included.
  • Each ECU (including the gateway) in the above embodiment is a device including a digital circuit such as a processor and a memory, an analog circuit, a communication circuit, and the like.
  • a digital circuit such as a processor and a memory
  • an analog circuit such as a communication circuit, and the like.
  • a hard disk device such as a display, a keyboard, Other hardware components such as a mouse may be included.
  • the function may be realized by dedicated hardware (digital circuit or the like).
  • a part or all of the constituent elements constituting each device in the above embodiment may be constituted by one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip.
  • the system LSI is a computer system including a microprocessor, a ROM, a RAM, and the like. .
  • a computer program is recorded in the RAM.
  • the system LSI achieves its functions by the microprocessor operating according to the computer program.
  • each part of the components constituting each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • the system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of the circuit cells inside the LSI may be used.
  • integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. Biotechnology can be applied as a possibility.
  • a part or all of the constituent elements constituting each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system including a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the super multifunctional LSI described above.
  • the IC card or the module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.
  • the transfer method includes a reception step for receiving a frame, and when the frame is received in the reception step, the frame is transferred to a transfer destination bus which is one of the buses, and verification information used for verifying the frame.
  • the present invention may be a computer program that realizes this method by a computer, or may be a digital signal composed of the computer program.
  • a computer-readable recording medium such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray (registered trademark) Disc), recorded on a semiconductor memory or the like.
  • the digital signal may be recorded on these recording media.
  • the computer program or the digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • an aspect of the present disclosure may be a computer system including a microprocessor and a memory, the memory recording the computer program, and the microprocessor operating according to the computer program. .
  • the program or the digital signal is recorded on the recording medium and transferred, or the program or the digital signal is transferred via the network or the like and executed by another independent computer system. You may do that.
  • the present disclosure can be used for appropriately transferring a frame in an in-vehicle network used for transmission / reception of a frame (message) that can include verification information such as a MAC.

Abstract

複数の電子制御ユニットが通信に用いるバス（１０）、バス（２０）等に接続されたゲートウェイ（９０）は、フレームを受信するフレーム送受信部（９０１）と、フレーム送受信部（９０１）により受信されたフレームの内容からフレームの検証に用いられる検証用情報を削除してそのフレームの、転送先バスへの転送を行う、又は、そのフレームの内容に検証用情報を付加してそのフレームの、転送先バスへの転送を行うよう制御する転送制御部（９０６）等とを備える。

Description

ゲートウェイ装置、車載ネットワークシステム及び転送方法
　本開示は、電子制御ユニットが通信を行うネットワークにおいてフレームの転送を行うゲートウェイ装置に関する。
　近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic　Control　Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８－１で規定されているＣＡＮ（Controller　Area　Network）という規格が存在する。
　ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。
　またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤ（フレームの識別子）を付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたＩＤのフレームのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier　Sense　Multiple　Access/Collision　Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。
　車載ネットワークにおける複数のバスに接続されたＥＣＵの一種であるゲートウェイ装置（ＧＷ：gateway）は、バス間でフレームを転送する機能を有する。
　ところで、ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しないため、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレームを送信することで、車体を不正にコントロールしてしまう可能性がある。このような不正なフレームの送信によるコントロールを防止するために、ＣＡＮにおけるデータフィールドにメッセージ認証コード（ＭＡＣ：Message　Authentication　Code）を付加して送信することで、正規のＥＣＵが送信したフレームを識別する技術が知られている（「特許文献１」参照）。
特開２０１３－９８７１９号公報
　上記従来の技術では、更なる改善が必要とされていた。
　本開示の一態様に係るゲートウェイ装置は、複数の電子制御ユニットが通信に用いる１つ以上のバスに接続されたゲートウェイ装置であって、フレームを受信する受信部と、前記受信部により受信されたフレームの内容から当該フレームの検証に用いられる検証用情報を削除して当該フレームの、前記バスの１つである転送先バスへの転送を行う、又は、当該フレームの内容に検証用情報を付加して当該フレームの、前記転送先バスへの転送を行う、転送部とを備えるゲートウェイ装置である。
　なお、これらの全般的または具体的な態様は、装置、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、装置、システム、方法、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　上記態様によれば、更なる改善を実現することができる。
　なお、本開示の更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。
実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 実施の形態１に係るＭＡＣ非対応ＥＣＵ（ＭＡＣを処理する機能を有さないＥＣＵ）の構成図である。 実施の形態１に係るＭＡＣ対応ＥＣＵ（ＭＡＣを処理する機能を有するＥＣＵ）の構成図である。 実施の形態１に係るゲートウェイの構成図である。 実施の形態１に係るゲートウェイが保持するバス情報の一例を示す図である。 実施の形態１に係るゲートウェイが保持する転送ルール情報の一例を示す図である。 実施の形態１に係るゲートウェイが保持するＭＡＣ鍵リストの一例を示す図である。 実施の形態１に係るゲートウェイが保持するカウンタリストの一例を示す図である。 実施の形態１に係るゲートウェイによるフレームの転送に係る動作例を示すシーケンス図である（図１１に続く）。 実施の形態１に係るゲートウェイによるフレームの転送に係る動作例を示すシーケンス図である（図１０から続く）。 実施の形態２に係るゲートウェイが保持するＭＡＣ削除条件リストの一例を示す図である。 実施の形態２に係るゲートウェイによるフレームの転送に係る動作例を示すシーケンス図である（図１４に続く）。 実施の形態２に係るゲートウェイによるフレームの転送に係る動作例を示すシーケンス図である（図１３から続く）。 データフレームの標準フォーマット及び拡張フォーマットを示す図である。 実施の形態３に係るゲートウェイが保持するバス情報の一例を示す図である。 実施の形態３に係るゲートウェイによるフォーマット変換例を示す図である。 実施の形態３に係るゲートウェイによる別のフォーマット変換例を示す図である。
　（本開示の基礎となった知見）
　車両に搭載される各種ＥＣＵ間で授受されるフレームの内容は、車両のセキュリティにおいて重要性が高いものから重要性が低いものまで多岐に亘る。このため、車両に搭載される全てのＥＣＵが、フレームの検証用情報としてのＭＡＣに対応したメッセージ認証機能（検証機能）を有するように車載ネットワークシステムを構築することは、効率的ではない。
　以上の検討を踏まえ、本発明者は、本開示の各態様を想到するに至った。
　本開示の一態様に係るゲートウェイ装置は、複数の電子制御ユニットが通信に用いる１つ以上のバスに接続されたゲートウェイ装置であって、フレームを受信する受信部と、前記受信部により受信されたフレームの内容から当該フレームの検証に用いられる検証用情報を削除して当該フレームの、前記バスの１つである転送先バスへの転送を行う、又は、当該フレームの内容に検証用情報を付加して当該フレームの、前記転送先バスへの転送を行う、転送部とを備えるゲートウェイ装置である。これにより、転送に際して検証用情報の付加或いは削除がなされるので検証用情報の検証機能を有さない電子制御ユニット（ＥＣＵ）を一部に含むネットワークシステムにおいて効率的なフレームの転送が実現され得る。
　また、前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、前記検証用情報を削除するための所定削除条件が満たされた場合には、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含む第２フレームを生成して当該第２フレームを前記転送先バスに送信することで、前記転送を行うこととしても良い。これにより、一定条件下で検証用情報が削除されてフレームの転送が行われるので、検証用情報が削除されて転送された場合における転送先バスのトラフィック量が抑制され得る。また、検証用情報が削除されて転送された場合における転送先バスに接続されたＥＣＵは、検証用情報を処理する必要がなくなる。これは、例えば、ネットワークシステムにおける効率的なＥＣＵの編成の実現に繋がり得る。
　また、前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、前記検証用情報はフレームにおいてデータフィールドに配置されるメッセージ認証コードであり、前記転送部は、前記所定削除条件が満たされた場合には、前記第１フレームにおけるメッセージ認証コード以外のデータフィールドの内容を含み、メッセージ認証コードを含まない第２フレームを前記転送先バスに送信することとしても良い。これにより、車載ネットワークシステムにおいてメッセージ認証コードを用いてフレーム（メッセージ）のセキュリティを高めることが可能であり、また、フレームの転送先となるＥＣＵにおいてメッセージ認証コードが不要な場合において所定削除条件が満たされるように所定削除条件を設定しておくことで、無駄なバス占有時間が削減され得る。
　また、前記ゲートウェイ装置は、複数のバスに接続され、前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、バス毎に当該バスが、前記検証用情報に基づくフレームの検証機能を有する電子制御ユニットが接続されている検証対応バスか、前記検証機能を有する電子制御ユニットが接続されていない検証非対応バスかを示すバス情報とを保持する転送ルール保持部を備え、前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが検証非対応バスである場合には前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、フレームの転送先となる転送先バスに、検証用情報に係る検証機能を有するＥＣＵが接続されていない場合に、転送先バスに、有効利用されない検証用情報を含むフレームが送信されることが抑制され得る。
　また、前記バス情報は、検証対応バスに接続された前記検証機能を有する電子制御ユニットにより検証されるフレームの識別子である検証メッセージ識別子と、検証されないフレームの識別子である非検証メッセージ識別子とを区別するためのメッセージ識別子情報を含み、前記転送部は、前記転送先バスが検証対応バスである場合において、前記受信部により受信されたフレームの識別子が非検証メッセージ識別子であるときには前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、例えば、ある識別子（メッセージＩＤ）を有するフレームの転送先となる転送先バスに、その識別子のフレームを検証用情報に基づいて検証機能を有するＥＣＵが接続されていない場合に、転送先バスへの、有効利用されない検証用情報を含むフレームの送信が、抑制され得る。
　また、前記転送部は、前記転送先バスのバス占有率が所定値より高い場合に前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、例えば、転送先バスのトラフィック量が一定量を超えた場合には、転送先バスに接続されたＥＣＵによるフレームの検証の実行確保よりバス占有率の抑制を優先させることが可能となる。
　また、前記転送部は、前記転送先バスに送信するフレームに、当該フレームに検証用情報が含まれるか否かを表す情報を含ませることとしても良い。これにより、転送先バスに接続されたＥＣＵにおいて、例えばバス占有率の測定等を行わなくても、受信したフレームに検証用情報が含まれているか否かを容易に確認可能となる。
　また、前記ゲートウェイ装置は、前記１以上のバスに接続された電子制御ユニット毎に当該電子制御ユニットが前記検証用情報に基づくフレームの検証機能を有するか否かを示す情報を保持し、前記転送部は、前記受信部により受信されたフレームの転送先となる前記転送先バスに接続されて当該フレームに応じた処理を実行する電子制御ユニットが前記検証機能を有さない場合に、前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、フレームの転送先となる転送先バスに、そのフレームに対応して検証機能を有するＥＣＵが接続されていない場合に、転送先バスへの、有効利用されない検証用情報を含むフレームの送信が、抑制され得る。
　また、前記ゲートウェイ装置は、前記１以上のバスに接続された、前記検証用情報に基づくフレームの検証機能を有する電子制御ユニットにより、検証されるフレームの識別子である検証メッセージ識別子と、検証されないフレームの識別子である非検証メッセージ識別子とを区別するメッセージ識別子情報を保持し、前記転送部は、前記受信部により受信されたフレームの識別子が非検証メッセージ識別子であるときには前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、例えば、ある識別子（メッセージＩＤ）を有する転送対象のフレームが、ＥＣＵによる検証対象でない場合に、転送先バスへの、有効利用されない検証用情報を含むフレームの送信が、抑制され得る。また、メッセージＩＤ毎に検証用情報（例えばＭＡＣ）を含ませるか否かを定めることが可能となり、同一ＥＣＵへと転送するフレーム（メッセージ）でも、フレームの重要度に応じてＭＡＣを含ませるか否かを変えることが可能となる。
　また、前記転送部は、前記受信部により受信されたフレームの前記検証用情報に基づく検証により当該フレームが不正と判定した場合には、前記転送を行わないこととしても良い。これにより、不正なフレームが転送されることが抑制され、転送先のＥＣＵにおいて不正なフレームへ対処するための処理負荷が削減される。
　また、前記ゲートウェイ装置は、複数のバスに接続され、前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、バス毎に当該バスとフレームフォーマットとを対応付けたバス情報とを保持する転送ルール保持部を備え、前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが前記バス情報により所定のフレームフォーマットに対応付けられている場合には前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これは、例えば、所定のフレームフォーマットのバスに、フレームの検証用情報に基づく検証機能を有するＥＣＵを接続しないシステム構成において有用である。所定のフレームフォーマットとして、例えば、検証用情報の付加によるバス占有率の上昇が顕著となり易い、フレーム長が比較的短いフレームフォーマットを、定めることが有用となり得る。なお、ゲートウェイ装置は、転送元バスと転送先バスとのそれぞれに対応するフレームフォーマットが相違する場合において転送に際してフレームフォーマット変換を行っても良い。
　また、前記ゲートウェイ装置は、複数のバスに接続され、前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、バス毎に当該バスでの通信で用いられる通信プロトコルの種別を対応付けたバス情報とを保持する転送ルール保持部を備え、前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが前記バス情報により所定の通信プロトコルに対応付けられている場合には前記所定削除条件が満たされたとして、前記転送を行うこととしても良い。これにより、所定の通信プロトコルで通信するために用いられるバスにおいて検証用情報に基づく検証を行わないようにＥＣＵを編成したシステムにとって、効率的なフレームの転送が行われ得る。
　また、前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、前記検証用情報を削除するための所定削除条件が満たされなかった場合には、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報と、前記転送先バスに接続された電子制御ユニットと共有している鍵を用いて生成した検証用情報とを含む第２フレームを生成して当該第２フレームを前記転送先バスに送信することとしても良い。これにより、フレームのセキュリティを高めることが可能となる。
　また、前記転送部は、前記受信部により受信された、検証用情報を含まないフレームについて、検証用情報を付加するための所定付加条件が満たされた場合には、当該フレームの内容に基づく情報と、検証用情報とを含むフレームを生成して、生成した当該フレームを前記転送先バスに送信することで、前記転送を行うこととしても良い。これにより、例えば、検証用情報が利用されないバスにおいてフレームに検証用情報が含まれなくても、そのフレームに検証用情報が付加されて転送され得るので、転送先バスにおいてフレームについて検証用情報に基づく検証によりセキュリティを高めること等が可能となり得る。
　また、前記転送部は、前記受信部により受信されたフレームの内容が暗号化されている場合に当該フレームを復号した後に、復号した当該フレームの内容から検証用情報を削除して、又は、復号した当該フレームの内容に検証用情報を付加して、当該フレームの前記転送を行うこととしても良い。これにより、フレームの転送に際して復号がなされるので、転送先のＥＣＵは、例えば復号機能を有さなくても、受信したフレームを適切に処理できるようになる。
　また、前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含まない第２フレームを生成して当該第２フレームを前記転送先バスに送信することで、前記転送を行い、更に、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含み、前記第２フレームとは異なる、フレームの識別子を有する第３フレームを送信することとしても良い。これにより、転送先バスに、検証用情報に基づき検証するための検証機能を有するＥＣＵとその検証機能を有さないＥＣＵとが接続されている場合であっても、検証機能を有さないＥＣＵは第２フレームを受信して処理することができ、検証機能を有するＥＣＵは第３フレームを受信して検証をした上で処理することができるようになる。この場合には、検証機能を有さないＥＣＵにとって検証用情報に対応する処理負荷が削減される。
　また、本開示の一態様に係る車載ネットワークシステムは、１以上のバスを介して通信する複数の電子制御ユニットと前記バスに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、前記ゲートウェイ装置は、フレームを受信する受信部と、前記受信部により受信されたフレームの内容から当該フレームの検証に用いられる検証用情報を削除して当該フレームの、前記バスの１つである転送先バスへの転送を行う、又は、当該フレームの内容に検証用情報を付加して当該フレームの、前記転送先バスへの転送を行う、転送部とを備える車載ネットワークシステムである。これにより、何らかの通信路（例えば１つのバス）から受信したフレームの転送先バスへの転送に際して検証用情報の付加或いは削除がなされるので検証用情報の検証機能を有さない電子制御ユニット（ＥＣＵ）を一部に含む車載ネットワークシステムにおいて効率的なフレームの転送が実現され得る。
　また、前記車載ネットワークシステムは、電子制御ユニットが接続されている複数のバスを備え、前記ゲートウェイ装置は、前記複数のバスに接続され、前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報を保持する転送ルール保持部を備え、前記転送部は前記受信部により受信されたフレームの前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが、検証用情報に基づくフレームの検証機能を有する電子制御ユニットが接続されているバスであるか否かに応じて、当該フレームについて検証用情報の削除又は付加をして前記転送を行うこととしても良い。これにより、フレームの転送先となる転送先バスに、検証用情報に係る検証機能を有するＥＣＵが接続されていない場合に、転送先バスに、有効利用されない検証用情報を含むフレームが送信されることが抑制され得る。
　また、本開示の一態様に係る転送方法は、１以上のバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる転送方法であって、フレームを受信する受信ステップと、前記受信ステップでフレームが受信された場合に、前記バスの１つである転送先バスへ、当該フレームを、当該フレームの検証に用いられる検証用情報の削除又は付加をした上で、転送する転送ステップとを含む転送方法である。これにより、フレームの転送先バスへの転送に際して検証用情報の付加或いは削除がなされるので、検証用情報の検証機能を有さない電子制御ユニット（ＥＣＵ）を一部に含む車載ネットワークシステムにおいて効率的なフレームの転送が実現され得る。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
　以下、実施の形態に係るゲートウェイ装置を含む車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　以下、本開示の実施の形態として、ゲートウェイ装置を含む複数の電子制御ユニット（ＥＣＵ）がバスを介して通信する車載ネットワークシステム１について、図面を用いて説明する。本実施の形態に係るゲートウェイ装置は、受信したフレーム（メッセージとも称する）について転送先のバスへと転送するために所定の転送方法を用いる。この転送方法では、フレームの転送に際して、フレームの検証のための検証用情報であるメッセージ認証コード（ＭＡＣ）を、一定条件下で削除し、或いは、一定条件下で付加する。例えば、ＭＡＣを検証する検証機能を有するＥＣＵが接続されていないバス（検証機能を有さないＥＣＵが接続されているバス）にフレームを転送する場合に、ゲートウェイ装置は、受信したフレームからＭＡＣを削除して転送先のバスに送信することで転送を行う。このため、転送先のバスのトラフィック量の低減化が可能となり、また、そのバスに接続されたＥＣＵはＭＡＣに関する処理を行う必要がなくなる。
　［１．１　車載ネットワークシステム１の全体構成］
　図１は、実施の形態１に係る車載ネットワークシステム１の全体構成を示す図である。車載ネットワークシステム１は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム１は、ＣＡＮのバス１０～７０により接続された、複数のＥＣＵ（ＥＣＵ１００、１０１、２００、２０１、３００、３０１、４００、４０１、５００、６００、７００）とゲートウェイ９０といった各ノードを含んで構成される。なお、図１では省略しているものの、車載ネットワークシステム１には、更に多くのＥＣＵが含まれ得る。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　バス１０には、それぞれエンジン１１０、トランスミッション１１１に接続されたＥＣＵ１００及びＥＣＵ１０１を含む、モータ、燃料、電池の制御といった車両の「走る」（走行）に関連する駆動系のＥＣＵが、接続されている。
　バス２０には、それぞれブレーキ２１０、ステアリング２１１に接続されたＥＣＵ２００及びＥＣＵ２０１を含む、「曲がる」、「止まる」等といった車両の挙動等の制御に関連するシャーシ系のＥＣＵが、接続されている。
　バス３０には、それぞれ自動ブレーキ３１０、車線維持装置３１１に接続されたＥＣＵ３００及びＥＣＵ３０１を含む、車間距離維持機能、衝突防止機能、エアバッグ等に関連する安全快適機能系のＥＣＵが、接続されている。
　バス４０には、それぞれドア４１０、ライト４１１に接続されたＥＣＵ４００及びＥＣＵ４０１を含む、エアコン、ウィンカー等といった車両の装備の制御に関連するボディ系のＥＣＵが、接続されている。
　バス５０には、インストルメントパネル５１０に接続されたＥＣＵ５００（ヘッドユニット）を含む、カーナビゲーション、オーディオ等に関連したインフォテインメント系のＥＣＵが、接続されている。
　バス６０には、ＩＴＳ（Intelligent　Transport　Systems）装置６１０に接続されたＥＣＵ６００を含む、ＥＴＣ（Electronic　Toll　Collection　System）等の高度道路交通システムに対応するＩＴＳ系のＥＣＵが、接続されている。
　バス７０には、例えばＯＢＤ２（On-Board　Diagnostics２）等といった、外部の故障診断ツール等と通信するためのインタフェースである診断ポート７１０に接続されたＥＣＵ７００が、接続されている。なお、ＥＣＵ７００を除き診断ポート７１０をバス７０に接続していても良い。ここで示した各バスに接続されたＥＣＵに接続されている機器は、一例に過ぎず、例えば、他の１台又は複数台の機器に置き換えても良いし、省いても良い。
　ＥＣＵ（ＥＣＵ１００、２００等）のそれぞれは、接続されている機器（エンジン１１０、ブレーキ２１０等）の状態を取得し、定期的に状態を表すフレーム等をネットワーク（つまりＣＡＮのバス）に送信している。
　バス１０に接続されたＥＣＵ１００、１０１と、バス２０に接続されたＥＣＵ２００、２０１と、バス３０に接続されたＥＣＵ３００、３０１とは、ＭＡＣ対応ＥＣＵであり、メッセージ認証コード（ＭＡＣ）を処理する機能（ＭＡＣの生成機能、ＭＡＣの検証機能）を有する。また、バス４０に接続されたＥＣＵ４００、４０１と、バス５０に接続されたＥＣＵ５００と、バス６０に接続されたＥＣＵ６００と、バス７０に接続されたＥＣＵ７００とは、ＭＡＣ非対応ＥＣＵであり、ＭＡＣを処理する機能（ＭＡＣの生成機能、ＭＡＣの検証機能）を有さない。
　ゲートウェイ９０は、異なる複数の通信路を接続して通信路間でデータを転送するゲートウェイ装置である。ゲートウェイ９０は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０及びバス７０と接続している。つまり、ゲートウェイ９０は、一方のバスから受信したフレーム（データフレーム）を、一定条件下で他のバス（つまり条件に応じて選択した転送先バス）に転送する機能を有する一種のＥＣＵである。ゲートウェイ９０は、例えば、一方のバスから受信した、ＭＡＣを含むフレームについて転送する。この転送は、具体的には、受信したＭＡＣを含むフレームの内容に基づく情報を含む送信用フレームであってＭＡＣ（例えば、受信したＭＡＣと同一のＭＡＣ、或いは、新たに生成したＭＡＣ）を含む送信用フレームを生成して、その送信用フレームを転送先バスに送信することである。また、ゲートウェイ９０は、一方のバスから受信した、ＭＡＣを含むフレームについて一定条件下でＭＡＣを削除した上で転送する。フレームからＭＡＣを削除して転送することは、具体的には、受信したＭＡＣを含むフレームの内容のうち、ＭＡＣ以外の部分に基づく情報を含む送信用フレームを生成して、その送信用フレームにＭＡＣを含ませずに転送先バスに送信することである。また、ゲートウェイ９０は、一方のバスから受信した、ＭＡＣを含まないフレームについて一定条件下でＭＡＣを付加した上で転送する。フレームにＭＡＣを付加して転送することは、具体的には、受信したフレームの内容に基づく情報を含む送信用フレームを生成して、その送信用フレームにＭＡＣを含ませて転送先バスに送信することである。ゲートウェイ９０は、受信したフレームを転送するかしないかを接続されたバス間毎に切り替え得る。なお、車載ネットワークシステム１には、図１に示さないバスも含まれ得るし、ゲートウェイ９０以外の１台以上のゲートウェイ装置が含まれ得る。
　この車載ネットワークシステム１においてはＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがあるが、ここでは主にデータフレームに注目して説明する。
　［１．２　データフレームフォーマット］
　以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。
　図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準フォーマット（標準ＩＤフォーマット）におけるデータフレームを示している。データフレームは、ＳＯＦ（Start　Of　Frame）、ＩＤフィールド、ＲＴＲ（Remote　Transmission　Request）、ＩＤＥ（Identifier　Extension）、予約ビット「ｒ」、ＤＬＣ（Data　Length　Code）、データフィールド、ＣＲＣ（Cyclic　Redundancy　Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End　Of　Frame）の各フィールドで構成される。
　ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
　ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（つまりフレームにおける識別子であるメッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
　ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
　ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
　ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
　データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
　ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
　ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
　ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
　ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
　ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
　図２において（ａ）は、ＭＡＣ非対応ＥＣＵが送受信するフレームのデータフィールドの内容例を示しており、データフィールドは、ＭＡＣを含まずにデータ８０ａのみを含む。
　図２において（ｂ）は、ＭＡＣ対応ＥＣＵが送受信するフレームのデータフィールドの内容例を示しており、データフィールドは、データ８０ｂとＭＡＣ８１とを含む。この（ｂ）に例示する内容のフレームをゲートウェイ９０が受信して、例えばＭＡＣ対応ＥＣＵが接続されておらずＭＡＣ非対応ＥＣＵが接続されている転送先バスに転送する場合には、データフィールド内のＭＡＣを削除したフレームが転送されることになる。
　また、（ｂ）では、データとＭＡＣとをそれぞれ３２ビットとしているが、これは一例に過ぎず、これ以外のサイズであっても良い。ＭＡＣのサイズはメッセージＩＤ毎に予め定めておくこととしても良い。また、バス毎にＭＡＣのサイズを定めておくこととしても良い。また、（ｂ）では、データとＭＡＣとを１つのフレーム内に含ませているが、データとＭＡＣとを別々のフレーム各々におけるデータフィールドに含ませて送信しても良い。この場合に、例えばＭＡＣ対応ＥＣＵが接続されておらずＭＡＣ非対応ＥＣＵが接続されている転送先バスに転送する場合には、ゲートウェイ９０は、データを含むフレームを転送してＭＡＣを含んだフレームを転送しないように制御しても良い。
　［１．３　ＭＡＣ非対応ＥＣＵの構成］
　図３は、ＭＡＣ非対応ＥＣＵであるＥＣＵ４００の構成図である。ＥＣＵ４００は、ＭＡＣを処理する機能（ＭＡＣの生成機能、ＭＡＣの検証機能）に係る構成を有さず、フレーム送受信部８００と、フレーム解釈部８０１と、受信ＩＤ判断部８０２と、受信ＩＤリスト保持部８０３と、フレーム処理部８０４と、フレーム生成部８０５と、データ取得部８０６とを含んで構成される。これらの各構成要素の各機能は、例えばＥＣＵ４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部８００は、バス４０に対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス４０からフレームを１ｂｉｔずつ受信し、フレーム解釈部８０１に通知する。また、フレーム生成部８０５より通知を受けたフレームの内容をバス４０に送信する。
　フレーム解釈部８０１は、フレーム送受信部８００よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部８０２へ通知する。フレーム解釈部８０１は、受信ＩＤ判断部８０２から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部８０４へ通知するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部８０１は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部８０５へ通知する。また、フレーム解釈部８０１は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部８０２は、フレーム解釈部８０１から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部８０３が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部８０２は、フレーム解釈部８０１へ通知する。
　受信ＩＤリスト保持部８０３は、ＥＣＵ４００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。例えば、ＥＣＵ４００が０ｘ１００、０ｘ２００というＩＤのメッセージを受信して処理する場合においては、これらの０ｘ１００、０ｘ２００というＩＤのリストが受信ＩＤリストに予め登録されている。
　フレーム処理部８０４は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、ドア４１０に接続されたＥＣＵ４００は、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能を備える。ＥＣＵ４００は、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ４００のフレーム処理部８０４は、他のＥＣＵから受信したデータを管理し、ドア４１０から取得されたドアの開閉状態等に基づいて一定条件下でアラーム音を鳴らす処理等を行う。なお、フレーム処理部８０４は、ここで例示した以外のフレームのデータに係る処理を行っても良い。
　データ取得部８０６は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部８０５に通知する。
　フレーム生成部８０５は、フレーム解釈部８０１から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部８００へ通知して送信させる。また、フレーム生成部８０５は、データ取得部８０６より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレーム送受信部８００へ通知する。
　なお、ＥＣＵ４０１、５００、６００、７００も、ＭＡＣ非対応ＥＣＵであり、上述したＥＣＵ４００と基本的に同様の構成を備える。但し、受信ＩＤリスト保持部８０３に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。また、フレーム処理部８０４の処理内容は、ＥＣＵ毎に異なる。ＥＣＵ４０１のフレーム送受信部８００は、バス４０に対して、フレームを送受信し、ＥＣＵ５００のフレーム送受信部８００は、バス５０に対して、フレームを送受信し、ＥＣＵ６００のフレーム送受信部８００は、バス６０に対して、フレームを送受信し、ＥＣＵ７００のフレーム送受信部８００は、バス７０に対して、フレームを送受信する。
　［１．４　ＭＡＣ対応ＥＣＵの構成］
　図４は、ＭＡＣ対応ＥＣＵであるＥＣＵ１００の構成図である。ＥＣＵ１００は、ＭＡＣを処理する機能（ＭＡＣの生成機能、ＭＡＣの検証機能）に係る構成を有し、フレーム送受信部８１０と、フレーム解釈部８１１と、受信ＩＤ判断部８１２と、受信ＩＤリスト保持部８１３と、フレーム処理部８１４と、フレーム生成部８１５と、データ取得部８１６と、ＭＡＣ制御部８２０と、ＭＡＣ鍵保持部８２１と、カウンタ保持部８２２とを含んで構成される。これらの各構成要素の各機能は、例えばＥＣＵ１００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部８１０と、フレーム解釈部８１１と、受信ＩＤ判断部８１２と、受信ＩＤリスト保持部８１３と、フレーム処理部８１４と、フレーム生成部８１５と、データ取得部８１６とは、ＭＡＣ非対応ＥＣＵである上述のＥＣＵ４００のフレーム送受信部８００と、フレーム解釈部８０１と、受信ＩＤ判断部８０２と、受信ＩＤリスト保持部８０３と、フレーム処理部８０４と、フレーム生成部８０５と、データ取得部８０６とそれぞれ同様の機能を有するので、ここでは説明を適宜省略する。
　フレーム送受信部８１０は、バス１０に対して、ＣＡＮプロトコルに従ったフレームを送受信する。
　ＭＡＣ制御部８２０は、ＣＡＮのデータフレームのデータフィールドに配置されるＭＡＣ（図２の（ｂ）参照）の生成、及び、ＭＡＣの検証をする。フレーム送受信部８１０によるデータフレームの受信時には、ＭＡＣ制御部８２０は、フレーム解釈部８１１から取得したフレームの内容であるメッセージＩＤ及びデータの値と、カウンタ保持部８２２が保持するカウンタ値とを結合した値に対して、ＭＡＣ鍵保持部８２１が保持するＭＡＣ鍵を用いて、ＭＡＣ値を計算し、計算結果であるＭＡＣ値とフレーム解釈部８１１から取得したフレームの内容であるＭＡＣ値とを比較する。ＭＡＣ制御部８２０は、その比較の結果が一致しなければ、不正なメッセージと判定し、そのフレームの処理を中止して、例えばエラーフレームを送信するようにフレーム生成部８１５へ通知する。フレーム送受信部８１０によるデータフレームの送信に際しては、ＭＡＣ制御部８２０は、データ取得部８１６からのデータに基づいてフレーム生成部８１５が構成したフレームの内容であるメッセージＩＤ及びデータの値と、カウンタ保持部８２２が保持するカウンタ値とを結合した値に対して、ＭＡＣ鍵保持部８２１が保持するＭＡＣ鍵を用いて、ＭＡＣ値を計算し、計算結果であるＭＡＣ値をフレーム生成部８１５に通知して送信用のフレームに設定させる。ＭＡＣ制御部８２０は、ＭＡＣ鍵を用いてＭＡＣを計算し、出てきた計算結果の例えば先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでは、ＭＡＣを計算するために、メッセージＩＤと、データの値と、カウンタ保持部８２２で保持するカウンタ値との３つを用いる例を説明したが、そのいずれか１つ又は２つだけをＭＡＣの計算に用いても良いし、ＭＡＣの計算に、フレーム内の他のフィールドの内容（例えばＤＬＣ等）を用いても良い。ＭＡＣの計算方法としては、例えばＨＭＡＣ（Hash-based　Message　Authentication　Code)、ＣＢＣ－ＭＡＣ（Cipher　Block　Chaining　Message　Authentication　Code）等を用いることができる。
　ＭＡＣ鍵保持部８２１は、ＭＡＣ値を計算するために必要となるＭＡＣ鍵を保持する。
　カウンタ保持部８２２は、ＭＡＣ値を計算するために必要となるカウンタ値を保持する。ＥＣＵ１００においてフレームを正常に送受信した場合はカウンタ保持部８２２のカウンタ値が１増加（インクリメント）される。カウンタ値は、例えば送受信するフレームのメッセージＩＤ毎に保持される。
　フレーム生成部８１５は、フレーム解釈部８１１から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部８１０へ通知して送信させる。また、フレーム生成部８１５は、データ取得部８１６より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレームにＭＡＣ制御部８２０より通知されたＭＡＣの値を設定して、フレーム送受信部８１０へ通知する。
　なお、ＥＣＵ１０１、２００、２０１、３００、３０１も、ＭＡＣ対応ＥＣＵであり、上述したＥＣＵ１００と基本的に同様の構成を備える。但し、受信ＩＤリスト保持部８１３に保持される受信ＩＤリストはＥＣＵ毎に異なる内容となり得る。また、フレーム処理部８１４の処理内容は、ＥＣＵ毎に異なる。また、ＭＡＣ対応ＥＣＵ各々のＭＡＣ鍵保持部８２１は、例えば、そのＥＣＵが処理するメッセージＩＤ毎に異なるＭＡＣ鍵を保持する。なお、ＭＡＣ対応ＥＣＵ各々のＭＡＣ鍵保持部８２１は、メッセージＩＤに依らずそのＥＣＵが接続されるバス毎に統一したＭＡＣ鍵を保持することとしても良いし、いずれも同じＭＡＣ鍵を保持することとしても良い。ＥＣＵ１０１のフレーム送受信部８１０は、バス１０に対して、フレームを送受信し、ＥＣＵ２００、２０１のフレーム送受信部８１０は、バス２０に対して、フレームを送受信し、ＥＣＵ３００、３０１のフレーム送受信部８１０は、バス３０に対して、フレームを送受信する。
　［１．５　ゲートウェイ９０の構成］
　図５は、ゲートウェイ９０の構成図である。ゲートウェイ９０は、フレーム送受信部９０１と、フレーム解釈部９０２と、受信ＩＤ判断部９０３と、受信ＩＤリスト保持部９０４と、フレーム生成部９０５と、転送制御部９０６と、転送ルール保持部９０７と、ＭＡＣ制御部９２０と、ＭＡＣ鍵保持部９２１と、カウンタ保持部９２２とを含んで構成される。これらの各構成要素の各機能は、例えばゲートウェイ９０における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部９０１は、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及び、バス７０のそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部９０１は、バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部９０２に通知する受信部として機能する。また、フレーム生成部９０５より通知を受けた転送先のバスを示す転送先バス情報及びフレームに基づいて、そのフレームの内容を、バス１０、バス２０、バス３０、バス４０、バス５０、バス６０、及び、バス７０のうち転送先バスに、１ｂｉｔずつ送信する。
　フレーム解釈部９０２は、フレーム送受信部９０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部９０３へ通知する。フレーム解釈部９０２は、受信ＩＤ判断部９０３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送制御部９０６へ通知するか、その判定結果を受けた以降においてフレームの受信を中止するかを決定する。また、フレーム解釈部９０２は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部９０５へ通知する。また、フレーム解釈部９０２は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部９０３は、フレーム解釈部９０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部９０４が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部９０３は、フレーム解釈部９０２へ通知する。
　受信ＩＤリスト保持部９０４は、ゲートウェイ９０が受信するメッセージＩＤのリストである受信ＩＤリストを保持する。受信ＩＤリストには、各バス（バス１０～７０）からゲートウェイ９０が受信すべきフレームのメッセージＩＤが登録されている。なお、受信ＩＤリスト保持部９０４は、バス毎に別々の受信ＩＤリストを保持しても良いし、全体で１つの受信ＩＤリストを保持しても良い。
　転送制御部９０６は、転送ルール保持部９０７が保持する転送ルールに従って、受信したフレームのＩＤ（メッセージＩＤ）、及び、転送元バス（つまりそのフレームを受信したバス）に応じて、転送先バスを選択し、転送先バスを示す転送先バス情報とフレーム解釈部９０２より通知されたメッセージＩＤとデータ（データフィールドの内容）と、ＤＬＣ（データ長）とをフレーム生成部９０５へ通知する。転送制御部９０６は、転送ルール保持部９０７が保持するバス情報（バス毎にＭＡＣ対応バスかＭＡＣ非対応バスかを示す情報）と転送ルール情報とを参照し、受信したフレームの転送元バスと転送先バスとがＭＡＣ対応バスであるか否かを確認する。ＭＡＣ対応バスは、ＭＡＣ対応ＥＣＵが接続されているバスであり、ＭＡＣ非対応バスは、ＭＡＣ対応ＥＣＵが接続されていないバスである。ＭＡＣ非対応バスには、ＭＡＣ非対応ＥＣＵが接続され得る。
　転送元バスがＭＡＣ対応バスで且つ転送先バスがＭＡＣ非対応の場合には転送制御部９０６は、ＭＡＣ制御部９２０にＭＡＣ検証を依頼し、ＭＡＣ制御部９２０によるＭＡＣ検証に成功したとき（つまり転送元バスから受信したフレーム内のＭＡＣが計算したＭＡＣと一致したとき）には、適正なフレーム（メッセージ）と判定してＭＡＣを削除したデータフレームを転送するようフレーム生成部９０５に通知し、ＭＡＣ検証に失敗したときには不正なフレームと判定して、フレームの転送を中止する。
　また、転送元バスがＭＡＣ対応バスで且つ転送先バスがＭＡＣ対応バスの場合には転送制御部９０６は、ＭＡＣ制御部９２０にＭＡＣ検証を依頼し、ＭＡＣ制御部９２０によるＭＡＣ検証に成功したときには、適正なフレームと判定してＭＡＣを削除せずにデータフレームを転送するようフレーム生成部９０５に通知し、ＭＡＣ検証に失敗したときには不正なフレームと判定して、フレームの転送を中止する。ＭＡＣを削除しない場合において、バス毎にＭＡＣ鍵が異なるようにしているのであれば、ＭＡＣを転送先バスに合わせたＭＡＣ鍵で生成したものに付け替えてフレームの転送が行われる。
　また、転送元バスがＭＡＣ非対応バスで且つ転送先バスがＭＡＣ対応バスの場合には転送制御部９０６は、ＭＡＣ制御部９２０にＭＡＣ生成を依頼し、ＭＡＣ制御部９２０で生成されたＭＡＣ値を、データフィールドに付加してフレームの転送を行うようにフレーム生成部９０５に通知する。
　また、転送元バスがＭＡＣ非対応バスで且つ転送先バスがＭＡＣ非対応バスの場合には転送制御部９０６は、ＭＡＣ制御部９２０にＭＡＣの検証及び生成を依頼せずに、フレームを転送するようフレーム生成部９０５に通知する。
　ＭＡＣ制御部９２０は、ＭＡＣの生成、及び、ＭＡＣの検証をする機能を有する。ＭＡＣ制御部９２０は、転送制御部９０６からのＭＡＣ検証の依頼（要求）があった場合は、転送制御部９０６より通知されるメッセージＩＤと、データの値と、カウンタ保持部９２２で保持するカウンタ値（そのメッセージＩＤと対応してカウンタリスト９２２０で管理されたカウンタ値）とを結合した値に対し、ＭＡＣ鍵保持部９２１が保持するＭＡＣ鍵（そのメッセージＩＤと対応してＭＡＣ鍵リスト９２１０で管理されたＭＡＣ鍵）を用いて、ＭＡＣ値を計算し、計算結果であるＭＡＣ値と、転送制御部９０６より通知される、受信されたフレームのデータフィールド内のＭＡＣ値とを比較する。比較の結果が一致すれば検証に成功した旨を転送制御部９０６に通知し、一致しなければ検証に失敗した旨を転送制御部９０６に通知する。また、ＭＡＣ制御部９２０は、転送制御部９０６からのＭＡＣ生成の依頼（要求）があった場合は、転送制御部９０６より通知されるメッセージＩＤと、データの値と、カウンタ保持部９２２で保持するカウンタ値（そのメッセージＩＤと対応してカウンタリスト９２２０で管理されたカウンタ値）とを結合した値に対し、ＭＡＣ鍵保持部９２１が保持するＭＡＣ鍵（そのメッセージＩＤと対応してＭＡＣ鍵リスト９２１０で管理されたＭＡＣ鍵）を用いて、ＭＡＣ値を計算し、計算結果であるＭＡＣ値を転送制御部９０６へと通知する。ＭＡＣ制御部９２０は、ＭＡＣ鍵を用いてＭＡＣを計算し、出てきた計算結果の例えば先頭４ｂｙｔｅｓをＭＡＣ値とする。なお、ここでは、ＭＡＣを計算するために、メッセージＩＤと、データの値と、カウンタ保持部９２２で保持するカウンタ値との３つを用いる例を説明したが、そのいずれか１つ又は２つだけをＭＡＣの計算に用いても良いし、ＭＡＣの計算に、フレーム内の他のフィールドの内容（例えばＤＬＣ等）を用いても良い。ＭＡＣの計算方法としては、例えばＨＭＡＣ（Hash-based　Message　Authentication　Code)、ＣＢＣ－ＭＡＣ（Cipher　Block　Chaining　Message　Authentication　Code）等を用いることができる。
　ＭＡＣ鍵保持部９２１は、ＭＡＣ値を計算するために必要となるＭＡＣ鍵を管理するＭＡＣ鍵リスト９２１０を保持する。ＭＡＣ鍵リスト９２１０については図８を用いて後に説明する。
　カウンタ保持部９２２は、ＭＡＣ値を計算するために必要となるカウンタ値を管理するカウンタリスト９２２０を保持する。カウンタリスト９２２０については図９を用いて後に説明する。カウンタ値は、例えばバス毎において、送受信するフレームのメッセージＩＤ毎に保持される。ゲートウェイ９０においてフレームを正常に送受信した場合はカウンタ保持部９２２が、保持するカウンタリスト９２２０における、対応するメッセージＩＤのカウンタ値が１増加（インクリメント）される。カウンタ保持部９２２は、例えばバス毎にカウンタリスト９２２０を保持しても良い。
　転送ルール保持部９０７は、バス毎のフレームの転送についてのルールを表す情報である転送ルール情報、及び、各バスがＭＡＣ対応バスかＭＡＣ非対応バスかを示すバス情報を保持する。図６は、バス情報の一例を示し、図７は、転送ルール情報の一例を示す。
　フレーム生成部９０５は、フレーム解釈部９０２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部９０１へ通知して送信させる。また、フレーム生成部９０５は、転送制御部９０６から送信の要求に従い、転送制御部９０６より通知されたメッセージＩＤと、データフィールドの内容とを用いて送信用フレームを構成し、その送信用フレーム及び転送先バス情報（転送先バスの識別子であるバスＩＤ）をフレーム送受信部９０１へ通知する。
　［１．６　バス情報］
　図６は、ゲートウェイ９０の転送ルール保持部９０７が保持するバス情報の一例を示す。図６のバス情報９０７０は、各バスがＭＡＣ対応バスであるかＭＡＣ非対応バスであるかをバス毎に示した情報である。
　図６の例は、図１で示した各バスの符号が、そのバスの識別子（バスＩＤ）であることとした例である。図６の例では、バスＩＤが１０であるバス１０はＭＡＣ対応バスであり、このバス１０にはＭＡＣ対応ＥＣＵが接続されていることを示しており、つまりバス１０に接続されているＥＣＵ１００、１０１がＭＡＣ対応ＥＣＵであることを示している。
　また、バスＩＤが４０であるバス４０は、ＭＡＣ非対応バスであり、このバス４０にはＭＡＣ対応ＥＣＵが接続されていないことを示しており、つまりバス４０に接続されているＥＣＵ４００、４０１がＭＡＣ非対応ＥＣＵであることを示している。
　［１．７　転送ルール情報］
　図７は、ゲートウェイ９０の転送ルール保持部９０７が保持する転送ルール情報の一例を示す。図７の転送ルール情報９０７１は、転送元バスと転送先バスと転送対象のデータフレーム（メッセージ）のＩＤ（メッセージＩＤ）とを対応付けている。この転送ルール情報９０７１は、ゲートウェイ９０が、複数のバスから、受信されたフレームの転送先となる転送先バスを、選択するための基準を示す。
　図７における転送元バスＩＤは、ゲートウェイ９０が受信するフレームがどのバスから受信されたかを示すバスＩＤである。図７における転送先バスＩＤは、ゲートウェイ９０が受信したフレームの転送先（つまり送信先）となるバスを示すバスＩＤである。この転送先バスＩＤが、転送先バス情報としてフレーム送受信部９０１に通知されると、フレーム送受信部９０１は、転送先バス情報に応じたバスへとフレームを送信することになる。図７の例は、図１で示した各バスの符号が、そのバスのバスＩＤであることとした例である。この転送ルール情報に従ってゲートウェイ９０は、転送を行うか否か、どのバスを転送先バスとして選択するか等を決定する。
　図７の例は、例えば転送元バスがバス１０である全メッセージが、バス２０、バス３０及びバス７０の各々を転送先バスとして転送されるように定められていることを示す。また、転送元バスがバス１０である全メッセージのうちメッセージＩＤが０ｘ００１、０ｘ００２、０ｘ００３であるメッセージのみが、バス４０、バス５０及びバス６０の各々を転送先バスとして転送されるように定められており、転送元バスがバス１０の、それ以外のメッセージは、バス４０、バス５０及びバス６０の各々に対しては転送されないように定められていることを示す。また、転送元バスがバス３０である全メッセージが、バス１０、バス２０、バス４０及びバス７０の各々を転送先バスとして転送されるように定められていることを示す。また、転送元バスがバス３０の全メッセージについてのバスＩＤ５０、６０への転送は行われないように定められていることを示す。また、転送元バスがバス５０であるメッセージについては、どのバスにも転送されないことを示している。
　［１．８　ＭＡＣ鍵リスト］
　図８は、ゲートウェイ９０のＭＡＣ鍵保持部９２１が保持するＭＡＣ鍵リストの一例を示す。図８のＭＡＣ鍵リスト９２１０は、メッセージＩＤ毎に、メッセージＩＤに対応するＭＡＣ鍵をリストとして登録したものであり、ＭＡＣ制御部９２０によるＭＡＣの生成及び検証において利用される。
　図８では、メッセージＩＤ毎に、個別に異なるＭＡＣ鍵を保持している例を示したが、ＭＡＣ鍵保持部９２１は、バス毎に個別のＭＡＣ鍵を保持しても良い。この場合には、ＭＡＣ鍵リスト９２１０には、バスＩＤとバスＩＤに対応する鍵値とを登録する。バス毎に個別のＭＡＣ鍵を管理する場合には、ゲートウェイ９０は、フレームの転送に際して、転送先バスに対応したＭＡＣ鍵を用いてＭＡＣを新たに生成して生成したＭＡＣを送信用フレームに設定して送信する。
　［１．９　カウンタリスト］
　図９は、ゲートウェイ９０のカウンタ保持部９２２が保持するカウンタリストの一例を示す。図９のカウンタリスト９２２０は、メッセージＩＤ毎に、メッセージＩＤに対応するカウンタ値をリストとして記録したものであり、ＭＡＣ制御部９２０によるＭＡＣの生成及び検証において利用される。
　図９では、メッセージＩＤ毎に、個別のカウンタ値を保持している例を示したが、カウンタ保持部９２２は、バス毎に個別のカウンタ値を保持しても良い。この場合には、カウンタリスト９２２０には、バスＩＤとバスＩＤに対応するカウンタ値とを記録する。
　［１．１０　フレームの転送に係る動作例］
　図１０及び図１１は、転送元ＥＣＵが送信したフレームを一のバスから受信して、ゲートウェイ９０が、転送先ＥＣＵが接続されている、他のバスへと転送する動作例を示す。一のバスと他のバスとのそれぞれは、ＭＡＣ対応バスであり得るし、ＭＡＣ非対応のバスであり得る。また、ＭＡＣ対応ＥＣＵ及びＭＡＣ非対応ＥＣＵのいずれもが、転送元ＥＣＵにも転送先ＥＣＵにもなり得る。以下、図１０及び図１１に即して、各装置の動作について説明する。
　まず、転送元ＥＣＵが、その転送元ＥＣＵ自身が接続されているバスに対してフレーム（メッセージ）を送信する（ステップＳ１００１）。ＣＡＮの通信では、フレームの送信はブロードキャストであり、そのバスに接続された各ノードはそのフレームを受信し得る。転送元ＥＣＵが接続されたバスには、ゲートウェイ９０も接続されており、ゲートウェイ９０のフレーム送受信部９０１が、転送元ＥＣＵからのフレームを受信する（ステップＳ１００２）。
　ゲートウェイ９０の受信ＩＤ判断部９０３は、フレーム解釈部９０２から通知された、受信されたフレーム（メッセージ）のメッセージＩＤが、受信ＩＤリスト保持部９０４が保持する受信ＩＤリストに記載されたものであるか否かにより、受信すべきフレーム（受信すべきＩＤを含むフレーム）か否かを判断する（ステップＳ１００３）。受信すべきフレームでない場合には、ゲートウェイ９０は、受信したフレームについての転送を中止する（つまり転送を行わない）。
　ステップＳ１００３で受信すべきフレームであると判断された場合には、ゲートウェイ９０の転送制御部９０６は、転送ルール保持部９０７が保持する転送ルール情報９０７１を参照して、いずれかのバスに転送すべきメッセージＩＤのフレームか否かを判断して、転送すべきフレームであれば転送先バスを選択する（ステップＳ１００４）。転送すべきメッセージＩＤのフレームでない場合には、ゲートウェイ９０は、受信したフレームについての転送を中止する。
　ステップＳ１００４で転送すべきメッセージＩＤのフレームであると判断された場合には、転送制御部９０６は、転送ルール保持部９０７が保持するバス情報９０７０を参照してフレームを受信したバスである転送元バスがＭＡＣ対応バスか否かを判断し（ステップＳ１００５）、ＭＡＣ対応バスであるときには、ステップＳ１００６へ進み、ＭＡＣ対応バスでないとき（つまりＭＡＣ非対応バスであるとき）には、ステップＳ１００６での処理をスキップしてステップＳ１００７へ進む。ステップＳ１００６では、ゲートウェイ９０のＭＡＣ制御部９２０が、ＭＡＣ鍵保持部９２１が保持するＭＡＣ鍵リスト９２１０と、カウンタ保持部９２２が保持するカウンタリスト９２２０とから、受信したフレームのメッセージＩＤに対応するＭＡＣ鍵とカウンタとを利用してＭＡＣ値を計算し、計算結果のＭＡＣ値と、受信したフレームのデータフィールド内のＭＡＣと比較して、受信したフレームの検証（ＭＡＣ検証）を行う。ＭＡＣ検証の結果として、不正なフレームであると判定されると（検証に失敗すれば）、ゲートウェイ９０は、そのフレームの転送を中止する。ＭＡＣ検証の結果として、適正なフレームであると判定されると（検証に成功すれば）、ステップＳ１００７へ進む。なお、検証に成功した際には、後のＭＡＣ検証のために、ゲートウェイ９０は、カウンタリスト９２２０における、そのフレームのメッセージＩＤに対応するカウンタ値を、１増加（インクリメント）する。
　ステップＳ１００７では、転送制御部９０６が、転送ルール保持部９０７が保持するバス情報９０７０を参照して、転送先バスがＭＡＣ対応バスか否かを判断する。ステップＳ１００７での判断の結果として、転送先バスがＭＡＣ対応バスであると判断した場合にはステップＳ１０１０へ進み、転送先バスがＭＡＣ対応バスでないと判断した場合には、ステップＳ１００８へ進む。
　ステップＳ１００８では、転送制御部９０６は、フレームのデータフィールドからＭＡＣ部分を削除する。続いて、転送制御部９０６は、ステップＳ１００８で削除したＭＡＣのサイズ（データ長）をＤＬＣの値から減算し（ステップＳ１００９）、ステップＳ１０１３へ進む。なお、ゲートウェイ９０が受信したフレームのデータフィールドにＭＡＣが付されていない場合（つまり転送元バスがＭＡＣ非対応バスである場合）においては、ステップＳ１００８、Ｓ１００９でＭＡＣの削除、及び、ＭＡＣのサイズのＤＬＣからの減算を行わない。
　ステップＳ１０１０では、転送制御部９０６は、転送元バスから受信したフレームにＭＡＣが付されているか否かを確認する。ＭＡＣが付されていなければ、転送制御部９０６は、ＭＡＣ制御部９２０に転送先バスへ送信する送信用フレームに含ませるためのＭＡＣを生成するよう依頼し、Ｓ１０１１へ進む。ＭＡＣが付されていれば、ステップＳ１０１３へ進む。
　ステップＳ１０１１では、ＭＡＣ制御部９２０は、ＭＡＣの付加によって増加するデータフィールドのサイズを再計算し、その値をＤＬＣに設定する。続いて、ＭＡＣ制御部９２０は、転送制御部９０６より通知されるメッセージＩＤと、データの値と、カウンタ保持部９２２で保持するカウンタリスト９２２０内のメッセージＩＤに対応するカウンタ値とを結合した値に対し、ＭＡＣ鍵保持部９２１で保持するＭＡＣ鍵リスト９２１０内のメッセージＩＤに対応するＭＡＣ鍵を用いて、ＭＡＣ値を計算し、計算結果としてのＭＡＣ値を転送制御部９０６へと通知する（ステップＳ１０１２）。この通知を受けて転送制御部９０６は、データフィールドにＭＡＣを付加する。
　ステップＳ１０１０で、受信したフレームにＭＡＣが付されていた場合、或いは、ステップＳ１００９又はステップＳ１０１２での処理後に、転送制御部９０６は、フレーム生成部９０５に、メッセージＩＤ、データフィールド、ＤＬＣ、及び、転送先バス情報（転送先バスＩＤ）を通知する。これにより、フレーム生成部９０５は、転送制御部９０６より通知されたメッセージＩＤと、データフィールドとを用い、ＣＲＣを再計算して送信用フレームを構成し、転送先バス情報（転送先バスＩＤ）と、その送信用フレームとをフレーム送受信部９０１へ通知する（ステップＳ１０１３）。
　次に、ゲートウェイ９０のフレーム送受信部９０１は、フレーム生成部９０５より生成された送信用フレームを転送先バス情報が示すバス（つまり転送先バス）へと送信する（ステップＳ１０１４）。これにより、ゲートウェイ９０によりバス間でのフレームの転送が実現される。
　ステップＳ１０１４に対応して、転送先バスに接続された転送先ＥＣＵは、ゲートウェイ９０により送信（転送）されたフレームを受信する（ステップＳ１０１５）。
　［１．１１　実施の形態１の効果］
　実施の形態１に係る車載ネットワークシステム１では、ゲートウェイ９０の転送制御部９０６、フレーム生成部９０５及びフレーム送受信部９０１が連携して、受信部として機能するフレーム送受信部９０１により受信されたフレーム（メッセージ）の内容からそのフレームの検証に用いられる検証用情報（例えばＭＡＣ）を削除してそのフレームの、転送先バスへの転送を行う、又は、そのフレームの内容に検証用情報を付加してそのフレームの、転送先バスへの転送を行う、転送部として機能する。この転送部は、受信部により受信された検証用情報を含む第１フレーム（例えばＭＡＣを含むフレーム）について、検証用情報を削除するための所定削除条件が満たされた場合には、その第１フレームの内容のうち検証用情報を除いた内容に基づく情報を含む第２フレーム（例えばＭＡＣを含まないフレーム）を生成してその第２フレームを転送先バスに送信することで、フレームの転送を行い得る。また、この転送部は、受信部により受信された、検証用情報を含まないフレームについて、検証用情報を付加するための所定付加条件が満たされた場合には、そのフレームの内容に基づく情報と、検証用情報とを含むフレームを生成して、生成したフレームを転送先バスに送信することで、フレームの転送を行い得る。この転送部は、例えば、所定削除条件が満たされた場合には、第１フレームにおけるＭＡＣ以外のデータフィールドの内容を含み、ＭＡＣを含まない第２フレームを転送先バスに送信し得る。このようにゲートウェイ９０が、フレームの転送に際して、転送先バスにＭＡＣ対応ＥＣＵが接続されていない場合（つまり転送先バスがＭＡＣ非対応バスである場合）には、ＭＡＣを削除して送信するので、転送先バスのトラフィック量を抑えることできる。即ち、特定のバスに対してフレームが転送される場合にはＭＡＣが削除されて送信され得るので、そのバスに接続されたＥＣＵはＭＡＣを処理する必要がなくなる。このことは、車載ネットワークシステムにおける効率的なＥＣＵの編成の実現に繋がり得る。また、ゲートウェイ９０は、転送に際してＭＡＣを検証し、検証に失敗した場合に不正なフレームの転送を中止するので、ＭＡＣを削除してフレームを転送する場合であってもある程度のセキュリティを高めることが可能となる。また、ゲートウェイ９０が、ＭＡＣの検証に失敗した場合に不正なフレームを転送しないことにより、転送先バスに接続されたＥＣＵにとって不正なフレームに対処するための処理負荷が削減され得る。
　なお、ゲートウェイ９０における上述の転送部は、受信部により受信された検証用情報を含む第１フレームについて、検証用情報を削除するための所定削除条件が満たされなかった場合には、その第１フレームの内容のうち検証用情報を除いた内容に基づく情報と、転送先バスに接続されたＥＣＵと共有している鍵を用いて生成した検証用情報とを含む第２フレームを生成してその第２フレームを転送先バスに送信し得る。これにより、フレームのセキュリティが高まり得る。
　（実施の形態２）
　以下、実施の形態１で示した車載ネットワークシステム１の一部を変形した実施の形態について説明する。
　実施の形態１では、転送先バスがＭＡＣ非対応バスであることを条件として、ゲートウェイ装置がフレームの転送に際してフレーム内の検証用情報であるＭＡＣを削除した。これに対して、実施の形態２では、更に、ＭＡＣを削除する所定削除条件として、転送先バスのバス占有率が所定値より高いことという条件を付加する。ゲートウェイ装置は、自装置に接続されている各バスでの通信状態を検知し、各バスの占有の度合い（例えばバスアイドル状態でない時間の割合等）を、例えば随時、測定或いは算定して、各バスについてのバス占有率として、転送に際してＭＡＣを削除すべきか否かの条件判断に用いる。
　本実施の形態におけるゲートウェイ装置を含む車載ネットワークシステムの構成要素は、概ね実施の形態１と同様であるため、ここでは、実施の形態１と同様の符号を用いる。ここでは実施の形態１と相違点について説明し、ここで説明しない点については、実施の形態１と同様である。
　［２．１　ＭＡＣ削除条件リスト］
　本実施の形態に係るゲートウェイ９０の転送ルール保持部９０７は、バス情報９０７０と転送ルール情報９０７１との他に、ＭＡＣ削除条件リスト９０７２を保持する。
　図１２は、ゲートウェイ９０の転送ルール保持部９０７が保持するＭＡＣ削除条件リストの一例を示す。図１２のＭＡＣ削除条件リスト９０７２は、ＭＡＣ対応バスであるバス毎に、転送先バスＩＤ（転送先バスのバスＩＤ）とＭＡＣの削除条件とを対応付けた情報である。図１２の例は、図１で示した各バスの符号が、そのバスの識別子（バスＩＤ）であることとした例である。
　図１２の例では、バスＩＤが１０であるバス１０が転送先バスとして選択された場合においてはバス１０のバス占有率が５０％以上であることがＭＡＣの削除条件となることを示している。これにより、ゲートウェイ９０は、ＭＡＣ対応バスであるバス１０へフレームを転送する際には、バス１０のバス占有率が５０％以上であればＭＡＣを削除して転送する。また、図１２の例では、バスＩＤが２０であるバス２０が転送先バスとして選択された場合においてはバス２０のバス占有率が４０％以上であることがＭＡＣの削除条件となることを示している。図１２はＭＡＣの削除条件の一例を示すに過ぎず、ゲートウェイ９０は、転送先バスのバス占有率が予め定められた所定値（例えば５０％等）より高いことというＭＡＣの削除条件を定め得るし、この所定値はバス毎に異なる値であっても良い。本実施の形態に係るゲートウェイ９０の転送制御部９０６は、転送先バスのバス占有率を算定する機能を有し、ＭＡＣ削除条件リスト９０７２が示すバス占有率に係るＭＡＣの削除条件を、実施の形態１で示した転送先バスがＭＡＣ非対応バスであることというＭＡＣの削除条件と合わせて適用する。なお、ゲートウェイ９０が、バス占有率に係るＭＡＣの削除条件のみを用いて、ＭＡＣを削除するか否かを判断することとしても良い。
　［２．２　フレームの転送に際してＭＡＣ削除条件リストを利用する場合の転送の動作例］
　図１３及び図１４は、転送元ＥＣＵが送信したフレームを一のバスから受信して、ゲートウェイ９０が、ＭＡＣ削除条件リストを参照して、転送先ＥＣＵが接続されている、他のバスへと転送する動作例を示す。一のバスと他のバスとのそれぞれは、ＭＡＣ対応バスであり得るし、ＭＡＣ非対応のバスであり得る。また、ＭＡＣ対応ＥＣＵ及びＭＡＣ非対応ＥＣＵのいずれもが、転送元ＥＣＵにも転送先ＥＣＵにもなり得る。以下、図１３及び図１４に即して、各装置の動作について説明する。なお、ステップＳ２００１～Ｓ２００４は、実施の形態１で示したステップＳ１００１～Ｓ１００４と同様なので説明を適宜省略する。
　ゲートウェイ９０のフレーム送受信部９０１が、転送元ＥＣＵがステップＳ２００１で送信したフレームを転送元バスから受信する（ステップＳ２００２）。
　ゲートウェイ９０の転送制御部９０６は、受信したフレームが受信すべきものであれば（ステップＳ２００３）、転送ルール情報９０７１を参照して、いずれかのバスに転送すべきメッセージＩＤのフレームか否かを判断して、転送すべきフレームであれば転送先バスを選択する（ステップＳ２００４）。
　ステップＳ２００４で転送すべきメッセージＩＤのフレームであると判断された場合には、転送制御部９０６は、そのフレームにＭＡＣが含まれているか否かを判断し（ステップＳ２００５）、ＭＡＣが含まれている場合には、ステップＳ２００６へ進み、ＭＡＣが含まれていないときには、ステップＳ２００６での処理をスキップしてステップＳ２００７へ進む。転送制御部９０６は、受信したフレームにＭＡＣが含まれているか否かを、例えば、転送ルール保持部９０７が保持するバス情報９０７０を参照してフレームを受信したバスである転送元バスがＭＡＣ対応バスであるか否かによって判断する。この場合に、例えば転送元バスがＭＡＣ対応バスであれば受信したフレームにＭＡＣが含まれており、転送元バスがＭＡＣ非対応バスであれば受信したフレームにＭＡＣが含まれていると判断する。なお、転送元バスにこのゲートウェイ９０と同機能を有する別のゲートウェイ装置が接続されているような場合を想定すれば、転送元バスがＭＡＣ対応バスであってもバス占有率に応じてＭＡＣが削除されていることがあり得る。このため、転送制御部９０６では、予めメッセージＩＤ毎にフレーム内のデータのサイズが定められているのであればＤＬＣの値によってＭＡＣが付加されているか否かを判断しても良い。また、本実施の形態に係る車載ネットワークシステム１におけるゲートウェイ装置が、転送先バスに送信するフレームに、そのフレームにＭＡＣが含まれるか否かを表す情報を含ませることとしても良く、この場合には、その情報に基づいて転送制御部９０６は、受信したフレームにＭＡＣが含まれているか否かを判断し得る。
　ステップＳ２００６では、ゲートウェイ９０のＭＡＣ制御部９２０が、ＭＡＣ鍵リスト９２１０と、保持するカウンタリスト９２２０とから、受信したフレームのメッセージＩＤに対応するＭＡＣ鍵とカウンタとを利用してＭＡＣ値を計算し、計算結果のＭＡＣ値と、受信したフレームのデータフィールド内のＭＡＣと比較して、受信したフレームの検証（ＭＡＣ検証）を行う。ＭＡＣ検証の結果として、不正なフレームであると判定されると（検証に失敗すれば）、ゲートウェイ９０は、そのフレームの転送を中止する。ＭＡＣ検証の結果として、適正なフレームであると判定されると（検証に成功すれば）、ステップＳ２００７へ進む。
　ステップＳ２００７では、転送制御部９０６が、転送ルール保持部９０７が保持するバス情報９０７０を参照して、転送先バスがＭＡＣ対応バスか否かを判断する。ステップＳ２００７での判断の結果として、転送先バスがＭＡＣ対応バスであると判断した場合にはステップＳ２０１０へ進み、転送先バスがＭＡＣ対応バスでないと判断した場合には、ステップＳ２００８へ進む。
　ステップＳ２００８では、転送制御部９０６は、フレームのデータフィールドからＭＡＣ部分を削除する。続いて、転送制御部９０６は、ステップＳ２００８で削除したＭＡＣのサイズをＤＬＣの値から減算し（ステップＳ２００９）、ステップＳ２０１４へ進む。なお、ゲートウェイ９０が受信したフレームのデータフィールドにＭＡＣが付されていない場合においては、ステップＳ２００８、Ｓ２００９でＭＡＣの削除、及び、ＭＡＣのサイズのＤＬＣからの減算を行わない。
　ステップＳ２０１０では、転送制御部９０６は、転送先バスについてのバス占有率を算出し、転送ルール保持部９０７が保持しているＭＡＣ削除条件リスト９０７２の条件と比較し、ＭＡＣの削除条件が満たされるか否かを判断する。ＭＡＣの削除条件が満たされると、ステップＳ２００８に移ってＭＡＣの削除を行う。
　ステップＳ２０１０でＭＡＣの削除条件が満たされないと判断した場合には、転送制御部９０６は、転送元バスから受信したフレームにＭＡＣが付されているか否かを確認する（ステップＳ２０１１）。ＭＡＣが付されていなければ、転送制御部９０６は、ＭＡＣ制御部９２０に転送先バスへ送信する送信用フレームに含ませるためのＭＡＣを生成するよう依頼し、Ｓ２０１２へ進む。ＭＡＣが付されていれば、ステップＳ２０１４へ進む。
　ステップＳ２０１２では、ＭＡＣ制御部９２０は、ＭＡＣの付加によって増加するデータフィールドのサイズを再計算し、その値をＤＬＣに設定する。続いて、ＭＡＣ制御部９２０は、転送制御部９０６より通知されるメッセージＩＤと、データの値と、カウンタリスト９２２０内のメッセージＩＤに対応するカウンタ値とを結合した値に対し、ＭＡＣ鍵リスト９２１０内のメッセージＩＤに対応するＭＡＣ鍵を用いて、ＭＡＣ値を計算し、計算結果としてのＭＡＣ値を転送制御部９０６へと通知する（ステップＳ２０１３）。この通知を受けて転送制御部９０６は、データフィールドにＭＡＣを付加する。
　ステップＳ２０１１で、受信したフレームにＭＡＣが付されていた場合、或いは、ステップＳ２００９又はステップＳ２０１３での処理後に、転送制御部９０６は、フレーム生成部９０５に、メッセージＩＤ、データフィールド、ＤＬＣ、及び、転送先バス情報（転送先バスＩＤ）を通知する。これにより、フレーム生成部９０５は、転送制御部９０６より通知されたメッセージＩＤと、データフィールドとを用い、ＣＲＣを再計算して送信用フレームを構成し、転送先バス情報（転送先バスＩＤ）と、その送信用フレームとをフレーム送受信部９０１へ通知する（ステップＳ２０１４）。
　次に、ゲートウェイ９０のフレーム送受信部９０１は、フレーム生成部９０５より生成された送信用フレームを転送先バス情報が示すバス（つまり転送先バス）へと送信する（ステップＳ２０１５）。これにより、ゲートウェイ９０によりバス間でのフレームの転送が実現される。
　ステップＳ２０１５に対応して、転送先バスに接続された転送先ＥＣＵは、ゲートウェイ９０により送信（転送）されたフレームを受信する（ステップＳ２０１６）。なお、転送先ＥＣＵがＭＡＣ対応ＥＣＵである場合において、受信したフレームにおけるデータフィールドの内容から、バス占有率に応じてＭＡＣが削除されていることがあり得る。これに対して、ＭＡＣ対応ＥＣＵは、例えば、自らが処理対象とするメッセージＩＤのフレームについてのデータのサイズが予め仕様等により定められているのであれば、ＤＬＣの値によってＭＡＣが付加されているか否かを判断可能となる。また、本実施の形態に係る車載ネットワークシステム１においてフレームには、そのフレームにＭＡＣ（検証用情報）が含まれるか否かを表す情報（例えばデータフィールド内の１ビットの領域を用いたフラグ）を含ませることとしても良く、ゲートウェイ９０でＭＡＣを削除した場合には、ＭＡＣが含まれない旨を示す情報をフレームに含ませ得る。この場合には、ステップＳ２０１５でフレームを受信したＭＡＣ対応ＥＣＵは、そのＭＡＣが含まれるか否かを表す情報に基づいて、ＭＡＣが含まれていればＭＡＣの検証を行い、ＭＡＣが含まれていなければＭＡＣの検証を行わない等の対処を行い得る。
　［２．３　実施の形態２の効果］
　実施の形態２に係る車載ネットワークシステム１では、ゲートウェイ９０が、フレーム（メッセージ）の転送に際して、転送先バスにＭＡＣ対応ＥＣＵが接続されていない場合（つまり転送先バスがＭＡＣ非対応バスである場合）に加えて、転送先バスにＭＡＣ対応ＥＣＵが接続されていてもその転送先バスのバス占有率がＭＡＣの削除条件を満たす程度に高い場合にも、ＭＡＣを削除して送信するので、転送先バスのトラフィック量を抑えることできる。また、ＭＡＣ対応バスである転送先バスのバス占有率がＭＡＣの削除条件を満たさない程度に低い場合には、ゲートウェイ９０がＭＡＣを含むフレームを転送するので、その転送先バスに接続されたＭＡＣ対応ＥＣＵにとっては、ＭＡＣの検証によりフレームが不正か否かを判別可能となり、車載ネットワークのセキュリティの確保等が実現され得る。
　（実施の形態３）
　以下、実施の形態１で示した車載ネットワークシステム１の一部を変形した、また別の実施の形態について説明する。
　実施の形態１では、データフレームのフォーマットとして、バス間で共通してＣＡＮの標準フォーマットを用いる例を示した（図２参照）。これに対して、実施の形態３では、バス毎に、ＣＡＮの標準フォーマットを用いるか、拡張フォーマットを用いるかが定められている例を示す。拡張フォーマットは、ＣＡＮの派生プロトコルであるＣＡＮ－ＦＤ（CAN　with　Flexible　Data　Rate）で規定されるフォーマットである。
　本実施の形態におけるゲートウェイ装置を含む車載ネットワークシステムの構成要素は、概ね実施の形態１と同様であるため、ここでは、実施の形態１と同様の符号を用いる。ここでは実施の形態１と相違点について説明し、ここで説明しない点については、実施の形態１と同様である。
　［３．１　標準フォーマット及び拡張フォーマット］
　図１５は、データフレームの標準ファーマットと拡張フォーマットとを示す図である。図１５において（ａ）は、図２に示したものと同様の、ＣＡＮの標準フォーマットを示し、（ｂ）は、ＣＡＮ－ＦＤで規定されるフォーマットである拡張フォーマットを示す。
　標準フォーマットでは、ＩＤ（メッセージＩＤ）が１１ビットであり、データフィールドが６４ビットであるのに対して、拡張フォーマットでは、標準フォーマットにおけるＩＤフィールドのベースＩＤの１１ビットと、拡張ＩＤの１８ビットとを合わせて２９ビットでＩＤ（メッセージＩＤ）が表され、データフィールドが５１２ビットに拡張されている。
　［３．２　バス情報（対応フォーマットリスト）］
　本実施の形態に係るゲートウェイ９０の転送ルール保持部９０７は、バス情報９０７０と転送ルール情報９０７１との他に、バス情報の一種としての対応フォーマットリスト９０７３を保持する。
　図１６は、本実施の形態に係るゲートウェイ９０の転送ルール保持部９０７が保持するバス情報の一種としての対応フォーマットリストの一例を示す。実施の形態１で示したバス情報９０７０（図６参照）は、各バスがＭＡＣ対応バスであるかＭＡＣ非対応バスであるかをバス毎に示した情報であるのに対して、この対応フォーマットリスト９０７３は、各バスで送受信されるデータフレームのフォーマットが標準フォーマットであるか拡張フォーマットであるかをバス毎に示した情報である。なお、図１６の例は、図１で示した各バスの符号が、そのバスの識別子（バスＩＤ）であることとした例である。
　図１６の例では、例えばバスＩＤが１０であるバス１０は、拡張フォーマットのフレームの送受信に対応していることを示している。また、バスＩＤが５０であるバス５０は、標準フォーマットのフレームの送受信に対応しており、拡張フォーマットのフレームの送受信に対応していないことを示している。なお、対応フォーマットリスト９０７３の内容を、バス情報９０７０に含ませることとしても良い。
　また、例えば、拡張フォーマットはデータフィールドが比較的大きいため、ＭＡＣ対応ＥＣＵを接続したバスを拡張フォーマットに対応させ、ＭＡＣ対応ＥＣＵを接続しておらずＭＡＣ非対応ＥＣＵを接続しているバスを、標準フォーマットに対応させるように車載ネットワークシステムを構成しても良い。この場合には、バス情報９０７０を用いずに対応フォーマットリスト９０７３に基づいて、ゲートウェイ９０が、転送先バスが、標準フォーマットに対応しているバスか拡張フォーマットに対応しているバスかによって、ＭＡＣ対応バスであるかＭＡＣ非対応バスであるかを判断するようにしても良い。つまり、ゲートウェイ９０は、バス情報の一種である対応フォーマットリスト（バス毎にバスとフレームフォーマットとを対応付けた情報）により所定のフレームフォーマットに対応付けられている場合にはＭＡＣの削除条件が満たされたとして、ＭＡＣを削除して転送を行い得る。
　［３．３　標準フォーマットのバスから拡張フォーマットのバスへのフレーム転送に係るフォーマット変換例］
　図１７は、フレームの転送元バスが標準フォーマットに対応したＭＡＣ対応バスで、転送先バスが拡張フォーマットに対応したＭＡＣ非対応バスである場合の転送に係るフォーマット変換例を示す図である。
　同図の例では、ゲートウェイ９０の転送制御部９０６が、転送先バスがＭＡＣ非対応バスであると判断し、受信したフレームのデータフィールドのＭＡＣを削除するとともに、フォーマットを標準フォーマットから拡張フォーマットに変更して、転送するように制御する。拡張フォーマットに変更するため、転送制御部９０６は、図１７に示すように、受信した複数の標準フォーマットのデータフレームを１つの拡張フォーマットのフレームに統合して転送するようにフレーム生成部９０５に指示する。この指示に対応して、フレーム生成部９０５は、転送制御部９０６から受信した複数のデータを１つのデータに結合して、拡張フォーマットのフレームを生成する。そして、フレーム送受信部９０１は、フレーム生成部９０５にて生成された拡張フォーマットのフレームを、転送先バスへと送信する。
　なお、ゲートウェイ９０が、フレームの転送に際して、ＭＡＣを付加するか削除するかに係る判断については、実施の形態１と同様である（図１０及び図１１参照）。この判断を、例えば実施の形態２で示したように転送先バスのバス占有率にも基づいて行っても良い（図１３及び図１４参照）。
　標準フォーマットに対応したバスから拡張フォーマットに対応したバスへの転送に際しては、ゲートウェイ９０は、例えば、受信した標準フォーマットのデータフレームを即座に転送するのではなく、一定時間待ってその間に後続する同じメッセージＩＤの１以上のフレームが受信できれば、合わせて拡張フォーマットに変換してから変換後のフレームを転送先バスへと送信（転送）する。この一定時間待っている間に後続する同じメッセージＩＤのフレームが受信できなければ、一定時間の経過時点で受信できていたデータフレームのみを拡張フォーマットに変換して転送することになる。なお、ゲートウェイ９０は、転送に際してフレームを統合しなくても良く、例えば、１つの標準フォーマットのフレームを受信する都度、１つの拡張フォーマットのフレームを送信することとしても良い。
　［３．４　拡張フォーマットのバスから標準フォーマットのバスへのフレーム転送に係るフォーマット変換例］
　図１８は、フレームの転送元バスが拡張フォーマットに対応したＭＡＣ対応バスで、転送先バスが標準フォーマットに対応したＭＡＣ非対応バスである場合の転送に係るフォーマット変換例を示す図である。
　同図の例では、ゲートウェイ９０の転送制御部９０６が、転送先バスがＭＡＣ非対応バスであると判断し、受信したフレームのデータフィールドのＭＡＣを削除するとともに、フォーマットを拡張フォーマットから標準フォーマットに変更して、転送するように制御する。標準フォーマットに変更するため、転送制御部９０６は、図１８に示すように、受信した拡張フォーマットのデータフレームのデータフィールドの長さに応じて、１つの標準フォーマットのフレームとして転送するように、或いは、標準フォーマットのデータフィールドに収まらない場合には複数の標準フォーマットのフレームへと分割して転送するように、フレーム生成部９０５に指示する。この指示に対応して、フレーム生成部９０５は、転送制御部９０６から受信したデータを必要に応じて複数のデータに分割して、各データをデータフィールドに格納した標準フォーマットの各データフレームを生成する。そして、フレーム送受信部９０１は、フレーム生成部９０５にて生成された標準フォーマットの各フレームを、転送先バスへと送信する。ゲートウェイ９０は、分割により複数のフレームを送信することとなる場合において、送信を連続的に行っても良いし、例えばフレーム間に予め定めた送信間隔を空けて断続的に送信を行っても良い。
　［３．５　実施の形態３の効果］
　実施の形態３に係る車載ネットワークシステム１では、ゲートウェイ９０が、フレーム（メッセージ）の転送に際して、フォーマットの変換を行うことができ、転送先バスにＭＡＣ対応ＥＣＵが接続されていない場合等にＭＡＣを削除して送信するので、転送先バスのトラフィック量を抑えることできる。
　（他の実施の形態）
　以上のように、本開示に係る技術の例示として実施の形態１～３を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
　（１）上記実施の形態では、転送先バスがＭＡＣ対応バスであるか否か、転送先バスのバス占有率、転送先バスが対応しているフレームのフォーマット等に基づき、転送に際してフレームのＭＡＣを削除すべきか否かをゲートウェイ９０が判断する例を示したが、これらの組み合わせを用いて判断しても良いし、他の条件を合わせて用いて判断しても良い。実施の形態１では、転送先バスがＭＡＣ対応バスである場合にはゲートウェイはＭＡＣを削除せずに（ＭＡＣが付加されていなければ付加して）フレームを転送することとした。このＭＡＣ対応バスには、ＭＡＣ対応ＥＣＵの他にＭＡＣ非対応ＥＣＵが接続されていても良い。この場合に、ＭＡＣ非対応ＥＣＵでは、フレームに含まれるＭＡＣを検証しないが、ＭＡＣ対応ＥＣＵではＭＡＣを検証するので、セキュリティの確保が実現され得る。
　（２）上記実施の形態２では、ゲートウェイ９０が、ＭＡＣを含むフレームの転送に際して、転送先バスのバス占有率が、ＭＡＣの削除条件として定められた占有率の値よりも低い場合に、そのＭＡＣを含んだフレームのデータフィールドの内容を変更せずにフレームを転送先バスへと転送（送信）する例を示したが、ＭＡＣの付け替えを行って転送しても良い。これは実施の形態１で示したように、バス毎にＭＡＣ鍵が異なるようにしているのであれば、ＭＡＣを転送先バスに合わせたＭＡＣ鍵で生成したものに付け替える方式を採り得る。ＭＡＣ鍵は、ＥＣＵ毎に個別のＭＡＣ鍵にしても良いし、同一バス上に接続されるＥＣＵは同一のＭＡＣ鍵を利用することとしても良い。また、ゲートウェイ９０は、ＭＡＣを含まないフレームの転送に際して、転送先バスのバス占有率が、ＭＡＣの付加条件として定められた占有率の値よりも低い場合に、そのフレームのデータフィールドの内容にＭＡＣを付加したフレームを構成して転送先バスへと転送（送信）することとしても良い。
　（３）上記実施の形態３では、ゲートウェイ９０が、ＣＡＮの標準フォーマットのデータフレームからＭＡＣを削除して、複数のデータフレームを１つのＣＡＮ－ＦＤの拡張フォーマットのデータフレームとして送信する例を示したが、転送先バスに接続されたＥＣＵがＭＡＣ対応ＥＣＵである場合には、拡張フォーマットのデータフレーム内にＭＡＣを付加して送信しても良い。なお、標準フォーマットの複数のデータフレームにおけるＭＡＣに基づいて（例えば複数のＭＡＣの結合等で）、拡張フォーマットのデータフレーム内に含ませるＭＡＣを算定しても良いし、標準フォーマットの複数のデータフレームにおけるデータを結合したものである、拡張フォーマットのデータフレーム内に含ませるデータに基づいて、そのＭＡＣの算定を行っても良い。
　（４）上記実施の形態３では、転送元バスと転送先バスとで対応フォーマットが異なる場合においてフレームの転送に際してゲートウェイ９０がＭＡＣを削除する例を示したが、転送元バスと転送先バスとが標準フォーマットに対応する場合において、ゲートウェイ９０が、複数のフレームについてＭＡＣを削除して、１つの標準フォーマットのフレームにまとめて転送しても良い。例えば、データフィールドが４バイトのデータと４バイトのＭＡＣとで構成される標準フォーマットのデータフレームを受信する場合に、ゲートウェイ９０は、２つのフレームのデータフィールドの４バイトのデータを、１つにまとめて８バイトのデータにしてデータフィールドに格納して標準フォーマットのデータフレームにして転送を行っても良い。また、転送元バスと転送先バスとが拡張フォーマットに対応する場合にも、同様に、ゲートウェイ９０は、ＭＡＣを削除した複数のフレームの内容を１つの拡張フォーマットのフレームとして転送しても良い。
　（５）上記実施の形態では、１台のゲートウェイ９０に注目して説明したが、ゲートウェイ装置を複数含むように車載ネットワークシステムを構成しても良く、１つのバスに複数のゲートウェイ装置が接続され得る。この各ゲートウェイ装置は、各実施の形態で示したゲートウェイ９０と同様の転送に係る処理を行い得る。
　（６）上記実施の形態では、バス毎に、そのバスがＭＡＣ対応バスか否かを区別して、フレームの転送に際してＭＡＣを削除するか付加するかの判断を行うゲートウェイ９０を示した。ＭＡＣは、フレームの検証用情報の一例であり、他の検証に用いられる情報であっても良い。つまり、ゲートウェイ９０は、バス毎にそのバスが、検証用情報（例えばＭＡＣ）に基づくフレームの検証機能を有するＥＣＵが接続されている検証対応バス（例えばＭＡＣ対応バス）か、検証機能を有するＥＣＵが接続されていない検証非対応バス（例えばＭＡＣ非対応バス）かを示すバス情報に基づいて、検証用情報の削除又は付加に係る判断を行い得る。この他に、ゲートウェイ９０は、フレームの転送に際して、そのフレームのメッセージＩＤと転送先バスにおいてそのメッセージＩＤのフレームを処理するＥＣＵがＭＡＣ対応ＥＣＵであるかＭＡＣ非対応ＥＣＵであるかを予め対応付けておいた情報を用いて、ＭＡＣを削除すべきか否か、或いはＭＡＣを付加すべきか否かを判断することとしても良い。この具体例として、ゲートウェイ９０は、メッセージＩＤ毎に、ＭＡＣ対応ＥＣＵにより検証等の処理対象とされる検証メッセージ識別子と、その検証等の処理対象とされない非検証メッセージ識別子とを区別するメッセージ識別子情報を保持し、受信したフレームのメッセージＩＤに応じてＭＡＣを削除する削除条件が満たされたか否かをメッセージ識別子情報に基づいて判断することとしても良い。例えば、ゲートウェイ９０は、受信したフレームのメッセージＩＤが非検証メッセージ識別子であるときにはＭＡＣの削除条件が満たされたとして、ＭＡＣを削除して転送し得る。なお、バス情報にメッセージ識別子情報が含まれていても良く、ゲートウェイ９０は、転送先バスが検証対応バス（例えばＭＡＣ対応バス）である場合において、受信されたフレームの識別子が非検証メッセージ識別子であるときにはＭＡＣの削除条件が満たされたとして、ＭＡＣを削除して転送を行うこととしても良い。また別の具体例として、ゲートウェイ９０は、ＥＣＵ毎に、ＭＡＣ対応ＥＣＵ（ＭＡＣに基づくフレームの検証機能を有するＥＣＵ）であるか否かを示すＥＣＵ情報を保持し、ＭＡＣを削除する削除条件が満たされたか否かをこのＥＣＵ情報に基づいて判断することとしても良い。例えば、ゲートウェイ９０は、受信したフレームの転送先となる転送先バスに接続されてそのフレームに応じた処理を実行するＥＣＵがＭＡＣ対応ＥＣＵでない場合に、ＭＡＣの削除条件が満たされたとして、ＭＡＣを削除して転送し得る。なお、フレームの転送に際して、ゲートウェイ９０は、どのバスにどのＥＣＵが接続されているかを示す情報を保持して利用しても良いし、どのメッセージＩＤを含むフレームがどのＥＣＵに処理されるかを示す情報を保持して利用しても良い。ゲートウェイ９０は、バス毎にバスがＭＡＣ対応か否かを示すリスト、フレームを受信し得るＥＣＵ毎にＭＡＣ対応ＥＣＵであるか否かを示すリスト、メッセージＩＤ毎にＭＡＣ対応ＥＣＵに処理されるか否かを示すリスト等を適宜利用し、必要に応じて転送先バスのバス占有率を用いて、転送に際してフレームのＭＡＣを削除するか否かを判断し得る。
　（７）上記実施の形態では、バス単位で、ＭＡＣ対応バス（ＭＡＣ対応ＥＣＵが接続されているバス）か否かにより、ゲートウェイ９０がフレームの転送に際してＭＡＣを削除すべきか否かを判断する例を示した。しかし、１つのバスにＭＡＣ対応ＥＣＵとＭＡＣ非対応ＥＣＵとが接続されている場合には、ゲートウェイ９０がフレームを受信した際に、ＭＡＣ対応ＥＣＵ向けの、ＭＡＣを含ませたフレームと、そのフレームと異なるメッセージＩＤを有するＭＡＣ非対応ＥＣＵ向けの、ＭＡＣを削除したフレームとを送信することで、フレームの転送を実現しても良い。即ち、ゲートウェイ９０の転送部（転送制御部９０６、フレーム生成部９０５、フレーム送受信部９０１等）により、受信された検証用情報（例えばＭＡＣ）を含む第１フレームについて、その第１フレームの内容のうち検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含まない第２フレームを生成してその第２フレームを転送先バスに送信することで、フレームの転送を行い、更に、その第１フレームの内容のうち検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含み、第２フレームとは異なる、フレームの識別子を有する第３フレームを送信することとしても良い。この場合に、ゲートウェイ９０から送信される２種類のフレームそれぞれのメッセージＩＤについては、予め車載ネットワークシステム１において定められ、各ＥＣＵは必要なメッセージＩＤを識別して受信する。
　（８）上記実施の形態で示したゲートウェイ９０は、転送に際して例えばステップＳ１００６等でＭＡＣを検証するが、ゲートウェイ９０は、ＭＡＣ検証に成功した場合に、転送するフレームの一部に予め定めておくフラグ領域に、ＭＡＣを削除するか否かに拘わらず、ＭＡＣ検証に成功したことを示す値を設定することとしても良い。この場合において、転送先バスに接続されたＥＣＵでは、ＭＡＣ検証に成功したことを示す値がフラグ領域に設定されているフレームを受信したときに、そのフレームについてのＭＡＣの検証処理を省略しても良い。これにより、ＥＣＵの処理負荷の削減、省電力化等の効果が生じる。また、上記実施の形態では、受信したフレームのＭＡＣの検証に失敗した場合に、ゲートウェイ９０が、そのフレームの転送を中止する例を示したが、フレームのＭＡＣの検証に失敗した場合にそのフレームのメッセージＩＤを記憶しておき、ゲートウェイ９０は、それ以後そのメッセージＩＤのフレームを受信しても、転送を行わないこととしても良い。
　（９）上記実施の形態３では、転送先バスと転送元バスとで対応するフレームフォーマットが異なる場合におけるＭＡＣの削除について説明しているが、逆に転送に際してＭＡＣを付加しても良い。また、フレームフォーマットが異なる他、転送元と転送先バスとにおいて対応する通信プロトコル種別が相違（物理層、その他の上位層のいずれかが相違）する場合に、ゲートウェイ９０が、フレームに対するＭＡＣの削除又は付加を行うこととしても良い。ゲートウェイ９０は、一のネットワークから受信したフレームを他のネットワークへと転送する機能を有するものであれば良く、バス以外のネットワーク（例えば無線ネットワーク）から受信したフレームをＣＡＮのバスに転送するものであっても良い。フレームを受信したネットワークと、転送先のネットワークとのそれぞれが対応する通信プロトコル種別の相違は、例えばネットワーク種別の相違である。バス情報として、バス毎にそのバスでの通信で用いられる通信プロトコルの種別を対応付けていても良い。例えば、ゲートウェイ９０がＣＡＮのバス以外にＥｔｈｅｒｎｅｔ（登録商標）にも接続されており、転送元ネットワークがＥｔｈｅｒｎｅｔ（登録商標）であって転送先ネットワークがＣＡＮのバスである場合に、ゲートウェイ９０は、ＭＡＣの削除条件が満たされたと判定してＭＡＣを削除するようにしても良い。また、転送元ネットワークがＣＡＮのバスで、転送先ネットワークがＥｔｈｅｒｎｅｔ（登録商標）の場合に、ゲートウェイ９０は、ＭＡＣを付加するようにしても良い。ここでの、ＭＡＣの削除或いは付加の条件とする転送元ネットワークと転送先ネットワークとに係るネットワーク種別（通信プロトコル）は、いかなるものであっても良く、例えば、ＣＡＮ、ＣＡＮ－ＦＤ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＬＩＮ（Local　Interconnect　Network）、Ｆｌｅｘｒａｙ（登録商標）等の組合せであっても良い。また、ネットワーク種別毎にＭＡＣの削除又は付加を定めておく場合において、フレーム長が一定値より長いネットワークを転送先とするときにはＭＡＣを付加し、その一定値より短いネットワークを転送先とするときにはＭＡＣを削除するという方式を用いても良い。
　（１０）上記実施の形態で示したゲートウェイ９０は、受信したデータフレームの内容が暗号化されている場合には、そのフレームを復号した後に、その復号したフレームの内容からＭＡＣを削除して、或いは、復号したフレームの内容にＭＡＣを付加して、転送を行うこととしても良い。この場合に再度フレームの内容を暗号化しても良い。なお、ゲートウェイ９０は、転送先となるＥＣＵが復号機能を有さない場合等に転送に際してフレームの内容を復号により平文にして送信することとしても良い。このフレームを受信したＥＣＵでは復号処理の負荷が削減され得る。また、転送先のＥＣＵが復号機能を有する場合には、そのＥＣＵに対応した鍵でフレームの内容を暗号して送信しても良い。このとき、共通鍵暗号方式で暗号化して転送するのであれば、ゲートウェイ９０と転送先のＥＣＵとの間で共有している鍵で再暗号化することとしても良い。
　（１１）上記実施の形態で示したＭＡＣ対応バスは、ＭＡＣ対応ＥＣＵが接続されているバスであることとしたが、ＭＡＣ対応バスは、例えば、そのバスにＭＡＣを含むフレームが流されるべきバスであることとしても良い。ＭＡＣ非対応バスは、例えば、そのバスにＭＡＣを含まないフレームが流されるべきバスであることとしても良い。車載ネットワークシステム１において、各バスをＭＡＣ対応バスかＭＡＣ非対応バスかに分類しておくことにより、各バスについて、そのバスに適したＥＣＵを随時追加することが可能になる。
　（１２）上記実施の形態で示したゲートウェイ９０は、フレームの転送に際して一定条件下でＭＡＣを削除する機能と一定条件下でＭＡＣを付加する機能とを含むこととしたが、その機能の一方のみを含むものであっても良い。
　（１３）上記実施の形態における各ＥＣＵ（ゲートウェイを含む）は、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
　（１４）上記実施の形態における各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large　Scale　Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field　Programmable　Gate　Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（１５）上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしても良い。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしても良い。
　（１６）本開示の一態様としては、上述した車載ネットワークにおけるフレームの転送に係る転送方法等の方法であるとしても良い。例えば、転送方法は、フレームを受信する受信ステップと、受信ステップでフレームが受信された場合に、バスの１つである転送先バスへ、そのフレームを、そのフレームの検証に用いられる検証用情報（例えばＭＡＣ）の削除又は付加をした上で、転送する転送ステップとを含む。また、この方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標）　Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
　（１７）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示は、ＭＡＣ等の検証用情報を含み得るフレーム（メッセージ）の送受信に用いられる車載ネットワークにおいて適切にフレームを転送するために利用可能である。
　１　車載ネットワークシステム
　１０，２０，３０，４０，５０，６０，７０　バス
　９０　ゲートウェイ
　１００，１０１，２００，２０１，３００，３０１　電子制御ユニット（ＭＡＣ対応ＥＣＵ）
　１１０　エンジン
　１１１　トランスミッション
　２１０　ブレーキ
　２１１　ステアリング
　３１０　自動ブレーキ
　３１１　車線維持装置
　４００，４０１，５００，６００，７００　電子制御ユニット（ＭＡＣ非対応ＥＣＵ）
　４１０　ドア
　４１１　ライト
　５１０　インストルメントパネル
　６１０　ＩＴＳ装置
　７１０　診断ポート
　８００，８１０，９０１　フレーム送受信部
　８０１，８１１，９０２　フレーム解釈部
　８０２，８１２，９０３　受信ＩＤ判断部
　８０３，８１３，９０４　受信ＩＤリスト保持部
　８０４，８１４　フレーム処理部
　８０５，８１５，９０５　フレーム生成部
　８０６，８１６　データ取得部
　８２０，９２０　ＭＡＣ制御部
　８２１，９２１　ＭＡＣ鍵保持部
　８２２，９２２　カウンタ保持部
　９０６　転送制御部
　９０７　転送ルール保持部
　９０７０　バス情報
　９０７１　転送ルール情報
　９０７２　削除条件リスト
　９０７３　対応フォーマットリスト
　９２１０　ＭＡＣ鍵リスト
　９２２０　カウンタリスト

Claims (19)

  1. 　複数の電子制御ユニットが通信に用いる１つ以上のバスに接続されたゲートウェイ装置であって、
    　フレームを受信する受信部と、
    　前記受信部により受信されたフレームの内容から当該フレームの検証に用いられる検証用情報を削除して当該フレームの、前記バスの１つである転送先バスへの転送を行う、又は、当該フレームの内容に検証用情報を付加して当該フレームの、前記転送先バスへの転送を行う、転送部とを備える
    　ゲートウェイ装置。
  2. 　前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、前記検証用情報を削除するための所定削除条件が満たされた場合には、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含む第２フレームを生成して当該第２フレームを前記転送先バスに送信することで、前記転送を行う
    　請求項１記載のゲートウェイ装置。
  3. 　前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、
    　前記検証用情報はフレームにおいてデータフィールドに配置されるメッセージ認証コードであり、
    　前記転送部は、前記所定削除条件が満たされた場合には、前記第１フレームにおけるメッセージ認証コード以外のデータフィールドの内容を含み、メッセージ認証コードを含まない第２フレームを前記転送先バスに送信する
    　請求項２記載のゲートウェイ装置。
  4. 　前記ゲートウェイ装置は、複数のバスに接続され、
    　前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、バス毎に当該バスが、前記検証用情報に基づくフレームの検証機能を有する電子制御ユニットが接続されている検証対応バスか、前記検証機能を有する電子制御ユニットが接続されていない検証非対応バスかを示すバス情報とを保持する転送ルール保持部を備え、
    　前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが検証非対応バスである場合には前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２又は３記載のゲートウェイ装置。
  5. 　前記バス情報は、検証対応バスに接続された前記検証機能を有する電子制御ユニットにより検証されるフレームの識別子である検証メッセージ識別子と、検証されないフレームの識別子である非検証メッセージ識別子とを区別するためのメッセージ識別子情報を含み、
    　前記転送部は、前記転送先バスが検証対応バスである場合において、前記受信部により受信されたフレームの識別子が非検証メッセージ識別子であるときには前記所定削除条件が満たされたとして、前記転送を行う
    　請求項４記載のゲートウェイ装置。
  6. 　前記転送部は、前記転送先バスのバス占有率が所定値より高い場合に前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２～５のいずれか一項に記載のゲートウェイ装置。
  7. 　前記転送部は、前記転送先バスに送信するフレームに、当該フレームに検証用情報が含まれるか否かを表す情報を含ませる
    　請求項６記載のゲートウェイ装置。
  8. 　前記ゲートウェイ装置は、前記１以上のバスに接続された電子制御ユニット毎に当該電子制御ユニットが前記検証用情報に基づくフレームの検証機能を有するか否かを示す情報を保持し、
    　前記転送部は、前記受信部により受信されたフレームの転送先となる前記転送先バスに接続されて当該フレームに応じた処理を実行する電子制御ユニットが前記検証機能を有さない場合に、前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２又は３記載のゲートウェイ装置。
  9. 　前記ゲートウェイ装置は、前記１以上のバスに接続された、前記検証用情報に基づくフレームの検証機能を有する電子制御ユニットにより、検証されるフレームの識別子である検証メッセージ識別子と、検証されないフレームの識別子である非検証メッセージ識別子とを区別するメッセージ識別子情報を保持し、
    　前記転送部は、前記受信部により受信されたフレームの識別子が非検証メッセージ識別子であるときには前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２又は３記載のゲートウェイ装置。
  10. 　前記転送部は、前記受信部により受信されたフレームの前記検証用情報に基づく検証により当該フレームが不正と判定した場合には、前記転送を行わない
    　請求項２～９のいずれか一項に記載のゲートウェイ装置。
  11. 　前記ゲートウェイ装置は、複数のバスに接続され、
    　前記ゲートウェイ装置は、
    　前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、
    　バス毎に当該バスとフレームフォーマットとを対応付けたバス情報とを保持する転送ルール保持部を備え、
    　前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが前記バス情報により所定のフレームフォーマットに対応付けられている場合には前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２又は３記載のゲートウェイ装置。
  12. 　前記ゲートウェイ装置は、複数のバスに接続され、
    　前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報と、バス毎に当該バスでの通信で用いられる通信プロトコルの種別を対応付けたバス情報とを保持する転送ルール保持部を備え、
    　前記転送部は前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが前記バス情報により所定の通信プロトコルに対応付けられている場合には前記所定削除条件が満たされたとして、前記転送を行う
    　請求項２又は３記載のゲートウェイ装置。
  13. 　前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、前記検証用情報を削除するための所定削除条件が満たされなかった場合には、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報と、前記転送先バスに接続された電子制御ユニットと共有している鍵を用いて生成した検証用情報とを含む第２フレームを生成して当該第２フレームを前記転送先バスに送信する
    　請求項２～１２のいずれか一項に記載のゲートウェイ装置。
  14. 　前記転送部は、前記受信部により受信された、検証用情報を含まないフレームについて、検証用情報を付加するための所定付加条件が満たされた場合には、当該フレームの内容に基づく情報と、検証用情報とを含むフレームを生成して、生成した当該フレームを前記転送先バスに送信することで、前記転送を行う
    　請求項１～１３のいずれか一項に記載のゲートウェイ装置。
  15. 　前記転送部は、
    　前記受信部により受信されたフレームの内容が暗号化されている場合に当該フレームを復号した後に、
    　復号した当該フレームの内容から検証用情報を削除して、又は、復号した当該フレームの内容に検証用情報を付加して、
    　当該フレームの前記転送を行う
    　請求項１記載のゲートウェイ装置。
  16. 　前記転送部は、前記受信部により受信された検証用情報を含む第１フレームについて、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含まない第２フレームを生成して当該第２フレームを前記転送先バスに送信することで、前記転送を行い、更に、当該第１フレームの内容のうち前記検証用情報を除いた内容に基づく情報を含み且つ検証用情報を含み、前記第２フレームとは異なる、フレームの識別子を有する第３フレームを送信する
    　請求項１記載のゲートウェイ装置。
  17. 　１以上のバスを介して通信する複数の電子制御ユニットと前記バスに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、
    　前記ゲートウェイ装置は、
    　フレームを受信する受信部と、
    　前記受信部により受信されたフレームの内容から当該フレームの検証に用いられる検証用情報を削除して当該フレームの、前記バスの１つである転送先バスへの転送を行う、又は、当該フレームの内容に検証用情報を付加して当該フレームの、前記転送先バスへの転送を行う、転送部とを備える
    　車載ネットワークシステム。
  18. 　前記車載ネットワークシステムは、電子制御ユニットが接続されている複数のバスを備え、
    　前記ゲートウェイ装置は、前記複数のバスに接続され、
    　前記ゲートウェイ装置は、前記複数のバスから、前記受信部により受信されたフレームの転送先となる前記転送先バスを、選択するための基準を示す転送ルール情報を保持する転送ルール保持部を備え、
    　前記転送部は前記受信部により受信されたフレームの前記転送に際して前記転送ルール情報に基づいて前記転送先バスを選択し、当該転送先バスが、検証用情報に基づくフレームの検証機能を有する電子制御ユニットが接続されているバスであるか否かに応じて、当該フレームについて検証用情報の削除又は付加をして前記転送を行う
    　請求項１７記載の車載ネットワークシステム。
  19. 　１以上のバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる転送方法であって、
    　フレームを受信する受信ステップと、
    　前記受信ステップでフレームが受信された場合に、前記バスの１つである転送先バスへ、当該フレームを、当該フレームの検証に用いられる検証用情報の削除又は付加をした上で、転送する転送ステップとを含む
    　転送方法。
PCT/JP2016/003145 2015-08-31 2016-06-30 ゲートウェイ装置、車載ネットワークシステム及び転送方法 WO2017037982A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
CN202110623085.9A CN113300947B (zh) 2015-08-31 2016-06-30 网关装置、车载网络系统以及转送方法
CN202110629451.1A CN113300927B (zh) 2015-08-31 2016-06-30 网关装置、车载网络系统以及转送方法
CN201680016304.4A CN107431625B (zh) 2015-08-31 2016-06-30 网关装置、车载网络系统以及转送方法
EP19180080.4A EP3562103B1 (en) 2015-08-31 2016-06-30 Gateway device, car onboard network system, and transfer method
EP20182263.2A EP3734911B1 (en) 2015-08-31 2016-06-30 Gateway device, car onboard network system, and transfer method
EP16841029.8A EP3346646B1 (en) 2015-08-31 2016-06-30 Gateway device, car onboard network system, and transfer method
US15/881,826 US10525911B2 (en) 2015-08-31 2018-01-29 Gateway device, vehicle network system, and transfer method
US16/664,192 US10974669B2 (en) 2015-08-31 2019-10-25 Gateway device, vehicle network system, and transfer method
US17/194,701 US11529914B2 (en) 2015-08-31 2021-03-08 Gateway device, vehicle network system, and transfer method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562212104P 2015-08-31 2015-08-31
US62/212,104 2015-08-31
JP2016119773A JP6787697B2 (ja) 2015-08-31 2016-06-16 ゲートウェイ装置、車載ネットワークシステム及び転送方法
JP2016-119773 2016-06-16

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/881,826 Continuation US10525911B2 (en) 2015-08-31 2018-01-29 Gateway device, vehicle network system, and transfer method

Publications (1)

Publication Number Publication Date
WO2017037982A1 true WO2017037982A1 (ja) 2017-03-09

Family

ID=58186850

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/003145 WO2017037982A1 (ja) 2015-08-31 2016-06-30 ゲートウェイ装置、車載ネットワークシステム及び転送方法

Country Status (4)

Country Link
EP (1) EP3734911B1 (ja)
JP (1) JP6983977B2 (ja)
CN (2) CN113300947B (ja)
WO (1) WO2017037982A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110001552A (zh) * 2017-10-31 2019-07-12 矢崎总业株式会社 车载控制器
WO2020090108A1 (ja) * 2018-11-02 2020-05-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正制御防止システムおよび、不正制御防止方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09214556A (ja) * 1995-11-30 1997-08-15 Toshiba Corp パケット転送方法、パケット処理装置、パケット暗号化方法、パケット復号化方法及びパケット暗号処理方法
JP2005343430A (ja) * 2004-06-07 2005-12-15 Denso Corp 車両制御システム
JP2013201510A (ja) * 2012-03-23 2013-10-03 Denso Corp 車両用データ通信システム及び車両用データ通信装置
WO2013175633A1 (ja) * 2012-05-25 2013-11-28 トヨタ自動車 株式会社 通信装置、通信システム及び通信方法
WO2013179392A1 (ja) * 2012-05-29 2013-12-05 トヨタ自動車 株式会社 認証システム及び認証方法
US20150089236A1 (en) * 2013-09-24 2015-03-26 The Regents Of The University Of Michigan Real-Time Frame Authentication Using ID Anonymization In Automotive Networks
JP2016134834A (ja) * 2015-01-21 2016-07-25 トヨタ自動車株式会社 車載ゲートウェイ装置及び車載ネットワークシステム

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3449542B2 (ja) * 1999-12-22 2003-09-22 日本電気株式会社 Ｍａｃフレーム転送方法及びフレーム転送システム
US6735621B1 (en) * 2000-02-18 2004-05-11 Nortel Networks Limited Method and apparatus for messaging between disparate networks
CN100484044C (zh) * 2004-04-27 2009-04-29 华为技术有限公司 检测默认网关工作状态的方法及其装置
JP2006191337A (ja) * 2005-01-06 2006-07-20 Fujitsu Ten Ltd バス間のメッセージ転送を行うゲートウエイ装置及びそれを使用したネットワークシステム
JP2006352553A (ja) * 2005-06-16 2006-12-28 Nissan Motor Co Ltd 車載通信システム及び車載ゲートウェイ装置
US8130768B1 (en) * 2005-07-14 2012-03-06 Avaya Inc. Enhanced gateway for routing between networks
CN100586105C (zh) * 2007-04-20 2010-01-27 杭州华三通信技术有限公司 报文转发方法、系统及设备
CN101325554B (zh) * 2008-08-04 2011-04-27 北京星网锐捷网络技术有限公司 一种路由创建方法、转发芯片及三层交换机
JP5189432B2 (ja) * 2008-08-05 2013-04-24 株式会社東海理化電機製作所 暗号データ通信システム
CN101938500B (zh) * 2010-09-28 2012-12-12 中国人民解放军信息工程大学 源地址验证方法及系统
EP3328002B1 (en) * 2010-12-09 2019-05-15 Lantiq Deutschland GmbH Mac cycle alignment method for neighboring network coordination
EP2716502A4 (en) * 2011-05-25 2015-09-16 Toyota Motor Co Ltd VEHICLE COMMUNICATION DEVICE
JP4843116B1 (ja) * 2011-08-22 2011-12-21 株式会社Ｉｎｔｏ ネットワークゲートウェイ装置
CN103828477B (zh) * 2011-09-15 2018-05-22 费希尔-罗斯蒙特系统公司 跨越使用不兼容网络路由协议的通信网络传送数据帧
JP5770602B2 (ja) * 2011-10-31 2015-08-26 トヨタ自動車株式会社 通信システムにおけるメッセージ認証方法および通信システム
EP2832070B1 (en) * 2012-03-29 2020-05-20 Arilou Information Security Technologies Ltd. Device for protecting a vehicle electronic system
CN202513948U (zh) * 2012-04-16 2012-10-31 武汉大学 以太网至profibus-dp的主从式协议转换网关
US9843523B2 (en) * 2012-05-14 2017-12-12 Toyota Jidosha Kabushiki Kaisha Communication management apparatus and communication management method for vehicle network
DE102012215765A1 (de) * 2012-09-05 2014-05-15 Robert Bosch Gmbh Gateway-Modul für ein Kommunikationssystem, Kommunikationssystem und Verfahren zur Übertragung von Daten zwischen Teilnehmern eines Kommunikationssystems
JP2015534355A (ja) * 2012-09-14 2015-11-26 インターデイジタル パテント ホールディングス インコーポレイテッド 無線システムでＷｉ−Ｆｉオフローディングを行うためのモビリティ制御方法
CN103166858B (zh) * 2013-03-26 2016-06-08 杭州华三通信技术有限公司 一种报文传输方法和设备
WO2014199687A1 (ja) * 2013-06-13 2014-12-18 日立オートモティブシステムズ株式会社 ネットワーク装置およびネットワークシステム
JP6126980B2 (ja) * 2013-12-12 2017-05-10 日立オートモティブシステムズ株式会社 ネットワーク装置およびネットワークシステム
CN104767618B (zh) * 2015-04-03 2018-02-09 清华大学 一种基于广播的can总线认证方法及系统
CN104703174B (zh) * 2015-04-03 2017-11-21 清华大学 一种无线Mesh网络路由安全保护方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09214556A (ja) * 1995-11-30 1997-08-15 Toshiba Corp パケット転送方法、パケット処理装置、パケット暗号化方法、パケット復号化方法及びパケット暗号処理方法
JP2005343430A (ja) * 2004-06-07 2005-12-15 Denso Corp 車両制御システム
JP2013201510A (ja) * 2012-03-23 2013-10-03 Denso Corp 車両用データ通信システム及び車両用データ通信装置
WO2013175633A1 (ja) * 2012-05-25 2013-11-28 トヨタ自動車 株式会社 通信装置、通信システム及び通信方法
WO2013179392A1 (ja) * 2012-05-29 2013-12-05 トヨタ自動車 株式会社 認証システム及び認証方法
US20150089236A1 (en) * 2013-09-24 2015-03-26 The Regents Of The University Of Michigan Real-Time Frame Authentication Using ID Anonymization In Automotive Networks
JP2016134834A (ja) * 2015-01-21 2016-07-25 トヨタ自動車株式会社 車載ゲートウェイ装置及び車載ネットワークシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3346646A4 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110001552A (zh) * 2017-10-31 2019-07-12 矢崎总业株式会社 车载控制器
WO2020090108A1 (ja) * 2018-11-02 2020-05-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正制御防止システムおよび、不正制御防止方法
WO2020090976A1 (ja) * 2018-11-02 2020-05-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正制御防止システム、監視装置、および、不正制御防止方法
CN112823494A (zh) * 2018-11-02 2021-05-18 松下电器（美国）知识产权公司 防止不正常控制系统、监视装置以及防止不正常控制方法
JPWO2020090976A1 (ja) * 2018-11-02 2021-09-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 不正制御防止システム、監視装置、および、不正制御防止方法
CN112823494B (zh) * 2018-11-02 2022-04-29 松下电器（美国）知识产权公司 防止不正常控制系统、监视装置以及防止不正常控制方法
JP7340537B2 (ja) 2018-11-02 2023-09-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正制御防止システム、監視装置、および、不正制御防止方法

Also Published As

Publication number Publication date
CN113300947A (zh) 2021-08-24
EP3734911B1 (en) 2022-02-09
EP3734911A1 (en) 2020-11-04
JP6983977B2 (ja) 2021-12-17
CN113300927A (zh) 2021-08-24
JP2021016186A (ja) 2021-02-12
CN113300927B (zh) 2024-03-22
CN113300947B (zh) 2022-10-28

Similar Documents

Publication Publication Date Title
JP6787697B2 (ja) ゲートウェイ装置、車載ネットワークシステム及び転送方法
JP6873198B2 (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP6928051B2 (ja) ゲートウェイ装置、車載ネットワークシステム及び通信方法
WO2016075869A1 (ja) 鍵管理方法、車載ネットワークシステム及び鍵管理装置
JP6396464B2 (ja) 車載ネットワークシステム、電子制御ユニット、受信方法及び送信方法
US8467324B2 (en) Managing devices within a vehicular communication network
JP6983977B2 (ja) ゲートウェイ装置、車載ネットワークシステム及び転送方法
WO2018173603A1 (ja) 更新処理方法、車載ネットワークシステムおよび電子制御ユニット
JP2022190041A (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP2018160888A (ja) 更新処理方法、車載ネットワークシステムおよび電子制御ユニット
WO2018179630A1 (ja) 情報処理装置、情報処理方法及びプログラム
CN116488953A (zh) Can通信方法、电子设备及can通信系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16841029

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE