WO2017046981A1 - ゲートウェイ装置、ファームウェア更新方法及び制御プログラム - Google Patents

ゲートウェイ装置、ファームウェア更新方法及び制御プログラム Download PDF

Info

Publication number
WO2017046981A1
WO2017046981A1 PCT/JP2016/003082 JP2016003082W WO2017046981A1 WO 2017046981 A1 WO2017046981 A1 WO 2017046981A1 JP 2016003082 W JP2016003082 W JP 2016003082W WO 2017046981 A1 WO2017046981 A1 WO 2017046981A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
firmware
ecu
unit
electronic control
Prior art date
Application number
PCT/JP2016/003082
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
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP23182025.9A priority Critical patent/EP4239469A3/en
Priority to CN201680021023.8A priority patent/CN107533491B/zh
Priority to CN202110284790.0A priority patent/CN112953820B/zh
Priority to EP16845861.0A priority patent/EP3352080B1/en
Publication of WO2017046981A1 publication Critical patent/WO2017046981A1/ja
Priority to US15/878,787 priority patent/US10735260B2/en
Priority to US16/915,187 priority patent/US11223525B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • 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/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • 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/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • 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

Definitions

  • This disclosure relates to a technology for updating (updating) firmware of an electronic control unit that communicates via an in-vehicle network.
  • ECUs electronice control units
  • in-vehicle network A network connecting these ECUs.
  • ISO11898-1 A network connecting these ECUs.
  • CAN Controller Area Network
  • 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.
  • the transmission node transmits an ID called a message ID for each frame (that is, sends a signal to the bus), and each reception node is determined in advance. Only the message ID received (that is, the signal is read from the bus).
  • a gateway device is a gateway device in which a plurality of electronic control units mounted on a vehicle are connected to a bus used for communication, and the plurality of electronic control units are connected from an external device outside the vehicle.
  • a receiving unit that receives firmware update information including update firmware for one electronic control unit, an acquisition unit that acquires system configuration information indicating the type of each of the plurality of electronic control units connected to the bus,
  • An update processing unit that performs control for updating the firmware of the corresponding electronic control unit based on the update firmware after operation verification of the update firmware is performed using each type of electronic control unit indicated by the system configuration information Is a gateway device.
  • 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
  • 2 is a configuration diagram of a gateway according to Embodiment 1.
  • FIG. It is a figure which shows an example of a reception ID list.
  • 1 is a configuration diagram of an ECU according to Embodiment 1.
  • FIG. 2 is a configuration diagram of a server according to Embodiment 1.
  • FIG. 6 is a diagram illustrating an example of a format of firmware (FW) update information according to Embodiment 1.
  • FIG. FIG. 13 is a sequence diagram illustrating an operation example related to firmware update in the first embodiment (continuing from FIG. 12);
  • FIG. 12 is a sequence diagram illustrating an operation example according to firmware update in the first embodiment (continuing from FIG. 11).
  • 7 is a flowchart illustrating an example of FW update control processing by a gateway according to the first embodiment.
  • 4 is a flowchart illustrating an example of FW update control processing by the ECU according to Embodiment 1; 6 is a configuration diagram of a gateway according to Embodiment 2.
  • FIG. 10 is a flowchart illustrating FW registration processing related to registration of update firmware by a server according to the second embodiment.
  • 6 is a flowchart illustrating an example of FW operation verification processing by a server according to Embodiment 2.
  • FIG. 14 is a flowchart illustrating an example of FW operation verification processing related to verification of a plurality of firmware by a server according to the second embodiment.
  • FIG. 26 is a sequence diagram illustrating an operation example according to firmware update in the second embodiment (continuing from FIG. 25);
  • FIG. 25 is a sequence diagram illustrating an operation example according to firmware update in the second embodiment (continuing from FIG. 24).
  • 10 is a diagram illustrating an example of a software configuration of a virtual environment by a simulator used for FW operation verification processing in Embodiment 2.
  • FIG. 26 is a sequence diagram illustrating an operation example according to firmware update in the second embodiment (continuing from FIG. 25);
  • FIG. 25 is a sequence diagram illustrating an operation example according to firmware update in the second embodiment (continuing from FIG. 24).
  • 10 is a diagram illustrating an example of a software configuration of a virtual environment by a simulator used for FW operation verification processing in Embodiment 2.
  • FIG. 26 is a sequence diagram illustrating an operation example
  • the present inventor examined the following improvement measures in order to solve the above-mentioned problems.
  • a gateway device is a gateway device in which a plurality of electronic control units mounted on a vehicle are connected to a bus used for communication, and the plurality of electronic control units are connected from an external device outside the vehicle.
  • a receiving unit that receives firmware update information including update firmware for one electronic control unit, an acquisition unit that acquires system configuration information indicating the type of each of the plurality of electronic control units connected to the bus,
  • An update processing unit that performs control for updating the firmware of the corresponding electronic control unit based on the update firmware after operation verification of the update firmware is performed using each type of electronic control unit indicated by the system configuration information Is a gateway device.
  • the update control is performed after the operation verification of the update firmware corresponding to a plurality of electronic control units is ensured at the time of the firmware update, so the firmware update compared to the case where the operation verification is not performed.
  • the possibility that the vehicle will not function properly later is reduced.
  • the firmware update information includes verified configuration information indicating each type of a plurality of electronic control units used for operation verification of the update firmware, and the update processing unit is indicated by the system configuration information, Comparing the types of each of the plurality of electronic control units mounted on the vehicle with the types of each of the plurality of electronic control units used for the operation verification indicated by the verified configuration information received by the receiving unit; The control may be performed so that the update based on the update firmware is performed when a comparison result satisfies a certain condition. As a result, it is possible to confirm whether or not effective operation verification has been executed in accordance with the configuration of the in-vehicle network (organization of the electronic control unit group) in the vehicle on which the gateway device is mounted. Can be possible.
  • the type of each of the plurality of electronic control units connected to the bus indicated by the system configuration information identifies the version of firmware installed in the electronic control unit, and is indicated by the verified configuration information
  • the type of each of the plurality of electronic control units used for the operation verification of the update firmware may identify the version of the firmware installed in the electronic control unit.
  • the update processing unit confirms that the same type as all types indicated by the system configuration information is indicated in the verified configuration information received by the reception unit, the comparison result is the The control may be performed on the assumption that a certain condition is satisfied.
  • updating the firmware it may be possible to ensure the operation verification of the update firmware using the same type of electronic control unit as each electronic control unit connected to the in-vehicle network in the vehicle equipped with the gateway device. .
  • the gateway device further includes a transmission unit that transmits the system configuration information to the external device, and the update processing unit is configured to transmit the system configuration information to the external device after the transmission unit transmits the system configuration information to the external device.
  • the firmware update information transmitted after the operation verification of the update firmware using a plurality of electronic control units with reference to the system configuration information is received by the receiving unit, the firmware update information The control may be performed so that the update based on the update firmware is performed.
  • the firmware update is performed after the external device performs the operation verification of the update firmware using the same type of electronic control unit as each electronic control unit connected to the in-vehicle network in the vehicle in which the gateway device is mounted. Therefore, the possibility that the vehicle will not function normally after updating the firmware is reduced.
  • the system configuration information includes identification information about the electronic control unit and firmware mounted on the electronic control unit for specifying the type of each of the plurality of electronic control units connected to the bus. It is good also as including identification information of the version. This makes it possible for the external device to perform operation verification in an operating environment in which firmware of the same version as the firmware of each electronic control unit connected to the in-vehicle network is installed. The possibility of not functioning is reduced.
  • the gateway device includes a transmission unit having a function of transmitting the system configuration information to the external device, and the firmware update information is stored in each of a plurality of electronic control units used for operation verification of the update firmware. Including the verified configuration information indicating the type, and the update processing unit has confirmed that the same type as all types indicated by the system configuration information is not indicated in the verified configuration information received by the receiving unit In this case, the updating based on the updating firmware may be suppressed and the transmission unit may be controlled to transmit the system configuration information to the external device.
  • the operation verification of the update firmware corresponding to the configuration of the in-vehicle network in the vehicle on which the gateway device is mounted is not performed, useful information is transmitted to perform the appropriate operation verification. Therefore, there is a high possibility that execution of appropriate operation verification of the update firmware is ensured.
  • the gateway device further includes a simulation unit that simulates a plurality of electronic control units, and the firmware update information is a verification that indicates a type of each of the plurality of electronic control units used for operation verification of the update firmware.
  • the update processing unit confirms that the same type as all types indicated by the system configuration information is not indicated in the verified configuration information received by the receiving unit
  • the simulation unit performs a simulation of the operation of the update firmware using each electronic control unit of the same type as all types indicated by the system configuration information, and after the operation verification by the simulation is performed, the update firmware To perform the control to make the update based on It may be.
  • the firmware is updated after the operation of the firmware for update is verified by simulation.
  • the possibility of not functioning is reduced. For example, in the state after replacing or adding the electronic control unit mounted on the vehicle to the firmware transmitted after the operation verification corresponding to the configuration of the standard electronic control unit is performed, the operation is performed. Since the verification is not appropriate, it is useful to perform a new appropriate operation verification.
  • the gateway device further includes a simulation unit that simulates a plurality of electronic control units, and the update processing unit uses the electronic control units of the same type as all types indicated by the system configuration information. It is also possible to cause the simulation unit to perform a simulation of the operation of the firmware, and to perform the control so that the update based on the update firmware is performed after the operation verification by the simulation is performed. As a result, the firmware is updated after the operation of the updating firmware is verified by simulation, so that the possibility that the vehicle will not function normally after the firmware is updated is reduced.
  • the plurality of electronic control units connected to the bus communicate via the bus according to a Controller Area Network (CAN) protocol, and the update processing unit is a corresponding electronic control unit based on the update firmware.
  • the update firmware may be transmitted to the corresponding electronic control unit via the bus.
  • the update firmware is transmitted to the electronic control unit in the in-vehicle network according to CAN to update the firmware, so that the vehicle does not function normally after the firmware update. The possibility is reduced.
  • a firmware update method is a firmware update method for updating firmware of an electronic control unit, and a plurality of electronic control units mounted on a vehicle are connected to a bus used for communication.
  • a firmware updating method comprising the update processing step of performing a control for updating the firmware of the electronic control unit of the relevant.
  • the update control is performed after the operation verification of the update firmware corresponding to a plurality of electronic control units is ensured at the time of the firmware update, so the firmware update compared to the case where the operation verification is not performed.
  • the possibility that the vehicle will not function properly later is reduced.
  • the firmware update method further includes an operation verification step in which the external device performs operation verification of the update firmware using a plurality of electronic control units, and the external device is used for operation verification in the operation verification step.
  • the firmware update method may further include an operation verification request transmission step in which the gateway device transmits the system configuration information acquired in the acquisition step to the external device, and the external device in the operation verification request transmission step.
  • An operation verification step of receiving the transmitted system configuration information and verifying the operation of the update firmware using a plurality of electronic control units of the same type as all types indicated by the system configuration information; and And a firmware update information transmission step for transmitting the firmware update information after the operation verification is performed in the operation verification step, wherein the update processing step includes the system configuration information in the operation verification request transmission step.
  • the firmware update information is received in the reception step after transmission.
  • the control may be performed so as to perform the update based on the update firmware when it is trust.
  • the firmware is updated after the operation verification of the update firmware using the same type of electronic control unit as each electronic control unit connected to the in-vehicle network in the vehicle on which the gateway device is mounted is performed by the external device. Therefore, the possibility that the vehicle will not function normally after updating the firmware is reduced.
  • a control program is a control program for causing a gateway device including a processor, which is connected to a bus used for communication by a plurality of electronic control units mounted on a vehicle, to execute firmware update processing.
  • the firmware update processing includes receiving a firmware update information including update firmware for one electronic control unit among the plurality of electronic control units from an external device outside the vehicle; and connecting to the bus An acquisition step of acquiring system configuration information indicating each type of the plurality of electronic control units; and after the operation of the update firmware is verified using each type of electronic control unit indicated by the system configuration information Applicable electronic control unit based on firmware for update
  • a control program including an update processing step of performing the control for updating the firmware.
  • This control program is installed and executed in an in-vehicle device having a processor (for example, a gateway device), so that it is possible to perform operation verification of the update firmware corresponding to a plurality of electronic control units when updating the firmware. Update control will be performed later. For this reason, the possibility that the vehicle does not function normally after updating the firmware is reduced.
  • a processor for example, a gateway device
  • firmware (FW: Firmware) installed in each ECU mounted on the vehicle is updated with new update firmware distributed from a server located outside the vehicle (that is, replaced with update firmware). ).
  • firmware is updated after the operation verification of the update firmware using a plurality of ECUs corresponding to the vehicle is performed. The method of doing is used.
  • FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system 10 according to the first embodiment.
  • the in-vehicle network system 10 is an example of a network communication system that performs communication according to the CAN protocol, and is a network communication system in a vehicle on which various devices such as a control device, a sensor, an actuator, and a user interface device are mounted.
  • the in-vehicle network system 10 includes a plurality of devices that perform communication related to a frame via a bus, and uses a firmware update method.
  • the in-vehicle network system 10 includes ECUs 100a to 100d, buses 200a and 200b, a gateway 300 mounted on a vehicle and connected to various devices, a network 400 outside the vehicle, and a server 500. Consists of.
  • the in-vehicle network system 10 may include a number of ECUs in addition to the gateway 300 and the ECUs 100a to 100d, but here, the description will be given focusing on the gateway 300 and the ECUs 100a to 100d for convenience.
  • 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 ROM, RAM, or the like, and can store a control program (computer program as software) executed by the processor.
  • the firmware is all or part of the control program, and is stored in a nonvolatile memory (referred to as an activation ROM) such as EEPROM (Electrically Erasable Programmable Read Only Memory).
  • an activation ROM such as EEPROM (Electrically Erasable Programmable Read Only Memory).
  • EEPROM Electrical Erasable Programmable Read Only Memory
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the processor in order to achieve a predetermined function.
  • the firmware may include all or part of microcode for interpreting instructions in the processor.
  • the ECUs 100a to 100d are connected to devices such as the engine 101, the brake 102, the door opening / closing sensor 103, and the window opening / closing sensor 104, respectively.
  • the ECUs 100a to 100d acquire the state of the devices and periodically represent the frame (data frame). ) Is transmitted to the in-vehicle network including the bus 200a and the bus 200b.
  • the gateway 300 is a kind of ECU as a gateway device connected to the bus 200a to which the ECU 100a and the ECU 100b are connected and the bus 200b to which the ECU 100c and the ECU 100d are connected.
  • the gateway 300 has a function of transferring a frame received from one bus to the other bus, and also has a function of communicating with the server 500 via the network 400.
  • the server 500 as an external device located outside the vehicle is a computer having a function of distributing FW update information, which is data for updating the firmware of the ECUs 100a to 100d, via the network 400.
  • distributing FW update information which is data for updating the firmware of the ECUs 100a to 100d, via the network 400.
  • any communication protocol of wireless communication or wired communication may be applied.
  • Each ECU in the in-vehicle network system 10 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.
  • FIG. 2 is a diagram showing a data frame format defined by the CAN protocol.
  • a data frame in a standard ID format defined by the CAN protocol is shown.
  • the data frame includes an 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.
  • 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 (message ID) that is a value indicating the type of data, which is composed of 11 bits.
  • ID message ID
  • a frame having a small ID is designed to have a high priority in order to perform communication arbitration in this ID field.
  • 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 the data to be sent is not defined by the CAN protocol, but is defined in the in-vehicle network system 10. 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.
  • FIG. 3 is a configuration diagram of the gateway 300.
  • the gateway 300 performs functions such as frame transfer between buses and communication with an external server 500 (such as reception of FW update information for updating firmware such as the ECUs 100a to 100d). Therefore, as shown in FIG. 3, the gateway 300 includes a frame transmission / reception unit 310, a frame interpretation unit 320, a reception ID determination unit 330, a reception ID list holding unit 340, a frame processing unit 350, and a transfer rule holding unit. 360, FW update processing unit 370, ECU information holding unit 372, signature verification unit 373, key holding unit 374, external communication unit 375, frame generation unit 380, and ECU information acquisition unit 390. Composed. Each of these components is realized by a communication circuit in the gateway 300, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 310 transmits / receives a frame according to the CAN protocol to / from each of the bus 200a and the bus 200b.
  • a frame is received from the bus 200 a or the bus 200 b and transferred to the frame interpreter 320. Further, the frame transmission / reception unit 310 transmits the contents of the frame to the bus 200a or the bus 200b based on the bus information indicating the transfer destination bus received from the frame generation unit 380 and the frame.
  • the frame interpretation unit 320 receives the frame value from the frame transmission / reception unit 310, and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the frame interpretation unit 320 transfers the value determined as the ID field to the reception ID determination unit 330.
  • the frame interpretation unit 320 transfers the value of the ID field and the data field (data) appearing after the ID field to the frame processing unit 350 according to the determination result notified from the reception ID determination unit 330, or Decide whether to stop receiving. If the frame interpretation unit 320 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 320 notifies the frame generation unit 380 to transmit an error frame. In addition, when an error frame is received, the frame interpreter 320 discards the received frame thereafter, that is, stops the interpretation of the frame.
  • the reception ID determination unit 330 receives the value of the ID field notified from the frame interpretation unit 320, 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 340. Judge whether to do. The reception ID determination unit 330 notifies the frame interpretation unit 320 of this determination result.
  • the reception ID list holding unit 340 holds a reception ID list that is a list of IDs (message IDs) received by the gateway 300.
  • FIG. 4 is a diagram illustrating an example of the reception ID list.
  • the frame processing unit 350 determines the bus to be transferred according to the received frame ID according to the transfer rule held by the transfer rule holding unit 360, and is notified by the frame interpreter 320 of the bus information of the bus to be transferred.
  • the message generation unit 380 is notified of the message ID and the data.
  • the frame processing unit 350 notifies the FW update processing unit 370 of update result data related to the firmware update notified from the frame interpretation unit 320 and notifies the ECU information acquisition unit 390 of data related to ECU information. . It should be noted that the frame processing unit 350 does not transfer update result data related to firmware update and data related to ECU information.
  • the transfer rule holding unit 360 holds a transfer rule that is information indicating a rule for frame transfer for each bus.
  • FIG. 5 is a diagram illustrating an example of a transfer rule.
  • the FW update processing unit 370 requests the signature verification unit 373 to verify the signature of the FW update information including the FW data such as update firmware notified from the external communication unit 375. If the signature verification is successful, the FW update processing unit 370 The frame generation unit 380 is notified of the FW data relating to the firmware and the bus information of the bus to which the ECU to be updated is connected. Further, the FW update processing unit 370 notifies the external communication unit 375 of the update result notified from the frame processing unit 350.
  • the FW update processing unit 370 sends system configuration information, which is a set of ECU information held in the ECU information holding unit 372, to the external communication unit 375 as an FW update request based on a notification from the ECU information acquisition unit 390 and the like. Notice.
  • the frame generation unit 380 is notified of data necessary for communication with the ECUs 100a to 100d.
  • the FW update processing unit 370 receives the FW update information including the FW data such as the update firmware after verifying the operation of the update firmware using each type of ECU indicated by the system configuration information, and verifies the signature. When it succeeds, it functions as an update processor that performs control for updating the firmware of the corresponding ECU (for example, transmission of FW data to the ECU via the bus, etc.).
  • the ECU information holding unit 372 holds system configuration information that is a set of ECU information that is information related to all the ECUs (ECUs 100a to 100d) connected to the bus 200a and the bus 200b.
  • An example of the system configuration information is shown in FIG.
  • the signature verification unit 373 receives from the FW update processing unit 370 data to be subjected to signature verification related to the FW update information, performs signature verification using the signature verification key acquired from the key holding unit 374, and verifies the verification. The result is notified to the FW update processing unit 370.
  • the key holding unit 374 holds a key for signature verification of FW update information received from the server 500.
  • the external communication unit 375 has a function as a reception unit that receives FW update information including FW data related to firmware for update from the server 500, and notifies the FW update processing unit 370 of the received FW update information. Further, the external communication unit 375 transmits the update result notified from the FW update processing unit 370 to the server 500. In addition, the external communication unit 375 has a function as a transmission unit that transmits the system configuration information notified from the FW update processing unit 370 to the server 500 that is an external device as an FW update request. The external communication unit 375 holds, for example, address information of the server 500 necessary for accessing the server 500 via the network 400 in advance.
  • the frame generation unit 380 notifies the frame transmission / reception unit 310 to transmit the error frame in accordance with the error frame transmission request notified from the frame interpretation unit 320. Further, the frame generation unit 380 forms a frame using the message ID and data notified from the frame processing unit 350 and notifies the frame transmission / reception unit 310 together with the bus information. The frame generation unit 380 forms a frame using the FW data related to the firmware for update notified from the FW update processing unit 370 and notifies the frame transmission / reception unit 310 together with the bus information. The frame generation unit 380 configures an ECU information acquisition frame in accordance with the request notified from the ECU information acquisition unit 390, and notifies the frame transmission / reception unit 310 of the configured frame for transmission.
  • the ECU information acquisition unit 390 In order to acquire ECU information from all ECUs connected to the bus 200a and the bus 200b, the ECU information acquisition unit 390, for example, periodically generates a frame (data frame) for acquiring ECU information in the frame generation unit 380. Request to send. When each ECU receives the ECU information acquisition frame, each ECU transmits the ECU information in a predetermined ID frame (data frame) so as to reach the gateway 300. For this reason, the ECU information acquisition unit 390 is notified by the frame processing unit 350 of data related to the ECU information of each ECU, and based on this ECU information, the ECU of the system configuration information held by the ECU information holding unit 372 Update information as needed. That is, the ECU information acquisition unit 390 has a function as an acquisition unit that acquires system configuration information indicating each type of the plurality of ECUs connected to the buses 200a and 200b.
  • FIG. 4 is a diagram illustrating an example of the reception ID list held in the reception ID list holding unit 340 of the gateway 300.
  • the reception ID list illustrated in FIG. 4 selectively receives a frame including a message ID whose ID (message ID) value is “1”, “2”, “3”, or “4”. Used for processing. This is merely an example, but the message IDs of frames determined to be received by the gateway 300 are listed in the reception ID list.
  • FIG. 5 shows an example of transfer rules held by the transfer rule holding unit 360 of the gateway 300.
  • This transfer rule associates a transfer source bus, a transfer destination bus, and a transfer target ID (message ID).
  • “*” In FIG. 5 indicates that the frame is transferred regardless of the message ID.
  • the example of FIG. 5 indicates that the frame received from the bus 200a is set to be transferred to the bus 200b regardless of the message ID. Further, it is shown that only the frame having the message ID “3” among the frames received from the bus 200b is set to be transferred to the bus 200a.
  • FIG. 6 shows an example of system configuration information (a set of ECU information) held by the ECU information holding unit 372 of the gateway 300.
  • the system configuration information in this example is a list of ECU information for each ECU.
  • the ECU information includes an ECU-ID, an ECU type indicating the function type of the ECU, an ECU manufacturer, and an FW version such as a version number of firmware installed in the ECU.
  • the ECU-ID is an identifier (identification information) such as a serial number unique to each ECU, for example.
  • the ECU type can be identified by the ECU-ID and the FW version.
  • the plurality of ECUs of the same type are, for example, a plurality of ECUs having the same function related to the operation of exchanging data via a bus, and the plurality of ECUs of different types are a plurality of ECUs having different functions related to the operation. .
  • the ECU-ID for the ECU 100 a connected to the engine 101 is “0001”, the ECU type is “engine”, and the manufacturer is “A company”. This indicates that the FW version of the ECU-ID is 1.0.
  • the initial value of the system configuration information may be set at the time of manufacture, or may be acquired by the gateway 300 from an external device such as the server 500 when power supply to the gateway 300 is started, for example. May be.
  • An ECU information acquisition unit when the state changes due to replacement of the ECUs connected to the buses 200a and 200b, firmware update, or when the ECU is newly introduced into the vehicle and connected to the buses 200a or 200b.
  • the system configuration information can be sequentially updated to indicate the latest state of each ECU in the vehicle.
  • FIG. 7 is a configuration diagram of the ECU 100a.
  • the ECU 100a includes a frame transmission / reception unit 110, a frame interpretation unit 120, a reception ID determination unit 130, a reception ID list holding unit 140, a frame processing unit 150, an FW update processing unit 160, an FW cache holding unit 161,
  • the signature verification unit 163, the key holding unit 164, the data acquisition unit 170, and the frame generation unit 180 are configured.
  • Each of these components is realized by a communication circuit in the ECU 100a, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 110 transmits / receives a frame according to the CAN protocol to / from the bus 200a.
  • a frame is received from the bus bit by bit and transferred to the frame interpreter 120. Further, the content of the frame received from the frame generation unit 180 is transmitted to the bus 200a.
  • the frame interpretation unit 120 receives a frame value from the frame transmission / reception unit 110, 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 transferred to the reception ID determination unit 130.
  • the frame interpretation unit 120 transfers the value of the ID field and the data field appearing after the ID field to the frame processing unit 150 according to the determination result notified from the reception ID determination unit 130, or determines the determination result. Determine whether to stop receiving frames after receiving them. If the frame interpretation unit 120 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 120 notifies the frame generation unit 180 to transmit an error frame. Further, when an error frame is received, the frame interpretation unit 120 discards the frame thereafter, that is, stops the interpretation of the frame.
  • the reception ID determination unit 130 receives the value of the ID field notified from the frame interpretation unit 120, 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 140. Judge whether to do. The reception ID determination unit 130 notifies the frame interpretation unit 120 of the determination result.
  • the reception ID list holding unit 140 holds a reception ID list that is a list of message IDs received by the ECU 100a. This reception ID list is the same as that in the example of FIG.
  • the frame processing unit 150 performs different processing for each ECU according to the received frame data.
  • the ECU 100a connected to the engine 101 has a function of sounding an alarm sound when the door is open with a speed exceeding 30 km / h.
  • the frame processing unit 150 of the ECU 100a manages data (for example, information indicating the state of the door) received from another ECU, and performs processing for sounding an alarm sound under a certain condition based on the speed obtained from the engine 101, etc. I do.
  • the ECU 100c has a function of sounding an alarm sound when the door is opened in a state where the brake is not applied.
  • the ECUs 100b and 100d do nothing in particular.
  • the ECUs 100a to 100d may have functions other than those described above.
  • the frame processing unit 150 notifies the FW update processing unit 160 when the firmware update FW data is acquired and when the data related to the ECU information acquisition frame is acquired.
  • the FW update processing unit 160 requests the signature verification unit 163 to verify the signature of the FW data received from the gateway 300 and notified from the frame processing unit 150. If the signature verification is successful, the FW update processing unit 160 determines the ECU 100a based on the FW data.
  • the firmware in the boot ROM is updated (rewritten).
  • the activation ROM is a non-volatile memory that is set as a storage destination of firmware that is executed after reset by the processor of the ECU 100a, for example.
  • the FW update processing unit 160 stores the existing firmware, for example, in the FW cache holding unit 161 so that the state before the update can be restored when the update fails.
  • the FW update processing unit 160 notifies the frame generation unit 180 to generate and transmit a frame indicating a firmware update result based on the FW data.
  • the firmware update result may include, for example, an FW version such as a firmware version number after the update.
  • the FW update processing unit 160 when notified from the frame processing unit 150 about the ECU information acquisition frame, the ECU configuration information including the ECU-ID of the ECU 100a and the FW version of the current firmware.
  • the frame generation unit 180 is notified to generate and transmit a frame.
  • the FW cache holding unit 161 is realized by a storage area such as a nonvolatile memory in the ECU 100a, for example, and is used for storing existing firmware when updating the firmware in the boot ROM.
  • the signature verification unit 163 receives the FW data to be subjected to signature verification from the FW update processing unit 160, performs signature verification using the signature verification key acquired from the key holding unit 164, and updates the verification result by FW The processing unit 160 is notified.
  • the key holding unit 164 holds a signature verification key for firmware update FW data.
  • the data acquisition unit 170 acquires data indicating the state of devices, sensors, and the like connected to the ECU, and notifies the frame generation unit 180 of the data.
  • the frame generation unit 180 configures an error frame according to the notification for instructing error frame transmission notified from the frame interpretation unit 120, and notifies the frame transmission / reception unit 110 to transmit the error frame.
  • the frame generation unit 180 forms a frame by attaching a predetermined message ID to the data value notified from the data acquisition unit 170 and notifies the frame transmission / reception unit 110 of the frame.
  • the frame generation unit 180 configures a frame with a predetermined message ID according to an instruction to generate a frame of the firmware update result by the FW update processing unit 160 or a frame of the ECU configuration information, Notify the frame transmission / reception unit 110.
  • the ECUs 100b to 100d have substantially the same configuration as the ECU 100a.
  • the server 500 is a computer located outside the vehicle on which the in-vehicle network system 10 is mounted, and includes a storage medium such as a memory and a hard disk, a processor, a communication circuit, and the like.
  • the server 500 may include an input device (such as a keyboard) as a user interface, a display, and the like.
  • the server 500 manages firmware provided from various ECU manufacturing companies, etc., performs firmware operation verification, and each vehicle Has a function of distributing FW update information including update firmware.
  • FIG. 8 is a configuration diagram of the server 500.
  • the server 500 includes a data transmission / reception unit 510, an FW update control unit 520, an FW operation verification unit 530, an ECU information holding unit 531, an all FW holding unit 532, and a distribution data generation unit 570.
  • Each of these components is realized by a communication circuit in the server 500, a processor that executes a control program stored in a memory, and the like.
  • the data transmission / reception unit 510 communicates with the gateway 300 to transmit / receive data.
  • the data transmission / reception unit 510 receives the system configuration information from the gateway 300 as a firmware update request (FW update request)
  • the data transmission / reception unit 510 notifies the FW update control unit 520 and the firmware to be updated in response to the FW update request.
  • FW update information is received from the FW update control unit 520 and transmitted to the gateway 300.
  • the data transmission / reception unit 510 receives a firmware update result from the gateway 300, the data transmission / reception unit 510 notifies the FW update control unit 520.
  • the FW update control unit 520 stores the firmware in the FW holding unit 571 and stores the firmware in the information from the terminal device. Based on this, the firmware, the FW version indicating the version number and the like, and the information indicating the type of the target ECU are managed in association with each other.
  • the FW update control unit 520 receives the system configuration information related to the FW update request from the gateway 300 via the data transmission / reception unit 510, the firmware to be updated corresponding to the gateway 300 based on the system configuration information If there is, the distribution data generation unit 570 generates FW update information as a firmware package for update.
  • the FW update control unit 520 can determine whether there is firmware to be updated based on, for example, information about the firmware held by the FW holding unit 571 and system configuration information. Based on the system configuration information, the FW update control unit 520 requests the FW operation verification unit 530 to perform operation verification on the firmware to be updated, and after the operation verification is performed (that is, it is verified that it operates properly without problems). FW update information is transmitted to the data transmitting / receiving unit 510. Note that if the verification fails in the operation verification for the update firmware (that is, if the operation is not performed properly), the server 500 does not transmit the FW update information including the update firmware to the gateway 300. When the firmware update result is received from the gateway 300, the FW update control unit 520 updates the vehicle ECU management information held by the ECU management information holding unit 572.
  • the FW operation verification unit 530 receives the request from the FW update control unit 520, and updates firmware for each ECU in the operation environment in the operation environment configured by the same type of ECU as the ECU indicated by the system configuration information. It has a function of executing FW operation verification processing for verifying that the firmware operates properly (normally).
  • FW operation verification process for example, an update operation in which firmware for update is applied to an ECU to be updated in the operation environment, an operation whether or not each ECU in the operation environment operates normally after the update, etc. Is verified.
  • the operation of the update firmware may be verified using hardware of various ECUs as the operation environment, or simulation in a virtual environment in which various ECUs are simulated (simulated execution) Thus, the operation verification of the update firmware may be performed.
  • an explanation will be given assuming an example in which operation verification of firmware for update is performed by simulation in a virtual environment in which various ECUs are simulated.
  • the ECU information holding unit 531 holds information (software) for simulating various ECUs, and the information includes the latest firmware used by the various ECUs.
  • the all FW holding unit 532 holds not only the latest firmware corresponding to various ECUs but also all firmware including past versions of firmware.
  • FW operation verification unit 530 determines the type of each ECU identified by the ECU-ID and the FW version of the system configuration information and the same type of ECU. An operating environment to be simulated is constructed, and it is verified whether the operation can be appropriately performed without any problem by performing a simulation on the update to which the update firmware is applied and the subsequent operation.
  • the distribution data generation unit 570 generates FW update information as an update firmware package for distribution to the gateway 300, and requests the signature generation unit 590 to generate a signature for the FW update information.
  • the format of the FW update information will be described later (see FIG. 10).
  • FW holding unit 571 holds uploaded firmware for ECU.
  • the ECU management information holding unit 572 holds vehicle ECU management information that is information related to each ECU in the in-vehicle network of each vehicle.
  • vehicle ECU management information will be described later (see FIG. 9).
  • the signature generation unit 590 Upon receiving a request from the distribution data generation unit 570, the signature generation unit 590 generates a signature for the FW update information using the signature key stored in the key storage unit 591 and notifies the distribution data generation unit 570 of the signature. To do.
  • the signature generation unit 590 can perform a signature for each FW data in the FW update information and a signature for the entire FW update information.
  • the key holding unit 591 holds a key used by the signature generation unit 590 to sign the FW update information.
  • FIG. 9 shows an example of vehicle ECU management information (a set of ECU information for each vehicle) held by the ECU management information holding unit 572 of the server 500.
  • the vehicle ECU management information in this example includes vehicle information for each vehicle to be managed by the server 500 and ECU information for each ECU mounted on the vehicle.
  • the vehicle information is an identifier (vehicle ID) for identifying the vehicle.
  • the ECU information associated with the vehicle information in the vehicle ECU management information includes the ECU-ID, the ECU type indicating the function type of the ECU, the manufacturer of the ECU, the version number of the firmware installed in the ECU, etc. And the latest FW version such as the latest firmware version number corresponding to the ECU.
  • Each ECU information about a certain vehicle in the vehicle ECU management information is uploaded to the server 500 from information received from the gateway 300 of the vehicle (system configuration information and firmware update result), and various ECU manufacturers, for example. It is set based on the FW version for the firmware.
  • FIG. 9 only information related to one vehicle A is illustrated, but the vehicle ECU management information may include information about other vehicles.
  • FIG. 10 shows an example of the format of FW update information as distribution data distributed by the server 500.
  • the FW update information includes a FW number F1 indicating the number of FW data, one or more FW data (two individual FW data F10 and F20 in the example of FIG. 10), and a signature for the entire FW update information (distributed data). And a certain FW update information signature F30.
  • the FW data F10 and F20 are respectively update firmware (FW) F13 and F23, ECU-IDF11 and F21 for identifying the target ECU, FW versions F12 and F22 indicating the version number of the firmware, and the like.
  • FW data signatures F14 and F24 which are signatures for data, are included.
  • the firmware F13 and F23 are firmware itself, that is, binary data.
  • FIG. 11 and FIG. 12 are sequence diagrams showing an operation example related to the firmware update of the ECU, which is performed in cooperation with devices such as the server 500, the gateway 300, and the ECUs 100a and 100b.
  • Each sequence here means each processing procedure (step) in each apparatus.
  • steps operations of some ECUs are illustrated.
  • the sequence shown in this operation example is assumed to be repeatedly executed, for example, at intervals of a certain number of days, but may be executed when it is detected that a new ECU has been added to the in-vehicle network. It may be executed in response to an operation of a driver or the like on any of the ECUs.
  • the gateway 300 in the vehicle transmits ECU information acquisition frames to the buses 200a and 200b, thereby requesting ECU information from all ECUs (ECUs 100a and 100b, etc.) connected via the in-vehicle network (step S1001). .
  • the ECU 100a that has received the ECU information acquisition frame transmits to the bus 200a a frame including ECU information that includes the ECU-ID of the ECU 100a and the FW version related to the installed firmware (step S100). S1002).
  • the gateway 300 receives ECU information about the ECU 100a by receiving a frame from the bus 200a.
  • the ECU 100b that has received the ECU information acquisition frame also transmits the frame including the ECU information about the ECU 100b to the bus 200a (step S1003).
  • the gateway 300 receives ECU information about the ECU 100b by receiving a frame from the bus 200a.
  • the gateway 300 can receive each ECU information transmitted from each other ECU.
  • Steps S1002 and S1003 are acquisition steps in which the gateway 300 acquires system configuration information (a set of ECU information) indicating the type of each ECU.
  • the gateway 300 changes.
  • the system configuration information held by the ECU information holding unit 372 is updated with the acquired ECU information (Step S1005).
  • the gateway 300 may perform control for notifying the driver of the vehicle and the like when the ECU information acquired from each ECU has changed with respect to the held system configuration information. good.
  • the gateway 300 transmits the system configuration information held by the ECU information holding unit 372 and representing the organization of all ECUs connected to the in-vehicle network as a set of ECU information to the server 500 as an FW update request (Ste S1006).
  • the server 500 receives system configuration information as an FW update request.
  • the server 500 In response to the FW update request, the server 500 includes the gateway 300 that is the transmission source of the FW update request, based on the received system configuration information, vehicle ECU management information held by the ECU management information holding unit 572, and the like. It is determined whether or not firmware update is required for one or more ECUs of the vehicle (step S1007). If the update is unnecessary, the server 500 notifies the gateway 300 that the update is unnecessary, for example. In FIG. 11, the description when the update is unnecessary is omitted.
  • the server 500 uses the FW update control unit 520 based on the received system configuration information, the vehicle ECU management information held by the ECU management information holding unit 572, and the like. Then, one or more firmware for update to be transmitted is determined (step S1008). This determination also determines the number of update firmware.
  • the server 500 uses the FW operation verification unit 530 to verify the operation of the update firmware determined in step S1008 in an environment configured by the same type of ECU as the ECU indicated by the received system configuration information (step S1008). S1009).
  • the update firmware the firmware held in the FW holding unit 571 is used.
  • the server 500 performs the update by applying the update firmware to the target ECU in the environment configured by the type of ECU indicated by the system configuration information.
  • the distribution data generation unit 570 generates FW update information (see FIG. 10).
  • the distribution data generation unit 570 obtains FW data such as firmware held by the FW holding unit 571 (step S1011) by the number of FWs that is the number of firmware for update (step S1010), and the FW data The addition of the FW data signature generated by the signature generation unit 590 (step S1012) is repeated. Further, the distribution data generation unit 570 causes the signature generation unit 590 to generate a signature (FW update information signature) for the FW update information (step S1013), and generates FW update information to which the signature is added.
  • FW update information signature a signature for the FW update information
  • Step S1014 the FW update control unit 520 causes the data transmission / reception unit 510 to transmit the FW update information.
  • the FW update information is transmitted from the server 500 to the gateway 300 that is the transmission source of the system configuration information as the FW update request, and the gateway 300 receives the FW update information.
  • Step S1014 is a reception step in which gateway 300 receives FW update information including update firmware for updating at least one ECU from server 500.
  • the signature verification unit 373 verifies the signature (FW update information signature) of the FW update information (step S1015). Then, the FW update processing unit 370 of the gateway 300 determines whether or not the signature verification is successful (step S1016). If the verification is not successful, the FW update information is discarded (step S1017). In this case, the firmware is not updated based on the FW update information.
  • the gateway 300 mainly performs the FW update control process in cooperation with the ECU corresponding to the update target by the FW update processing unit 370 (step S1018). The contents of the FW update control process will be described later. In step S1018 and the like, after the operation of the updating firmware is verified using each type of ECU indicated by the system configuration information, the gateway 300 performs control for updating the firmware of the corresponding ECU based on the updating firmware. This is an update process step.
  • the gateway 300 transmits the firmware update result to the server 500 after completing the FW update control process in step S1018 or after discarding the FW update information in step S1017 (step S1019).
  • the firmware update result is, for example, information indicating whether or not the update is successful, and the information may include, for example, the FW version related to the firmware after the update.
  • the server 500 receives the update result.
  • the server 500 updates the vehicle ECU management information held by the ECU management information holding unit 572 so as to indicate the state after the firmware update (step S1020).
  • FIG. 13 is a flowchart illustrating an example of the FW update control process by the gateway 300.
  • the gateway 300 uses the FW update processing unit 370 to acquire the number of FWs in the FW update information (see FIG. 10) (step S1201), and repeats the processes in steps S1203 to S1205 for the number of FWs (step S1202).
  • the FW update processing unit 370 acquires the ECU-ID in the FW data of the FW update information (step S1203).
  • FW update processing section 370 causes frame generation section 380 to generate a frame including FW data for transmission to the ECU identified by the ECU-ID, and frame transmission / reception section 310 receives the frame from ECU. It transmits to ECU via the connected bus (step S1204).
  • the ECU identified by the ECU-ID in the FW data receives the FW data, performs a process for updating the firmware, and transmits the update result to the gateway 300.
  • the gateway 300 receives the update result transmitted from the ECU (step S1205).
  • FIG. 14 is a flowchart illustrating an example of the FW update control process by the ECU 100a.
  • the frame transmitting / receiving unit 110 receives a frame including FW data (step S1301).
  • the FW update processing unit 160 of the ECU 100a acquires the FW data related to the frame received in step S1301 via the frame interpretation unit 120 and the frame processing unit 150, and verifies the FW data signature in the FW data to the signature verification unit 163. (Step S1302).
  • the FW update processing unit 160 determines whether or not the verification of the FW data signature is successful (step S1303). If the verification is not successful, the FW data is discarded (step S1304) and the firmware is not updated.
  • the FW update processing unit 160 stores the firmware, which is the content of the startup ROM in the ECU 100a, by copying it to the FW cache holding unit 161 (step S1305).
  • the FW update processing unit 160 updates the firmware in the startup ROM with the firmware (FW) in the FW data (step S1306), and restarts the processor of the ECU 100a by resetting (step S1307).
  • the ECU 100a when the activation from the activation ROM is not successful, the ECU 100a is set in advance so as to be activated according to the contents of the FW cache holding unit 161, and when the restart in step S1307 is not successful (step S1308).
  • the firmware before update stored in the FW cache holding unit 161 is activated (step S1309).
  • the firmware before update stored in the FW cache holding unit 161 is copied to the boot ROM to return the contents of the boot ROM to the state before the update (step S1310).
  • step S1307 If the restart in step S1307 is successful, the ECU 100a transmits a frame including an update result indicating that the firmware has been successfully updated to the gateway 300, and if the restart is not successful in step S1307. After step S1310, a frame including an update result indicating that the firmware update has failed is transmitted to gateway 300 (step S1311).
  • the gateway 300 collects ECU information indicating the types of ECUs and the like for all ECUs connected to the in-vehicle network (buses 200a and 200b) and holds the collected ECU configuration information as system configuration information. To do. Then, the gateway 300 notifies the server 500 of the system configuration information. As a result, the server 500 can determine whether or not firmware update is necessary for one or more ECUs in the in-vehicle network of the vehicle on which the gateway 300 is mounted, and can determine the firmware to be updated.
  • server 500 an operation related to the update of firmware to be updated in an environment organized by the same type of ECU (an environment by an actual ECU or an environment by an ECU simulation) corresponding to the organization of the ECU indicated by the system configuration information Verification (verification of whether firmware can be updated properly, verification of whether each ECU operates properly after the update, etc.) is performed. Since the server 500 transmits the FW update information including the firmware to be updated to the gateway 300 after completing the operation verification (after confirming the proper operation), the gateway 300 is configured by each ECU of the vehicle. It is possible to acquire firmware that has been verified in an environment corresponding to the environment that has been set. For this reason, the possibility that the vehicle will not function normally after updating the firmware in the vehicle is reduced.
  • the server performs operation verification in each ECU in the vehicle corresponding to each vehicle model.
  • a firmware update method that transmits later firmware is used.
  • verified configuration information verified ECU configuration information
  • the organization of ECUs types of ECUs, etc.
  • the in-vehicle network system 11 includes ECUs 100a to 100d, buses 200a and 200b, a gateway 300a, a network 400 outside the vehicle, and a server 500a that are mounted on a vehicle and connected to various devices.
  • This in-vehicle network system 11 is obtained by replacing the gateway 300 and the server 500 in the in-vehicle network system 10 (see FIG. 1) shown in the first embodiment with a gateway 300a and a server 500a.
  • the vehicle-mounted network system 11 is the same as that of the vehicle-mounted network system 10.
  • the gateway 300a is a kind of ECU as a gateway device connected to the bus 200a to which the ECU 100a and the ECU 100b are connected and the bus 200b to which the ECU 100c and the ECU 100d are connected.
  • the gateway 300a has a function of transferring a frame received from one bus to the other bus, and a function of communicating with the server 500a via the network 400.
  • FIG. 15 is a configuration diagram of the gateway 300a.
  • the gateway 300a is obtained by replacing the FW update processing unit 370 in the gateway 300 described in Embodiment 1 with the FW update processing unit 370a.
  • the gateway 300a includes a frame transmission / reception unit 310, a frame interpretation unit 320, a reception ID determination unit 330, a reception ID list holding unit 340, a frame processing unit 350, and a transfer rule holding unit 360.
  • An FW update processing unit 370a an ECU information holding unit 372, a signature verification unit 373, a key holding unit 374, an external communication unit 375, a frame generation unit 380, and an ECU information acquisition unit 390.
  • the Each of these components is realized by a communication circuit in the gateway 300a, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • a communication circuit in the gateway 300a a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the same components as those of the gateway 300 (see FIG. 3) described above are denoted by the same reference numerals in FIG. 15, and description thereof is omitted here.
  • the FW update processing unit 370a requests the signature verification unit 373 to verify the signature of the FW update information (see FIG. 16) including the FW data such as firmware for update notified from the external communication unit 375, and the signature verification is successful. Confirm that the firmware operation is properly verified. Confirmation that the operation verification is properly performed is included in the system configuration information, which is a set of ECU information of each ECU acquired by the ECU information acquisition unit 390 and stored in the ECU information holding unit 372, and the FW update information. This is done by comparing the verified ECU configuration information.
  • the ECU information acquisition unit 390 collects the ECU information of each ECU, and then the operation verification is appropriately performed. You may make it confirm.
  • the verified ECU configuration information is information indicating the type and the like of each ECU constituting the environment used for verifying the operation of the firmware included in the FW update information in the server 500a.
  • the type of ECU is specified by the FW version such as the ECU-ID and the version number of the firmware installed in the ECU.
  • the FW update processing unit 370a indicates the type of each ECU mounted on the vehicle indicated by the system configuration information and the ECU used for operation verification indicated by the verified ECU configuration information of the FW update information received from the server 500a. The type is compared, and when the comparison result satisfies a certain condition, control is performed to perform an update based on the update firmware included in the FW update information.
  • the certain condition is, for example, that all the ECU types indicated by the system configuration information and all the ECU types indicated by the verified ECU configuration information are completely matched.
  • the FW update processing unit 370a generates a frame of the FW data related to the update firmware and the bus information of the bus to which the ECU to be updated is connected as control for performing the update based on the update firmware.
  • the FW update processing unit 370a performs firmware update according to the order indicated by the update order information. Controls to update.
  • the FW update processing unit 370a notifies the external communication unit 375 of the update result notified from the frame processing unit 350. Further, the FW update processing unit 370a updates the firmware when the comparison result between the type of each ECU indicated by the system configuration information and the type of each ECU indicated by the verified ECU configuration information does not satisfy the above-described certain condition. And the system configuration information is notified to the external communication unit 375 as an operation verification request. For example, information specifying the firmware to be updated is added to the operation verification request.
  • the server 500a When the server 500a performs the operation verification according to the operation verification request, and the FW update processing unit 370a transmits the FW update information including the verified ECU configuration information that satisfies the above-described certain condition, the server 500a FW update information is acquired and firmware update is resumed.
  • the FW update processing unit 370a receives the FW update information including the FW data such as the update firmware after verifying the operation of the update firmware using each type of ECU indicated by the system configuration information, and verifies the signature. When it succeeds, it functions as an update processor that performs control for updating the firmware of the corresponding ECU (for example, transmission of FW data to the ECU via the bus, etc.). In addition, the FW update processing unit 370a notifies the frame generation unit 380 of data necessary for communication with the ECUs 100a to 100d.
  • the external communication unit 375 receives FW update information including FW data related to the firmware for update from the server 500a, notifies the FW update processing unit 370a, and displays the update result notified from the FW update processing unit 370a as the server 500a. Send to. Further, the external communication unit 375 transmits the system configuration information notified from the FW update processing unit 370a to the server 500a as an operation verification request.
  • the external communication unit 375 previously holds, for example, address information of the server 500a necessary for accessing the server 500a via the network 400. Note that the external communication unit 375 may transmit a firmware update request to the server 500a.
  • FIG. 16 shows an example of a format of FW update information as distribution data distributed by the server 500a.
  • the FW update information distributed by the server 500a is obtained by adding verified ECU configuration information F40 to the FW update information distributed by the server 500 shown in the first embodiment (see FIG. 10).
  • the FW update information distributed by the server 500a includes the FW number F1, one or more FW data (two individual FW data F10 and F20 in the example of FIG. 16), verified ECU configuration information F40, and FW update.
  • FW update information signature F30 which is a signature for the entire information.
  • FIG. 17 shows an example of the format of verified ECU configuration information F40.
  • the verified ECU configuration information F40 is information about the ECU used for the firmware operation verification in the server 500a.
  • the verified ECU configuration information F40 includes vehicle type information for identifying a vehicle model, update order information indicating the update order of firmware used for operation verification (update order in which firmware can be updated without any problem), operation It includes an ECU-ID for each ECU used for verification, and an FW version such as a version number of firmware installed in the ECU.
  • the server 500a is a computer having a function of distributing FW update information (see FIG. 16) that is data for updating the firmware of the ECUs 100a to 100d via the network 400.
  • the server 500a manages firmware provided from various ECU manufacturing companies, etc., and verifies the operation of the firmware. And has a function of distributing FW update information including update firmware to each vehicle.
  • FIG. 18 is a configuration diagram of the server 500a.
  • the server 500a includes a data transmission / reception unit 510a, an FW update control unit 520a, an FW operation verification unit 530a, an ECU information holding unit 531, an all FW holding unit 532, and a distribution data generation unit 570a.
  • Each of these components is realized by a communication circuit in the server 500a, a processor that executes a control program stored in a memory, and the like.
  • the same components as those of the server 500 (see FIG. 8) described above are denoted by the same reference numerals in FIG. 18, and description thereof is omitted here.
  • the data transmission / reception unit 510a communicates with the gateway 300a to transmit / receive data.
  • the data transmission / reception unit 510a notifies the FW update control unit 520a, and the FW update control unit 520a notifies the firmware distribution. Therefore, when the FW update information is received, the FW update information is transmitted to the gateway 300a.
  • the data transmission / reception unit 510a receives the firmware update result from the gateway 300a, the data transmission / reception unit 510a notifies the FW update control unit 520a.
  • the gateway 300a makes a firmware update request
  • the data transmission / reception unit 510a notifies the FW update control unit 520a when a firmware update request is received from the gateway 300a.
  • the FW update control unit 520a receives a firmware registration request from the terminal device, such as an ECU manufacturer, when the latest ECU firmware (that is, for update) is uploaded to the server 500a and a firmware registration request is made. In cooperation with the above, the registration process is performed after the firmware operation is verified. For operation verification, first, the FW update control unit 520a specifies an ECU on which the uploaded update firmware operates based on information from the terminal device, and further mounts (uses) the specified ECU. Identify the vehicle model of the vehicle. In order to identify a vehicle model using an ECU that requires firmware update, the FW update control unit 520a holds an ECU vehicle model management table as exemplified in FIG. 19, for example.
  • the ECU vehicle model management table is a table in which an ECU-ID or the like is associated with a vehicle model.
  • the vehicle model is identification information such as the structure of the vehicle, and may be a model, for example.
  • the FW update control unit 520a uses, for example, a vehicle model ECU management table as illustrated in FIG. 20 to identify all ECUs used by a vehicle model equipped with an ECU that requires firmware update. Generate an enumerated list.
  • the vehicle model ECU management table is a table in which identification information (ECU-ID, etc.) about all ECUs mounted on vehicles of the vehicle model is associated with each vehicle model.
  • the FW update control unit 520a notifies the FW operation verification unit 530a of the generated list, and causes the firmware update operation verification to be performed using an environment including all ECUs listed in the list. After the operation verification is completed and it is confirmed that there is no problem, the FW update control unit 520a stores the uploaded firmware in the FW holding unit 571, and based on the information from the terminal device, the firmware and its version number And the like, and the information indicating the type of the target ECU are managed in association with each other. Further, the FW update control unit 520a becomes distribution data to a plurality of vehicles (specifically, gateways 300a of the respective vehicles) in the distribution data generation unit 570a after the operation verification by the FW operation verification unit 530a is completed.
  • a plurality of vehicles specifically, gateways 300a of the respective vehicles
  • FW update information is generated as a firmware package for update including the firmware whose operation has been verified.
  • the FW update control unit 520a causes the data transmission / reception unit 510a to transmit the FW update information generated by the distribution data generation unit 570a to the gateway 300a.
  • the FW update control unit 520a receives the firmware update request from the gateway 300a via the data transmission / reception unit 510a, and the FW update control unit 520a verifies that the FW operation verification unit 530a operates without any problem.
  • the distribution data generation unit 570a generates FW update information including update firmware corresponding to 300a, and transmits it to the gateway 300a.
  • the FW update control unit 520a performs an operation verification on the firmware for update to the FW operation verification unit 530.
  • the FW update information is transmitted to the data transmission / reception unit 510a after the request is made and the operation is verified (that is, after the operation is properly verified without any problem).
  • the FW update information transmitted from the server 500a to the gateway 300a always includes verified ECU configuration information indicating information on the ECU used for operation verification by the FW operation verification unit 530a as shown in FIG.
  • the FW update control unit 520a updates the vehicle ECU management information held by the ECU management information holding unit 572.
  • the FW operation verification unit 530a includes an ECU of the same type as each ECU indicated by the system configuration information in an operating environment configured by an ECU indicated by a list of ECUs It has a function of executing the FW operation verification process for verifying that the firmware for update and the firmware of each ECU in the operation environment operate properly (normally) in the operated environment.
  • the FW operation verification process for example, an update operation in which firmware for update is applied to an ECU to be updated in the operation environment, an operation whether or not each ECU in the operation environment operates normally after the update, etc. Is verified.
  • the operation of the update firmware may be verified using hardware of various ECUs as the operation environment, or the update firmware may be verified by simulation in a virtual environment that simulates the various ECUs. Operation verification may be performed.
  • the distribution data generation unit 570a generates FW update information (see FIG. 16) as an update firmware package for distribution to the gateway 300a, and requests the signature generation unit 590 to generate a signature for the FW update information. .
  • the distribution data generation unit 570a obtains information (ECU-ID, FW version, etc.) about all ECUs used as the operating environment of firmware verified to operate properly from the FW operation verification unit 530. Then, the verified ECU configuration information in the FW update information is set.
  • the FW holding unit 571 holds firmware for ECUs that have been uploaded and have undergone operation verification.
  • FIG. 21 is a flowchart showing FW registration processing related to registration of firmware for update by the server 500a.
  • the FW registration process is executed when firmware is transmitted from a terminal device external to the server 500a via the network and a firmware registration request is made.
  • the server 500a receives a firmware registration request that is accompanied by uploading of firmware to the server 500a (step S2000).
  • the firmware registration request includes, for example, information indicating the FW version indicating the version number of the firmware and the ECU-ID of the ECU that is the target of the firmware.
  • the server 500a that has received the registration request identifies a vehicle model that requires firmware update (step S2001). That is, the server 500a acquires the ECU-ID of the ECU that needs to be updated from the information included in the received firmware registration request, refers to the ECU vehicle model management table as illustrated in FIG. The vehicle model equipped with the ECU identified by the included ECU-ID is specified.
  • the server 500a executes a firmware operation verification process (steps S2003 to S2007) in an operating environment configured by an ECU used in the vehicle model for each vehicle model specified in step S2001 (step S2002).
  • the server 500a identifies the ECU mounted on the corresponding vehicle model with reference to the vehicle model ECU management table (see FIG. 20), and lists information (ECU-ID) of all the identified ECUs.
  • a list is generated (step S2003).
  • operation verification FW operation verification processing
  • for the firmware to be updated is performed in an operation environment configured using the ECU shown in the list (step S2004).
  • this operation verification when the firmware to be updated operates normally in an environment constituted by the ECU mounted on the corresponding vehicle model, and when the firmware of the ECU to be updated is updated, other ECUs Confirmation of normal operation is made.
  • the server 500a determines whether the operation verification is successful (step S2005). If it is determined in step S2005 that the operation verification is successful, the server 500a stores the firmware in the FW holding unit 571 and manages the firmware (step S2006). On the other hand, if it is determined in step S2005 that the operation verification has failed, the server 500a notifies the terminal device that has transmitted the firmware registration request in step S2000 (step S2007).
  • FIG. 22 is a flowchart showing the FW operation verification process by the server 500a.
  • the FW operation verification process is mainly executed by the FW operation verification unit 530a and the like in the server 500a and is a part of the above-described FW registration process (see FIG. 21) (step S2004). It is also a process performed when an operation verification request based on the system configuration information is received.
  • the FW operation verification process is generally an environment configured using an ECU group indicated by the list from the FW update control unit 520a or an ECU group of the same type as the ECU indicated by the system configuration information acquired from the gateway 300a. In this process, the operation of the update firmware is verified.
  • the FW operation verification process will be described below with reference to FIG.
  • the FW operation verification unit 530a refers to the ECU-ID indicated in the received list, or the ECU-ID indicated by the system configuration information, and sets information on each ECU to be used for operation verification in the simulator 800 (step S2100).
  • the simulator 800 is a computer that can be controlled by the FW operation verification unit 530a, and is configured to be able to simulate various ECUs.
  • the configuration of the FW operation verification unit 530a and the simulator 800 operates as a simulation unit that simulates a plurality of ECUs.
  • the FW operation verification unit 530a should be used for operation verification based on information (software) for simulating various ECUs held in the ECU information holding unit 531 and the latest firmware. Information on each ECU is set in the simulator 800.
  • the information for simulating various ECUs held by the ECU information holding unit 531 includes, for example, information on the processor and memory in the ECU (operating frequency, memory size, etc.), information on the CAN controller in the ECU ( Model number, operating frequency, etc.), information on the bus connected to the ECU or communication path used by the ECU, information on sensors and actuators connected to the ECU (information on rotary encoders, torque sensors, motors, etc.), etc. Can be.
  • information on the processor and memory in the ECU operating frequency, memory size, etc.
  • information on the CAN controller in the ECU Model number, operating frequency, etc.
  • information on the bus connected to the ECU or communication path used by the ECU information on sensors and actuators connected to the ECU (information on rotary encoders, torque sensors, motors, etc.), etc.
  • information on sensors and actuators connected to the ECU information on rotary encoders, torque sensors, motors, etc.
  • the FW operation verification unit 530a selects the firmware set in each ECU to be simulated by the simulator 800 from all the firmware corresponding to the various ECUs held in the all FW holding unit 532, and the firmware Is set in the simulator 800 (step S2101). Note that the firmware before update is also set for the ECU whose firmware is to be updated.
  • the FW operation verification unit 530a performs an operation verification of the update firmware by simulating the update for setting the update firmware in the target ECU and the operation of each ECU after the update by the simulator 800. This is performed (step S2102).
  • the simulator 800 applies the update firmware. Then, a simulation is executed for the subsequent operation, and operation verification is realized as to whether the operation is normal.
  • the FW operation verification unit 530a determines whether the operation verification is successful (step S2103). If it is determined in step S2103 that the operation verification is successful, the FW operation verification unit 530a stores the firmware that has been verified in the FW holding unit 532 (step S2104). When the FW operation verification process is performed based on the operation verification request from the gateway 300a, the process in step S2104 is omitted.
  • the FW operation verification unit 530a transmits information (ECU-ID, FW version, etc.) about all ECUs used for operation verification to the FW update control unit 520a, and the FW update control unit 520a transmits a distribution data generation unit.
  • Information about the ECU used for the operation verification is included in the 570a as verified ECU configuration information, and FW update information including FW data of the firmware that has been verified for operation is generated.
  • the signature generation unit 590 generates a signature for the FW update information including the verified ECU configuration information, and includes the signature in the FW update information as the FW update information signature (step S2105).
  • step S2103 If it is determined in step S2103 that the operation verification has not been successful, the FW operation verification unit 530a notifies the FW update control unit 520a of an error (step S2106), and the FW update control unit 520a receives the error. , Processing related to generation of FW update information is stopped.
  • the verified ECU configuration information may include not only information related to each ECU itself but also information related to the state of each ECU when operation verification is performed. Examples of this information include, for example, the rewrite time (processing length) when updating from the current version of firmware to the new firmware, the time until operation becomes possible after rewriting, the load of rewriting processing, sensor information and in-vehicle The time when the message on the network cannot be received, the ID of the message that cannot be received during rewriting, the memory size used by the firmware after rewriting, and the like can be mentioned. From these pieces of information, the gateway 300a and each ECU may determine when to update the firmware.
  • FIG. 23 is a flowchart illustrating an example of FW operation verification processing related to verification of a plurality of firmware by the server 500a.
  • FIG. 23 shows processing that is a substitute for step S2101 and step S2102 shown in FIG. 22, but other processing is omitted.
  • the operation of verifying a plurality of firmware by the server 500a will be described below with reference to FIG.
  • the FW operation verification unit 530a generates a verification order pattern indicating the order in which the plurality of update firmwares are to be verified after performing the processing in step S2100 illustrated in FIG. S2200).
  • the FW operation verification unit 530a repeatedly executes the process from step S2201 to step S2204 for each generated verification order pattern.
  • the verification order pattern used in steps S2201 to S2204 for each repeated execution is referred to as a “target verification order pattern”.
  • the FW operation verification unit 530a reads firmware for operating on each ECU set in the simulator 800 from all the FW holding units 532, and sets the firmware on the ECU on the simulator 800 (step S2202).
  • Step S2202 is the same process as step S2101.
  • the processing in step S2204 is repeated for each of a plurality of update firmware (step S2203).
  • the FW operation verification unit 530a performs the operation verification in step S2204 on each update firmware according to the order indicated by the target verification order pattern with respect to a plurality of update firmware.
  • the FW operation verification unit 530a executes the simulator 800 so as to set the update firmware in the ECU to be updated, and verifies whether it operates normally.
  • the FW operation verification unit 530a verifies whether the simulator 800 operates normally every time one update firmware is set for one ECU in the simulator 800. It is determined that the operation verification in the target verification order pattern is successful only when the setting to the ECU and the operation verification are completed and all the operation verifications are successful for all the update firmware.
  • the FW operation verification unit 530a determines whether there is a verification order pattern in which the operation verification is determined to be successful among the verified verification order patterns (Ste S2205). If it is determined in step S2205 that there is a pattern for which operation verification has succeeded, the FW operation verification unit 530a records the verification order pattern for which operation verification has been successful as update order information (step S2206). Then, including update order information and the like, information about all ECUs used for operation verification (ECU-ID, FW version, etc.), and further, an operation verification result indicating that the operation verification has been successful, The unit 520a is notified (step S2207). On the other hand, if there is no pattern in which the operation verification is successful in step S2205, the FW operation verification unit 530a notifies the FW update control unit 520a of the verification failure (step S2208).
  • FIG. 24 and FIG. 25 are sequence diagrams showing an operation example related to the update of the firmware of the ECU performed by the devices such as the server 500a, the gateway 300a, and the ECUs 100a and 100b.
  • Each sequence here means each processing procedure (step) in each apparatus.
  • steps S2301 to S2304 shown in this operation example is assumed to be repeatedly executed at a period of, for example, a certain number of days, but is executed when it is detected that a new ECU is added to the in-vehicle network. Alternatively, it may be executed in response to an operation of a driver or the like on any ECU in the vehicle.
  • the procedure after step S2306 is started, for example, when the server 500a receives a firmware registration request.
  • the gateway 300a can hold system configuration information (see FIG. 6), which is a set of the latest ECU information of each ECU connected to the in-vehicle network, in the ECU information holding unit 372. it can. It should be noted that the gateway 300a in step S2301 omits the process of transmitting the ECU information acquisition frame and requesting the ECU information, and when each ECU is started or when the ECU information (ECU- The frame including the ECU information may be transmitted to the gateway 300a when the ID, FW version, or the like is changed.
  • the server 500a When the latest ECU firmware (that is, for update) is uploaded to the server 500a from a terminal device outside the server 500a (for example, a terminal device such as an ECU manufacturing company) and a firmware registration request is made, the server 500a Performs FW registration processing (see FIG. 21) for registering the firmware (step S2306).
  • the firmware for update is stored and managed in the FW holding unit 571 of the server 500a after operation verification (verification of proper operation without problems) in an environment using the ECU group in the corresponding vehicle model. (That is, registered in the server 500a).
  • the server 500a generates FW update information including registered update firmware, verified ECU configuration information indicating each ECU used for the operation verification of the firmware, and distributes it to the gateway 300a (step S2307). Thereby, the gateway 300a receives the FW update information.
  • the distribution in step S2307 may be transmission to the gateway 300a of one vehicle, or transmission to the gateway 300a of each of a plurality of vehicles that require firmware update. May be.
  • Step S2307 is a reception step of receiving, from the server 500a, FW update information including update firmware whose update target is at least one ECU in the gateway 300a.
  • the signature verification unit 373 verifies the signature (FW update information signature) of the FW update information (step S2308). Then, the FW update processing unit 370a of the gateway 300a determines whether or not the signature verification is successful (step S2309). If the signature verification is not successful, the FW update information is discarded. Does not update the firmware based on the FW update information.
  • the FW update processing unit 370a compares the verified ECU configuration information included in the FW update information with the system configuration information held by the ECU information holding unit 372 (step S2310).
  • the FW update processing unit 370a of the gateway 300a includes a type of each of the plurality of ECUs mounted on the vehicle indicated by the system configuration information and a type of each of the plurality of ECUs used for operation verification indicated by the verified ECU configuration information. It is determined whether or not appropriate operation verification is performed based on whether or not the comparison result satisfies a certain condition (for example, whether or not they completely match) (step S2311). For example, the FW update processing unit 370a determines that appropriate operation verification has been performed when the comparison results completely match.
  • the server 500a performs firmware operation verification using each ECU used in the vehicle model at the time of firmware registration. For example, a vehicle on which the gateway 300a is mounted receives an ECU from the ECU of the vehicle model. If they are exchanged or added, the comparison results in step S2310 do not match.
  • Step S2312 is an operation verification request transmission step in which the gateway 300a transmits system configuration information to the server 500a as an external device.
  • the FW operation verification unit 530a performs the FW operation verification process related to the operation verification of the distributed firmware in the environment according to the system configuration information (step S2313).
  • the server 500a receives the system configuration information, and performs an operation verification of the update firmware using a plurality of ECUs of the same type as all the types indicated by the system configuration information. This is a verification step.
  • the server 500a includes the verified ECU configuration information that is information on each ECU used for the operation verification in step S2313.
  • Step S2314 is a firmware update information transmission step of transmitting FW update information after the operation verification is performed.
  • verified ECU configuration information indicating the type of each of the plurality of ECUs used for operation verification may be included in the FW update information and transmitted.
  • the gateway 300a receives FW update information again.
  • the signature verification unit 373 verifies the signature (FW update information signature) of the FW update information (step S2315).
  • the processing in steps S2315 to S2318 is the same as the processing in steps S2308 to S2311.
  • the gateway 300a is appropriate depending on whether or not a comparison result between each ECU type indicated by the system configuration information and each ECU type indicated by the verified ECU configuration information satisfies a certain condition (for example, whether or not they completely match). Whether or not proper operation verification has been performed is determined (step S2318). If it is determined that proper operation verification has not been performed, a predetermined abnormality process is performed and the firmware is not updated.
  • the FW update processing unit 370a mainly cooperates with the ECU corresponding to the update target to perform the FW update control process ( 13 and 14) (step S2319).
  • the gateway 300a performs control for updating the firmware of the corresponding ECU based on the update firmware after the operation of the update firmware is verified using each type of ECU indicated by the system configuration information. It is an update processing step for performing
  • the gateway 300a After completing the FW update control process in step S2319, the gateway 300a transmits the firmware update result to the server 500a (step S2320). Thereby, the server 500a receives the update result.
  • the firmware update result is, for example, information indicating whether or not the update is successful.
  • the information may include, for example, the FW version related to the firmware after the update, or may include, for example, system configuration information.
  • the gateway 300a also sends an update result indicating a firmware update failure to the server even when signature verification fails in steps S2309 and S2316, or when it is determined that appropriate operation verification is not performed in step S2318. You may transmit to 500a.
  • the server 500a When the server 500a receives the firmware update result, the server 500a updates the vehicle ECU management information held by the ECU management information holding unit 572 so as to indicate the state after the firmware update (step S2321).
  • FIG. 26 shows an example of the software configuration of the virtual environment used for the firmware operation verification by the simulator 800 in the FW operation verification process.
  • the software that operates in the simulator 800 includes a virtual machine monitor 801, virtual machines 802, 803, 804, and 805, virtual hardware 810, 820, 830, and 840, and a general-purpose OS (operating system). 811, 821, RTOS (real-time operating system) 831, firmware 841, application (application program) A 812, application B 813, application C 814, application D 822, and application E 832.
  • the simulator 800 is a computer and executes software (such as a virtual machine monitor 801) on a processor.
  • the virtual machine monitor 801 has a virtual machine control function for controlling the virtual machines 802 to 805 so that the virtual machine monitor 801 operates independently of each other, and a resource for managing the virtual machine by allocating hardware resources such as memory and CPU. It has a management function, a device access function for accessing a device in accordance with a request from a virtual machine, a scheduling function for scheduling a virtual machine, and the like.
  • Each of the virtual machines 802 to 805 includes virtual hardware, an OS, an application, or firmware, and is executed independently by the virtual machine monitor 801.
  • the virtual hardware 810, 820, 830, and 840 virtually provide hardware functions to the respective virtual machines, and may include IPL (Initial Program Loader) and BIOS (Basic Input / Output System).
  • IPL Initial Program Loader
  • BIOS Basic Input / Output System
  • the general-purpose OS 811 has a function of loading and executing an application (application A 812, application B 813, application C 814) on a memory, or deleting (unloading) each application from the memory. , Providing a network communication function according to the CAN protocol. The same applies to the general-purpose OS 821.
  • RTOS 831 is an OS for operating an application that emphasizes real-time characteristics.
  • Application A 812, application B 813, application C 814, application D 822, and application E 832 include a car navigation function, a driving support function, a steering control function, an engine control function, a brake control function, and sensor information (torque, angle, speed, rotational speed, etc.). It has various functions for automobiles such as an acquisition function. Each of these automotive function groups may be executed by a single app or may be executed by a plurality of apps.
  • Firmware 841 is software that operates a function that does not require an OS. Note that the firmware 841 may include an OS, and may have a function of controlling the execution of another application as an operating environment of the other application.
  • the number of applications operating on the general-purpose OSs 811 and 821 or RTOS 831 illustrated in FIG. 26 is merely an example, and more applications may operate.
  • the virtual environment may be configured only by a virtual machine on which firmware operates, or may be configured by only a virtual machine on which firmware operates and a virtual machine on which RTOS operates.
  • one ECU is simulated by one virtual machine such as the virtual machines 802 to 805 described above.
  • a plurality of virtual machines 805 (for the number of ECUs constituting the operating environment) are generated and operated on the virtual machine monitor 801, and the operation of one ECU hardware is performed by the virtual hardware 840 of each virtual machine 805.
  • the firmware 841 has the same contents as the firmware installed in the ECU.
  • the virtual machine monitor 801 is configured to simulate communication between ECUs via a bus between a plurality of virtual hardware operating on the virtual machine monitor 801.
  • the FW operation verification unit 530a sets the virtual machine to perform the same operation as each ECU when setting each ECU configuring the operation environment for the operation verification of the firmware in the simulator 800.
  • the ECU constituting the operating environment may be set by loading a virtual machine (that is, a virtual ECU) already set to simulate the operation of the ECU onto the virtual machine monitor 801.
  • the firmware is appropriately updated in the operating environment suitable for the vehicle by comparing the verified ECU configuration information in the received FW update information with the system configuration information that is information of all the ECUs in the vehicle. It is confirmed whether or not the operation verification related to the update is performed, and if the appropriate operation verification is not performed, an operation verification request is made to the server 500a. Thereby, before actually updating the ECU of the vehicle, it is possible to verify whether the firmware update has an adverse effect.
  • the gateway 300a can receive from the server 500a update firmware that has been verified for operation in an operating environment suitable for the vehicle.
  • the gateway 300a can acquire the firmware whose operation has been verified, Firmware update is possible. That is, the possibility that the vehicle does not function normally after the firmware is updated in the vehicle is reduced.
  • Embodiments 1 and 2 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 gateways 300 and 300a having the external communication unit 375 communicate with the servers 500 and 500a via the network 400 outside the vehicle, but this is only an example.
  • the gateways 300 and 300a may communicate with the servers 500 and 500a via another ECU (for example, a head unit) having a communication function with the outside.
  • the head unit is a kind of ECU having a relatively high-performance processor, and includes a display device such as a liquid crystal display provided in an instrument panel (instrument panel) of an automobile, and performs notification to a vehicle driver. It is a device to obtain.
  • the in-vehicle network has a diagnostic port called OBD2 (On-Board Diagnostics 2), which is an interface for communicating with an external device such as a diagnostic tool, and is used for diagnosis of the ECU. Therefore, for example, the gateways 300 and 300a may communicate with the servers 500 and 500a indirectly by communicating with an external device that is communicable with the servers 500 and 500a and connected to the diagnostic port. In these cases, the gateways 300 and 300a do not necessarily have an external communication function for communicating with the outside of the vehicle, and between the gateways 300 and 300a and the servers 500 and 500a via other ECUs or external devices. Then, it is possible to exchange an operation verification request or FW update request accompanied by system configuration information, and FW update information.
  • OBD2 On-Board Diagnostics 2
  • an in-vehicle network is shown as an example of a network communication system that performs communication according to the CAN protocol.
  • the technology according to the present disclosure is not limited to the in-vehicle network, but can be applied to a network such as a robot or an industrial device, or a network communication system that performs communication according to a CAN protocol other than the in-vehicle network.
  • the CAN protocol has a broad meaning including CANNOpen used for embedded systems in automation systems, or derivative protocols such as TTCAN (Time-Triggered CAN) and CANFD (CAN with Flexible Data Rate). Should be treated.
  • FW data FW update information
  • data encryption may be performed.
  • the signature key and the encryption key may be separate keys.
  • FW update information signature a signature for the entire FW update information as distribution data
  • FW data signature a signature for individual FW data is related to the FW data. It is good also as producing
  • each ECU verifies the FW data signature. However, the ECU does not verify the FW data signature, and the gateways 300 and 300a hold the verification key in advance. The verification of the FW data signature may be performed.
  • the gateway 300a in the second embodiment receives information (update order information) on the firmware update order included in the FW update information by the server 500a when a plurality of firmware needs to be updated. Although the update is performed in the order according to the update order information, it is not always necessary to update in the update order. Further, the server 500 according to the first embodiment transmits the update order information included in the FW update information, and the gateway 300 transmits the FW data in step S1204 in the order according to the update order information.
  • the firmware may be updated in order.
  • a part of the processing of the servers 500 and 500a in the above embodiment may be executed by another device (such as a computer) that can communicate with the servers 500 and 500a and is remote from the servers 500 and 500a.
  • another device such as a computer
  • the FW operation verification unit 530 in the above-described embodiment generates a verification order pattern and records the verification order in which the operation verification is successful when updating a plurality of firmware. It is also possible to update multiple firmwares at the same time and perform operation verification, or when operation verification fails for all verification order patterns, generate a pattern to be verified at the same time and perform operation verification. good.
  • the FW update processing unit 370a of the gateway 300a confirms that the same type as all types indicated by the system configuration information is not indicated in the verified configuration information, the update update included in the FW update information It is also possible to control the system configuration information to be transmitted to the server 500a as an external device as an operation verification request by suppressing the update based on the firmware.
  • ECU-ID ECU identification information
  • FW version firmware version identification information
  • the firmware operation may be verified by the simulator 800 shown in the second embodiment.
  • the servers 500 and 500a perform the operation verification of the firmware for update using the same type of ECU (that is, each type of ECU indicated by the system configuration information) as each ECU connected to the in-vehicle network in a certain vehicle.
  • a method in which the gateways 300 and 300a of the vehicle perform operation verification can also be used.
  • the gateways 300 and 300a include a simulation unit including a simulator similar to the simulator 800 shown in the second embodiment, and in the operating environment in which each type of ECU indicated by the system configuration information itself is simulated, It is also possible to verify the operation of the firmware received from 500a.
  • the gateway 300 or 300a after verifying that the gateways 300 and 300a operate without problems, the gateway 300 or 300a causes the ECU corresponding to the update target to update the firmware. For example, when the FW update processing unit 370a of the gateway 300a confirms that the same type as all types indicated by the system configuration information is not indicated in the verified configuration information, it is the same as all types indicated by the system configuration information. Performing control so that the simulation of the update firmware operation using each type of ECU is performed by the simulation unit in the gateway 300a, and the update based on the update firmware is performed after the operation verification by the simulation is performed. It is also good.
  • the message (frame) actually received by the gateway 300, 300a from the in-vehicle network is sent to the in-vehicle network in the operation environment (virtual environment) configured by the simulator. It may be configured to transmit.
  • the message received by the gateways 300 and 300a may be transmitted in a virtual environment from a virtual machine (virtual ECU) that does not execute update firmware.
  • each of the one or more ECUs that are firmware update targets may be realized as a virtual machine that operates on a computer having a configuration like the simulation 800.
  • the updating firmware (binary data) shown in the above embodiment may be the whole firmware or a part of the firmware mounted on the ECU.
  • the update firmware is a part of firmware installed in the ECU, it is overwritten on a part of the existing firmware in the ECU.
  • the update firmware can be configured to include difference data (binary data) and information (for example, address information) indicating which part is applied.
  • the difference data and the existing firmware may be merged, and then the firmware in the startup ROM of the ECU may be replaced.
  • the execution order of the various processing procedures shown in the above embodiment is not necessarily limited to the order described above. However, the order of execution can be changed, a plurality of procedures can be performed in parallel, or a part of the procedures can be omitted without departing from the scope of the disclosure.
  • the gateways 300, 300a and other ECUs in the above embodiment are devices including, for example, a digital circuit such as a processor and a memory, an analog circuit, a communication circuit, etc., but a hard disk device, a display, a keyboard, Other hardware components such as a mouse may be included. Further, instead of the control program stored in the memory being executed by the processor and realizing the function in software, 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 constituent elements 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 the whole.
  • 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 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 constituted by 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.
  • a firmware update method including all or part of the processing procedures illustrated in FIGS. 11, 12, 24, 25, and the like may be used.
  • it may be a computer program (control program) for realizing this method by a computer, or may be a digital signal composed of the computer program.
  • it may be a control program for executing firmware update processing including a reception step, an acquisition step, and an update processing step in the firmware update method.
  • 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 can be used as the computer program or the digital signal.
  • 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. . Also, by recording and transferring the program or the digital signal on the recording medium, or by transferring the program or the digital signal via the network or the like, by another independent computer system It may be carried out.
  • the present disclosure can be used to appropriately update the firmware of the ECU connected to the in-vehicle network conforming to the CAN.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Mechanical Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)
  • Small-Scale Networks (AREA)

Abstract

車両に搭載された複数のＥＣＵが通信に用いるバスに接続されたゲートウェイ３００ａは、車両外のサーバから、複数のＥＣＵのうち１つのＥＣＵの更新用ファームウェアを含むファームウェア更新情報を受信する外部通信部３７５と、バスに接続される複数のＥＣＵ各々の種類を示すシステム構成情報を取得するＥＣＵ情報取得部３９０と、システム構成情報が示す各種類のＥＣＵを用いて更新用ファームウェアの動作検証がなされた後にその更新用ファームウェアに基づく該当のＥＣＵのファームウェアの更新のための制御を行うＦＷ更新処理部３７０ａとを備える。

Description

ゲートウェイ装置、ファームウェア更新方法及び制御プログラム
　本開示は、車載ネットワークで通信する電子制御ユニットのファームウェアを更新（アップデート）する技術に関する。
　近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８－１で規定されているＣＡＮ（Controller Area Network）という規格が存在する。
　ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。またＣＡＮでは、送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。
　多数のＥＣＵがバスを介したメッセージの授受により連携して動作している場合に、あるＥＣＵがファームウェアの更新を開始すると、その更新中はメッセージの授受ができない等によって自動車の走行に影響を与える可能性がある。この点に関して、自動車の状態を示す情報から、停車中等といったＥＣＵのファームウェアを更新できると判断できた場合にのみファームウェアを更新する技術が知られている（特許文献１参照）。
特開２０１０－２７３１８１号公報
　しかしながら、上記従来の技術では、更なる改善が必要とされていた。
　本開示の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得部と、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理部とを備えるゲートウェイ装置である。
　なお、これらの全般的または具体的な態様は、装置、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、装置、システム、方法、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　上記態様によれば、更なる改善を実現することができる。
　なお、本開示の更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。
実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 実施の形態１に係るゲートウェイの構成図である。 受信ＩＤリストの一例を示す図である。 ゲートウェイが用いる転送ルールの一例を示す図である。 実施の形態１に係るシステム構成情報（ＥＣＵ情報のリスト）の一例を示す図である。 実施の形態１に係るＥＣＵの構成図である。 実施の形態１に係るサーバの構成図である。 サーバが保持する車両ＥＣＵ管理情報の一例を示す図である。 実施の形態１に係るファームウェア（ＦＷ）更新情報のフォーマットの一例を示す図である。 実施の形態１におけるファームウェアの更新に係る動作例を示すシーケンス図である（図１２に続く）。 実施の形態１におけるファームウェアの更新に係る動作例を示すシーケンス図である（図１１から続く）。 実施の形態１に係るゲートウェイによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係るＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態２に係るゲートウェイの構成図である。 実施の形態２に係るＦＷ更新情報のフォーマットの一例を示す図である。 実施の形態２に係るＥＣＵ構成情報のフォーマットの一例を示す図である。 実施の形態２に係るサーバの構成図である。 実施の形態２に係るＥＣＵ車両モデル管理テーブルの一例を示す図である。 実施の形態２に係る車両モデルＥＣＵ管理テーブルの一例を示す図である。 実施の形態２におけるサーバによる更新用ファームウェアの登録に係るＦＷ登録処理を示すフローチャートである。 実施の形態２に係るサーバによるＦＷ動作検証処理の一例を示すフローチャートである。 実施の形態２に係るサーバによる複数のファームウェアの検証に係るＦＷ動作検証処理の一例を示すフローチャートである。 実施の形態２におけるファームウェアの更新に係る動作例を示すシーケンス図である（図２５に続く）。 実施の形態２におけるファームウェアの更新に係る動作例を示すシーケンス図である（図２４から続く）。 実施の形態２におけるＦＷ動作検証処理に用いられるシミュレータによる仮想環境のソフトウェア構成の一例を示す図である。
　（本開示の基礎となった知見）
　特許文献１の技術は、ファームウェアの更新を適切（例えば安全）なタイミングで実行するものの、ファームウェアの更新後に自動車等の車両が正常に機能しないことを抑制するものではない。
　以上の検討を踏まえ、本発明者は、上記課題を解決するために、下記の改善策を検討した。
　本開示の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得部と、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理部とを備えるゲートウェイ装置である。
　これにより、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるので、動作検証が行われない場合と比べてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信部に受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成（電子制御ユニット群の編成）に対応して有効な動作検証が実行されたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。
　また、前記システム構成情報が示す、前記バスに接続される前記複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別し、前記検証済構成情報が示す、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別することとしても良い。これにより、車載ネットワークに接続された各電子制御ユニットのファームウェアと同じバージョンのファームウェアを実装した動作環境で動作検証がなされたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。
　また、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていることを確認した場合に、前記比較結果が前記一定条件を満たしたとして前記制御を行うこととしても良い。これにより、ファームウェアの更新に際して、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証の実施の確保が可能となり得る。
　また、前記ゲートウェイ装置は更に、前記システム構成情報を前記外部装置に送信する送信部を備え、前記更新処理部は、前記送信部が前記システム構成情報を前記外部装置に送信した後に、前記外部装置が当該システム構成情報を参照して複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行った後に送信した前記ファームウェア更新情報を、前記受信部により受信した場合に、当該ファームウェア更新情報の前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証を外部装置に行わせてからファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、前記システム構成情報は、前記バスに接続される前記複数の電子制御ユニット各々について、前記種類を特定するための、当該電子制御ユニットについての識別情報及び当該電子制御ユニットが実装しているファームウェアのバージョンの識別情報を含むこととしても良い。これにより、外部装置では、車載ネットワークに接続された各電子制御ユニットのファームウェアと同じバージョンのファームウェアを実装した動作環境で動作検証を行うことが可能となり、この結果として、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、前記ゲートウェイ装置は、前記システム構成情報を前記外部装置に送信する機能を有する送信部を備え、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記更新用ファームウェアに基づく前記更新を抑止して前記送信部に前記システム構成情報を前記外部装置に送信させるよう制御することとしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成に対応した適切な、更新用ファームウェアの動作検証が行われていない場合に、適切な動作検証を行わせるために有用な情報を送信するので、更新用ファームウェアの適切な動作検証の実施が確保される可能性が高まる。
　また、前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、車載ネットワークにおける各電子制御ユニットに対応した動作検証が行われていない場合に、シミュレーションにより更新用ファームウェアの動作検証を行った後にファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。なお、例えば、標準的な電子制御ユニットの構成に対応した動作検証がなされて送信されたファームウェアに対して、車両に搭載された電子制御ユニットを交換した或いは追加した後の状態においては、その動作検証では適切でないために、新たに適切な動作検証を行うことは有用である。
　また、前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、シミュレーションにより更新用ファームウェアの動作検証を行った後にファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、前記バスに接続された前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、前記更新処理部は、前記更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための前記制御として、前記バスを介して前記該当の電子制御ユニットへの前記更新用ファームウェアの送信を行うこととしても良い。これにより、更新用ファームウェアの動作検証の実施が確保された後に、ＣＡＮに従う車載ネットワークにおける電子制御ユニットへ更新用ファームウェアを送信してファームウェアを更新させるので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、本開示の一態様に係るファームウェア更新方法は、電子制御ユニットのファームウェアを更新するためのファームウェア更新方法であって、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置が、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記ゲートウェイ装置が、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記ゲートウェイ装置が、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含むファームウェア更新方法である。これにより、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるので、動作検証が行われない場合と比べてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、前記ファームウェア更新方法は更に、前記外部装置が、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、前記外部装置が、前記動作検証ステップで動作検証に用いた複数の電子制御ユニット各々の種類を示す検証済構成情報を、前記ファームウェア更新情報に含めて送信するファームウェア更新情報送信ステップとを含み、前記更新処理ステップは、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信ステップで受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成（電子制御ユニット群の編成）に対応して有効な動作検証が実行されたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。
　また、前記ファームウェア更新方法は更に、前記ゲートウェイ装置が、前記取得ステップで取得した前記システム構成情報を前記外部装置に送信する動作検証要求送信ステップと、前記外部装置が、前記動作検証要求送信ステップで送信された前記システム構成情報を受信して、当該システム構成情報が示す全ての種類と同じ種類の、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、前記外部装置が、前記動作検証ステップで動作検証が行われた後に前記ファームウェア更新情報を送信するファームウェア更新情報送信ステップとを含み、前記更新処理ステップは、前記動作検証要求送信ステップでの前記システム構成情報の送信の後に前記受信ステップで前記ファームウェア更新情報が受信された場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証が外部装置により行われてからファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　また、本開示の一態様に係る制御プログラムは、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続された、プロセッサを備えるゲートウェイ装置にファームウェア更新処理を実行させるための制御プログラムであって、前記ファームウェア更新処理は、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含む制御プログラムである。この制御プログラムがプロセッサを有する車両内の装置（例えばゲートウェイ装置）にインストールされ実行されることで、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるようになる。このため、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
　以下、実施の形態に係るゲートウェイ装置を含む車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　以下、本開示の実施の形態として、ゲートウェイ装置を含む複数の電子制御ユニット（ＥＣＵ）がバスを介して通信する車載ネットワークシステム１０において用いられるファームウェア更新方法について、図面を用いて説明する。
　ファームウェア更新方法は、車両に搭載された各ＥＣＵに実装されたファームウェア（ＦＷ：Firmware）を、車両の外部に所在するサーバから配信される新たな更新用ファームウェアで更新する（つまり更新用ファームウェアに置き換える）ための方法である。車載ネットワークシステム１０では、ファームウェアの更新後に車両が正常に機能しなくなる可能性を低減させるべく、その車両に対応した複数のＥＣＵを用いた更新用ファームウェアの動作検証が行われた後にファームウェアの更新を行う方法が用いられる。
　［１．１　車載ネットワークシステム１０の全体構成］
　図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。
　車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。車載ネットワークシステム１０は、バスを介してフレームに係る通信を行う複数の装置を備え、ファームウェア更新方法を用いる。
　具体的には図１に示すように車載ネットワークシステム１０は、車両に搭載され各種機器に接続されたＥＣＵ１００ａ～１００ｄ、バス２００ａ、２００ｂ、ゲートウェイ３００と、車両外のネットワーク４００とサーバ５００とを含んで構成される。なお、車載ネットワークシステム１０には、ゲートウェイ３００、ＥＣＵ１００ａ～１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ゲートウェイ３００及びＥＣＵ１００ａ～１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（ソフトウェアとしてのコンピュータプログラム）を記憶することができる。ファームウェアはこの制御プログラムの全部又は一部であり、例えばＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性メモリ（起動ＲＯＭと称する）に記憶される。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。なお、ファームウェアは、プロセッサ内において命令解釈を行うためのマイクロコードの全部又は一部を含むものであっても良い。
　ＥＣＵ１００ａ～１００ｄは、それぞれエンジン１０１、ブレーキ１０２、ドア開閉センサ１０３、窓（ウィンドウ）開閉センサ１０４といった機器に接続されており、その機器の状態を取得し、周期的に状態を表すフレーム（データフレーム）を、バス２００ａ、バス２００ｂ等で構成される車載ネットワークに送信している。
　ゲートウェイ３００は、ＥＣＵ１００ａとＥＣＵ１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１００ｃとＥＣＵ１００ｄとが接続されたバス２００ｂと接続されたゲートウェイ装置としての一種のＥＣＵである。ゲートウェイ３００は一方のバスから受信したフレームを他方のバスに転送する機能を有し、また、ネットワーク４００を介してサーバ５００と通信する機能を有する。
　車両外部に所在する外部装置としてのサーバ５００は、ネットワーク４００を介して、ＥＣＵ１００ａ～１００ｄのファームウェアを更新するためのデータであるＦＷ更新情報を配信する機能を有するコンピュータである。ネットワーク４００における通信には、無線通信、或いは、有線通信のいかなる通信プロトコルを適用しても良い。
　車載ネットワークシステム１０における各ＥＣＵは、ＣＡＮプロトコルに従ってフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。
　［１．２　データフレームフォーマット］
　以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。
　図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。
　ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
　ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
　ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
　ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
　ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
　データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
　ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
　ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
　ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
　ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
　ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
　［１．３　ゲートウェイ３００の構成］
　図３は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、バス間でのフレーム転送、外部のサーバ５００との通信（ＥＣＵ１００ａ～１００ｄ等のファームウェアの更新のためのＦＷ更新情報の受信等）等の機能を実行する。このためゲートウェイ３００は、図３に示すように、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、ＦＷ更新処理部３７０と、ＥＣＵ情報保持部３７２と、署名検証部３７３と、鍵保持部３７４と、外部通信部３７５と、フレーム生成部３８０と、ＥＣＵ情報取得部３９０とを含んで構成される。これらの各構成要素は、ゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部３１０は、バス２００ａ及びバス２００ｂのそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス２００ａ又はバス２００ｂからフレームを受信し、フレーム解釈部３２０に転送する。また、フレーム送受信部３１０は、フレーム生成部３８０より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス２００ａ又はバス２００ｂに送信する。
　フレーム解釈部３２０は、フレーム送受信部３１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部３２０は、ＩＤフィールドと判断した値は受信ＩＤ判断部３３０へ転送する。フレーム解釈部３２０は、受信ＩＤ判断部３３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、フレーム処理部３５０へ転送するか、フレームの受信を中止するかを決定する。また、フレーム解釈部３２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部３８０へ通知する。また、フレーム解釈部３２０は、エラーフレームを受信した場合には、受信中のフレームについてそれ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部３３０は、フレーム解釈部３２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部３３０は、フレーム解釈部３２０へ通知する。
　受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図４は、受信ＩＤリストの一例を示す図である。
　フレーム処理部３５０は、転送ルール保持部３６０が保持する転送ルールに従って、受信したフレームのＩＤに応じて、転送するバスを決定し、転送するバスのバス情報と、フレーム解釈部３２０より通知されたメッセージＩＤと、データとをフレーム生成部３８０へ通知する。また、フレーム処理部３５０は、フレーム解釈部３２０より通知されたファームウェアの更新に係る更新結果のデータを、ＦＷ更新処理部３７０へ通知し、ＥＣＵ情報に関するデータを、ＥＣＵ情報取得部３９０へ通知する。なお、フレーム処理部３５０は、ファームウェアの更新に係る更新結果のデータ及びＥＣＵ情報に関するデータを、転送の対象としない。
　転送ルール保持部３６０は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図５は、転送ルールの一例を示す図である。
　ＦＷ更新処理部３７０は、外部通信部３７５から通知された更新用のファームウェア等のＦＷデータを含むＦＷ更新情報の署名検証を署名検証部３７３へ依頼し、署名検証に成功した場合に更新用のファームウェアに係るＦＷデータと、更新対象となるＥＣＵが接続されたバスのバス情報とを、フレーム生成部３８０に通知する。また、ＦＷ更新処理部３７０は、フレーム処理部３５０から通知された更新結果を外部通信部３７５に通知する。また、ＦＷ更新処理部３７０は、ＥＣＵ情報取得部３９０からの通知等に基づいて、ＥＣＵ情報保持部３７２に保持されたＥＣＵ情報の集合であるシステム構成情報をＦＷ更新要求として外部通信部３７５に通知する。また、ＥＣＵ１００ａ～１００ｄとの通信に必要となるデータをフレーム生成部３８０へ通知する。なお、ＦＷ更新処理部３７０は、システム構成情報が示す各種類のＥＣＵを用いて更新用のファームウェアの動作検証がなされた後にその更新用ファームウェア等のＦＷデータを含むＦＷ更新情報を受けて署名検証に成功した場合に漸く該当のＥＣＵのファームウェアの更新のための制御（例えばバスを介してのＥＣＵへのＦＷデータの送信等）を行う更新処理部として機能する。
　ＥＣＵ情報保持部３７２は、バス２００ａ、バス２００ｂに繋がる全てのＥＣＵ（ＥＣＵ１００ａ～１００ｄ）それぞれに関する情報であるＥＣＵ情報の集合であるシステム構成情報を保持する。システム構成情報の一例を図６に示す。
　署名検証部３７３は、ＦＷ更新処理部３７０から、ＦＷ更新情報に係る署名検証対象となるデータを受信し、鍵保持部３７４より取得した署名検証用の鍵を用いて署名検証を行ってその検証結果をＦＷ更新処理部３７０へ通知する。
　鍵保持部３７４は、サーバ５００から受信するＦＷ更新情報の署名検証用の鍵を保持する。
　外部通信部３７５は、サーバ５００から更新用のファームウェアに係るＦＷデータを含むＦＷ更新情報を受信する受信部としての機能を有し、受信したＦＷ更新情報をＦＷ更新処理部３７０へ通知する。また、外部通信部３７５は、ＦＷ更新処理部３７０から通知された更新結果を、サーバ５００へ送信する。また、外部通信部３７５は、ＦＷ更新処理部３７０から通知されたシステム構成情報をＦＷ更新要求として外部装置であるサーバ５００へ送信する送信部としての機能を有する。外部通信部３７５は、例えば、ネットワーク４００を介してサーバ５００にアクセスするために必要なサーバ５００のアドレス情報等を予め保持している。
　フレーム生成部３８０は、フレーム解釈部３２０から通知されたエラーフレーム送信の要求に従い、エラーフレームを、フレーム送受信部３１０へ通知して送信させる。また、フレーム生成部３８０は、フレーム処理部３５０から通知されたメッセージＩＤと、データとを用いてフレームを構成し、バス情報とともにフレーム送受信部３１０へ通知する。また、フレーム生成部３８０は、ＦＷ更新処理部３７０から通知された更新用のファームウェアに係るＦＷデータを用いてフレームを構成し、バス情報とともにフレーム送受信部３１０へ通知する。また、フレーム生成部３８０は、ＥＣＵ情報取得部３９０から通知された要求に従い、ＥＣＵ情報取得用のフレームを構成して、構成したフレームをフレーム送受信部３１０へ通知して送信させる。
　ＥＣＵ情報取得部３９０は、バス２００ａ、バス２００ｂに繋がる全てのＥＣＵからＥＣＵ情報を取得するために、例えば周期的に、フレーム生成部３８０にＥＣＵ情報取得用のフレーム（データフレーム）を生成して送信するよう要求する。なお、各ＥＣＵは、ＥＣＵ情報取得用のフレームを受信すると予め定められたＩＤのフレーム（データフレーム）でＥＣＵ情報を、ゲートウェイ３００へ到達するように送信する。このため、ＥＣＵ情報取得部３９０は、フレーム処理部３５０から、各ＥＣＵのＥＣＵ情報に関するデータを通知されて取得し、このＥＣＵ情報に基づいて、ＥＣＵ情報保持部３７２が保持するシステム構成情報のＥＣＵ情報を必要に応じて更新する。即ち、ＥＣＵ情報取得部３９０は、バス２００ａ、２００ｂに接続される複数のＥＣＵ各々の種類を示すシステム構成情報を取得する取得部としての機能を有する。
　［１．４　受信ＩＤリスト例］
　図４は、ゲートウェイ３００の受信ＩＤリスト保持部３４０に保持される受信ＩＤリストの一例を示す図である。
　図４に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。これは一例に過ぎないが、受信ＩＤリストには、ゲートウェイ３００が受信すると定められているフレームのメッセージＩＤが列挙されている。
　［１．５　転送ルール例］
　図５は、ゲートウェイ３００の転送ルール保持部３６０が保持する転送ルールの一例を示す。
　この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図５中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。図５の例は、バス２００ａから受信するフレームはメッセージＩＤにかかわらず、バス２００ｂに転送するように設定されていることを示している。また、バス２００ｂから受信するフレームのうちメッセージＩＤが「３」であるフレームのみがバス２００ａに転送されるように設定されていることを示している。
　［１．６　システム構成情報例］
　図６は、ゲートウェイ３００のＥＣＵ情報保持部３７２が保持するシステム構成情報（ＥＣＵ情報の集合）の一例を示す。
　この例のシステム構成情報は、ＥＣＵ毎のＥＣＵ情報のリストである。ＥＣＵ情報は、ＥＣＵ－ＩＤと、ＥＣＵの機能種別を示すＥＣＵ種別と、ＥＣＵの製造会社と、ＥＣＵに実装されたファームウェアのバージョン番号等であるＦＷバージョンとを含んで構成される。ＥＣＵ－ＩＤは、例えば各ＥＣＵに固有のシリアル番号等の識別子（識別情報）である。このＥＣＵ－ＩＤとＦＷバージョンとにより、ＥＣＵの種類が識別可能である。種類の同じ複数のＥＣＵは、例えばバスを介したデータの授受の動作に関する機能が同一な複数のＥＣＵであり、種類の異なる複数のＥＣＵは、その動作に関する機能が相互に異なる複数のＥＣＵである。図６の例は、エンジン１０１に接続されたＥＣＵ１００ａについてのＥＣＵ－ＩＤが「０００１」であり、ＥＣＵ種別が「エンジン」で識別されるエンジン制御用という種別であり、製造会社が「Ａ社」であり、ＥＣＵ－ＩＤのＦＷバージョンが１．０であること等を示している。システム構成情報の初期値は、製造時に設定されたものであっても良いし、例えばゲートウェイ３００に電力の供給が開始された際に、サーバ５００等の外部装置からゲートウェイ３００が取得したものであっても良い。バス２００ａ、２００ｂに接続されたＥＣＵの交換或いはファームウェアの更新等で状態が変化した場合や、車両に新たにＥＣＵが導入されてバス２００ａ又はバス２００ｂに接続された場合等において、ＥＣＵ情報取得部３９０が周期的に収集するＥＣＵ情報に基づいてシステム構成情報は車両内の各ＥＣＵの最新の状態を示すように逐次更新され得る。
　［１．７　ＥＣＵ１００ａの構成］
　図７は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、ＦＷ更新処理部１６０と、ＦＷキャッシュ保持部１６１と、署名検証部１６３と、鍵保持部１６４と、データ取得部１７０と、フレーム生成部１８０とを含んで構成される。これらの各構成要素は、ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部１１０は、バス２００ａに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バスからフレームを１ｂｉｔずつ受信し、フレーム解釈部１２０に転送する。また、フレーム生成部１８０より通知を受けたフレームの内容をバス２００ａに送信する。
　フレーム解釈部１２０は、フレーム送受信部１１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１３０へ転送する。フレーム解釈部１２０は、受信ＩＤ判断部１３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部１５０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止するかを決定する。また、フレーム解釈部１２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１８０へ通知する。また、フレーム解釈部１２０は、エラーフレームを受信した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部１３０は、フレーム解釈部１２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１３０は、フレーム解釈部１２０へ通知する。
　受信ＩＤリスト保持部１４０は、ＥＣＵ１００ａが受信するメッセージＩＤのリストである受信ＩＤリストを保持する。この受信ＩＤリストは、例えば上述の図４の例と同様である。
　フレーム処理部１５０は、受信したフレームのデータに応じてＥＣＵ毎に異なる処理を行う。例えば、エンジン１０１に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。そして、ＥＣＵ１００ａのフレーム処理部１５０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン１０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。ＥＣＵ１００ｃは、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能を備える。ＥＣＵ１００ｂ、１００ｄでは特に何もしない。なお、ＥＣＵ１００ａ～１００ｄは上記以外の機能を備えていても良い。また、フレーム処理部１５０は、ファームウェアの更新用のＦＷデータを取得した場合及びＥＣＵ情報取得用のフレームに係るデータを取得した場合には、ＦＷ更新処理部１６０へ通知する。
　ＦＷ更新処理部１６０は、ゲートウェイ３００から受信してフレーム処理部１５０から通知されたＦＷデータの署名検証を署名検証部１６３へ依頼し、署名検証に成功した場合にＦＷデータに基づいて、ＥＣＵ１００ａの起動ＲＯＭ内のファームウェアを更新する（書き換える）。起動ＲＯＭは、例えばＥＣＵ１００ａのプロセッサでリセット後に実行されるファームウェアの格納先として設定された不揮発性メモリである。起動ＲＯＭ内のファームウェアの更新の際には、ＦＷ更新処理部１６０は、更新失敗時に更新前の状態へと復元可能にするために、例えばＦＷキャッシュ保持部１６１に既存のファームウェアを格納する。また、ＦＷ更新処理部１６０は、ＦＷデータに基づくファームウェアの更新結果を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。ファームウェアの更新結果には、例えば更新後におけるファームウェアのバージョン番号等のＦＷバージョンを含めても良い。また、ＦＷ更新処理部１６０は、フレーム処理部１５０からＥＣＵ情報取得用のフレームに係る通知がなされた場合には、ＥＣＵ１００ａのＥＣＵ－ＩＤ及び現在のファームウェアについてのＦＷバージョンを含むＥＣＵ構成情報についてのフレームを生成して送信するようにフレーム生成部１８０に通知する。
　ＦＷキャッシュ保持部１６１は、例えばＥＣＵ１００ａにおける不揮発性メモリ等の記憶領域で実現され、起動ＲＯＭ内のファームウェアの更新に際して既存のファームウェアを格納する等のために用いられる。
　署名検証部１６３は、ＦＷ更新処理部１６０から、署名検証対象となるＦＷデータを受信し、鍵保持部１６４より取得した署名検証用の鍵を用いて署名検証を行ってその検証結果をＦＷ更新処理部１６０へ通知する。
　鍵保持部１６４は、ファームウェアの更新用のＦＷデータの署名検証用の鍵を保持する。
　データ取得部１７０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１８０に通知する。
　フレーム生成部１８０は、フレーム解釈部１２０から通知されたエラーフレーム送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１０へ通知して送信させる。また、フレーム生成部１８０は、データ取得部１７０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレーム送受信部１１０へ通知する。また、フレーム生成部１８０は、ＦＷ更新処理部１６０によるファームウェアの更新結果のフレーム又はＥＣＵ構成情報のフレームの生成の指示に応じて、それぞれ予め定められたメッセージＩＤを付したフレームを構成して、フレーム送受信部１１０へ通知する。
　ＥＣＵ１００ｂ～１００ｄもＥＣＵ１００ａと概ね同様の構成を備える。
　［１．８　サーバ５００の構成］
　サーバ５００は、車載ネットワークシステム１０が搭載される車両の外部に所在するコンピュータであり、メモリ、ハードディスク等の記憶媒体、プロセッサ、通信回路等を含む。サーバ５００は、ユーザインタフェースとしての入力装置（キーボード等）、ディスプレイ等を備えていても良い。複数の車両それぞれに車載ネットワークに係る複数のＥＣＵが搭載されていることを前提として、サーバ５００は、各種ＥＣＵの製造会社等から提供されたファームウェアを管理し、ファームウェアの動作検証を行い、各車両に更新用ファームウェアを含むＦＷ更新情報を配信する機能を有する。
　図８は、サーバ５００の構成図である。サーバ５００は、同図に示すように、データ送受信部５１０と、ＦＷ更新制御部５２０と、ＦＷ動作検証部５３０と、ＥＣＵ情報保持部５３１と、全ＦＷ保持部５３２と、配信データ生成部５７０と、ＦＷ保持部５７１と、ＥＣＵ管理情報保持部５７２と、署名生成部５９０と、鍵保持部５９１とを含んで構成される。これらの各構成要素は、サーバ５００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。
　データ送受信部５１０は、ゲートウェイ３００と通信し、データを送受信する。データ送受信部５１０は、ゲートウェイ３００からファームウェアの更新の要求（ＦＷ更新要求）としてシステム構成情報を受信した場合には、ＦＷ更新制御部５２０へ通知し、ＦＷ更新要求に対して更新すべきファームウェアがある場合にＦＷ更新制御部５２０からＦＷ更新情報を受け取ってゲートウェイ３００へと送信する。データ送受信部５１０は、ゲートウェイ３００より、ファームウェアの更新結果を受信した場合には、ＦＷ更新制御部５２０に通知する。
　ＦＷ更新制御部５２０は、ＥＣＵの製造会社等の端末装置から、ＥＣＵ用の最新のファームウェアがサーバ５００へアップロードされた場合に、ＦＷ保持部５７１にファームウェアを格納して、端末装置からの情報に基づいてファームウェアと、そのバージョン番号等を示すＦＷバージョンと、対象のＥＣＵの種類を示す情報等とを対応付けて管理する。ＦＷ更新制御部５２０は、データ送受信部５１０を経由して、ゲートウェイ３００からＦＷ更新要求に係るシステム構成情報を受け取った場合に、システム構成情報に基づいてそのゲートウェイ３００に対応して更新すべきファームウェアがある場合には配信データ生成部５７０に更新用のファームウェアのパッケージとしてのＦＷ更新情報を生成させる。なお、ＦＷ更新制御部５２０は、更新すべきファームウェアがあるか否かを、例えばＦＷ保持部５７１が保持するファームウェアに係る情報とシステム構成情報とに基づき判断し得る。ＦＷ更新制御部５２０は、そのシステム構成情報に基づいて、更新すべきファームウェアについての動作検証をＦＷ動作検証部５３０に依頼し、動作検証がなされた後（つまり問題なく適切に動作することが検証された後）においてＦＷ更新情報をデータ送受信部５１０に送信させる。なお、更新用のファームウェアについての動作検証に際して検証に失敗した場合（つまり適切に動作しなかった場合）には、サーバ５００は、更新用のファームウェアを含むＦＷ更新情報をゲートウェイ３００に送信しない。また、ＦＷ更新制御部５２０は、ゲートウェイ３００からファームウェアの更新結果を受け取った場合に、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新する。
　ＦＷ動作検証部５３０は、ＦＷ更新制御部５２０の依頼を受けてシステム構成情報が示す各ＥＣＵと同一種類のＥＣＵで構成された動作環境において、更新用のファームウェア、及び、動作環境における各ＥＣＵのファームウェアが適切（正常）に動作することを検証するためのＦＷ動作検証処理を実行する機能を有する。ＦＷ動作検証処理では、例えば、動作環境のうち更新対象となるＥＣＵに対して更新用のファームウェアを適用する更新の動作、その更新後に動作環境の各ＥＣＵが正常に動作するか否かの動作等が検証される。ＦＷ動作検証処理においては、動作環境としての各種ＥＣＵのハードウェアを用いて更新用のファームウェアの動作検証を行っても良いし、各種ＥＣＵをシミュレート（擬似的に実行）する仮想環境でのシミュレーションにより更新用のファームウェアの動作検証を行っても良い。ここでは、一例として各種ＥＣＵをシミュレートする仮想環境でのシミュレーションにより更新用のファームウェアの動作検証を行う例を想定して説明する。
　ＥＣＵ情報保持部５３１は、各種ＥＣＵをシミュレートするための情報（ソフトウェア）を保持し、その情報は、各種ＥＣＵが使用している最新のファームウェアを含む。
　全ＦＷ保持部５３２は、各種ＥＣＵに対応する最新のファームウェアだけでなく、過去のバージョンのファームウェアを含む全てのファームウェアを保持する。このＥＣＵ情報保持部５３１及び全ＦＷ保持部５３２を参照して、ＦＷ動作検証部５３０は、システム構成情報のＥＣＵ－ＩＤとＦＷバージョンとにより識別される各ＥＣＵの種類と、同一種類のＥＣＵをシミュレートする動作環境を構築して、更新用のファームウェアを適用した更新とその後の動作についてシミュレーションを行うことで問題なく適切に動作が行われるかを検証する。
　配信データ生成部５７０は、ゲートウェイ３００に配信するための更新用のファームウェアのパッケージとしてのＦＷ更新情報を生成し、署名生成部５９０に依頼してＦＷ更新情報に対する署名を生成させる。ＦＷ更新情報のフォーマットについては後述する（図１０参照）。
　ＦＷ保持部５７１は、アップロードされたＥＣＵ用のファームウェアを保持する。
　ＥＣＵ管理情報保持部５７２は、各車両の車載ネットワークにおける各ＥＣＵに関する情報である車両ＥＣＵ管理情報を保持する。車両ＥＣＵ管理情報については後述する（図９参照）。
　署名生成部５９０は、配信データ生成部５７０の依頼を受けて、鍵保持部５９１に保持されている署名用の鍵を用いて、ＦＷ更新情報に対する署名を生成して配信データ生成部５７０に通知する。署名生成部５９０は、例えば、ＦＷ更新情報における各ＦＷデータに対する署名及びＦＷ更新情報全体に対する署名を行い得る。
　鍵保持部５９１は、署名生成部５９０がＦＷ更新情報に署名するために用いる鍵を保持する。
　［１．９　ＥＣＵ管理情報例］
　図９は、サーバ５００のＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報（車両別のＥＣＵ情報の集合）の一例を示す。
　この例の車両ＥＣＵ管理情報は、サーバ５００の管理対象となる車両毎について車両情報とその車両に搭載される各ＥＣＵについてのＥＣＵ情報とを含んで構成される。車両情報は、車両を識別するための識別子（車両ＩＤ）である。車両ＥＣＵ管理情報において車両情報と対応付けたＥＣＵ情報は、ＥＣＵ－ＩＤと、ＥＣＵの機能種別を示すＥＣＵ種別と、ＥＣＵの製造会社と、ＥＣＵに実装されたファームウェアのバージョン番号等であるＦＷバージョンと、そのＥＣＵに対応する最新のファームウェアのバージョン番号等である最新ＦＷバージョンとを含んで構成される。車両ＥＣＵ管理情報における、ある車両についての各ＥＣＵ情報は、例えば、その車両のゲートウェイ３００から受信した情報（システム構成情報及びファームウェアの更新結果）と、各種ＥＣＵの製造会社からサーバ５００にアップロードされたファームウェアについてのＦＷバージョンとに基づいて設定されている。なお、図９では、一台の車両Ａに関する情報のみを例示しているが、車両ＥＣＵ管理情報は、他の車両についての情報も含み得る。
　［１．１０　ＦＷ更新情報のフォーマット例］
　図１０は、サーバ５００が配信する配信データとしてのＦＷ更新情報のフォーマットの一例を示す。
　ＦＷ更新情報は、ＦＷデータの個数を示すＦＷ数Ｆ１と、１個以上のＦＷデータ（図１０の例では２つの個別ＦＷデータＦ１０、Ｆ２０）と、ＦＷ更新情報（配信データ）全体に対する署名であるＦＷ更新情報署名Ｆ３０とを含む。ＦＷデータＦ１０、Ｆ２０はそれぞれ、更新用のファームウェア（ＦＷ）Ｆ１３、Ｆ２３と、対象となるＥＣＵを識別するＥＣＵ－ＩＤＦ１１、Ｆ２１と、ファームウェアのバージョン番号等を示すＦＷバージョンＦ１２、Ｆ２２と、これらのデータに対する署名であるＦＷデータ署名Ｆ１４、Ｆ２４を含む。ファームウェアＦ１３、Ｆ２３は、ファームウェア自体つまりバイナリデータである。
　［１．１１　ゲートウェイ３００等によるファームウェアの更新に係る動作例］
　以下、車載ネットワークシステム１０におけるＥＣＵのファームウェアの更新に係る動作について説明する。
　図１１及び図１２は、サーバ５００、ゲートウェイ３００、ＥＣＵ１００ａ、１００ｂ等の装置が連携して行うＥＣＵのファームウェアの更新に係る動作例を示すシーケンス図である。ここでの各シーケンスは、各装置における各処理手順（ステップ）を意味する。ここでは、説明の便宜上、一部のＥＣＵの動作について図示している。この動作例に示すシーケンスは、例えば一定日数毎等といった周期で繰り返し実行されることが想定されるが、車載ネットワークに新たなＥＣＵが追加されたことを検知した時に実行されても良いし、車両内のいずれかのＥＣＵへの運転者等の操作に対応して実行されても良い。
　車両におけるゲートウェイ３００は、バス２００ａ、２００ｂにＥＣＵ情報取得用のフレームを送信することで、車載ネットワークで接続された全てのＥＣＵ（ＥＣＵ１００ａ、１００ｂ等）に対してＥＣＵ情報を要求する（ステップＳ１００１）。
　ＥＣＵ情報取得用のフレームを受信したＥＣＵ１００ａは、ＥＣＵ１００ａについてのＥＣＵ－ＩＤと、実装しているファームウェアに係るＦＷバージョンとを含んで構成されるＥＣＵ情報を含むフレームを、バス２００ａへ送信する（ステップＳ１００２）。これに対応してゲートウェイ３００は、バス２００ａからフレームを受信することで、ＥＣＵ１００ａについてのＥＣＵ情報を受信する。
　また、ＥＣＵ１００ａと同様にＥＣＵ情報取得用のフレームを受信したＥＣＵ１００ｂも、ＥＣＵ１００ｂについてのＥＣＵ情報を含むフレームをバス２００ａへ送信する（ステップＳ１００３）。これに対応してゲートウェイ３００は、バス２００ａからフレームを受信することで、ＥＣＵ１００ｂについてのＥＣＵ情報を受信する。同様に、ゲートウェイ３００は、他の各ＥＣＵから送信される各ＥＣＵ情報を受信し得る。ステップＳ１００２、Ｓ１００３は、ゲートウェイ３００においては、各ＥＣＵの種類等を示すシステム構成情報（ＥＣＵ情報の集合）を取得する取得ステップである。
　次に、ゲートウェイ３００は、ＥＣＵ情報保持部３７２が保持するシステム構成情報としてのＥＣＵ情報群（ＥＣＵ情報の集合）に対して、各ＥＣＵから取得したＥＣＵ情報の集合が変化している場合には（ステップＳ１００４）、その取得したＥＣＵ情報により、ＥＣＵ情報保持部３７２が保持するシステム構成情報を更新する（ステップＳ１００５）。なお、ゲートウェイ３００は、保持しているシステム構成情報に対して、各ＥＣＵから取得したＥＣＵ情報が変化している場合に、車両の運転者等にそのことを報知するための制御を行っても良い。
　次に、ゲートウェイ３００は、ＥＣＵ情報保持部３７２が保持する、車載ネットワークに接続された全てのＥＣＵの編成をＥＣＵ情報の集合によって表すシステム構成情報を、ＦＷ更新要求として、サーバ５００に送信する（ステップＳ１００６）。これに対応してサーバ５００はＦＷ更新要求としてのシステム構成情報を受信する。
　サーバ５００は、ＦＷ更新要求に対応して、受信したシステム構成情報、及び、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報等に基づいて、ＦＷ更新要求の送信元のゲートウェイ３００を搭載する車両の１台以上のＥＣＵに対するファームウェアの更新が必要か否かを判別する（ステップＳ１００７）。更新が不要であればサーバ５００は、例えばゲートウェイ３００に更新が不要の旨を通知する。図１１では、更新が不要の場合の説明を省略している。
　ステップＳ１００７でファームウェアの更新が必要と判別した場合に、サーバ５００は、ＦＷ更新制御部５２０で、受信したシステム構成情報、及び、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報等に基づいて、送信すべき更新用の１つ以上のファームウェアを決定する（ステップＳ１００８）。この決定により更新用のファームウェアの個数も決定される。
　続いてサーバ５００は、ＦＷ動作検証部５３０により、受信したシステム構成情報が示す各ＥＣＵと同一種類のＥＣＵで構成される環境で、ステップＳ１００８で決定した更新用のファームウェアの動作検証を行う（ステップＳ１００９）。更新用のファームウェアとしては、ＦＷ保持部５７１に保持されているファームウェアが用いられる。サーバ５００は、ステップＳ１００９での動作検証を適切に終えた場合、つまりシステム構成情報が示す種類のＥＣＵで構成される環境で、更新用のファームウェアを対象となる該当のＥＣＵに適用した更新を行い、その更新後において各ＥＣＵが適切に動作すると確認された場合に、配信データ生成部５７０でＦＷ更新情報（図１０参照）の生成を行う。即ち、配信データ生成部５７０は、更新用のファームウェアの個数であるＦＷ数分だけ（ステップＳ１０１０）、ＦＷ保持部５７１が保持するファームウェア等のＦＷデータの取得（ステップＳ１０１１）、及び、ＦＷデータに対する署名生成部５９０で生成したＦＷデータ署名の付加（ステップＳ１０１２）を、繰り返す。また、配信データ生成部５７０は、署名生成部５９０によりＦＷ更新情報に対する署名（ＦＷ更新情報署名）を生成させて（ステップＳ１０１３）、その署名を付加したＦＷ更新情報を生成する。
　サーバ５００では、ＦＷ更新情報が生成されると、ＦＷ更新制御部５２０が、そのＦＷ更新情報をデータ送受信部５１０に送信させる（ステップＳ１０１４）。これにより、サーバ５００から、ＦＷ更新要求としてのシステム構成情報の送信元であるゲートウェイ３００へとＦＷ更新情報が送信され、ゲートウェイ３００はそのＦＷ更新情報を受信する。ステップＳ１０１４は、ゲートウェイ３００においては、サーバ５００から、少なくとも１つのＥＣＵを更新対象とする更新用ファームウェアを含むＦＷ更新情報を受信する受信ステップである。
　ゲートウェイ３００は、ＦＷ更新情報を受信すると、署名検証部３７３により、ＦＷ更新情報の署名（ＦＷ更新情報署名）を検証する（ステップＳ１０１５）。そして、ゲートウェイ３００のＦＷ更新処理部３７０は、署名の検証に成功したか否かを判定し（ステップＳ１０１６）、検証に成功しなかった場合には、ＦＷ更新情報を破棄し（ステップＳ１０１７）、この場合にはＦＷ更新情報に基づくファームウェアの更新が行われない。検証に成功した場合には、ゲートウェイ３００は、主としてＦＷ更新処理部３７０により、更新対象に該当するＥＣＵと連携して、ＦＷ更新制御処理を行う（ステップＳ１０１８）。ＦＷ更新制御処理の内容については後述する。ステップＳ１０１８等は、システム構成情報が示す各種類のＥＣＵを用いて更新用ファームウェアの動作検証がなされた後にゲートウェイ３００が、その更新用ファームウェアに基づく該当のＥＣＵのファームウェアの更新のための制御を行う更新処理ステップである。
　ゲートウェイ３００は、ステップＳ１０１８でのＦＷ更新制御処理を終えた後、或いは、ステップＳ１０１７でのＦＷ更新情報の破棄の後において、ファームウェアの更新結果をサーバ５００に送信する（ステップＳ１０１９）。ファームウェアの更新結果は、例えば更新に成功したか否かを示す情報であり、その情報は例えば更新後におけるファームウェアに係るＦＷバージョンを含んでも良い。これにより、サーバ５００は更新結果を受信する。
　サーバ５００は、ファームウェアの更新結果を受信した場合に、そのファームウェアの更新後の状態を表すように、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新する（ステップＳ１０２０）。
　［１．１２　ゲートウェイ３００によるＦＷ更新制御処理例］
　図１３は、ゲートウェイ３００によるＦＷ更新制御処理の一例を示すフローチャートである。
　以下、上述のステップＳ１０１８においてゲートウェイ３００により実行されるＦＷ更新制御処理について、図１３に即して説明する。
　ゲートウェイ３００は、ＦＷ更新処理部３７０により、ＦＷ更新情報（図１０参照）におけるＦＷ数を取得し（ステップＳ１２０１）、ステップＳ１２０３～ステップＳ１２０５での処理を、ＦＷ数分繰り返す（ステップＳ１２０２）。
　ＦＷ更新処理部３７０は、ＦＷ更新情報のＦＷデータにおけるＥＣＵ－ＩＤを取得する（ステップＳ１２０３）。
　続いてゲートウェイ３００では、ＦＷ更新処理部３７０がＥＣＵ－ＩＤで識別されるＥＣＵに送信するためにＦＷデータを含むフレームをフレーム生成部３８０に生成させ、そのフレームをフレーム送受信部３１０がそのＥＣＵが接続されたバスを介してＥＣＵに送信する（ステップＳ１２０４）。これにより、ＦＷデータにおけるＥＣＵ－ＩＤで識別されるＥＣＵがそのＦＷデータを受信してファームウェアの更新のための処理を行ってその更新結果をゲートウェイ３００に送信する。
　ゲートウェイ３００は、ＥＣＵから送信される更新結果を受信する（ステップＳ１２０５）。
　［１．１３　ＥＣＵ１００ａによるＦＷ更新制御処理例］
　図１４は、ＥＣＵ１００ａによるＦＷ更新制御処理の一例を示すフローチャートである。
　以下、ゲートウェイ３００から上述のステップＳ１２０４でＦＷデータを送信されたＥＣＵがＥＣＵ１００ａである場合にＥＣＵ１００ａが行うＦＷ更新制御処理について、図１４に即して説明する。
　ＥＣＵ１００ａでは、フレーム送受信部１１０がＦＷデータを含むフレームを受信する（ステップＳ１３０１）。
　ＥＣＵ１００ａのＦＷ更新処理部１６０は、フレーム解釈部１２０及びフレーム処理部１５０を介して、ステップＳ１３０１で受信されたフレームに係るＦＷデータを取得し、署名検証部１６３にＦＷデータにおけるＦＷデータ署名を検証させる（ステップＳ１３０２）。
　ＦＷ更新処理部１６０は、ＦＷデータ署名の検証に成功したか否かを判定し（ステップＳ１３０３）、成功しなかった場合にはＦＷデータを破棄して（ステップＳ１３０４）、ファームウェアの更新をしない。
　ＦＷデータ署名の検証に成功した場合には、ＦＷ更新処理部１６０は、ＥＣＵ１００ａにおける起動ＲＯＭの内容であるファームウェアを、ＦＷキャッシュ保持部１６１にコピーすることで保存する（ステップＳ１３０５）。
　次にＦＷ更新処理部１６０は、ＦＷデータにおけるファームウェア（ＦＷ）により起動ＲＯＭ内のファームウェアの更新を行い（ステップＳ１３０６）、ＥＣＵ１００ａのプロセッサを、リセットすることで再起動する（ステップＳ１３０７）。
　ＥＣＵ１００ａでは、起動ＲＯＭからの起動に成功しない場合には、ＦＷキャッシュ保持部１６１の内容による起動がなされるように予め設定されており、ステップＳ１３０７での再起動が成功しない場合に（ステップＳ１３０８）、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアが起動される（ステップＳ１３０９）。そして、その更新前のファームウェアの制御下で、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアを起動ＲＯＭへコピーすることで起動ＲＯＭの内容を更新前の状態に戻す（ステップＳ１３１０）。
　ＥＣＵ１００ａは、ステップＳ１３０７での再起動に成功した場合にはファームウェアの更新に成功した旨を示す更新結果を含むフレームをゲートウェイ３００へ送信し、ステップＳ１３０７での再起動に成功しなかった場合にはステップＳ１３１０の後に、ファームウェアの更新に失敗した旨を示す更新結果を含むフレームをゲートウェイ３００へ送信する（ステップＳ１３１１）。
　［１．１４　実施の形態１の効果］
　実施の形態１に係る車載ネットワークシステム１０では、ゲートウェイ３００が、車載ネットワーク（バス２００ａ、２００ｂ）に接続された全てのＥＣＵについてのＥＣＵの種類等を示すＥＣＵ情報を収集してシステム構成情報として保持する。そしてゲートウェイ３００がシステム構成情報をサーバ５００に通知する。これによりサーバ５００では、そのゲートウェイ３００が搭載された車両の車載ネットワークにおけるＥＣＵの１台以上についてファームウェアの更新が必要か否かを判断でき、更新すべきファームウェアを決定することができる。サーバ５００では、システム構成情報が示すＥＣＵの編成に対応した、同一種類のＥＣＵで編成される環境（現実のＥＣＵによる環境又はＥＣＵのシミュレーションによる環境）で、更新すべきファームウェアの更新に関連した動作検証（ファームウェアの更新が適切に行えるか否かの検証及びその更新後に各ＥＣＵが適切に動作するか否かの検証等）を行う。サーバ５００では、動作検証を終えた後（適切な動作が確認された後）に、更新すべきファームウェアを含むＦＷ更新情報をゲートウェイ３００に送信するので、ゲートウェイ３００は、その車両の各ＥＣＵで構成された環境に相当する環境で動作検証済のファームウェアを取得可能となる。このため、その車両においてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減される。
　（実施の形態２）
　以下、実施の形態１で示した車載ネットワークシステム１０の一部を変形した車載ネットワークシステム１１について説明する。
　本実施の形態に係る車載ネットワークシステム１１では、複数の車両それぞれのＥＣＵのファームウェアの更新を効率的に行うために、サーバが車両モデル毎に対応した車両内の各ＥＣＵでの動作検証を行った後のファームウェアを送信するファームウェア更新方法を用いる。このファームウェア更新方法においては、車両内のゲートウェイ装置では、サーバから送信されたファームウェアについて動作検証に用いられたＥＣＵの編成（各ＥＣＵの種類等）を示す検証済構成情報（検証済ＥＣＵ構成情報）をファームウェアと共に受信し、車両内のＥＣＵの編成と比較することで自車両に対応した動作検証が行われたか否かを確認する方式が用いられる。
　［２．１　車載ネットワークシステム１１の全体構成］
　車載ネットワークシステム１１は、車両に搭載され各種機器に接続されたＥＣＵ１００ａ～１００ｄ、バス２００ａ、２００ｂ、ゲートウェイ３００ａと、車両外のネットワーク４００とサーバ５００ａとを含んで構成される。この車載ネットワークシステム１１は、実施の形態１で示した車載ネットワークシステム１０（図１参照）におけるゲートウェイ３００及びサーバ５００を、ゲートウェイ３００ａ及びサーバ５００ａに置き換えたものである。ここで説明しない点については、車載ネットワークシステム１１は、車載ネットワークシステム１０と同様である。
　［２．２　ゲートウェイ３００ａの構成］
　ゲートウェイ３００ａは、ＥＣＵ１００ａとＥＣＵ１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１００ｃとＥＣＵ１００ｄとが接続されたバス２００ｂと接続されたゲートウェイ装置としての一種のＥＣＵである。ゲートウェイ３００ａは一方のバスから受信したフレームを他方のバスに転送する機能を有し、また、ネットワーク４００を介してサーバ５００ａと通信する機能を有する。
　図１５は、ゲートウェイ３００ａの構成図である。ゲートウェイ３００ａは、実施の形態１で示したゲートウェイ３００におけるＦＷ更新処理部３７０を、ＦＷ更新処理部３７０ａに置き換えたものである。ゲートウェイ３００ａは、図１５に示すように、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、ＦＷ更新処理部３７０ａと、ＥＣＵ情報保持部３７２と、署名検証部３７３と、鍵保持部３７４と、外部通信部３７５と、フレーム生成部３８０と、ＥＣＵ情報取得部３９０とを含んで構成される。これらの各構成要素は、ゲートウェイ３００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ゲートウェイ３００ａの構成要素のうち、上述したゲートウェイ３００（図３参照）と同様の構成要素については図１５で同じ符号を付しており、ここでは説明を省略する。
　ＦＷ更新処理部３７０ａは、外部通信部３７５から通知された更新用のファームウェア等のＦＷデータを含むＦＷ更新情報（図１６参照）の署名検証を署名検証部３７３へ依頼し、署名検証に成功した場合にファームウェアの動作検証が適切になされていることを確認する。動作検証が適切になされていることの確認は、ＥＣＵ情報取得部３９０が取得してＥＣＵ情報保持部３７２に格納した各ＥＣＵのＥＣＵ情報の集合であるシステム構成情報と、ＦＷ更新情報に含まれる検証済ＥＣＵ構成情報とを比較することで行われる。なお、ＦＷ更新処理部３７０ａは、外部通信部３７５からＦＷ更新情報を通知された場合に、ＥＣＵ情報取得部３９０に各ＥＣＵのＥＣＵ情報を収集させてから、動作検証が適切になされていることの確認を行うようにしても良い。検証済ＥＣＵ構成情報は、サーバ５００ａにおいて、ＦＷ更新情報に含まれるファームウェアの動作検証に用いられた環境を構成する各ＥＣＵの種類等を示す情報である。ＥＣＵの種類は例えばＥＣＵ－ＩＤ及びＥＣＵが実装しているファームウェアのバージョン番号等のＦＷバージョンにより特定される。
　ＦＷ更新処理部３７０ａは、システム構成情報が示す、車両に搭載された各ＥＣＵの種類と、サーバ５００ａから受信したＦＷ更新情報の検証済ＥＣＵ構成情報が示す、動作検証に用いられたＥＣＵ各々の種類とを比較し、比較結果が一定条件を満たした場合に、ＦＷ更新情報に含まれる更新用のファームウェアに基づく更新を行わせるための制御を行う。この一定条件は、例えば、システム構成情報が示すＥＣＵの種類全てと検証済ＥＣＵ構成情報が示すＥＣＵの種類全てとが完全に一致することである。ＦＷ更新処理部３７０ａは、更新用のファームウェアに基づく更新を行わせるための制御として、更新用のファームウェアに係るＦＷデータと、更新対象となるＥＣＵが接続されたバスのバス情報とを、フレーム生成部３８０に通知する。なお、更新対象となるＥＣＵが複数ある場合においては、ＦＷ更新情報における検証済ＥＣＵ構成情報に更新順情報が含まれているので、ＦＷ更新処理部３７０ａは、この更新順情報が示す順序に従ってファームウェアの更新を行わせるための制御を行う。
　また、ＦＷ更新処理部３７０ａは、フレーム処理部３５０から通知された更新結果を外部通信部３７５に通知する。また、ＦＷ更新処理部３７０ａは、システム構成情報が示す各ＥＣＵの種類と検証済ＥＣＵ構成情報が示す各ＥＣＵの種類との比較結果が上述の一定条件を満たさなかった場合には、ファームウェアの更新を中止し、そのシステム構成情報を動作検証要求として外部通信部３７５に通知する。動作検証要求には例えば更新しようとしていたファームウェアを特定する情報が付加される。ＦＷ更新処理部３７０ａは、サーバ５００ａで、動作検証要求に応じた動作検証がなされて、サーバ５００ａから上述の一定条件を満たす検証済ＥＣＵ構成情報を含むＦＷ更新情報が送信された場合に、そのＦＷ更新情報を取得してファームウェアの更新を再開する。なお、ＦＷ更新処理部３７０ａは、システム構成情報が示す各種類のＥＣＵを用いて更新用のファームウェアの動作検証がなされた後にその更新用ファームウェア等のＦＷデータを含むＦＷ更新情報を受けて署名検証に成功した場合に漸く該当のＥＣＵのファームウェアの更新のための制御（例えばバスを介してのＥＣＵへのＦＷデータの送信等）を行う更新処理部として機能する。また、ＦＷ更新処理部３７０ａは、ＥＣＵ１００ａ～１００ｄとの通信に必要となるデータをフレーム生成部３８０へ通知する。
　外部通信部３７５は、サーバ５００ａから更新用のファームウェアに係るＦＷデータを含むＦＷ更新情報を受信してＦＷ更新処理部３７０ａへ通知し、ＦＷ更新処理部３７０ａから通知された更新結果を、サーバ５００ａへ送信する。また、外部通信部３７５は、ＦＷ更新処理部３７０ａから通知されたシステム構成情報を動作検証要求としてサーバ５００ａへ送信する。外部通信部３７５は、例えば、ネットワーク４００を介してサーバ５００ａにアクセスするために必要なサーバ５００ａのアドレス情報等を予め保持している。なお、外部通信部３７５は、ファームウェアの更新の要求をサーバ５００ａに対して送信しても良い。
　［２．３　ＦＷ更新情報のフォーマット例］
　図１６は、サーバ５００ａが配信する配信データとしてのＦＷ更新情報のフォーマットの一例を示す。
　サーバ５００ａが配信するＦＷ更新情報は、実施の形態１で示したサーバ５００が配信するＦＷ更新情報（図１０参照）に、検証済ＥＣＵ構成情報Ｆ４０を追加したものである。
　即ち、サーバ５００ａが配信するＦＷ更新情報は、ＦＷ数Ｆ１と、１個以上のＦＷデータ（図１６の例では２つの個別ＦＷデータＦ１０、Ｆ２０）と、検証済ＥＣＵ構成情報Ｆ４０と、ＦＷ更新情報全体に対する署名であるＦＷ更新情報署名Ｆ３０とを含む。
　［２．４　検証済ＥＣＵ構成情報のフォーマット例］
　図１７は、検証済ＥＣＵ構成情報Ｆ４０のフォーマットの一例を示す。
　検証済ＥＣＵ構成情報Ｆ４０は、サーバ５００ａでファームウェアの動作検証に用いられたＥＣＵについての情報である。検証済ＥＣＵ構成情報Ｆ４０は、車両モデルを識別する車種情報と、動作検証に用いられたファームウェアの更新順序（ファームウェアの更新を問題なく行うことができた更新順序）を示す更新順情報と、動作検証に用いられた各ＥＣＵについてのＥＣＵ－ＩＤ、及び、ＥＣＵが実装しているファームウェアのバージョン番号等であるＦＷバージョンとを含む。
　［２．５　サーバ５００ａの構成］
　サーバ５００ａは、ネットワーク４００を介して、ＥＣＵ１００ａ～１００ｄのファームウェアを更新するためのデータであるＦＷ更新情報（図１６参照）を配信する機能を有するコンピュータである。
　サーバ５００ａは、複数の車両それぞれに車載ネットワークに係る複数のＥＣＵが搭載されていることを前提として、サーバ５００は、各種ＥＣＵの製造会社等から提供されたファームウェアを管理し、ファームウェアの動作検証を行い、各車両に更新用ファームウェアを含むＦＷ更新情報を配信する機能を有する。
　図１８は、サーバ５００ａの構成図である。サーバ５００ａは、同図に示すように、データ送受信部５１０ａと、ＦＷ更新制御部５２０ａと、ＦＷ動作検証部５３０ａと、ＥＣＵ情報保持部５３１と、全ＦＷ保持部５３２と、配信データ生成部５７０ａと、ＦＷ保持部５７１と、ＥＣＵ管理情報保持部５７２と、署名生成部５９０と、鍵保持部５９１とを含んで構成される。これらの各構成要素は、サーバ５００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。サーバ５００ａの構成要素のうち、上述したサーバ５００（図８参照）と同様の構成要素については図１８で同じ符号を付しており、ここでは説明を省略する。
　データ送受信部５１０ａは、ゲートウェイ３００ａと通信し、データを送受信する。データ送受信部５１０ａは、ゲートウェイ３００ａからファームウェアの動作検証の要求（動作検証要求）としてシステム構成情報を受信した場合には、ＦＷ更新制御部５２０ａへ通知し、ＦＷ更新制御部５２０ａによりファームウェアの配信のためにＦＷ更新情報を受け取った場合にはＦＷ更新情報をゲートウェイ３００ａへと送信する。データ送受信部５１０ａは、ゲートウェイ３００ａより、ファームウェアの更新結果を受信した場合には、ＦＷ更新制御部５２０ａに通知する。なお、ファームウェアの更新の要求をゲートウェイ３００ａが行う場合においては、データ送受信部５１０ａは、ゲートウェイ３００ａより、ファームウェアの更新の要求を受信した場合には、ＦＷ更新制御部５２０ａに通知する。
　ＦＷ更新制御部５２０ａは、ＥＣＵの製造会社等の端末装置から、ＥＣＵ用の最新（つまり更新用）のファームウェアがサーバ５００ａへアップロードされてファームウェアの登録要求がなされた場合に、ＦＷ動作検証部５３０ａ等と連携して、ファームウェアの動作検証を行ってから登録する処理を行う。動作検証のためにまずＦＷ更新制御部５２０ａは、端末装置からの情報に基づいて、アップロードされた更新用のファームウェアが動作するＥＣＵを特定し、更に、その特定したＥＣＵを搭載（使用）している車両の車両モデルを特定する。ファームウェアの更新が必要なＥＣＵを使用している車両モデルを特定するために、ＦＷ更新制御部５２０ａは、例えば、図１９に例示するようなＥＣＵ車両モデル管理テーブルを保持しており、このＥＣＵ車両モデル管理テーブルを参照することで、ファームウェアの更新が必要なＥＣＵのＥＣＵ－ＩＤに対応する車両モデルを特定する。ＥＣＵ車両モデル管理テーブルは、ＥＣＵ－ＩＤ等と車両モデルとを対応付けたテーブルである。車両モデルは、車両の構造等の識別情報であり、例えば型式等であっても良い。そして、ＦＷ更新制御部５２０ａは、例えば、図２０に例示するような車両モデルＥＣＵ管理テーブルを用いて、ファームウェアの更新が必要なＥＣＵを搭載している車両モデルが使用している全てのＥＣＵを列挙したリストを生成する。車両モデルＥＣＵ管理テーブルは、車両モデル毎にその車両モデルの車両が搭載している全てのＥＣＵについての識別情報（ＥＣＵ－ＩＤ等）を対応付けたテーブルである。ＦＷ更新制御部５２０ａは、ＦＷ動作検証部５３０ａに、この生成したリストを通知し、リストに列挙された全てのＥＣＵで構成される環境を用いて、ファームウェアの更新の動作検証を行わせる。動作検証が終わり問題なく動作することが確認された後に、ＦＷ更新制御部５２０ａは、アップロードされたファームウェアをＦＷ保持部５７１に格納して、端末装置からの情報に基づいてファームウェアと、そのバージョン番号等を示すＦＷバージョンと、対象のＥＣＵの種類を示す情報等とを対応付けて管理する。また、ＦＷ更新制御部５２０ａは、ＦＷ動作検証部５３０ａでの動作検証が終わった後に、配信データ生成部５７０ａに、複数の車両（具体的には各車両のゲートウェイ３００ａ）への配信データとなる、動作検証がなされたファームウェアを含む更新用のファームウェアのパッケージとしてのＦＷ更新情報を生成させる。ＦＷ更新制御部５２０ａは、配信データ生成部５７０ａにより生成されたＦＷ更新情報を、データ送受信部５１０ａにゲートウェイ３００ａへと送信させる。
　また、ＦＷ更新制御部５２０ａは、データ送受信部５１０ａを経由して、ゲートウェイ３００ａからファームウェアの更新の要求を受け取った場合に、ＦＷ動作検証部５３０ａで問題なく動作すると検証された後の、そのゲートウェイ３００ａに対応した更新用のファームウェアを含むＦＷ更新情報を配信データ生成部５７０ａに生成させて、ゲートウェイ３００ａに送信する。また、ＦＷ更新制御部５２０ａは、データ送受信部５１０ａを経由して、ゲートウェイ３００ａから動作検証要求としてシステム構成情報を取得した場合には、更新用のファームウェアについての動作検証をＦＷ動作検証部５３０に依頼し、動作検証がなされた後（つまり問題なく適切に動作することが検証された後）においてＦＷ更新情報をデータ送受信部５１０ａに送信させる。なお、サーバ５００ａがゲートウェイ３００ａに送信するＦＷ更新情報には、必ず、図１６に示すようにＦＷ動作検証部５３０ａで動作検証に用いられたＥＣＵの情報を示す検証済ＥＣＵ構成情報が含まれる。また、ＦＷ更新制御部５２０ａは、ゲートウェイ３００からファームウェアの更新結果を受け取った場合に、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新する。
　ＦＷ動作検証部５３０ａは、ＦＷ更新制御部５２０ａの要求を受けて、ＥＣＵを列挙したリストが示すＥＣＵで構成された動作環境において、或いは、システム構成情報が示す各ＥＣＵと同一種類のＥＣＵで構成された動作環境において、更新用のファームウェア、及び、動作環境における各ＥＣＵのファームウェアが適切（正常）に動作することを検証するためのＦＷ動作検証処理を実行する機能を有する。ＦＷ動作検証処理では、例えば、動作環境のうち更新対象となるＥＣＵに対して更新用のファームウェアを適用する更新の動作、その更新後に動作環境の各ＥＣＵが正常に動作するか否かの動作等が検証される。ＦＷ動作検証処理においては、動作環境としての各種ＥＣＵのハードウェアを用いて更新用のファームウェアの動作検証を行っても良いし、各種ＥＣＵをシミュレートする仮想環境でのシミュレーションにより更新用のファームウェアの動作検証を行っても良い。
　配信データ生成部５７０ａは、ゲートウェイ３００ａに配信するための更新用のファームウェアのパッケージとしてのＦＷ更新情報（図１６参照）を生成し、署名生成部５９０に依頼してＦＷ更新情報に対する署名を生成させる。なお、配信データ生成部５７０ａは、ＦＷ動作検証部５３０から、適切に動作することが検証されたファームウェアの動作環境として用いられた全てのＥＣＵについての情報（ＥＣＵ－ＩＤ、ＦＷバージョン等）を取得して、ＦＷ更新情報における検証済ＥＣＵ構成情報を設定する。
　ＦＷ保持部５７１は、アップロードされて動作検証を経たＥＣＵ用のファームウェアを保持する。
　［２．６　更新用ファームウェアのサーバへの登録に係る動作例］
　図２１は、サーバ５００ａによる更新用ファームウェアの登録に係るＦＷ登録処理を示すフローチャートである。以下、同図に即して、サーバ５００ａによるＦＷ登録処理について説明する。ＦＷ登録処理は、サーバ５００ａの外部の端末装置から、ネットワークを介して、ファームウェアが送信され、ファームウェアの登録要求がなされた場合に実行される。
　まず、サーバ５００ａは、ファームウェアのサーバ５００ａへのアップロードを伴ってなされるファームウェアの登録要求を受信する（ステップＳ２０００）。ファームウェアの登録要求は、例えばファームウェアのバージョン番号等を示すＦＷバージョンと、ファームウェアの対象のＥＣＵのＥＣＵ－ＩＤとを示す情報を含む。
　登録要求を受信したサーバ５００ａは、ファームウェアの更新が必要な車両モデルを特定する（ステップＳ２００１）。即ち、サーバ５００ａは、受信したファームウェアの登録要求に含まれる情報から、更新が必要なＥＣＵのＥＣＵ－ＩＤを取得し、図１９に例示するようなＥＣＵ車両モデル管理テーブルを参照し、登録要求に含まれるＥＣＵ－ＩＤで識別されるＥＣＵを搭載している車両モデルを特定する。
　サーバ５００ａは、ステップＳ２００１で特定した車両モデル毎に、その車両モデルで使用されるＥＣＵで構成される動作環境でのファームウェアの動作検証処理（ステップＳ２００３～Ｓ２００７）を実行する（ステップＳ２００２）。まず、サーバ５００ａは、該当する車両モデルが搭載しているＥＣＵを、車両モデルＥＣＵ管理テーブル（図２０参照）を参照して特定し、特定した全てのＥＣＵの情報（ＥＣＵ－ＩＤ）を列挙したリストを生成する（ステップＳ２００３）。そして、そのリストで示されるＥＣＵを用いて構成される動作環境で、更新するファームウェアについての動作検証（ＦＷ動作検証処理）を行う（ステップＳ２００４）。この動作検証では、更新するファームウェアが該当の車両モデルが搭載するＥＣＵで構成される環境において正常に動作するか、及び、更新の対象のＥＣＵについてファームウェアの更新を行ったときに、他のＥＣＵが正常に動作するかの確認がなされる。
　動作検証後、サーバ５００ａは、その動作検証が成功したかどうかを判断する（ステップＳ２００５）。ステップＳ２００５で動作検証が成功したと判断した場合に、サーバ５００ａは、そのファームウェアをＦＷ保持部５７１に格納して管理する（ステップＳ２００６）。一方、ステップＳ２００５で動作検証に失敗したと判断した場合には、サーバ５００ａは、ステップＳ２０００でファームウェアの登録要求を送信した端末装置に、エラーを通知する（ステップＳ２００７）。
　［２．７　ＦＷ動作検証処理］
　図２２は、サーバ５００ａによるＦＷ動作検証処理を示すフローチャートである。ＦＷ動作検証処理は、主にサーバ５００ａ内のＦＷ動作検証部５３０ａ等によって実行され、上述のＦＷ登録処理（図２１参照）の一部（ステップＳ２００４）の処理であり、また、別途、ゲートウェイ３００ａからシステム構成情報に基づく動作検証要求を受けた場合に行われる処理でもある。ＦＷ動作検証処理は、概ね、ＦＷ更新制御部５２０ａからのリストで示されたＥＣＵ群、或いは、ゲートウェイ３００ａから取得したシステム構成情報で示されたＥＣＵと同一種類のＥＣＵ群を用いて構成した環境で、更新用ファームウェアの動作を検証する処理である。以下、図２２に即して、ＦＷ動作検証処理について説明する。
　ＦＷ動作検証部５３０ａは、受け取ったリストで示されるＥＣＵ－ＩＤ、或いはシステム構成情報が示すＥＣＵ－ＩＤ等を参照して、動作検証に用いられるべき各ＥＣＵの情報をシミュレータ８００に設定する（ステップＳ２１００）。シミュレータ８００は、ＦＷ動作検証部５３０ａにより制御可能なコンピュータであり、各種のＥＣＵをシミュレート可能に構成されている。ＦＷ動作検証部５３０ａ及びシミュレータ８００による構成は、複数のＥＣＵをシミュレートするシミュレーション部として動作する。ステップＳ２１００では、ＦＷ動作検証部５３０ａは、ＥＣＵ情報保持部５３１に保持されている、各種ＥＣＵをシミュレートするための情報（ソフトウェア）、及び、最新のファームウェアに基づいて、動作検証に用いられるべき各ＥＣＵの情報をシミュレータ８００に設定する。なお、ＥＣＵ情報保持部５３１が保持する、各種ＥＣＵをシミュレートするための情報には、例えば、ＥＣＵ内のプロセッサ及びメモリに関する情報（動作周波数、メモリサイズ等）、ＥＣＵ内のＣＡＮコントローラに関する情報（型番、動作周波数等）、ＥＣＵに接続されているバス或いはＥＣＵが用いる通信路に係る情報、ＥＣＵに接続されているセンサやアクチュエータの情報（ロータリーエンコーダ、トルクセンサ、モータ等の情報）等が含まれ得る。これらの情報をシミュレータ８００に設定することで、各車両モデルにおけるＥＣＵや車載ネットワークのシミュレーションが可能となる。
　次に、ＦＷ動作検証部５３０ａは、全ＦＷ保持部５３２に保持されている、各種ＥＣＵに対応する全てのファームウェアとから、シミュレータ８００でシミュレートする各ＥＣＵに設定するファームウェアを選択してそのファームウェアの情報をシミュレータ８００に設定する（ステップＳ２１０１）。なお、ファームウェアを更新する対象のＥＣＵに対しても、更新前のファームウェアを設定する。
　次に、ＦＷ動作検証部５３０ａは、更新用のファームウェアを対象のＥＣＵに設定する更新と、その更新後の各ＥＣＵの動作とをシミュレータ８００によりシミュレーションすることで、更新用のファームウェアの動作検証を行う（ステップＳ２１０２）。これにより、ＦＷ更新制御部５２０ａから通知されたリスト或いはシステム構成情報により特定されるＥＣＵの種類と、同一種類のＥＣＵをシミュレートする動作環境において、シミュレータ８００により、更新用のファームウェアを適用した更新とその後の動作についてシミュレーションが実行され、正常に動作するかについて動作検証が実現される。
　動作検証後、ＦＷ動作検証部５３０ａは、その動作検証が成功したかどうかを判断する（ステップＳ２１０３）。ステップＳ２１０３で動作検証が成功したと判断した場合には、ＦＷ動作検証部５３０ａは、動作検証がなされたファームウェアを全ＦＷ保持部５３２へ格納する（ステップＳ２１０４）。なお、ＦＷ動作検証処理が、ゲートウェイ３００ａからの動作検証要求に基づいて行われる際にはステップＳ２１０４での処理は省略される。
　更に、ＦＷ動作検証部５３０ａは、動作検証に用いた全てのＥＣＵについての情報（ＥＣＵ－ＩＤ、ＦＷバージョン等）を、ＦＷ更新制御部５２０ａに伝え、ＦＷ更新制御部５２０ａでは、配信データ生成部５７０ａにその動作検証に用いられたＥＣＵについての情報を検証済ＥＣＵ構成情報として含み、動作検証がなされたファームウェアのＦＷデータを含むＦＷ更新情報を生成させる。配信データ生成部５７０ａでは、署名生成部５９０により、検証済ＥＣＵ構成情報を含むＦＷ更新情報に対する署名を生成させて、ＦＷ更新情報署名としてＦＷ更新情報に含ませる（ステップＳ２１０５）。また、ステップＳ２１０３で動作検証が成功しなかったと判断した場合には、ＦＷ動作検証部５３０ａは、エラーをＦＷ更新制御部５２０ａに通知し（ステップＳ２１０６）、これを受けてＦＷ更新制御部５２０ａは、ＦＷ更新情報の生成に係る処理を中止する。
　なお、検証済ＥＣＵ構成情報には、各ＥＣＵ自体に関する情報だけではなく、動作検証を行った際の各ＥＣＵの状態に関する情報を含めても良い。この情報の例としては、例えば、現行バージョンのファームウェアから新しいファームウェアへ更新する際の書き換え時間（処理の長さ）や、書き換え後に動作可能になるまでの時間、書き換え処理の負荷、センサ情報や車載ネットワーク上のメッセージが受信できなくなる時間、書き換え中に受信できなくなるメッセージのＩＤ、書き換え後のファームウェアが利用するメモリサイズ等が挙げられる。これらの情報から、ゲートウェイ３００ａや、各ＥＣＵは、どのタイミングでファームウェアの更新処理を行うかを判断しても良い。例えば、夜間等の車両（自動車）を長時間使わないことが予め分かっている時間帯にファームウェアを更新したり、更新に必要な時間を運転者や自動車の管理者等に通知して許可された場合にのみファームウェアを更新したり、運転者や自動車の管理者等に、自動車を使用しない或いは走行させない時間を問い合わせてその時間に収まる分のファームウェアのみを更新したりする等といった判断を行っても良い。これにより、柔軟なファームウェアの更新が実現可能となる。
　［２．８　複数の更新用のファームウェアの検証に係るＦＷ動作検証処理］
　図２３は、サーバ５００ａによる複数のファームウェアの検証に係るＦＷ動作検証処理の一例を示すフローチャートである。
　図２３では、複数のファームウェアの更新の順序（つまり検証順番）が互いに異なる複数の検証順番パターンのそれぞれについて、動作検証を行って検証が成功した検証順番を特定する処理に注目し、その他の処理は省略している。即ち、図２３では、図２２に示したステップＳ２１０１及びステップＳ２１０２の代わりとなる処理を示しているが、その他の処理は省略している。以下、図２３に即して、サーバ５００ａによる複数のファームウェアの検証の動作について説明する。
　まず、ＦＷ動作検証部５３０ａは、図２２に示したステップＳ２１００での処理を行った後に、複数の更新用のファームウェアをどの順番で検証を行うかを示す、検証順番のパターンを生成する（ステップＳ２２００）。ＦＷ動作検証部５３０ａは、生成した検証順番のパターン毎に、ステップＳ２２０１からステップＳ２２０４まで処理を繰り返し実行する。繰り返し実行の各回にステップＳ２２０１～Ｓ２２０４で使用される検証順番のパターンを、「対象検証順番パターン」と称する。
　まず、ＦＷ動作検証部５３０ａは、シミュレータ８００に設定したそれぞれのＥＣＵ上で動作させるためのファームウェアを全ＦＷ保持部５３２から読み出し、シミュレータ８００上のＥＣＵへ設定する（ステップＳ２２０２）。ステップＳ２２０２は、ステップＳ２１０１と同じ処理である。その後、複数ある更新用のファームウェア毎にステップＳ２２０４の処理を繰り返す（ステップＳ２２０３）。このときＦＷ動作検証部５３０ａは、複数ある更新用のファームウェアに対して、対象検証順番パターンで示される順番に従って、ステップＳ２２０４での動作検証をそれぞれの更新用ファームウェアに対して行う。ステップＳ２２０４では、ＦＷ動作検証部５３０ａは、更新用ファームウェアを更新対象のＥＣＵへ設定するようにしてシミュレータ８００を実行し、正常に動作するかを検証する。ＦＷ動作検証部５３０ａは、シミュレータ８００において１台のＥＣＵに１つの更新用ファームウェアを設定する度に、正常に動作するかを検証する。全ての更新用ファームウェアに対して、ＥＣＵへの設定と、動作検証が終了し、全ての動作検証が成功した場合のみ、対象検証順番パターンにおける動作検証が成功したと判断する。
　全ての検証順番パターンにおいて、動作検証が終了すれば、ＦＷ動作検証部５３０ａは、検証した検証順番のパターンの中で、動作検証が成功したと判断した検証順番のパターンがあったかどうかを判断する（ステップＳ２２０５）。ステップＳ２２０５で、動作検証が成功したパターンがあったと判断した場合には、ＦＷ動作検証部５３０ａは、動作検証が成功した検証順番のパターンを更新順情報として記録する（ステップＳ２２０６）。そして、更新順情報等を含み、動作検証に用いた全てのＥＣＵについての情報（ＥＣＵ－ＩＤ、ＦＷバージョン等）を含み、更に、動作検証に成功したことを示す動作検証結果を、ＦＷ更新制御部５２０ａに通知する（ステップＳ２２０７）。一方、ステップＳ２２０５で、動作検証が成功したパターンがなかった場合には、ＦＷ動作検証部５３０ａは、検証失敗をＦＷ更新制御部５２０ａに通知する（ステップＳ２２０８）。
　［２．９　ゲートウェイ３００ａ等によるファームウェアの更新に係る動作例］
　以下、車載ネットワークシステム１１におけるＥＣＵのファームウェアの更新に係る動作について説明する。
　図２４及び図２５は、サーバ５００ａ、ゲートウェイ３００ａ、ＥＣＵ１００ａ、１００ｂ等の装置が連携して行うＥＣＵのファームウェアの更新に係る動作例を示すシーケンス図である。ここでの各シーケンスは、各装置における各処理手順（ステップ）を意味する。ここでは、説明の便宜上、一部のＥＣＵの動作について図示している。この動作例に示すステップＳ２３０１～Ｓ２３０４の手順は、例えば一定日数毎等といった周期で繰り返し実行されることが想定されるが、車載ネットワークに新たなＥＣＵが追加されたことを検知した時に実行されても良いし、車両内のいずれかのＥＣＵへの運転者等の操作に対応して実行されても良い。また、ステップＳ２３０６以降の手順は、例えば、サーバ５００ａが、ファームウェアの登録要求を受けた場合等に開始される。
　ステップＳ２３０１～Ｓ２３０５の手順は、上述したステップＳ１００１～Ｓ１００５（図１１参照）と同一であるので、ここでは説明を省略する。ステップＳ２３０１～Ｓ２３０５での処理により、ゲートウェイ３００ａは、ＥＣＵ情報保持部３７２に、車載ネットワークに接続された各ＥＣＵの最新のＥＣＵ情報の集合であるシステム構成情報（図６参照）を保持することができる。なお、ステップＳ２３０１でのゲートウェイ３００ａがＥＣＵ情報取得用のフレームを送信してＥＣＵ情報の要求を行う処理を省略して、各ＥＣＵが、起動された時、或いは、自機のＥＣＵ情報（ＥＣＵ－ＩＤ、ＦＷバージョン等）に変更があった時等に、ＥＣＵ情報を含むフレームをゲートウェイ３００ａに送信することとしても良い。
　サーバ５００ａの外部の端末装置（例えばＥＣＵの製造会社等の端末装置）から、ＥＣＵ用の最新（つまり更新用）のファームウェアがサーバ５００ａへアップロードされてファームウェアの登録要求がなされた場合に、サーバ５００ａは、そのファームウェアの登録のためのＦＷ登録処理（図２１参照）を行う（ステップＳ２３０６）。これにより、更新用のファームウェアが、対応する車両モデルにおけるＥＣＵ群を用いた環境で動作検証（問題なく適切に動作することの検証）がなされた後にサーバ５００ａのＦＷ保持部５７１に格納されて管理される（つまりサーバ５００ａに登録される）。
　サーバ５００ａは、登録した更新用のファームウェア、ファームウェアの動作検証に用いられた各ＥＣＵを示す検証済ＥＣＵ構成情報等を含むＦＷ更新情報を生成して、ゲートウェイ３００ａへと配信する（ステップＳ２３０７）。これにより、ゲートウェイ３００ａはＦＷ更新情報を受信する。なお、ステップＳ２３０７での配信は、１台の車両のゲートウェイ３００ａに対しての送信であっても良いし、ファームウェアの更新が必要となる複数台の車両それぞれのゲートウェイ３００ａに対しての送信であっても良い。ステップＳ２３０７は、ゲートウェイ３００ａにおいては、サーバ５００ａから、少なくとも１つのＥＣＵを更新対象とする更新用ファームウェアを含むＦＷ更新情報を受信する受信ステップである。
　ゲートウェイ３００ａは、ＦＷ更新情報を受信すると、署名検証部３７３により、ＦＷ更新情報の署名（ＦＷ更新情報署名）を検証する（ステップＳ２３０８）。そして、ゲートウェイ３００ａのＦＷ更新処理部３７０ａは、署名の検証に成功したか否かを判定し（ステップＳ２３０９）、署名の検証に成功しなかった場合にはＦＷ更新情報を破棄し、この場合にはＦＷ更新情報に基づくファームウェアの更新を行わない。
　署名の検証に成功した場合には、ＦＷ更新処理部３７０ａは、ＦＷ更新情報に含まれる検証済ＥＣＵ構成情報と、ＥＣＵ情報保持部３７２が保持するシステム構成情報とを比較する（ステップＳ２３１０）。
　ゲートウェイ３００ａのＦＷ更新処理部３７０ａは、システム構成情報が示す、車両に搭載された複数のＥＣＵ各々の種類と、検証済ＥＣＵ構成情報が示す動作検証に用いられた複数のＥＣＵ各々の種類との比較結果が一定条件を満たすか否か（例えば完全一致するか否か）により、適切な動作検証が行われているか否かを判定する（ステップＳ２３１１）。ＦＷ更新処理部３７０ａは、例えば、比較結果が完全一致する場合には、適切な動作検証が行われていると判定する。サーバ５００ａでファームウェアの登録の際に車両モデルで使用されている各ＥＣＵを用いたファームウェアの動作検証を行っているが、例えば、ゲートウェイ３００ａが搭載された車両が、その車両モデルのＥＣＵからＥＣＵを交換し、或いは、追加している場合には、ステップＳ２３１０での比較の結果が一致しない。
　ゲートウェイ３００ａは、適切な動作検証が行われていないと判定した場合には、ＥＣＵ情報保持部３７２が保持する、車載ネットワークに接続された全てのＥＣＵの編成をＥＣＵ情報の集合によって表すシステム構成情報を、動作検証要求として、サーバ５００ａに送信する（ステップＳ２３１２）。動作検証要求には、例えば、更新用として配信されたファームウェアに関する情報が付加される。これに対応してサーバ５００ａは動作検証要求としてのシステム構成情報等を受信する。ステップＳ２３１２は、ゲートウェイ３００ａが、システム構成情報を外部装置としてのサーバ５００ａに送信する動作検証要求送信ステップである。
　サーバ５００ａは、動作検証要求を受けると、ＦＷ動作検証部５３０ａにより、システム構成情報に応じた環境で、配信したファームウェアの動作検証に係るＦＷ動作検証処理を行う（ステップＳ２３１３）。ステップＳ２３１２及びステップＳ２３１３は、サーバ５００ａにおいては、システム構成情報を受信して、そのシステム構成情報が示す全ての種類と同じ種類の、複数のＥＣＵを用いて更新用のファームウェアの動作検証を行う動作検証ステップである。そして、ファームウェアの動作検証後（適切に動作が行われることが確認された後）にサーバ５００ａは、ステップＳ２３１３での動作検証に用いられた各ＥＣＵに関する情報である検証済ＥＣＵ構成情報を含むＦＷ更新情報を生成して、動作検証要求の送信元である１台の車両のゲートウェイ３００ａに送信する（ステップＳ２３１４）。ステップＳ２３１４は、動作検証が行われた後に、ＦＷ更新情報を送信するファームウェア更新情報送信ステップである。ファームウェア更新情報送信ステップでは、動作検証に用いた複数のＥＣＵ各々の種類等を示す検証済ＥＣＵ構成情報を、ＦＷ更新情報に含めて送信し得る。これにより、ゲートウェイ３００ａは再びＦＷ更新情報を受信する。
　ゲートウェイ３００ａは、ステップＳ２３１４でサーバ５００ａが送信したＦＷ更新情報を受信すると、署名検証部３７３により、ＦＷ更新情報の署名（ＦＷ更新情報署名）を検証する（ステップＳ２３１５）。ステップＳ２３１５～Ｓ２３１８での処理はステップＳ２３０８～Ｓ２３１１での処理と同様である。
　ゲートウェイ３００ａは、システム構成情報が示すＥＣＵ各々の種類と、検証済ＥＣＵ構成情報が示すＥＣＵ各々の種類との比較結果が一定条件を満たすか否か（例えば完全一致するか否か）により、適切な動作検証が行われているか否かを判定し（ステップＳ２３１８）、適切な動作検証が行われていないと判定した場合には所定の異常処理を行ってファームウェアの更新を行わない。
　ゲートウェイ３００ａは、ステップＳ２３１８又はステップＳ２３１１で適切な動作検証が行われていると判定した場合には、主としてＦＷ更新処理部３７０ａにより、更新対象に該当するＥＣＵと連携して、ＦＷ更新制御処理（図１３、図１４参照）を行う（ステップＳ２３１９）。ステップＳ２３１７～Ｓ２３１９等は、ゲートウェイ３００ａが、システム構成情報が示す各種類のＥＣＵを用いて更新用ファームウェアの動作検証がなされた後にその更新用ファームウェアに基づく該当のＥＣＵのファームウェアの更新のための制御を行う更新処理ステップである。
　ゲートウェイ３００ａは、ステップＳ２３１９でのＦＷ更新制御処理を終えた後に、ファームウェアの更新結果をサーバ５００ａに送信する（ステップＳ２３２０）。これにより、サーバ５００ａは更新結果を受信する。ファームウェアの更新結果は、例えば更新に成功したか否かを示す情報であり、その情報は、例えば更新後におけるファームウェアに係るＦＷバージョンを含んでも良いし、例えばシステム構成情報を含んでも良い。なお、ゲートウェイ３００ａは、ステップＳ２３０９、Ｓ２３１６で署名の検証に失敗した場合、或いは、ステップＳ２３１８で適切な動作検証が行われていないと判定した場合にも、ファームウェアの更新失敗を示す更新結果をサーバ５００ａに送信しても良い。
　サーバ５００ａは、ファームウェアの更新結果を受信した場合に、そのファームウェアの更新後の状態を表すように、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新する（ステップＳ２３２１）。
　［２．１０　ファームウェアの動作検証の環境］
　以下、サーバ５００ａのＦＷ動作検証部５３０ａによるＦＷ動作検証処理に用いられるシミュレータ８００が行うファームウェアの動作検証のためのシミュレーションについて説明する。
　図２６は、ＦＷ動作検証処理でシミュレータ８００によりファームウェアの動作検証に用いられる仮想環境のソフトウェア構成の一例を示す。
　シミュレータ８００において動作するソフトウェアは、同図に示すように、仮想マシンモニタ８０１と、仮想マシン８０２、８０３、８０４、８０５と、仮想ハードウェア８１０、８２０、８３０、８４０と、汎用ＯＳ（オペレーティングシステム）８１１、８２１と、ＲＴＯＳ（リアルタイムオペレーティングシステム）８３１と、ファームウェア８４１と、アプリ（アプリケーションプログラム）Ａ８１２と、アプリＢ８１３と、アプリＣ８１４と、アプリＤ８２２と、アプリＥ８３２とを含む。
　シミュレータ８００は、コンピュータであり、プロセッサ上でソフトウェア（仮想マシンモニタ８０１等）を実行する。
　仮想マシンモニタ８０１は、その上で互いに独立して動作するように仮想マシン８０２～８０５を制御する仮想マシン制御機能、その仮想マシンに対してメモリやＣＰＵ等のハードウェアリソースを割り当てて管理するリソース管理機能、仮想マシンからの要求に従ってデバイスへアクセスするデバイスアクセス機能、仮想マシンをスケジューリングするスケジューリング機能等を有する。
　仮想マシン８０２～８０５はそれぞれ、仮想ハードウェア、ＯＳ、アプリ、或いは、ファームウェアを含んで構成され、仮想マシンモニタ８０１によりそれぞれ独立に実行される。
　仮想ハードウェア８１０、８２０、８３０、８４０は、それぞれの仮想マシンに仮想的にハードウェアの機能を提供し、また、ＩＰＬ（Initial Program Loader）、ＢＩＯＳ（Basic Input/Output System）を含み得る。
　汎用ＯＳ８１１は、アプリ（アプリＡ８１２、アプリＢ８１３、アプリＣ８１４）をメモリ上にロードして実行する、或いは、その各アプリをメモリ上から削除（アンロード）する機能を有し、各アプリに対して、ＣＡＮプロトコルによるネットワーク通信機能を提供する。汎用ＯＳ８２１も同様である。
　ＲＴＯＳ８３１は、リアルタイム性を重視するアプリを動作させるためのＯＳである。
　アプリＡ８１２、アプリＢ８１３、アプリＣ８１４、アプリＤ８２２、アプリＥ８３２は、カーナビゲーション機能、運転支援機能、ステアリング制御機能、エンジン制御機能、ブレーキ制御機能、センサ情報（トルク、角度、速度、回転数等）の取得機能等といった各種の自動車用の機能を有する。これらの自動車用の機能群のそれぞれは、１つのアプリにより実行されても良いし、複数のアプリで実行されていても良い。
　ファームウェア８４１は、ＯＳを必要としない機能を動作させるソフトウェア等である。なお、ファームウェア８４１は、ＯＳを含んでいても良く、他のアプリの動作環境となって他のアプリの実行を制御する機能を有するものであっても良い。
　なお、図２６で示した汎用ＯＳ８１１、８２１或いはＲＴＯＳ８３１上で動作するアプリの数は、一例に過ぎず、より多くのアプリが動作しても良い。また、汎用ＯＳが動作する仮想マシンが２つと、ＲＴＯＳが動作する仮想マシンが１つ、ファームウェアが動作する仮想マシンが１つの場合を図示しているが、これは一例に過ぎない。仮想環境を、例えば、ファームウェアが動作する仮想マシンだけで構成しても良いし、ファームウェアが動作する仮想マシンとＲＴＯＳが動作する仮想マシンとだけで構成しても良い。
　そして、シミュレータ８００では、１つのＥＣＵを、上述の仮想マシン８０２～８０５等といった１つの仮想マシンでシミュレートする。例えば、仮想マシンモニタ８０１上で仮想マシン８０５を複数（動作環境を構成するＥＣＵの数分）生成して動作させ、それぞれの仮想マシン８０５の仮想ハードウェア８４０で１つのＥＣＵのハードウェアの動作をシミュレートし、例えば、ファームウェア８４１はそのＥＣＵに実装されているファームウェアと同一の内容とする。例えば、仮想マシンモニタ８０１は、その上で動作する複数の仮想ハードウェア間で、ＥＣＵ間でのバスを介した通信がシミュレートされるように構成される。
　ＦＷ動作検証部５３０ａは、シミュレータ８００に、ファームウェアの動作検証のための動作環境を構成する各ＥＣＵを設定する場合に、それぞれのＥＣＵと同じ動作をするように仮想マシンを設定する。このときに、既にＥＣＵの動作をシミュレートするように設定された仮想マシン（言わば仮想ＥＣＵ）を仮想マシンモニタ８０１上へロードすることで、動作環境を構成するＥＣＵを設定しても良い。
　［２．１１　実施の形態２の効果］
　実施の形態２に係る車載ネットワークシステム１１では、サーバ５００ａへファームウェアが登録される場合に、車両モデルのＥＣＵ構成に対応した環境で、事前に動作検証を行う。そして、サーバ５００ａは、動作検証を経て登録されたファームウェアについて動作検証に用いられたＥＣＵに関する情報を含む検証済ＥＣＵ構成情報とそのファームウェアとを含めたＦＷ更新情報を各車両のゲートウェイ３００ａに配信する。これにより、動作検証が実施されているファームウェアが配信されるので、各車両のＥＣＵにおいて適切なファームウェアの更新が可能となる。また、動作検証に失敗したファームウェアをサーバ５００ａに登録しないので、正常に動作しないファームウェアを配信する可能性を低減できる。また、車両モデル毎のＥＣＵの構成で、動作検証を行うため、特定の車両モデルでのみ発生する不具合等を事前に検証することが可能となる。
　また、ある車両のゲートウェイ３００ａでは、受信したＦＷ更新情報における検証済ＥＣＵ構成情報と車両内の全てのＥＣＵの情報であるシステム構成情報との比較により、その車両に適した動作環境で適切にファームウェアの更新に係る動作検証がなされたか否かを確認して、適切な動作検証がなされていなければ動作検証要求をサーバ５００ａに対して行う。これにより、実際に車両のＥＣＵを更新する前に、ファームウェアの更新により悪影響が起きないかを検証させることができる。そして、ゲートウェイ３００ａは、その車両に適した動作環境で動作検証が行われた更新用のファームウェアをサーバ５００ａから受信できるようになる。このため、車両に搭載されたＥＣＵが故障して別のＥＣＵに交換された場合、新規にＥＣＵが追加された場合等においても、ゲートウェイ３００ａが動作検証済みのファームウェアを取得でき、適切にＥＣＵのファームウェアの更新が可能になる。即ち、その車両においてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減される。
　（他の実施の形態）
　以上のように、本開示に係る技術の例示として実施の形態１、２を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
　（１）上記実施の形態では、外部通信部３７５（外部通信機能）を有するゲートウェイ３００、３００ａが、車両外のネットワーク４００を介してサーバ５００、５００ａと通信したが、これは一例に過ぎない。例えば、ゲートウェイ３００、３００ａは、外部との通信機能を持つ別のＥＣＵ（例えばヘッドユニット等）を介して、サーバ５００、５００ａと通信することとしても良い。ヘッドユニットは、比較的高性能なプロセッサを備えるＥＣＵの一種であり、自動車のインパネ（インストルメントパネル）等に設けられた液晶ディスプレイ等の表示装置を含み、車両の運転者への報知等を行い得る装置である。なお、車載ネットワークには、ＯＢＤ２（On-Board Diagnostics２）等と呼ばれる、診断ツール等の外部装置と通信するインタフェースである診断ポートが存在し、ＥＣＵの診断に利用される。そこで、ゲートウェイ３００、３００ａは、例えば、サーバ５００、５００ａと通信可能でありかつ診断ポートと接続する外部装置と通信することで間接的にサーバ５００、５００ａと通信することとしても良い。これらの場合において、ゲートウェイ３００、３００ａは必ずしも車両外部と通信するための外部通信機能を有さなくても良く、他のＥＣＵ或いは外部装置を介してゲートウェイ３００、３００ａとサーバ５００、５００ａとの間では、システム構成情報等を伴う動作検証要求或いはＦＷ更新要求、及び、ＦＷ更新情報等の授受が可能となる。
　（２）上記実施の形態で示した各ＥＣＵのファームウェアのバージョン番号等を示すＦＷバージョンは、サーバ５００、５００ａ、ゲートウェイ３００、３００ａで管理される例を示したが、別のＥＣＵ、診断ツール等といった他の機器において管理されても良い。
　（３）上記実施の形態では、ＣＡＮプロトコルに従って通信するネットワーク通信システムの例として車載ネットワークを示した。本開示に係る技術は、車載ネットワークに限定されるものではなく、ロボット、産業機器等のネットワークその他、車載ネットワーク以外のＣＡＮプロトコルに従って通信するネットワーク通信システムにも適用可能である。また、ＣＡＮプロトコルは、オートメーションシステム内の組み込みシステム等に用いられるＣＡＮＯｐｅｎ、或いは、ＴＴＣＡＮ（Time-Triggered CAN)、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルも包含する広義の意味のものと扱われるべきである。また、上記実施の形態では、ＣＡＮプロトコルに基づいてバスでファームウェアに関するデータ（フレーム）を送受信する例を示したが、別のプロトコルを適用しても良く、ファームウェアに係るデータを通信するための通信路及び通信方式として任意のものを利用可能である。
　（４）上記実施の形態では、データ（ＦＷデータ、ＦＷ更新情報等）の完全性を担保するために、データに対して署名を付した構成を用いたが、更に、秘匿性を担保するためにデータの暗号化を行っても良い。署名用の鍵と暗号化用の鍵とを別個の鍵としても良い。
　（５）上記実施の形態では、ＦＷ更新情報に対する署名の生成とＦＷデータに対する署名の生成とに際して、同じ鍵を使用したが、それぞれ別の鍵を用いても良い。例えば、配信データとしてのＦＷ更新情報の全体に対する署名（ＦＷ更新情報署名）は、自動車メーカが持つ鍵を用いて生成し、個別のＦＷデータに対する署名（ＦＷデータ署名）は、そのＦＷデータに係るファームウェアを実装するＥＣＵの製造会社（或いはそのファームウェアの製造会社）が持つ鍵を用いて生成されることとしても良い。なお、上記実施の形態では、各ＥＣＵがＦＷデータ署名の検証を行う例を示したが、ＥＣＵはＦＷデータ署名の検証を行わずに、ゲートウェイ３００、３００ａが予め検証用の鍵を保持してＦＷデータ署名の検証を行うこととしても良い。
　（６）上記実施の形態２におけるゲートウェイ３００ａは、複数のファームウェアを更新する必要がある場合に、サーバ５００ａがＦＷ更新情報に含ませた、ファームウェアの更新順に関する情報（更新順情報）を受け、更新順情報に従った順に更新することとしたが、必ずしも更新順に更新しなくても良い。また、実施の形態１におけるサーバ５００が更新順情報をＦＷ更新情報に含ませて送信して、ゲートウェイ３００がその更新順情報に従った順で、ステップＳ１２０４でのＦＷデータの送信を行うことで、順にファームウェアを更新させても良い。
　（７）上記実施の形態におけるサーバ５００、５００ａの処理の一部は、サーバ５００、５００ａと通信可能でサーバ５００、５００ａと離れた他の装置（コンピュータ等）により実行されても良い。
　（８）上記実施の形態におけるサーバ５００、５００ａで、ファームウェアの動作検証に失敗した場合において、動作環境を構成したＥＣＵの編成（ＥＣＵの組み合わせ）に関する情報（不具合情報）を管理しても良い。この場合に、サーバ５００、５００ａは、不具合情報をゲートウェイ３００、３００ａへ通知すると、ゲートウェイ３００、３００ａは、車両内のＥＣＵの構成が、この不具合情報で示される構成と一致した場合にファームウェアを更新すべきでないと判断可能になる。
　（９）上記実施の形態におけるＦＷ動作検証部５３０は、複数のファームウェアを更新する場合に、検証順番のパターンを生成し、動作検証が成功した検証順番を記録するとしたが、これに限定されるものではなく、複数のファームウェアを同時に更新し、動作検証を行っても良いし、全ての検証順番のパターンで動作検証が失敗した場合に、同時に検証するパターンを生成し、動作検証を行っても良い。
　（１０）上記実施の形態２におけるゲートウェイ３００ａで、ファームウェアの適切な動作検証が行われているか否かを判定する例として、システム構成情報が示す、車両に搭載された複数のＥＣＵ各々の種類と、検証済ＥＣＵ構成情報が示す動作検証に用いられた複数のＥＣＵ各々の種類との比較結果が例えば完全一致するか否かという一定条件を満たすか否かを判定することを示した。しかし、これは一例に過ぎず、例えば、システム構成情報が示すＥＣＵ全ての種類を、検証済ＥＣＵ構成情報が示す動作検証に用いられた複数のＥＣＵの種類が包含している場合に、適切な動作検証が行われていると扱う方式等を用いても良い。これらを合わせて、システム構成情報が示すＥＣＵ全ての種類のＥＣＵと同じ種類が、検証済ＥＣＵ構成情報に示されている場合に適切な動作検証が行われていると扱う方式等を用いても良い。そして、例えば、ゲートウェイ３００ａのＦＷ更新処理部３７０ａが、システム構成情報が示す全ての種類と同じ種類が検証済構成情報に示されていないことを確認した場合に、ＦＷ更新情報に含まれる更新用のファームウェアに基づく更新を抑止して、動作検証要求としてシステム構成情報を外部装置としてのサーバ５００ａに送信させる制御を行うこととしても良い。
　（１１）上記実施の形態では、ＥＣＵの種類が、ＥＣＵ－ＩＤ（ＥＣＵの識別情報）とＦＷバージョン（ファームウェアのバージョンの識別情報）とにより特定可能である例を示したが、ＥＣＵ－ＩＤだけで特定されるものをＥＣＵの種類と規定することも可能である。なお、ＥＣＵ－ＩＤは、個々のＥＣＵを識別可能であると共に、ＥＣＵの種類を区別し得る情報である例を示したが、ＥＣＵ－ＩＤが、ＥＣＵの個体それぞれを識別できないがＥＣＵの種類を識別可能な情報であることとしても良い。
　（１２）上記実施の形態１で示したサーバ５００のＦＷ動作検証部５３０においても、上記実施の形態２示したシミュレータ８００によるファームウェアの動作検証を行っても良い。また、サーバ５００、５００ａが、ある車両における車載ネットワークに接続される各ＥＣＵと同じ種類のＥＣＵ（つまりシステム構成情報が示す各種類のＥＣＵ）を用いて更新用のファームウェアの動作検証を行う他に、その車両のゲートウェイ３００、３００ａが、動作検証を行う方式を用いることもできる。即ち、ゲートウェイ３００、３００ａは、実施の形態２で示したシミュレータ８００と同様のシミュレータを含むシミュレーション部を備え、自ら、システム構成情報が示す各種類のＥＣＵをシミュレートする動作環境において、サーバ５００、５００ａから受信したファームウェアの動作検証を行うこととしても良い。この場合には、ゲートウェイ３００、３００ａは、問題なく動作することを検証した後に、ファームウェアの更新を、更新対象に該当するＥＣＵに行わせる。例えば、ゲートウェイ３００ａのＦＷ更新処理部３７０ａは、システム構成情報が示す全ての種類と同じ種類が検証済構成情報に示されていないことを確認した場合に、システム構成情報が示す全ての種類と同じ種類の各ＥＣＵを用いた更新用のファームウェアの動作のシミュレーションを、ゲートウェイ３００ａにおけるシミュレーション部に行わせ、そのシミュレーションによる動作検証がなされた後に更新用ファームウェアに基づく更新を行わせるように制御を行うこととしても良い。なお、ゲートウェイ３００、３００ａがファームウェアの動作検証を行う場合において、実際にゲートウェイ３００、３００ａが車載ネットワークから受信したメッセージ（フレーム）を、シミュレータにより構成される動作環境（仮想環境）内の車載ネットワークへ送信する構成にしても良い。この場合には、ゲートウェイ３００、３００ａが受信したメッセージを仮想環境において、更新用のファームウェアを実行しない仮想マシン（仮想ＥＣＵ）から送信しても良い。また、ファームウェアの更新対象である１台以上のＥＣＵそれぞれが、シミュレート８００のような構成のコンピュータにおいて動作する仮想マシンとして実現されていても良い。
　（１３）上記実施の形態で示した更新用のファームウェア（バイナリデータ）は、ＥＣＵに実装されるファームウェアの全体であってもその一部であっても良い。更新用のファームウェアがＥＣＵに実装されるファームウェアの一部である場合において、ＥＣＵ内の既存のファームウェアの一部に上書きされる。この場合には、更新用のファームウェアは、差分データ（バイナリデータ）と、どの部分に適用されるかを示す情報（例えばアドレス情報等）とを含んで構成され得る。この場合において、ゲートウェイ３００、３００ａ或いは更新対象に該当するＥＣＵにおいて、差分データと既存のファームウェアとをマージしてから、ＥＣＵの起動ＲＯＭにおけるファームウェアの置き換えを行っても良い。
　（１４）上記実施の形態で示した各種処理の手順（例えば図１１～図１４、図２１～図２５に示した所定手順等）の実行順序は、必ずしも、上述した通りの順序に制限されるものではなく、開示の要旨を逸脱しない範囲で、実行順序を入れ替えたり、複数の手順を並列に行ったり、その手順の一部を省略したりすることができる。
　（１５）上記実施の形態におけるゲートウェイ３００、３００ａその他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
　（１６）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（１７）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしても良い。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしても良い。
　（１８）本開示の一態様としては、例えば図１１、図１２、図２４、図２５等に示す処理手順の全部又は一部を含むファームウェア更新方法であるとしても良い。また、この方法をコンピュータにより実現するコンピュータプログラム（制御プログラム）であるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。例えば、ファームウェア更新方法における受信ステップ、取得ステップ、更新処理ステップを含むファームウェア更新処理を実行するための制御プログラムであることとしても良い。また、本開示の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
　（１９）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示は、ＣＡＮに従う車載ネットワークに接続されたＥＣＵのファームウェアの更新を適切に行うために利用可能である。
　１０　車載ネットワークシステム
　１００ａ～１００ｄ　電子制御ユニット（ＥＣＵ）
　１０１　エンジン
　１０２　ブレーキ
　１０３　ドア開閉センサ
　１０４　窓（ウィンドウ）開閉センサ
　１１０，３１０　フレーム送受信部
　１２０，３２０　フレーム解釈部
　１３０，３３０　受信ＩＤ判断部
　１４０，３４０　受信ＩＤリスト保持部
　１５０，３５０　フレーム処理部
　１６０，３７０，３７０ａ　ＦＷ更新処理部
　１６１　ＦＷキャッシュ保持部
　１６３，３７３　署名検証部
　１６４，３７４，５９１　鍵保持部
　１７０　データ取得部
　１８０　フレーム生成部
　２００ａ，２００ｂ　バス
　３００，３００ａ　ゲートウェイ（ゲートウェイ装置）
　３６０　転送ルール保持部
　３７２，５３１　ＥＣＵ情報保持部
　３７５　外部通信部
　３８０　フレーム生成部
　３９０　ＥＣＵ情報取得部
　４００　ネットワーク
　５００，５００ａ　サーバ
　５１０，５１０ａ　データ送受信部
　５２０，５２０ａ　ＦＷ更新制御部
　５３０，５３０ａ　ＦＷ動作検証部
　５３２　全ＦＷ保持部
　５７０，５７０ａ　配信データ生成部
　５７１　ＦＷ保持部
　５７２　ＥＣＵ管理情報保持部
　５９０　署名生成部
　８００　シミュレータ
　８０１　仮想マシンモニタ
　８０２～８０５　仮想マシン
　８１０，８２０，８３０，８４０　仮想ハードウェア
　８４１　ファームウェア

Claims (14)

  1. 　車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、
    　前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、
    　前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得部と、
    　前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理部とを備える
    　ゲートウェイ装置。
  2. 　前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、
    　前記更新処理部は、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信部に受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１記載のゲートウェイ装置。
  3. 　前記システム構成情報が示す、前記バスに接続される前記複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別し、
    　前記検証済構成情報が示す、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別する
    　請求項２記載のゲートウェイ装置。
  4. 　前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていることを確認した場合に、前記比較結果が前記一定条件を満たしたとして前記制御を行う
    　請求項２又は３記載のゲートウェイ装置。
  5. 　前記ゲートウェイ装置は更に、前記システム構成情報を前記外部装置に送信する送信部を備え、
    　前記更新処理部は、前記送信部が前記システム構成情報を前記外部装置に送信した後に、前記外部装置が当該システム構成情報を参照して複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行った後に送信した前記ファームウェア更新情報を、前記受信部により受信した場合に、当該ファームウェア更新情報の前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１記載のゲートウェイ装置。
  6. 　前記システム構成情報は、前記バスに接続される前記複数の電子制御ユニット各々について、前記種類を特定するための、当該電子制御ユニットについての識別情報及び当該電子制御ユニットが実装しているファームウェアのバージョンの識別情報を含む
    　請求項５記載のゲートウェイ装置。
  7. 　前記ゲートウェイ装置は、前記システム構成情報を前記外部装置に送信する機能を有する送信部を備え、
    　前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、
    　前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記更新用ファームウェアに基づく前記更新を抑止して前記送信部に前記システム構成情報を前記外部装置に送信させるよう制御する
    　請求項１～５のいずれか一項に記載のゲートウェイ装置。
  8. 　前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、
    　前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、
    　前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１～４のいずれか一項に記載のゲートウェイ装置。
  9. 　前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、
    　前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１記載のゲートウェイ装置。
  10. 　前記バスに接続された前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、
    　前記更新処理部は、前記更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための前記制御として、前記バスを介して前記該当の電子制御ユニットへの前記更新用ファームウェアの送信を行う
    　請求項１～９のいずれか一項に記載のゲートウェイ装置。
  11. 　電子制御ユニットのファームウェアを更新するためのファームウェア更新方法であって、
    　車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置が、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、
    　前記ゲートウェイ装置が、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、
    　前記ゲートウェイ装置が、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含む
    　ファームウェア更新方法。
  12. 　前記ファームウェア更新方法は更に、
    　前記外部装置が、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、
    　前記外部装置が、前記動作検証ステップで動作検証に用いた複数の電子制御ユニット各々の種類を示す検証済構成情報を、前記ファームウェア更新情報に含めて送信するファームウェア更新情報送信ステップとを含み、
    　前記更新処理ステップは、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信ステップで受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１１記載のファームウェア更新方法。
  13. 　前記ファームウェア更新方法は更に、
    　前記ゲートウェイ装置が、前記取得ステップで取得した前記システム構成情報を前記外部装置に送信する動作検証要求送信ステップと、
    　前記外部装置が、前記動作検証要求送信ステップで送信された前記システム構成情報を受信して、当該システム構成情報が示す全ての種類と同じ種類の、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、
    　前記外部装置が、前記動作検証ステップで動作検証が行われた後に前記ファームウェア更新情報を送信するファームウェア更新情報送信ステップとを含み、
    　前記更新処理ステップは、前記動作検証要求送信ステップでの前記システム構成情報の送信の後に前記受信ステップで前記ファームウェア更新情報が受信された場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行う
    　請求項１１記載のファームウェア更新方法。
  14. 　車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続された、プロセッサを備えるゲートウェイ装置にファームウェア更新処理を実行させるための制御プログラムであって、
    　前記ファームウェア更新処理は、
    　前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、
    　前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、
    　前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含む
    　制御プログラム。
PCT/JP2016/003082 2015-09-14 2016-06-27 ゲートウェイ装置、ファームウェア更新方法及び制御プログラム WO2017046981A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP23182025.9A EP4239469A3 (en) 2015-09-14 2016-06-27 Gateway device, firmware update method, and control program
CN201680021023.8A CN107533491B (zh) 2015-09-14 2016-06-27 网关装置、固件更新方法以及存储介质
CN202110284790.0A CN112953820B (zh) 2015-09-14 2016-06-27 网关装置、固件更新方法以及存储介质
EP16845861.0A EP3352080B1 (en) 2015-09-14 2016-06-27 Gateway device, firmware update method, and control program
US15/878,787 US10735260B2 (en) 2015-09-14 2018-01-24 Gateway device, firmware update method, and recording medium
US16/915,187 US11223525B2 (en) 2015-09-14 2020-06-29 Gateway device, firmware update method, and recording medium

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562218074P 2015-09-14 2015-09-14
US62/218,074 2015-09-14
JP2016-109537 2016-05-31
JP2016109537A JP6723829B2 (ja) 2015-09-14 2016-05-31 ゲートウェイ装置、ファームウェア更新方法及び制御プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/878,787 Continuation US10735260B2 (en) 2015-09-14 2018-01-24 Gateway device, firmware update method, and recording medium

Publications (1)

Publication Number Publication Date
WO2017046981A1 true WO2017046981A1 (ja) 2017-03-23

Family

ID=58390741

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/003082 WO2017046981A1 (ja) 2015-09-14 2016-06-27 ゲートウェイ装置、ファームウェア更新方法及び制御プログラム

Country Status (5)

Country Link
US (2) US10735260B2 (ja)
EP (2) EP4239469A3 (ja)
JP (3) JP6723829B2 (ja)
CN (2) CN107533491B (ja)
WO (1) WO2017046981A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110659039A (zh) * 2018-06-29 2020-01-07 株式会社斯巴鲁 车辆
WO2020032197A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー センター装置，配信パッケージの生成方法及び配信パッケージ生成用プログラム
WO2020032200A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
JP2020027620A (ja) * 2018-08-10 2020-02-20 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
CN111433773A (zh) * 2017-11-30 2020-07-17 Abb瑞士股份有限公司 对变电站中的网关的更新
JP2020173597A (ja) * 2019-04-10 2020-10-22 株式会社デンソー 電子制御装置
CN113141300A (zh) * 2020-01-17 2021-07-20 大陆汽车有限公司 用于机动车辆的传送数据帧的通信网关
JP2021105924A (ja) * 2019-12-27 2021-07-26 本田技研工業株式会社 車両及びソフトウェア更新方法
CN114151933A (zh) * 2021-12-07 2022-03-08 青岛海信日立空调系统有限公司 多联机空调机组升级系统、升级控制器及升级方法

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6723829B2 (ja) * 2015-09-14 2020-07-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、ファームウェア更新方法及び制御プログラム
JP6414568B2 (ja) * 2016-06-09 2018-10-31 株式会社デンソー 車両用装置
JP6493381B2 (ja) * 2016-12-26 2019-04-03 トヨタ自動車株式会社 車載通信システム
US10825266B2 (en) * 2017-01-10 2020-11-03 Cummins Inc. Wireless ECU configuration updating
JP2018160208A (ja) * 2017-03-24 2018-10-11 日立オートモティブシステムズ株式会社 車載制御装置、及び、プログラム更新ソフトウェア
JP2018160207A (ja) * 2017-03-24 2018-10-11 日立オートモティブシステムズ株式会社 車載制御装置、及び、プログラム更新ソフトウェア
US10802818B2 (en) * 2017-05-02 2020-10-13 Dell Products L.P. Automatic firmware updates
JP6798413B2 (ja) * 2017-05-09 2020-12-09 株式会社オートネットワーク技術研究所 車載中継装置、制御プログラム及びメモリ共有方法
US11194562B2 (en) * 2017-05-19 2021-12-07 Blackberry Limited Method and system for hardware identification and software update control
US20200117799A1 (en) * 2017-06-23 2020-04-16 Robert Bosch Gmbh Graphical user interface tool for configuring a vehicle's intrusion detection system
JP7094670B2 (ja) * 2017-07-03 2022-07-04 矢崎総業株式会社 設定装置及びコンピュータ
US10387139B2 (en) 2017-07-25 2019-08-20 Aurora Labs Ltd. Opportunistic software updates during select operational modes
US10796500B2 (en) * 2017-08-01 2020-10-06 Ford Global Technologies, Llc Electronic communication modules provisioning for smart connectivity
JP6773617B2 (ja) 2017-08-21 2020-10-21 株式会社東芝 更新制御装置、ソフトウェア更新システムおよび更新制御方法
JP6915500B2 (ja) * 2017-11-06 2021-08-04 トヨタ自動車株式会社 更新システム、電子制御装置、更新管理装置、及び更新管理方法
JP7006335B2 (ja) * 2018-02-06 2022-01-24 トヨタ自動車株式会社 車載通信システム、車載通信方法、およびプログラム
JP7095300B2 (ja) * 2018-02-12 2022-07-05 株式会社デンソー 車両用制御システム
JP7139616B2 (ja) * 2018-02-13 2022-09-21 株式会社デンソー 操舵制御装置
JP7047444B2 (ja) 2018-02-16 2022-04-05 トヨタ自動車株式会社 車両制御装置、電子制御ユニット、制御方法、制御プログラム、車両、ｏｔａマスタ、システム及びセンタ
JP7081223B2 (ja) 2018-03-07 2022-06-07 トヨタ自動車株式会社 マスタ装置、マスタ、ソフトウェアの整合性を確認するための方法及びプログラム、車両
JP7331989B2 (ja) * 2018-03-07 2023-08-23 トヨタ自動車株式会社 ソフトウェアの整合性を確認する装置及びこれを備えた車両、ソフトウェアの整合性を確認する方法及びプログラム
JP7311245B2 (ja) 2018-03-07 2023-07-19 トヨタ自動車株式会社 マスタ装置、マスタ、制御方法、プログラム及び車両
US10909050B2 (en) * 2018-03-19 2021-02-02 Toyota Jidosha Kabushiki Kaisha Gateway apparatus and communication method
US11560240B2 (en) 2018-03-29 2023-01-24 Airbus Operations Gmbh Aircraft area having a textile display, aircraft passenger seat having a textile display, and aircraft including an aircraft area
EP3546355B1 (en) * 2018-03-29 2021-07-07 Airbus Operations GmbH Aircraft area having a textile display, and an aircraft including such an aircraft area
JP7049900B2 (ja) * 2018-04-18 2022-04-07 株式会社日立製作所 ソフトウェア管理システム、ゲートウェイ装置、保守装置、サーバ装置、及びソフトウェア管理システムの制御方法
EP3572939A1 (en) * 2018-05-25 2019-11-27 TTTech Auto AG Method, device and real-time network for highly-integrated automotive systems
JP7225596B2 (ja) * 2018-07-30 2023-02-21 トヨタ自動車株式会社 プログラム更新システム、プログラム更新サーバーおよび車両
JP7003976B2 (ja) * 2018-08-10 2022-01-21 株式会社デンソー 車両用マスタ装置、更新データの検証方法及び更新データの検証プログラム
JP7346956B2 (ja) * 2018-08-10 2023-09-20 株式会社デンソー 車両用プログラム書換えシステム、車両用マスタ装置、進捗状態の同期制御方法及び進捗状態の同期制御プログラム
US11163549B2 (en) 2018-08-10 2021-11-02 Denso Corporation Vehicle information communication system
WO2020032195A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー 車両情報通信システム
WO2020032196A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー 車両情報通信システム
US11579865B2 (en) 2018-08-10 2023-02-14 Denso Corporation Vehicle information communication system
JP6973450B2 (ja) * 2018-08-10 2021-12-01 株式会社デンソー 車両用マスタ装置、インストールの指示判定方法及びインストールの指示判定プログラム
WO2020032199A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー 車両情報通信システム
CN109189422A (zh) * 2018-08-13 2019-01-11 北京新能源汽车股份有限公司 一种电子控制单元的远程升级方法及装置
JPWO2020059033A1 (ja) * 2018-09-19 2020-12-17 三菱電機株式会社 車載装置、更新決定方法及び更新決定プログラム
CN109388418A (zh) * 2018-10-09 2019-02-26 郑州云海信息技术有限公司 带外刷新box节点服务器的固件和fru的方法及系统
KR101960724B1 (ko) * 2018-10-15 2019-03-21 (주)케이디티콘트롤 시뮬레이터를 이용한 원격지 디바이스의 펌웨어 관리 방법
JP7042408B2 (ja) * 2018-10-15 2022-03-28 株式会社オートネットワーク技術研究所 車載更新装置、更新処理プログラム、プログラムの更新方法及び車載更新システム
JP7124627B2 (ja) * 2018-10-16 2022-08-24 株式会社オートネットワーク技術研究所 車載更新装置、更新処理プログラム及び、プログラムの更新方法
US10732959B2 (en) 2018-10-17 2020-08-04 Ford Global Technologies, Llc Pre and post update vehicle bus traffic fingerprinting
US12110034B2 (en) * 2018-11-28 2024-10-08 Autonetworks Technologies, Ltd. Monitoring apparatus, monitoring program, and monitoring method
CN109582324B (zh) * 2018-12-03 2022-02-18 郑州云海信息技术有限公司 一种ic烧录方法及板卡
CN113168314B (zh) * 2018-12-04 2023-11-10 三菱电机株式会社 更新管理装置、更新管理系统及更新管理方法
CN109358888A (zh) * 2018-12-18 2019-02-19 郑州云海信息技术有限公司 服务器固件升级方法、装置、系统及计算机可读存储介质
CN111381844A (zh) * 2018-12-27 2020-07-07 中兴通讯股份有限公司 更新车辆ecu固件的方法及装置
WO2020145334A1 (ja) * 2019-01-10 2020-07-16 日本電気通信システム株式会社 車両用制御装置、車両用ネットワーク設計装置、通信方法及びプログラム
CN109754511B (zh) * 2019-01-14 2021-05-14 深圳前海微众银行股份有限公司 购物车设备固件更新方法、系统、平台、网关及存储介质
US11487649B2 (en) 2019-02-15 2022-11-01 Hitachi Astemo, Ltd. Verification device and method for verifying a program using a tree structure of common and non-common test scenario phases
JP2020154540A (ja) 2019-03-19 2020-09-24 キオクシア株式会社 メモリシステム及び制御システム
JP7123843B2 (ja) * 2019-03-29 2022-08-23 日立Astemo株式会社 演算装置、判定方法
CN117896698A (zh) 2019-08-01 2024-04-16 住友电气工业株式会社 中继装置、车辆通信系统、通信方法及记录介质
CN110928561B (zh) * 2019-08-09 2023-04-07 中国第一汽车股份有限公司 车辆控制器软件版本管理方法、装置、车辆和存储介质
CN112394969B (zh) * 2019-08-14 2023-04-28 华为技术有限公司 一种补丁发布的方法、服务器及终端设备
JP2021047742A (ja) * 2019-09-19 2021-03-25 株式会社ノーリツ 温水システム、温水装置およびサーバ
JP7298427B2 (ja) * 2019-10-07 2023-06-27 トヨタ自動車株式会社 プログラム更新システムおよびプログラム更新方法
JP7502014B2 (ja) * 2019-10-31 2024-06-18 トヨタ自動車株式会社 車両用制御装置、プログラム更新方法、及びプログラム更新システム
JP2021077169A (ja) * 2019-11-11 2021-05-20 株式会社オートネットワーク技術研究所 車載システム、中継装置、車載装置及びプログラム置換方法
CN111147492A (zh) * 2019-12-26 2020-05-12 国汽(北京)智能网联汽车研究院有限公司 一种数据安全传输系统、方法及装置
US11100230B1 (en) 2019-12-31 2021-08-24 Management Services Group, Inc. Modular embedded chassis with firmware for removably coupled compute devices, and methods and systems for the same
CN111552491A (zh) * 2020-04-22 2020-08-18 北京小马智行科技有限公司 移动载体的中转设备的固件升级的方法、装置与存储介质
US11150889B1 (en) 2020-05-29 2021-10-19 Honeywell International Inc. Usage profile based remote firmware upgrade for fire alarm system gateway
JP2021189715A (ja) * 2020-05-29 2021-12-13 株式会社メガチップス 情報処理システム、サーバ装置、情報処理装置及び動作制御装置
FR3111447A1 (fr) * 2020-06-16 2021-12-17 Psa Automobiles Sa Gestion de versions de logiciels embarqués à partir d’une empreinte informatique
CN112181453A (zh) * 2020-09-11 2021-01-05 上海润欣科技股份有限公司 固件升级方法、装置及存储介质
US11836476B2 (en) * 2020-11-27 2023-12-05 Denso Corporation Electronic control unit, software update method, software update program product and electronic control system
CN112817620B (zh) * 2021-01-08 2023-09-26 日立楼宇技术（广州）有限公司 控制器终端程序更新方法、装置、计算机设备和存储介质
JP7487681B2 (ja) * 2021-02-08 2024-05-21 トヨタ自動車株式会社 車両用制御装置
JP7419287B2 (ja) * 2021-03-26 2024-01-22 本田技研工業株式会社 車両プログラム更新管理システム、及び車両プログラム更新管理方法
JP7484791B2 (ja) * 2021-03-30 2024-05-16 トヨタ自動車株式会社 Ｏｔａマスタ、更新制御方法、及び更新制御プログラム
DE102021203435A1 (de) * 2021-04-07 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Aktualisieren eines Betriebsprogramms zum Betrieb und/oder zur Ansteuerung einer Fahrzeugkomponente eines Fahrzeugs, insbesondere eines Lenksystems des Fahrzeugs
JP7355061B2 (ja) * 2021-04-26 2023-10-03 トヨタ自動車株式会社 センタ、ｏｔａマスタ、システム、配信方法、配信プログラム、及び車両
JP2022170464A (ja) * 2021-04-28 2022-11-10 株式会社オートネットワーク技術研究所 車載装置、情報処理方法及びプログラム
US11789751B2 (en) * 2021-06-10 2023-10-17 EMC IP Holding Company LLC System and method for estimation of time to completion for heterogeneous application upgrades in a customer environment
KR102510167B1 (ko) * 2021-08-03 2023-03-15 시큐리티플랫폼 주식회사 플래시 메모리를 이용한 펌웨어 대용량 업데이트 개선 방법 및 이를 실행하기 위한 기록매체에 저장된 컴퓨터 프로그램
JP7552543B2 (ja) 2021-09-16 2024-09-18 トヨタ自動車株式会社 情報処理システム、情報処理方法、プログラム
DE102021210453A1 (de) 2021-09-21 2023-03-23 Robert Bosch Gesellschaft mit beschränkter Haftung Steuergerät, system und verfahren zum konfigurieren von geräten eines feldbusnetzwerks
KR102450917B1 (ko) * 2021-11-08 2022-10-06 재단법인 경북아이티융합 산업기술원 이중 ecu 기반 차량용 무선 업데이트 시스템
CN114253185A (zh) * 2021-12-03 2022-03-29 深圳元戎启行科技有限公司 车辆配置方法、装置、车载控制系统以及无人驾驶车辆
US11934820B2 (en) 2021-12-10 2024-03-19 Dell Products L.P. System and method for managing a model for solving issues relating to application upgrades in a customer environment
US11960873B2 (en) 2021-12-10 2024-04-16 Dell Products L.P. System and method for managing a model for solving issues using a set of actions performed on the client environment
CN114422358B (zh) * 2022-01-26 2024-01-30 中国农业银行股份有限公司 Api网关配置更新方法及设备
CN114475481A (zh) * 2022-03-24 2022-05-13 四川野马汽车股份有限公司 一种微型电动汽车零部件配置信息的传输系统及方法
WO2023199395A1 (ja) * 2022-04-12 2023-10-19 三菱電機株式会社 車両ソフトウェア管理装置および車両ソフトウェア管理システム
US20240012961A1 (en) * 2022-07-08 2024-01-11 X Development Llc Cloud-based electrical grid component validation
CN115442234A (zh) * 2022-08-25 2022-12-06 东风悦享科技有限公司 一种实现l4级别车辆ecu灰度ota升级的e2e系统及方法
US20240118880A1 (en) * 2022-10-11 2024-04-11 Ford Global Technologies, Llc Transmission of authentication keys
US20240168747A1 (en) * 2022-11-17 2024-05-23 Mercedes-Benz Group AG System, device and/or method for updating vehicle subsystem configurations
US12032473B2 (en) 2022-11-28 2024-07-09 Dell Products Moving an application context to the cloud during maintenance
US12088672B1 (en) * 2023-06-12 2024-09-10 Infineon Technologies Ag Efficient and secured access to in-vehicle end nodes across a vehicle fleet

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107803A (ja) * 2003-09-30 2005-04-21 Hitachi Ltd システム更新方法、および、それを実行するための計算機システム
JP2012091755A (ja) * 2010-10-29 2012-05-17 Honda Motor Co Ltd 車両用プログラム書換えシステム
JP2015103163A (ja) * 2013-11-27 2015-06-04 株式会社オートネットワーク技術研究所 プログラム更新システム及びプログラム更新方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050216902A1 (en) * 2004-03-23 2005-09-29 General Motors Corporation Method and system for vehicle software configuration update management
US7366589B2 (en) 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
JP4692231B2 (ja) * 2005-11-04 2011-06-01 株式会社デンソー 車両用の電子制御装置
JP2009053820A (ja) * 2007-08-24 2009-03-12 Nec Electronics Corp 階層型キャッシュメモリシステム
JP2009053920A (ja) * 2007-08-27 2009-03-12 Auto Network Gijutsu Kenkyusho:Kk 車載用電子制御ユニットのプログラム管理システム
US8892699B2 (en) * 2008-12-31 2014-11-18 Schneider Electric USA, Inc. Automatic firmware updates for intelligent electronic devices
JP2010273181A (ja) 2009-05-22 2010-12-02 Denso Corp 車載デバイス管理システム
WO2012043167A1 (ja) * 2010-09-27 2012-04-05 日本電気株式会社 情報処理システム、車両のチェック方法、及び、車両のチェックプログラム
EP2469416A1 (en) * 2010-12-21 2012-06-27 Robert Bosch GmbH Test bed for an AUTOSAR software component and method for checking an AUTOSAR software component
KR101348843B1 (ko) * 2011-10-28 2014-01-07 주식회사 현대케피코 가상화 및 이중화를 이용한 전자제어유닛의 리프로그래밍 방법
CN103377057B (zh) * 2012-04-20 2016-05-25 上海通用汽车有限公司 一种刷新用户车辆电子控制模块的软件的系统和方法
JP6064529B2 (ja) * 2012-11-07 2017-01-25 株式会社リコー 情報処理装置
US9323546B2 (en) * 2014-03-31 2016-04-26 Ford Global Technologies, Llc Targeted vehicle remote feature updates
US10387141B2 (en) * 2014-12-30 2019-08-20 Visteon Global Technologies, Inc. Upgradable firmware system
JP6723829B2 (ja) * 2015-09-14 2020-07-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、ファームウェア更新方法及び制御プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107803A (ja) * 2003-09-30 2005-04-21 Hitachi Ltd システム更新方法、および、それを実行するための計算機システム
JP2012091755A (ja) * 2010-10-29 2012-05-17 Honda Motor Co Ltd 車両用プログラム書換えシステム
JP2015103163A (ja) * 2013-11-27 2015-06-04 株式会社オートネットワーク技術研究所 プログラム更新システム及びプログラム更新方法

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111433773A (zh) * 2017-11-30 2020-07-17 Abb瑞士股份有限公司 对变电站中的网关的更新
CN111433773B (zh) * 2017-11-30 2023-04-11 Abb瑞士股份有限公司 对变电站中的网关的更新
JP2020004193A (ja) * 2018-06-29 2020-01-09 株式会社Ｓｕｂａｒｕ 車両
CN110659039A (zh) * 2018-06-29 2020-01-07 株式会社斯巴鲁 车辆
CN110659039B (zh) * 2018-06-29 2024-07-30 株式会社斯巴鲁 车辆
US11036487B2 (en) 2018-06-29 2021-06-15 Subaru Corporation Vehicle
JP2020027620A (ja) * 2018-08-10 2020-02-20 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
JP2020027624A (ja) * 2018-08-10 2020-02-20 株式会社デンソー センター装置，配信パッケージの生成方法及び配信パッケージ生成用プログラム
WO2020032200A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
US11900092B2 (en) 2018-08-10 2024-02-13 Denso Corporation Center device, distribution package generation method and distribution package generation program
US11886857B2 (en) 2018-08-10 2024-01-30 Denso Corporation Center device, specification data generation method and computer program product for generating specification data
WO2020032197A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー センター装置，配信パッケージの生成方法及び配信パッケージ生成用プログラム
JP7408937B2 (ja) 2018-08-10 2024-01-09 株式会社デンソー センター装置，配信パッケージの生成方法及び配信パッケージ生成用プログラム
JP7408936B2 (ja) 2018-08-10 2024-01-09 株式会社デンソー センター装置，諸元データの生成方法及び諸元データ生成用プログラム
JP2020173597A (ja) * 2019-04-10 2020-10-22 株式会社デンソー 電子制御装置
JP7302250B2 (ja) 2019-04-10 2023-07-04 株式会社デンソー 電子制御装置
JP2021105924A (ja) * 2019-12-27 2021-07-26 本田技研工業株式会社 車両及びソフトウェア更新方法
US11670117B2 (en) 2019-12-27 2023-06-06 Honda Motor Co., Ltd. Vehicle and software update method
JP7033116B2 (ja) 2019-12-27 2022-03-09 本田技研工業株式会社 車両及びソフトウェア更新方法
CN113141300B (zh) * 2020-01-17 2023-05-23 大陆汽车科技有限公司 用于机动车辆的传送数据帧的通信网关
CN113141300A (zh) * 2020-01-17 2021-07-20 大陆汽车有限公司 用于机动车辆的传送数据帧的通信网关
CN114151933A (zh) * 2021-12-07 2022-03-08 青岛海信日立空调系统有限公司 多联机空调机组升级系统、升级控制器及升级方法

Also Published As

Publication number Publication date
JP2022009195A (ja) 2022-01-14
US20200344116A1 (en) 2020-10-29
EP3352080A1 (en) 2018-07-25
CN112953820B (zh) 2023-03-24
EP4239469A3 (en) 2023-11-08
JP2023126316A (ja) 2023-09-07
CN107533491A (zh) 2018-01-02
CN107533491B (zh) 2021-04-06
US11223525B2 (en) 2022-01-11
EP4239469A2 (en) 2023-09-06
CN112953820A (zh) 2021-06-11
JP6723829B2 (ja) 2020-07-15
JP6964163B2 (ja) 2021-11-10
JP2017059210A (ja) 2017-03-23
US10735260B2 (en) 2020-08-04
EP3352080A4 (en) 2018-11-14
JP2020173832A (ja) 2020-10-22
US20180152341A1 (en) 2018-05-31
EP3352080B1 (en) 2023-09-13

Similar Documents

Publication Publication Date Title
JP6964163B2 (ja) ゲートウェイ装置、ファームウェア更新方法及び制御プログラム
JP7071574B2 (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
WO2017046980A1 (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
JP6216730B2 (ja) ソフト更新装置、ソフト更新方法
US11914987B2 (en) Master update agent and distributed update agent architecture for vehicles
JPWO2020059033A1 (ja) 車載装置、更新決定方法及び更新決定プログラム
CN103365684B (zh) 更新方法和多域嵌入式系统
JP2022187646A (ja) Ｏｔａマスタ、システム、方法、プログラム、及び車両
JP7559684B2 (ja) Ｏｔａマスタ、システム、方法、プログラム、及び車両
JP2022187162A (ja) Ｏｔａマスタ、システム、方法、プログラム、及び車両
WO2021166603A1 (ja) 情報処理装置、プログラム更新システム、及びプログラム更新方法
JP2023002161A (ja) センタ、ｏｔａマスタ、方法、プログラム、及び車両
Harris Novell NetWare 6.5 Administrator's Handbook

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: 16845861

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE