Gateway device, in-vehicle network system, and firmware update method
6 claims: 3 independent, 3 dependent
- 1車両に搭載された複数の電子制御ユニットのそれぞれの機能を有す る複 数の仮想マシンが通信に用いるネットワークに接続されたゲートウェイ装置であって、前記複数の仮想マシンのうち1つの仮想マシンを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、前記更新用ファームウェアの適用対象の仮想マシンの所定情報に基づいて前記仮想マシンが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記仮想マシンにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記仮想マシン以外で実行されるように制御する制御部とを備え、前記所定情報は、前記更新用ファームウェアの適用対象の仮想マシンの処理能力を示し、前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、前記制御部は、前記仮想マシンが処理能力を有し、前記仮想マシンのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記仮想マシンで実行させ、前記仮想マシンが処理能力を有していない場合、または、前記仮想マシンが処理能力を有していても前記仮想マシンのプロセッサの負荷が一定程度より高い場合、前記複数の仮想マシンのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する1つの仮想マシンを選定して、選定した前記仮想マシンに前記所定処理を実行させるように制御する、ゲートウェイ装置。
- 2前記所定情報は、前記更新用ファームウェアの適用対象の仮想マシンの前記所定処理の実行機能を有するか否かを示し、前記制御部は、前記更新用ファームウェアの適用対象の仮想マシンが、前記所定処理の実行機能を有し、前記仮想マシンのプロセッサの負荷が一定程度以下の場合に前記所定処理を前記仮想マシンで実行させ、前記所定処理の実行機能を有さない場合、または、前記仮想マシンが前記所定処理の実行機能を有していても前記仮想マシンのプロセッサの負荷が一定程度より高い場合、前記所定処理を前記仮想マシン以外で実行させるように制御する、請求項1記載のゲートウェイ装置。
- 3前記所定処理を前記仮想マシン以外で実行させるように制御することは、前記所定処理を前記ゲートウェイ装置において実行するように制御することである請求項1又は2に記載のゲートウェイ装置。
- 4前記複数の仮想マシンは、Controller Area Network(CAN)プロトコルに従って前記ネットワークを介して通信を行う請求項1~3のいずれか一項に記載のゲートウェイ装置。
- 51以上のネットワークを介して通信する複数の仮想マシン が動作するコンピュータ と前記ネットワークに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、前記ゲートウェイ装置は、前記複数の仮想マシンのうち1つの仮想マシンを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、前記更新用ファームウェアの適用対象の仮想マシンの所定情報に基づいて前記仮想マシンが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記仮想マシンにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記仮想マシン以外で実行されるように制御する制御部とを有し、前記所定情報は、前記更新用ファームウェアの適用対象の仮想マシンの処理能力を示し、前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、前記制御部は、前記仮想マシンが処理能力を有し、前記仮想マシンのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記仮想マシンで実行させ、前記仮想マシンが処理能力を有していない場合、または、前記仮想マシンが処理能力を有していても前記仮想マシンのプロセッサの負荷が一定程度より高い場合、前記複数の仮想マシンのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する1つの仮想マシンを選定して、選定した前記仮想マシンに前記所定処理を実行させるように制御する、車載ネットワークシステム。
- 61以上のネットワークを介して通信する複数の仮想マシン が動作するコンピュータ を備える車載ネットワークシステムにおいて用いられるファームウェア更新方法であって、前記複数の仮想マシンのうち1つの仮想マシンを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得ステップと、前記更新用ファームウェアの適用対象の仮想マシンの所定情報に基づいて前記仮想マシンが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記仮想マシンにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記仮想マシン以外で実行されるように制御する制御ステップとを含み、前記所定情報は、前記更新用ファームウェアの適用対象の仮想マシンの処理能力を示し、前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、前記制御ステップは、前記仮想マシンが処理能力を有し、前記仮想マシンのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記仮想マシンで実行させ、前記仮想マシンが処理能力を有していない場合、または、前記仮想マシンが処理能力を有していても前記仮想マシンのプロセッサの負荷が一定程度より高い場合、前記複数の仮想マシンのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する1つの仮想マシンを選定して、選定した前記仮想マシンに前記所定処理を実行させるように制御する、ファームウェア更新方法。
Independent claims6
245 paragraphs, as filed
The present invention relates to a virtual machine monitor, software and a method for updating firmware.
In recent years, systems inside automobiles have been equipped with many devices called electronic control units (ECUs). The network that connects these ECUs is called an in-vehicle network. There are many standards for in-vehicle networks. One of the most mainstream standards for in-vehicle networks is the CAN (Controller Area Network) standard defined in ISO11898-1.
In CAN, the communication path consists of two buses, and the ECUs connected to the buses are called nodes. Each node connected to the buses sends and receives messages called frames. The transmitting node that sends a frame applies a voltage to the two buses, generating a potential difference between the buses, and transmits a value of "1" called recessive and a value of "0" called dominant. If multiple transmitting nodes transmit recessive and dominant at exactly the same time, the dominant is transmitted with priority. If the receiving node detects an abnormality in the format of the received frame, it transmits a frame called an error frame. An error frame is a frame that notifies the transmitting node and other receiving nodes of an abnormality in the frame by transmitting 6 consecutive dominant bits.
In addition, in CAN, there are no identifiers that indicate the destination or source, and the transmitting node attaches an ID called a message ID to each frame before transmitting (i.e., sends a signal to the bus), and each receiving node receives only frames with a predetermined ID (i.e., reads the signal from the bus).In addition, the CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) method is used, and when multiple nodes are transmitting simultaneously, arbitration is performed by message ID, and frames with smaller message ID values are transmitted preferentially.
In the case where multiple ECUs work in cooperation with each other by sending and receiving messages via a bus, if one ECU starts updating its firmware (FW), it may affect the running of the vehicle due to the inability to send and receive messages during the update. In this regard, a technique is known that updates firmware only when it is determined that the firmware of the ECU can be updated, such as when the vehicle is stopped, based on information indicating the vehicle's state (see Patent Document 1).
<p><patcit num="1"><text>JP 2010-273181 A</text></patcit></p>
<p>However, although the technique of Patent Document 1 executes firmware updates at appropriate (eg, safe) times, it is not useful in cases where the ECU does not have a function for performing some processing required for firmware updates.</p><p>Therefore, the present invention provides a virtual machine monitor or the like that enables an ECU that does not execute processing required for firmware update to properly update its firmware.</p>
<p>In order to solve the above problems, a gateway device according to one aspect of the present invention has the functions of a plurality of electronic control units mounted on a vehicle.<u style="Single">Complex</u>and a control unit that determines whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is applied, and if the predetermined condition is satisfied, causes the virtual machine to execute a predetermined process related to the firmware update, and if the predetermined condition is not satisfied, controls so that the predetermined process is executed by a virtual machine other than the virtual machine, wherein the predetermined information indicates a processing capability of the virtual machine to which the update firmware is applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and the control unit causes the virtual machine to execute the predetermined process when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, and selects one of the multiple virtual machines that is not a target of the update firmware and has a key for verifying the signature, and controls so that the selected virtual machine executes the predetermined process.</p><p>In addition, an in-vehicle network system according to one aspect of the present invention includes a plurality of virtual machines that communicate with each other via one or more networks.<u style="Single">Computers that run</u>and a gateway device connected to the network, wherein the gateway device has an acquisition unit that acquires firmware update information including update firmware targeted for application to one of the plurality of virtual machines, and a control unit that determines whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is to be applied, and if the predetermined condition is satisfied, causes the virtual machine to execute a predetermined process related to the firmware update, and if the predetermined condition is not satisfied, controls so that the predetermined process is executed by a virtual machine other than the virtual machine, the predetermined information indicating a processing capability of the virtual machine to which the update firmware is to be applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and the control unit causes the virtual machine to execute the predetermined process when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, and selects one of the plurality of virtual machines that is not a target of the update firmware and has a key for verifying the signature, and controls so that the selected virtual machine executes the predetermined process.</p><p>Further, a firmware update method according to one aspect of the present invention includes:<u style="Single">Computers that run</u>a control step of determining whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is applied, and, if the predetermined condition is satisfied, having the virtual machine execute a predetermined process related to the firmware update, and, if the predetermined condition is not satisfied, controlling so that the predetermined process is executed by a virtual machine other than the virtual machine, wherein the predetermined information indicates a processing capability of the virtual machine to which the update firmware is applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and, in the control step, when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, having the predetermined process executed by the virtual machine, and when the virtual machine does not have processing capability or when the virtual machine has processing capability but a processor load of the virtual machine is higher than a certain level, selecting one virtual machine from the multiple virtual machines that is not a target of the update firmware and that has a key for verifying the signature, and controlling so that the selected virtual machine executes the predetermined process.</p>
<p>According to the present invention, since the processing required for firmware update is executed (acted on behalf of) an ECU that does not execute the processing, it becomes possible to appropriately update the firmware in that ECU.</p>
<figref num="1">1 is a diagram showing an overall configuration of an in-vehicle network system according to a first embodiment.</figref><figref num="2">FIG. 2 is a diagram illustrating a format of a data frame defined by the CAN protocol.</figref><figref num="3">FIG. 2 is a configuration diagram of a gateway according to the first embodiment.</figref><figref num="4">FIG. 13 is a diagram showing an example of a reception ID list.</figref><figref num="5">FIG. 2 is a diagram illustrating an example of a transfer rule used by a gateway.</figref><figref num="6">FIG. 4 is a diagram showing an example of a list of predetermined information (ECU information) according to the first embodiment. </figref><figref num="7">1 is a configuration diagram of an ECU having a signature verification function and a firmware (FW) cache function according to a first embodiment. FIG.</figref><figref num="8">1 is a configuration diagram of an ECU having a signature verification function according to a first embodiment.</figref><figref num="9">1 is a configuration diagram of an ECU having a FW cache function according to a first embodiment. FIG.</figref><figref num="10">FIG. 1 is a configuration diagram of an ECU having neither a signature verification function nor a FW cache function according to a first embodiment.</figref><figref num="11">FIG. 2 is a configuration diagram of a server according to the first embodiment.</figref><figref num="12">FIG. 4 is a diagram illustrating an example of vehicle ECU management information held by a server.</figref><figref num="13">4 is a diagram showing an example of a format of firmware (FW) update information according to the first embodiment; FIG.</figref><figref num="14">FIG. 4 is a sequence diagram showing an example of an operation related to distribution of FW update information in the first embodiment. </figref><figref num="15">5 is a flowchart showing an example of a FW update control process by the gateway according to the first embodiment.</figref><figref num="16">5 is a flowchart showing an example of a FW update control process performed by an ECU having a signature verification function and a FW cache function according to the first embodiment. </figref><figref num="17">5 is a flowchart showing an example of a FW update control process performed by an ECU having a signature verification function according to the first embodiment. </figref><figref num="18">5 is a flowchart showing an example of a FW update control process performed by an ECU having a FW cache function according to the first embodiment. </figref><figref num="19">6 is a flowchart showing an example of a FW update control process by an ECU that does not have a signature verification function and a FW cache function according to the first embodiment. </figref><figref num="20">FIG. 4 is a sequence diagram showing an example of operation related to a FW update GW (gateway) proxy process in the first embodiment.</figref><figref num="21">FIG. 11 is a diagram showing an overall configuration of an in-vehicle network system according to a second embodiment. </figref><figref num="22">11 is a flowchart showing an example of a FW update control process by a gateway according to the second embodiment. </figref><figref num="23">13 is a flowchart showing an example of a signature verification ECU proxy process performed by a gateway according to the second embodiment.</figref><figref num="24">FIG. 11 is a sequence diagram showing an example of operation related to ECU proxy processing for FW update in the second embodiment. </figref><figref num="25">FIG. 2 is a diagram illustrating an example of a software configuration of a virtual environment realized by a computer as an example of the configuration of an ECU.</figref>
In order to solve the above problems, a gateway device according to one aspect of the present invention has the functions of a plurality of electronic control units mounted on a vehicle.<u style="Single">Complex</u>and a control unit that determines whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is applied, and if the predetermined condition is satisfied, causes the virtual machine to execute a predetermined process related to the firmware update, and if the predetermined condition is not satisfied, controls so that the predetermined process is executed by a virtual machine other than the virtual machine, wherein the predetermined information indicates a processing capability of the virtual machine to which the update firmware is applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and the control unit causes the virtual machine to execute the predetermined process when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, and selects one of the multiple virtual machines that is not a target of the update firmware and has a key for verifying the signature, and controls so that the selected virtual machine executes the predetermined process.
In addition, an in-vehicle network system according to one aspect of the present invention includes a plurality of virtual machines that communicate with each other via one or more networks.<u style="Single">Computers that run</u>and a gateway device connected to the network, wherein the gateway device has an acquisition unit that acquires firmware update information including update firmware targeted for application to one of the plurality of virtual machines, and a control unit that determines whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is to be applied, and if the predetermined condition is satisfied, causes the virtual machine to execute a predetermined process related to the firmware update, and if the predetermined condition is not satisfied, controls so that the predetermined process is executed by a virtual machine other than the virtual machine, the predetermined information indicating a processing capability of the virtual machine to which the update firmware is to be applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and the control unit causes the virtual machine to execute the predetermined process when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, and selects one of the plurality of virtual machines that is not a target of the update firmware and has a key for verifying the signature, and controls so that the selected virtual machine executes the predetermined process.
Further, a firmware update method according to one aspect of the present invention includes:<u style="Single">Computers that run</u>a control step of determining whether the virtual machine satisfies a predetermined condition based on predetermined information of the virtual machine to which the update firmware is applied, and, if the predetermined condition is satisfied, having the virtual machine execute a predetermined process related to the firmware update, and, if the predetermined condition is not satisfied, controlling so that the predetermined process is executed by a virtual machine other than the virtual machine, wherein the predetermined information indicates a processing capability of the virtual machine to which the update firmware is applied, and the predetermined process is a process of verifying a signature attached to the update firmware in the firmware update information, and, in the control step, when the virtual machine has processing capability and a processor load of the virtual machine is equal to or lower than a certain level, having the predetermined process executed by the virtual machine, and when the virtual machine does not have processing capability or when the virtual machine has processing capability but a processor load of the virtual machine is higher than a certain level, selecting one virtual machine from the multiple virtual machines that is not a target of the update firmware and that has a key for verifying the signature, and controlling so that the selected virtual machine executes the predetermined process.
A gateway device according to one aspect of the present invention is a gateway device connected to a bus used for communication by a plurality of electronic control units mounted on a vehicle, and includes a receiving unit that receives firmware update information including update firmware targeted for one of the plurality of electronic control units from an external device outside the vehicle, and a control unit that determines whether the electronic control unit to which the update firmware is applied satisfies a predetermined condition based on predetermined information of the electronic control unit to which the update firmware is applied, and controls the electronic control unit to execute a predetermined process related to firmware update when the predetermined condition is satisfied, and controls the electronic control unit to execute the predetermined process other than the electronic control unit when the predetermined condition is not satisfied. As a result, when an ECU targeted for firmware update among electronic control units (ECUs) connected to the bus does not have a function for executing a predetermined process related to update (e.g., a signature verification process, etc.) or is in a situation where the predetermined process cannot be executed, the gateway device can control another ECU or the gateway device to execute the predetermined process instead of the ECU (i.e., to act as a proxy). Therefore, for example, firmware update can be appropriately performed even in an ECU that does not have a function required for performing firmware update while ensuring security.
The control unit may make the determination based on the predetermined information indicating the processing capacity of the electronic control unit to which the update firmware is to be applied, thereby making it possible to appropriately update the firmware even if the ECU to which the update firmware is to be applied (the update target) is unable to perform a predetermined process in terms of processing capacity.
The predetermined information indicating the processing capacity may indicate whether or not the ECU has a function for executing the predetermined process, and the control unit may determine that the predetermined condition is satisfied when the ECU to which the update firmware is applied has the function for executing the predetermined process, and that the predetermined condition is not satisfied when the ECU does not have the function for executing the predetermined process. In this way, even if the ECU to which the update firmware is applied does not have the function for executing a predetermined process that is useful for appropriately performing the update, the predetermined process is performed instead, so that the firmware update can be performed appropriately.
The predetermined process may be a process of verifying a signature attached to the update firmware in the firmware update information. In this way, even in an ECU that does not have a signature verification function for verifying the signature attached to the update firmware, signature verification is performed on behalf of the ECU, so that the firmware update can be performed appropriately while ensuring security.
The predetermined process may be a process of saving the firmware before the update in the electronic control unit to which the update firmware is applied. In this way, even in an ECU that cannot save the firmware before the update due to a lack of sufficient memory during firmware update, the process of saving the firmware before the update is performed instead, so that the firmware before the update can be restored when the firmware update fails.
The control unit may also select one of the plurality of electronic control units to which the update firmware is not applied, and cause the selected electronic control unit to execute the predetermined process. This allows firmware to be updated appropriately in ECUs that do not execute the predetermined process by effectively utilizing ECUs that can execute the predetermined process.
The control unit may control the gateway device to execute the predetermined process. In this way, the gateway device performs the predetermined process, and firmware update can be appropriately performed in an ECU that does not perform the predetermined process.
The predetermined process may be a process of verifying a signature attached to the update firmware in the firmware update information, and the control unit may select one of the electronic control units that is not a target of the update firmware and has a key for verifying the signature, and cause the selected electronic control unit to execute the predetermined process. This allows an ECU that has a key for verifying the signature to be effectively used, and firmware to be appropriately updated in an ECU that does not have the key for verifying the signature.
The electronic control units may communicate with each other via the bus in accordance with a Controller Area Network (CAN) protocol, thereby allowing firmware updates of ECUs in an in-vehicle network conforming to the CAN protocol to be properly performed.
According to one aspect of the present invention, an in-vehicle network system includes a plurality of electronic control units that communicate with each other via one or more buses and a gateway device connected to the buses, the gateway device having a receiver that receives firmware update information including update firmware targeted for one of the plurality of electronic control units from an external device outside the vehicle in which the gateway device is mounted, and a controller that determines whether the electronic control unit to which the update firmware is targeted satisfies a predetermined condition based on predetermined information of the electronic control unit to which the update firmware is targeted, and if the predetermined condition is satisfied, causes the electronic control unit to execute a predetermined process related to the firmware update, and if the predetermined condition is not satisfied, controls the electronic control unit so that the predetermined process is executed by a device other than the electronic control unit. This allows firmware updates to be performed appropriately even in ECUs that do not have the functions necessary to ensure security when updating firmware.
A firmware update method according to one aspect of the present invention is a firmware update method used in an in-vehicle network system having a plurality of electronic control units that communicate via one or more buses, and includes a receiving step of receiving firmware update information including update firmware targeted for one of the plurality of electronic control units from an external device outside the vehicle on which the plurality of electronic control units are mounted, and a control step of determining whether or not the electronic control unit to which the update firmware is targeted satisfies a predetermined condition based on predetermined information of the electronic control unit to which the update firmware is targeted, and if the predetermined condition is satisfied, causing the electronic control unit to execute a predetermined process related to firmware update, and if the predetermined condition is not satisfied, controlling so that the predetermined process is executed by a unit other than the electronic control unit. This allows the firmware to be updated appropriately.
Furthermore, these general or specific aspects may be realized by a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized by any combination of the system, method, integrated circuit, computer program, or recording medium.
An in-vehicle network system including a gateway device according to an embodiment will be described below with reference to the drawings. Each of the embodiments shown here shows a specific example of the present invention. Therefore, the numerical values, components, the arrangement and connection form of the components, as well as the steps (processes) and the order of the steps shown in the following embodiments are merely examples and do not limit the present invention. Among the components in the following embodiments, those not described in the independent claims are components that can be added arbitrarily. Furthermore, each figure is a schematic diagram and is not necessarily a precise illustration.
(First embodiment) Hereinafter, as an embodiment of the present invention, a firmware update method used in an in-vehicle network system 10 in which a plurality of electronic control units (ECUs) including a gateway device communicate via a bus will be described with reference to the drawings. The firmware update method is a method for updating (i.e., replacing) firmware (FW) implemented in each ECU mounted on a vehicle with new update firmware distributed from a server located outside the vehicle. In the in-vehicle network system 10, a firmware update method is used in which, when an ECU updates firmware, a gateway device performs a process (e.g., signature verification process, etc.) required for a safe and appropriate firmware update instead of an ECU that cannot perform the process. This makes it possible to perform an appropriate firmware update even in an ECU that does not have a function to perform a process required for a firmware update or an ECU that is in a state where the function cannot be performed.
[1.1 Overall configuration of the in-vehicle network system 10]
FIG. 1 is a diagram showing 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 communicates according to the CAN protocol, and is a network communication system in a vehicle equipped with various devices such as a control device, a sensor, an actuator, and a user interface device. The in-vehicle network system 10 includes a plurality of devices that perform frame-related communication via a bus, and uses a firmware update method. Specifically, as shown in FIG. 1, the in-vehicle network system 10 includes ECUs 100a to 100d that are mounted on a vehicle and connected to various devices, buses 200a and 200b, a gateway 300, a network 400 outside the vehicle, and a server 500. Note that the in-vehicle network system 10 may include several ECUs other than the gateway 300 and the ECUs 100a to 100d, but for convenience, the description will be given focusing on the gateway 300 and the ECUs 100a to 100d. The ECU is, for example, a device that includes a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like. The memory is a ROM, a RAM, and the like, and can store a control program (a computer program as software) executed by the processor. The firmware is all or part of this control program, and is stored in a non-volatile memory (called a boot ROM) such as an EEPROM (Electrically Erasable Programmable Read Only Memory). For example, the ECU realizes various functions by a processor operating in accordance with a control program (computer program). Note that a computer program is composed of a combination of multiple instruction codes that indicate commands to the processor to achieve a specified function. Note that the firmware may include all or part of microcode for interpreting instructions within the processor.
ECUs 100a to 100d are each connected to devices such as an engine 101, a brake 102, a door opening/closing sensor 103, and a window opening/closing sensor 104, and acquire the status of the devices and periodically transmit frames (data frames) representing the status to an in-vehicle network consisting of buses 200a, 200b, etc.
Gateway 300 is a kind of ECU as a gateway device connected to bus 200a to which ECU 100a and ECU 100b are connected, and to bus 200b to which ECU 100c and ECU 100d are connected. 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 server 500 via 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. Any communication protocol, such as wireless communication or wired communication, may be applied to the communication in the network 400.
Each ECU in the in-vehicle network system 10 exchanges frames according to the CAN protocol. The frames in the CAN protocol include a data frame, a remote frame, an overload frame, and an error frame.
[1.2 Data frame format]
Below, we will explain the data frame, which is one of the frames used in networks that conform to the CAN protocol.
Figure 2 is a diagram showing the format of a data frame defined by the CAN protocol. This diagram shows a data frame in the standard ID format defined by the CAN protocol. The data frame is composed of the following fields: 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, CRC delimiter "DEL", ACK (Acknowledgement) slot, ACK delimiter "DEL", and EOF (End Of Frame).
SOF is composed of 1 bit dominant. When the bus is idle, it is recessive, and by changing it to dominant with SOF, it notifies the start of frame transmission.
The ID field is an 11-bit field that stores an ID (message ID), which is a value that indicates the type of data. When multiple nodes start transmitting at the same time, this ID field is used to arbitrate communications, so it is designed so that frames with smaller ID values have higher priority.
The RTR is a value for distinguishing between a data frame and a remote frame, and in a data frame it consists of one dominant bit.
Both IDE and "r" consist of one dominant bit.
DLC is a 4-bit value that indicates the length of the data field. The IDE, "r" and DLC are collectively called the control field.
The data field is a value that indicates the content of the data to be transmitted, consisting of a maximum of 64 bits. The length can be adjusted in 8-bit increments. The specifications of the data to be transmitted are not regulated by the CAN protocol, but are determined by the in-vehicle network system 10. Therefore, the specifications depend on the vehicle model, manufacturer (manufacturer), etc.
The CRC sequence consists of 15 bits and is calculated from the transmitted values of the SOF, ID field, control field, and data field.
The CRC delimiter is a delimiter that indicates the end of the CRC sequence, which is composed of 1 recessive bit. The CRC sequence and the CRC delimiter are collectively referred to as the CRC field.
The ACK slot consists of 1 bit. The transmitting node sets the ACK slot to recessive and transmits. If the receiving node has received the CRC sequence successfully, it transmits the ACK slot as dominant. Since dominant takes precedence over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that one of the receiving nodes has successfully received the data.
The ACK delimiter is a 1-bit recessive delimiter that indicates the end of the ACK.
EOF consists of 7 recessive bits and indicates the end of a data frame.
[1.3 Configuration of Gateway 300]
3 is a configuration diagram of the gateway 300. The gateway 300 executes functions such as frame transfer between buses and communication with an external server 500 (receiving FW update information for updating firmware of the ECUs 100a to 100d, etc.). For this reason, 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, a transfer rule holding unit 360, a FW update processing unit 370, a firmware (FW) cache holding unit 371, an ECU information holding unit 372, a signature verification unit 373, a key holding unit 374, an external communication unit 375, and a frame generation unit 380, as shown in FIG. 3. 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 memory, a digital circuit, or the like.
Frame transmitting/receiving unit 310 transmits and receives frames conforming to the CAN protocol to and from bus 200a and bus 200b, respectively. Frame transmitting/receiving unit 310 receives a frame from bus 200a or bus 200b and transfers it to frame interpretation unit 320. Frame transmitting/receiving unit 310 also transmits the contents of the frame to bus 200a or bus 200b based on bus information indicating the destination bus notified by frame generating 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 that it judges to be an ID field to the received ID determination unit 330. Depending on the judgment result notified by the received ID determination unit 330, the frame interpretation unit 320 decides whether to transfer the value of the ID field and the data field (data) that appears after the ID field to the frame processing unit 350, or to stop receiving the frame. If the frame interpretation unit 320 judges that the frame does not comply with the CAN protocol, it notifies the frame generation unit 380 to transmit an error frame. If the frame interpretation unit 320 receives an error frame, it discards the frame that is being received thereafter, that is, it stops interpreting the frame.
The received ID determination unit 330 receives the value of the ID field notified by the frame interpretation unit 320, and determines whether or not to receive each field of the frame following the ID field, according to the list of message IDs held by the received ID list holding unit 340. The received ID determination unit 330 notifies the frame interpretation unit 320 of the result of this determination.
The received ID list holding unit 340 holds a received ID list, which is a list of IDs (message IDs) received by the gateway 300. Fig. 4 is a diagram showing an example of the received ID list.
The frame processing unit 350 determines a bus to transfer the frame to depending on the ID of the received frame, in accordance with the transfer rules stored in the transfer rule storage unit 360, and notifies the frame generating unit 380 of the bus information of the bus to transfer the frame to, the message ID notified by the frame interpretation unit 320, and the data. The frame processing unit 350 also notifies the FW update processing unit 370 of the update result data related to the firmware update notified by the frame interpretation unit 320. Note that the frame processing unit 350 does not transfer the update result data related to the firmware update.
The transfer rule storage unit 360 stores transfer rules, which are information that indicates rules regarding frame transfer for each bus. Fig. 5 is a diagram showing an example of the transfer rules.
The FW update processing unit 370 requests the signature verification unit 373 to verify the signature of the FW update information including FW data such as the firmware for update notified from the external communication unit 375, and receives the result of the signature verification (whether or not it is successful). The FW update processing unit 370 distinguishes whether or not the ECU to be updated, among the ECUs connected to the in-vehicle network (buses 200a, 200b), has a function to execute a process required for updating the firmware, based on the list of ECU information held by the ECU information holding unit 372. If the ECU to be updated does not have a function to execute a process required for updating the firmware, the FW update processing unit 370 controls the gateway 300 to execute the function instead. One of the functions to execute a process required for updating the firmware is a function (signature verification function) to verify the signature attached to the FW data related to the firmware (FW) for each ECU in the FW update information. Another function for executing a process required for updating firmware is a function (FW cache function) for storing (saving) the firmware before the update in a storage medium such as a memory when the ECU updates the firmware, and for restoring the saved firmware if the update fails. That is, the FW cache function includes a function for saving the firmware before the update. When acting as a proxy for the FW cache function, the FW update processing unit 370 controls the firmware before the update to be received from the ECU to be updated and stored (saved) in the FW cache holding unit 371, and to take out the saved firmware from the FW cache holding unit 371 as necessary and to transmit it so that the ECU to be updated can receive it. When acting as a proxy for the signature verification function, the FW update processing unit 370 requests the signature verification unit 373 to verify the signature attached to the FW data corresponding to the ECU to be updated. In addition, the FW update processing unit 370 notifies the frame generating unit 380 of the FW data related to the firmware for update and the bus information of the bus to which the ECU to be updated is connected. Furthermore, the FW update processing unit 370 notifies the external communication unit 375 of notifications (update results, etc.) by the ECUs notified by the frame processing unit 350. Furthermore, the FW update processing unit 370 notifies the frame generating unit 380 of data required for communication with the ECUs 100a to 100d when updating the firmware. The FW update processing unit 370 determines whether or not an ECU to which the update firmware is to be applied (update target) satisfies a predetermined condition (conditions such as having a signature verification function and having a FW cache function), based on information about the ECU, and if the predetermined condition is satisfied, causes the ECU to execute a predetermined process related to the firmware update (signature verification process, process related to the FW cache function, etc.), and if the predetermined condition is not satisfied, functions as a control unit that controls the predetermined process to be executed by another ECU (here, the gateway 300) than the ECU.
The FW cache holding unit 371 is realized, for example, in a storage area such as a non-volatile memory in the gateway 300, and is used for storing (saving) existing firmware received from ECUs 100b, 100d that are the ECUs to be updated and do not have a FW cache function when updating firmware.
The ECU information holding unit 372 holds a list of ECU information, which is predetermined information related to each of all ECUs (ECUs 100a to 100d) connected to the buses 200a and 200b. An example of the list of ECU information is shown in FIG.
The signature verification unit 373 receives data to be subjected to signature verification related to the FW update information from the FW update processing unit 370, performs signature verification using a signature verification key obtained from the key holding unit 374, and notifies the FW update processing unit 370 of the verification result.
The key holding unit 374 holds a key for verifying a signature on the data of the FW update information received from the server 500 .
The external communication unit 375 has a function as a receiving unit that receives FW update information including FW data related to the update firmware from the server 500, and notifies the FW update processing unit 370 of the received FW update information. Furthermore, the external communication unit 375 transmits the update result notified from the FW update processing unit 370 to the server 500. The external communication unit 375 holds, for example, address information of the server 500 required to access the server 500 via the network 400 in advance. Note that the gateway 300 may convert the format of the FW data received from the server 500 as necessary so as to include it in a frame conforming to the CAN protocol, and transmit the data to the ECUs 100a to 100d.
In accordance with the error frame transmission request notified by frame interpretation unit 320, frame generation unit 380 notifies frame transmission/reception unit 310 of the error frame to transmit it. Furthermore, frame generation unit 380 configures a frame using the message ID and data notified by frame processing unit 350, and notifies frame transmission/reception unit 310 of the frame together with the bus information. Furthermore, frame generation unit 380 configures a frame using FW data related to the update firmware notified by FW update processing unit 370, and notifies frame transmission/reception unit 310 of the frame together with the bus information.
[1.4 Receiving ID list example]
FIG. 4 is a diagram showing an example of the received ID list held in the received ID list holding unit 340 of the gateway 300. As shown in FIG.
4 is used to selectively receive and process frames including message IDs whose ID (message ID) values are any of "1," "2," "3," and "4." This is merely one example, but the reception ID list lists the message IDs of frames that gateway 300 is determined to receive.
[1.5 Example of forwarding rules]
FIG. 5 shows an example of the transfer rules stored in the transfer rule storage unit 360 of the gateway 300. As shown in FIG.
This transfer rule associates a source bus, a destination bus, and the ID (message ID) of the transfer target. An "*" in FIG. 5 indicates that a frame is transferred regardless of the message ID. The example in FIG. 5 shows that frames received from bus 200a are set to be transferred to bus 200b regardless of the message ID. It also shows that only frames with a message ID of "3" among frames received from bus 200b are set to be transferred to bus 200a.
[1.6 Example of ECU information list]
FIG. 6 shows an example of a list of ECU information stored in the ECU information storage unit 372 of the gateway 300. As shown in FIG.
6 is composed of ECU information for each ECU. The ECU information includes, for example, an ECU-ID, an ECU type indicating a function type of the ECU, a manufacturer of the ECU, information indicating whether the ECU has a signature verification function (i.e., the presence or absence of the signature verification function), and information indicating whether the ECU has a FW cache as an area of a storage medium for realizing the FW cache function (i.e., the presence or absence of the FW cache function). The ECU-ID is, for example, identification information for each ECU, such as an identifier such as a serial number. The list of ECU information held by the ECU information holding unit 372 can be said to be, for example, information indicating the processing capability of the ECU for each ECU (e.g., the presence or absence of the signature verification function, the FW cache function, etc.).
The example of FIG. 6 indicates that the ECU-ID of the ECU 100a connected to the engine 101 is "0001", the ECU type is for engine control identified by "engine", the manufacturer is "Company A", the ECU has a signature verification function, and the ECU has a FW cache function. The example of FIG. 6 indicates that the ECU-ID of the ECU 100b connected to the brake 102 is "0002", the ECU type is for brake control identified by "brake", the manufacturer is "Company B", the ECU has a signature verification function, and the ECU does not have a FW cache function. The example of FIG. 6 indicates that the ECU-ID of the ECU 100c connected to the door opening/closing sensor 103 is "0003", the ECU type is for door opening/closing control identified by "door", the manufacturer is "Company C", the ECU does not have a signature verification function, and the ECU has a FW cache function. In addition, the ECU-ID for the ECU 100a connected to the window opening/closing sensor 104 is "0004", the ECU type is for window opening/closing control identified by "window", the manufacturer is "Company D", it does not have a signature verification function, and it does not have a FW cache function.
The ECU information held by the ECU information holding unit 372 may be information set at the time of manufacture, or may be information acquired by the gateway 300 from an external device such as the server 500 when, for example, power supply to the gateway 300 is started. In addition, when the state of an ECU connected to the buses 200a and 200b is changed due to replacement or firmware update, or when a new ECU is introduced into the vehicle and connected to the bus 200a or 200b, the gateway 300 may collect new ECU information and update the list of ECU information held by the ECU information holding unit 372.
[1.7 Configuration of ECU100a]
7 is a configuration diagram of the ECU 100a. The ECU 100a has a signature verification function and a FW cache function, and includes a frame transmission/reception unit 110, a frame interpretation unit 120, a received ID determination unit 130, a received ID list holding unit 140, a frame processing unit 150, a FW update processing unit 160, a FW cache holding unit 161, a signature verification unit 163, a key holding unit 164, a data acquisition unit 170, and a frame generation unit 180. 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 memory, a digital circuit, or the like.
The frame transmitting/receiving unit 110 transmits and receives frames conforming to the CAN protocol to and from the bus 200a. It receives a frame from the bus one bit at a time and transfers it to the frame interpretation unit 120. It also transmits the contents of the frame notified by the frame generation unit 180 to the bus 200a.
The frame interpretation unit 120 receives the 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 that is determined to be an ID field is transferred to the received ID determination unit 130. Depending on the determination result notified from the received ID determination unit 130, the frame interpretation unit 120 decides whether to transfer the value of the ID field and the data field that appears after the ID field to the frame processing unit 150, or to stop receiving the frame after receiving the determination result. If the frame interpretation unit 120 determines that the frame does not comply with the CAN protocol, it notifies the frame generation unit 180 to transmit an error frame. If the frame interpretation unit 120 receives an error frame, it discards the frame thereafter, that is, it stops interpreting the frame.
The received ID determination unit 130 receives the value of the ID field notified from the frame interpretation unit 120, and determines whether or not to receive each field of the frame following the ID field, according to the list of message IDs held by the received ID list holding unit 140. The received ID determination unit 130 notifies the frame interpretation unit 120 of the result of this determination.
The reception ID list storage unit 140 stores a reception ID list, which is a list of message IDs received by the ECU 100a. This reception ID list is, for example, similar to the example in FIG.
The frame processing unit 150 performs different processing for each ECU according to the data of the received frame. For example, the ECU 100a connected to the engine 101 has a function of sounding an alarm when the door is open when the speed exceeds 30 km/h. The frame processing unit 150 of the ECU 100a manages data received from other ECUs (for example, information indicating the state of the door) and performs processing such as sounding an alarm under certain conditions based on the speed acquired from the engine 101. The frame processing unit 150 is also provided in the ECUs 100b to 100d, and the ECU 100c has a function of sounding an alarm when the door is opened without the brakes being applied. The ECUs 100b and 100d do nothing in particular. Note that the ECUs 100a to 100d may have functions other than those described above. In addition, when the frame processing unit 150 acquires FW data for updating the firmware, it notifies the FW update processing unit 160.
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 by the frame processing unit 150, and updates (rewrites) the firmware in the boot ROM of the ECU 100a based on the FW data if the signature verification is successful. The boot ROM is, for example, a non-volatile memory set as a storage destination for firmware executed after a reset by the processor of the ECU 100a. When updating the firmware in the boot ROM, the FW update processing unit 160 stores (preserves) the existing firmware in, for example, the FW cache holding unit 161 so that the firmware can be restored to the state before the update in the event of an update failure. In addition, the FW update processing unit 160 notifies the frame generating unit 180 to generate and transmit a frame indicating the result of the signature verification of the FW data (information indicating success or failure) and a frame indicating the result of the firmware update based on the FW data.
The FW cache holding unit 161 is realized by, for example, a storage area such as a non-volatile memory in the ECU 100a, and is used for storing (saving) existing firmware when updating 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 a signature verification key obtained from the key holding unit 164, and notifies the FW update processing unit 160 of the verification result.
The key holding unit 164 holds a key for verifying the signature of FW data for updating the firmware.
The data acquisition unit 170 acquires data indicating the states of devices, sensors, etc. connected to the ECU, and notifies the frame generation unit 180 of the data.
The frame generating unit 180 composes an error frame in accordance with the notification from the frame interpreting unit 120 instructing to transmit an error frame, and notifies the frame transmitting/receiving unit 110 of the error frame to transmit it. Furthermore, the frame generating unit 180 composes a frame by attaching a predetermined message ID to the value of the data notified by the data acquiring unit 170, and notifies the frame transmitting/receiving unit 110. Furthermore, in accordance with an instruction by the FW updating processing unit 160 to generate a frame of the result of firmware signature verification or a frame of the firmware updating result, the frame generating unit 180 composes a frame with a predetermined message ID attached, and notifies the frame transmitting/receiving unit 110.
[1.8 Configuration of ECU100b]
8 is a configuration diagram of the ECU 100b. The ECU 100b has a signature verification function but does not have a FW cache function, and includes a frame transmission/reception unit 110, a frame interpretation unit 120, a received ID determination unit 130, a received ID list holding unit 140, a frame processing unit 150, a FW update processing unit 165, a signature verification unit 163, a key holding unit 164, a data acquisition unit 170, and a frame generation unit 180. Each of these components is realized by a communication circuit in the ECU 100b, a processor that executes a control program stored in a memory, a memory, a digital circuit, or the like. Note that, among the components of the ECU 100b, components similar to those of the ECU 100a are assigned the same reference numerals in FIG. 8 as those in FIG. 7, and description thereof will be omitted here.
The FW update processing unit 165 requests the signature verification unit 163 to verify the signature of the FW data received from the gateway 300 and notified by the frame processing unit 150, and notifies the frame generating unit 180 to generate and transmit a frame indicating the result of the signature verification of the FW data (information indicating success or failure). When the FW update processing unit 165 is notified by the frame processing unit 150 that it has received a request for data (firmware) in the boot ROM from the gateway 300, it notifies the frame generating unit 180 to generate and transmit a frame including the existing firmware in the boot ROM as data. This boot ROM is, for example, a non-volatile memory set as a storage destination of firmware executed after reset by the processor of the ECU 100b. The FW update processing unit 165 updates (rewrites) the contents of the boot ROM of the ECU 100b with the update ROM data (updated firmware) notified by the frame processing unit 150 received from the gateway 300. The FW update processing unit 165 also notifies the frame generating unit 180 to generate and transmit a frame indicating the update result of the firmware.
[1.9 Configuration of ECU100c]
9 is a configuration diagram of the ECU 100c. The ECU 100c does not have a signature verification function but has a FW cache function, and 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, a FW update processing unit 166, a FW cache holding unit 161, a data acquisition unit 170, and a frame generation unit 180. Each of these components is realized by a communication circuit in the ECU 100c, a processor that executes a control program stored in a memory, a memory, a digital circuit, or the like. Note that, among the components of the ECU 100c, components similar to those of the ECU 100a are assigned the same reference numerals in FIG. 9 as those in FIG. 7, and description thereof will be omitted here.
The FW update processing unit 166 updates (rewrites) the firmware in the boot ROM of the ECU 100c based on the FW data received from the gateway 300 and notified by the frame processing unit 150. The boot ROM is, for example, a non-volatile memory set as a storage destination for firmware executed by the processor of the ECU 100c after reset. When updating the firmware in the boot ROM, the FW update processing unit 166 stores (saves) the existing firmware in, for example, the FW cache holding unit 161 so that the firmware can be restored to the state before the update in the event of an update failure. The FW update processing unit 166 also notifies the frame generating unit 180 to generate and transmit a frame indicating the result of updating the firmware based on the FW data.
[1.10 Configuration of ECU100d]
10 is a configuration diagram of the ECU 100d. The ECU 100d does not have a signature verification function or a FW cache function, and includes a frame transmission/reception unit 110, a frame interpretation unit 120, a received ID determination unit 130, a received ID list holding unit 140, a frame processing unit 150, a FW update processing unit 167, a data acquisition unit 170, and a frame generation unit 180. Each of these components is realized by a communication circuit in the ECU 100d, a processor that executes a control program stored in a memory, a memory, a digital circuit, or the like. Note that, among the components of the ECU 100d, components similar to those of the ECU 100a are assigned the same reference numerals in FIG. 10 as those in FIG. 7, and description thereof will be omitted here.
When the FW update processing unit 167 is notified by the frame processing unit 150 that it has received a request for data (firmware) in the boot ROM from the gateway 300, it notifies the frame generating unit 180 to generate and transmit a frame including the existing firmware in the boot ROM as data. This boot ROM is, for example, a non-volatile memory set as a storage destination for firmware to be executed after a reset by the processor of the ECU 100d. Furthermore, the FW update processing unit 167 updates (rewrites) the contents of the boot ROM of the ECU 100d with the update ROM data (updated firmware) received from the gateway 300 and notified by the frame processing unit 150. Furthermore, the FW update processing unit 165 notifies the frame generating unit 180 to generate and transmit a frame indicating the result of updating the firmware.
[1.11 Server 500 Configuration]
The server 500 is a computer located outside the vehicle in which the in-vehicle network system 10 is mounted, and includes a memory, a storage medium such as a hard disk, a processor, a communication circuit, etc. The server 500 may also include an input device (such as a keyboard) and a display as a user interface. Assuming that each of a plurality of vehicles is mounted with a plurality of ECUs related to the in-vehicle network, the server 500 has a function of managing firmware provided by manufacturers of various ECUs, etc., and distributing FW update information including update firmware to each vehicle.
11 is a configuration diagram of server 500. As shown in the figure, server 500 includes a data transmission/reception unit 510, a distribution data generation unit 570, a FW holding unit 571, an ECU management information holding unit 572, a signature generation unit 590, and a key holding unit 591. Each of these components is realized by a communication circuit in 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 and transmits and receives data. The data transmission/reception unit 510 distributes data (FW update information including firmware to be updated) notified from the distribution data generation unit 570 to the gateway 300. Furthermore, when the data transmission/reception unit 510 receives a firmware update result from the gateway 300, it updates the vehicle ECU management information held by the ECU management information holding unit 572.
The distribution data generation unit 570 generates FW update information (distribution data) as a package of update firmware to be distributed to the gateway 300, and requests the signature generation unit 590 to generate a signature for the FW update information. To generate the FW update information, the distribution data generation unit 570 acquires the latest firmware (FW) of each ECU from the FW holding unit 571, and acquires information on the ECU to be updated from the ECU management information holding unit 572. The format of the FW update information (distribution data) will be described later (see FIG. 13).
The FW storage unit 571 stores firmware (FW) for various ECUs.
The ECU management information storage unit 572 stores vehicle ECU management information, which is information about each ECU in the in-vehicle network of each vehicle. The vehicle ECU management information will be described later (see FIG. 12).
Upon receiving a request from the distribution data generation unit 570, the signature generation unit 590 uses the signature key held in the key holding unit 591 to generate a signature for the FW update information and notifies the distribution data generation unit 570. The signature generation unit 590 can, for example, generate 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.
[1.12 Vehicle ECU Management Information]
FIG. 12 shows an example of vehicle ECU management information (a list of ECU information for each vehicle) held in the ECU management information holding unit 572 of the server 500. In FIG.
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 an ECU-ID, an ECU type indicating a functional type of the ECU, a manufacturer of the ECU, the presence or absence of a signature verification function, the presence or absence of a FW cache function, a FW version which is a version number or the like of the firmware implemented in the ECU, and a latest FW version which is a version number or the like of the latest firmware corresponding to the ECU. Each ECU information for a certain vehicle in the vehicle ECU management information is set based on, for example, information received from the gateway 300 of the vehicle (such as a firmware update result) and a FW version for firmware uploaded to the server 500 from the manufacturer of each ECU and held in the FW holding unit 571. Note that, although FIG. 12 illustrates only information about one vehicle A, the vehicle ECU management information may also include information about other vehicles.
[1.13 FW update information format example]
FIG. 13 shows an example of a format of the FW update information as distribution data distributed by the server 500. In FIG.
The FW update information includes a FW number F1 indicating the number of FW data, one or more pieces of FW data (two individual FW data F10, F20 in the example of FIG. 13), and a FW update information signature F30 which is a signature for the entire FW update information (distribution data). The FW data F10, F20 respectively include firmware (FW) F13, F23 for updating, ECU-ID F11, F21 which identifies the target ECU, FW version F12, F22 which indicates the version number of the firmware, etc., and FW data signature F14, F24 which is a signature for these data. The firmware F13, F23 is the firmware itself, that is, binary data.
[1.14 Example of FW update information distribution and firmware update operations]
Hereinafter, operations related to distribution of FW update information and updating of firmware in an ECU in the in-vehicle network system 10 will be described.
14 is a sequence diagram showing an example of an operation in which the server 500 distributes distribution data (FW update information) to the gateway 300 and updates the firmware under the control of the gateway 300. Each sequence here means each processing procedure (step) in each device. This sequence may be started, for example, when new firmware is uploaded and registered in the server 500, or may be started in response to a distribution request from the gateway 300 of the vehicle to which the firmware is to be distributed.
The server 500 determines one or more pieces of firmware for updating to be distributed to the gateway 300 based on the vehicle ECU management information and the like stored in the ECU management information storage unit 572 (step S1101). This determination also determines the number of pieces of firmware for updating.
Next, the server 500 generates FW update information (see FIG. 13) in the distribution data generation unit 570. That is, the distribution data generation unit 570 repeats the acquisition of FW data such as firmware held by the FW holding unit 571 (step S1103) and the addition of the FW data signature generated by the signature generation unit 590 to the FW data (step S1104) for the number of FWs, which is the number of firmware for update (step S1102). In addition, the distribution data generation unit 570 causes the signature generation unit 590 to generate a signature for the FW update information (FW update information signature) (step S1105), and generates FW update information to which the signature has been added.
When the server 500 generates the FW update information, it causes the data transmitter/receiver 510 to transmit the FW update information (distribution data) (step S1106a). As a result, the server 500 transmits the FW update information to the gateway 300, and the gateway 300 receives the FW update information (step S1106b).
When the gateway 300 receives the FW update information, the signature verification unit 373 verifies the signature of the FW update information (FW update information signature) (step S1107). Then, the FW update processing unit 370 of the gateway 300 determines whether the signature verification is successful or not (step S1108), and if the verification is not successful, discards the FW update information (step S1110), in which case firmware update based on the FW update information is not performed. If the verification is successful, the gateway 300 performs FW update control processing mainly by the FW update processing unit 370 in cooperation with the ECU that is the target of the update (step S1109). The contents of the FW update control processing will be described later.
After completing the FW update control process in step S1109 or after discarding the FW update information in step S1110, the gateway 300 transmits the firmware update result to the server 500 (step S1111a). The firmware update result is, for example, information indicating whether the update was successful or not, and the information may include, for example, the FW version related to the firmware after the update. In this way, the server 500 receives the update result (step S1111b). Note that when the server 500 receives the firmware update result, it may update the vehicle ECU management information held by the ECU management information holding unit 572 so as to indicate the state of the firmware after the update.
[1.15 Example of FW update control processing by Gateway 300]
FIG. 15 is a flowchart showing an example of a FW update control process by the gateway 300.
The FW update control process executed by the gateway 300 in the above-mentioned step S1109 will be described below with reference to FIG.
The gateway 300 acquires the number of FWs in the FW update information (see FIG. 13) by the FW update processing unit 370 (step S1201), and repeats the processes in steps S1203 to S1213 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, and identifies the ECU whose firmware is to be updated (step S1203).
Next, in the gateway 300, the FW update processing unit 370 refers to the list of ECU information held by the ECU information holding unit 372 (see FIG. 6) and determines whether the ECU to be updated (the ECU identified by the ECU-ID acquired in step S1203) has signature verification capability (has a signature verification function) (step S1204).
If it is determined in step S1204 that the ECU to be updated has a signature verification function, the FW update processing unit 370 causes the frame generating unit 380 to generate a frame including FW data to be transmitted to the ECU, and the frame transmitting/receiving unit 310 transmits the frame to the ECU via the bus to which the ECU is connected (step S1205). Then, the gateway 300 receives the result of verification of the signature for the FW data (FW data signature) by the ECU to be updated for the firmware (step S1206).
If it is determined in step S1204 that the ECU to be updated does not have a signature verification function, the FW update processing unit 370 causes the signature verification unit 373 to verify the signature for the FW data (FW data signature) (step S1207). That is, the gateway 300 performs verification of the FW data signature in the ECU to be updated for firmware.
After step S1206 or step S1207, the gateway 300 judges the result of verification of the FW data signature (step S1208), and discards the FW data if the verification is unsuccessful (step S1209). If the verification is successful, the FW update processing unit 370 refers to the list of ECU information held by the ECU information holding unit 372 (see FIG. 6) and judges whether the ECU to be updated has a FW cache (has a FW cache function) (step S1210).
When it is determined in step S1210 that the ECU to be updated has a FW cache function, if the FW update processing unit 370 has not yet transmitted FW data to the ECU, the FW update processing unit 370 causes the frame generating unit 380 to generate a frame including FW data, and the frame transmitting/receiving unit 310 transmits the frame to the ECU via the bus to which the ECU is connected (step S1211). As a result, the ECU to be updated for firmware receives the FW data, performs processing for firmware update, and transmits the update result to the gateway 300. The gateway 300 then receives the update result transmitted from the ECU (step S1212).
If it is determined in step S1210 that the ECU to be updated does not have the FW cache function, the gateway 300 performs FW update GW proxy processing in cooperation with the ECU to be updated (step S1213). This FW update GW proxy processing will be described later.
[1.16 Example of firmware update in ECU100a]
16 is a flowchart showing an example of a FW update control process performed by the ECU 100a having the signature verification function and the FW cache function. The FW update control process performed by the ECU 100a will be described below with reference to FIG.
In the ECU 100a, the frame transmitting/receiving unit 110 receives the frame including the FW data transmitted from the gateway 300 in the above-mentioned step S1205 (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 causes the signature verification unit 163 to verify the FW data signature in the FW data (step S1302). Then, the ECU 100a transmits a frame indicating the verification result of the FW data signature to the bus 200a via the frame transmission/reception unit 110 (step S1303). As a result, the gateway 300 is notified of the verification result of the FW data signature.
The FW update processing unit 160 determines whether or not the verification of the FW data signature has been successful (step S1304), and if not successful, discards the FW data (step S1305) and does not update the firmware.
If the verification of the FW data signature is successful, the FW update processing unit 160 copies and stores the firmware, which is the content of the boot ROM in the ECU 100a, in the FW cache holding unit 161 (step S1306).
Next, the FW update processing unit 160 updates the firmware in the boot ROM with the firmware (FW) in the FW data (step S1307), and restarts the processor of the ECU 100a by resetting it (step S1308).
In ECU 100a, if booting from the boot ROM is unsuccessful, it is preset so that booting is performed using the contents of FW cache holding unit 161, and if the restart in step S1308 is unsuccessful (step S1309), the pre-update firmware stored in FW cache holding unit 161 is started (step S1310). Then, under the control of the pre-update firmware, the pre-update firmware stored in FW cache holding unit 161 is copied to the boot ROM, thereby restoring the contents of the boot ROM to the state before the update (step S1311).
If the restart in step S1308 is successful, the ECU 100a transmits a frame including an update result indicating that the firmware update was successful to the bus 200a, and if the restart in step S1308 is not successful, after step S1311, the ECU 100a transmits a frame including an update result indicating that the firmware update was unsuccessful to the bus 200a (step S1312). This notifies the gateway 300 of the firmware update result.
[1.17 Example of firmware update in ECU100b]
17 is a flowchart showing an example of FW update control processing by an ECU 100b having a signature verification function but not a FW cache function. In the figure, steps similar to those already described are given the same reference numerals. The FW update control processing performed by the ECU 100b will be described below with reference to FIG. 17.
In the ECU 100b, the frame transmitting/receiving unit 110 receives the frame including the FW data transmitted in the above-mentioned step S1205 from the gateway 300 (step S1301).
The FW update processing unit 165 of the ECU 100b 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 causes the signature verification unit 163 to verify the FW data signature in the FW data (step S1302). Then, the ECU 100b transmits a frame indicating the verification result of the FW data signature to the bus 200a via the frame transmission/reception unit 110 (step S1303). As a result, the gateway 300 is notified of the verification result of the FW data signature.
The FW update processing unit 165 determines whether or not the verification of the FW data signature has been successful (step S1304), and if not successful, discards the FW data (step S1305) and does not update the firmware.
If the verification of the FW data signature is successful, the ECU 100b cooperates with the gateway 300 to perform a FW update gateway proxy process (step S1213), which will be described later. The ECU 100b transmits a frame including the result of the firmware update performed by the FW update gateway proxy process to the bus 200a (step S1312). This notifies the gateway 300 of the result of the firmware update.
[1.18 Example of firmware update in ECU100c]
18 is a flowchart showing an example of a FW update control process by an ECU 100c that does not have a signature verification function but has a FW cache function. In the figure, steps similar to those already described are given the same reference numerals. The FW update control process performed by the ECU 100c will be described below with reference to FIG. 18.
In the ECU 100c, the frame transmitting/receiving unit 110 receives the frame including the FW data transmitted in the above-mentioned step S1211 from the gateway 300 (step S1301).
The FW update processing unit 166 of the ECU 100c 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 stores the firmware, which is the content of the boot ROM in the ECU 100c, by copying it to the FW cache holding unit 161 (step S1306).
Next, the FW update processing unit 166 updates the firmware in the boot ROM with the firmware (FW) in the FW data (step S1307), and restarts the processor of the ECU 100c by resetting it (step S1308).
In the ECU 100c, if the startup from the startup ROM is unsuccessful, the startup is performed using the contents of the FW cache holding unit 161, and if the restart in step S1308 is unsuccessful (step S1309), the pre-update firmware stored in the FW cache holding unit 161 is started (step S1310). Then, under the control of the pre-update firmware, the pre-update firmware stored in the FW cache holding unit 161 is copied to the startup ROM, thereby restoring the contents of the startup ROM to the state before the update (step S1311).
If the restart in step S1308 is successful, the ECU 100c transmits a frame including an update result indicating that the firmware update was successful to the bus 200b, and if the restart in step S1308 is not successful, after step S1311, the ECU 100c transmits a frame including an update result indicating that the firmware update was unsuccessful to the bus 200b (step S1312). This notifies the gateway 300 of the firmware update result.
[1.19 Example of firmware update in ECU100d]
19 is a flowchart showing an example of a FW update control process by an ECU 100d that does not have a signature verification function and a FW cache function, in which steps similar to those already described are given the same reference numerals.
The ECU 100d cooperates with the gateway 300 to perform a FW update gateway proxy process (step S1213), which will be described later. The ECU 100d transmits a frame including the result of the firmware update performed by the FW update gateway proxy process to the bus 200b (step S1312). As a result, the gateway 300 is notified of the result of the firmware update.
[1.20 FW update gateway proxy processing in Gateway 300 and ECU]
The FW update GW proxy processing will be described below with reference to Fig. 20. Fig. 20 is a sequence diagram showing an example of the FW update GW proxy processing in which the gateway 300 performs part of the processing when updating firmware in the ECUs (ECUs 100b and 100d).
First, the gateway 300 requests an ECU that does not have a FW cache function and is a target for firmware update to transmit boot ROM data (firmware before the update in the boot ROM) (step S1401a).
The ECU receives the request from the gateway 300 (step S1401b) and transmits the boot ROM data (firmware in the boot ROM) of the ECU (step S1402a).
The gateway 300 receives the boot ROM data from the ECU (step S1402b), stores a copy in the FW cache holding unit 371 (step S1403), and creates updated ROM data (e.g., data updated by applying the firmware of the update FW data to the firmware before the update) (step S1404).
Next, the gateway 300 transmits the created update ROM data (step S1405a), and this update ROM data is received by the ECU whose firmware is to be updated (step S1405b).
The ECU that has received the update ROM data updates the data in the boot ROM with the update ROM data (step S1406), and restarts the processor of the ECU by resetting it (step S1407). Note that, when restarting, the ECU is set in advance to request retransmission of the boot ROM data if the boot from the boot ROM is not successful, and if the restart in step S1407 is not successful (step S1408), the ECU requests retransmission of the boot ROM data (step S1409a). In response to this, when the gateway 300 receives a retransmission request for the boot ROM data (step S1409b), it transmits the boot ROM data stored in the FW cache holding unit 371 (step S1410a). As a result, the ECU receives the boot ROM data (step S1410b), updates the data in the boot ROM with the boot ROM data (step S1406), restores the firmware to the original firmware, and restarts (step S1407). If the restart is successful in step S1408, the ECU ends the firmware update process.
[1.21 Effect of the first embodiment]
In the in-vehicle network system 10 according to the first embodiment, the gateway 300 performs (acts on behalf of) the ECUs connected to the in-vehicle network (buses 200a and 200b) that do not have the functions for updating firmware (signature verification function, FW cache function) as the ECUs to be updated with the firmware. This allows the firmware to be safely updated even in ECUs that do not have the functions required for a secure firmware update.
Second Embodiment Hereinafter, an in-vehicle network system 20, which is a partial modification of the in-vehicle network system 10 shown in the first embodiment, will be described.
In the in-vehicle network system 20 according to the present embodiment, a firmware update method is used in which, when an ECU updates firmware, a gateway device and another ECU perform the necessary processes (e.g., signature verification process, etc.) for a safe and appropriate firmware update instead of an ECU that cannot perform the necessary processes. This enables appropriate firmware update even in an ECU that does not have a function for performing the processes required for firmware update or an ECU that is in a state where it cannot perform the function. In terms of points that are not specifically described in this embodiment, the in-vehicle network system 20 is similar to the in-vehicle network system 10.
[2.1 Overall configuration of the in-vehicle network system 20]
FIG. 21 is a diagram showing an overall configuration of an in-vehicle network system 20 according to the second embodiment.
As shown in Fig. 21, the in-vehicle network system 20 includes ECUs 1100a to 1100d mounted on a vehicle and connected to various devices, buses 200a and 200b, a gateway 1300, a network 400 outside the vehicle, and a server 500. Note that the in-vehicle network system 20 may include several ECUs other than the gateway 1300 and the ECUs 1100a to 1100d, but for the sake of convenience, the following description focuses on the gateway 1300 and the ECUs 1100a to 1100d. In Fig. 21, the same components as those in the in-vehicle network system 10 shown in the first embodiment are denoted by the same reference numerals as those in Fig. 1, and description thereof will be omitted here.
The ECUs 1100a to 1100d 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, and acquire the status of the devices and periodically transmit frames (data frames) indicating the status to an in-vehicle network constituted by the buses 200a and 200b, etc. The ECU information relating to the ECUs 1100a to 1100d is similar to that shown in FIG.
The gateway 1300 is a kind of ECU as a gateway device connected to the bus 200a to which the ECU 1100a and the ECU 1100b are connected, and to the bus 200b to which the ECU 1100c and the ECU 1100d are connected. The gateway 1300 is a partial modification of the gateway 300 shown in the first embodiment, and has a function of acting as a proxy for processing for updating firmware of a certain ECU in cooperation with an ECU other than the ECU. The functional configuration of the gateway 1300 is similar to the configuration of the gateway 300 shown in FIG. 3. The FW update processing unit 370 in the gateway 1300 functions as a control unit that determines whether or not the ECU to which the firmware for update is applied (update target) satisfies a predetermined condition (conditions such as having a signature verification function, having a FW cache function, etc.) based on information of the ECU, and causes the ECU to execute a predetermined process related to the firmware update (signature verification process, process related to the FW cache function, etc.) if the predetermined condition is satisfied, and controls the ECU to execute the predetermined process in another ECU (i.e., a selected substitute ECU) if the predetermined condition is not satisfied. Similarly to the gateway 300, the gateway 1300 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 has a function of distributing FW update information, which is data for updating the firmware of the ECUs 1100a to 1100d.
[2.2 Example of FW update control processing by Gateway 1300]
In the in-vehicle network system 20, similarly to the in-vehicle network system 10, FW update information is distributed from the server 500, and the ECU updates the firmware under the control of the gateway 1300 (see FIG. 14).
Fig. 22 is a flowchart showing an example of a FW update control process by the gateway 1300. This FW update control process corresponds to step S1109 in Fig. 14, which is executed by the gateway 1300 that receives the FW update information distributed from the server 500. Note that steps similar to those in the FW update control process of the first embodiment (see Fig. 15) are given the same reference numerals in Fig. 22 as in Fig. 15, and descriptions thereof will be omitted here as appropriate.
The gateway 1300 acquires the number of FWs in the FW update information (see FIG. 13) by the FW update processing unit 370 (step S1201), and repeats the processes of steps S1203 to S1212, S2207, S2213, etc., for the number of FWs (step S1202).
In step S1203, the gateway 1300 identifies the ECU whose firmware is to be updated by the ECU-ID of the FW data in the FW update information, and determines whether the ECU to be updated has a signature verification function by referring to the list of ECU information (see FIG. 6) stored in the ECU information storage unit 372 (step S1204).
If it is determined in step S1204 that the ECU to be updated does not have a signature verification function, the gateway 1300 performs signature verification ECU proxy processing (described later) (step S2207). Through this signature verification ECU proxy processing, the gateway 1300 causes another ECU to verify the FW data signature in the ECU to be updated.
After step S1206 or step S2207, the gateway 1300 judges the result of verification of the FW data signature (step S1208), and discards the FW data if the verification is unsuccessful (step S1209). If the verification is successful, the gateway 1300 refers to the list of ECU information (see FIG. 6) and judges whether the ECU to be updated has a FW cache (has a FW cache function) (step S1210).
If it is determined in step S1210 that the ECU to be updated does not have the FW cache function, the gateway 1300 performs a FW updating ECU proxy process, which will be described later (step S2213).
[2.3 Signature verification ECU proxy processing example]
FIG. 23 is a flowchart showing an example of signature verification ECU proxy processing by the gateway 1300.
Based on the list of ECU information (see FIG. 6) held by the ECU information holding unit 372, the gateway 1300 selects an ECU other than the ECU to be updated that has a function of executing processing associated with the firmware update as an ECU that will substitute for the processing (substitute ECU) (step S2200). Specifically, in the signature verification ECU substitute processing, an ECU that has a signature verification function (e.g., an ECU that has a key for verifying a signature) is selected as the substitute ECU that will substitute for the processing related to the signature verification function.
In the gateway 1300, for the proxy ECU selected in step S2200, the FW update processing unit 370 causes the frame generating unit 380 to generate a frame including FW data to be transmitted to the proxy ECU, and the frame transmitting/receiving unit 310 transmits the frame to the proxy ECU via the bus to which the proxy ECU is connected (step S1205). Then, the gateway 1300 receives the verification result of the signature for the FW data (FW data signature) by the proxy ECU (step S1206).
[2.4 Example of FW update ECU proxy processing in Gateway 1300 and ECU]
Fig. 24 is a sequence diagram showing an example of FW update ECU substitution processing by the gateway 1300 and ECUs (ECUs 1100a and 1100d). The example in the figure shows an example in which the ECU 1100a substitutes for the ECU 1100d that does not have the FW cache function. Note that the same steps as those shown in Fig. 21 in the first embodiment are denoted by the same reference numerals in Fig. 24, and explanations thereof will be omitted here as appropriate.
Based on the list of ECU information (see FIG. 6) held by the ECU information holding unit 372, the gateway 1300 selects an ECU having a function of executing processing associated with firmware update, other than the ECU to be updated with firmware, as an ECU (acting ECU) that will act on behalf of the processing (step S2200). Specifically, in the FW update ECU acting processing, the gateway 1300 selects the ECU 1100a having a FW cache function as an acting ECU that will act on behalf of the processing related to the FW cache function.
Next, the gateway 1300 transmits the FW data via the bus 200a to the ECU 1100a, which is a proxy ECU that performs the FW cache function for the ECU 1100d that is the target of firmware update (step S2400a). The ECU 1100a receives the FW data (step S2400b), recognizes that it should function as a proxy ECU related to the FW cache function, and waits for the reception of the boot ROM data.
Next, the gateway 1300 requests the ECU 1100d, which does not have a FW cache function and is a target for firmware update, to transmit boot ROM data (firmware before update in the boot ROM) (step S2401a). The ECU 1100d, which is a target for firmware update, receives the request from the gateway 1300 (step S2401b) and transmits the boot ROM data (firmware in the boot ROM) of the ECU 1100d (step S2402a). The boot ROM data (firmware in the boot ROM) transmitted from the ECU 1100d to the bus 200b is transferred by the gateway 1300 and received by the ECU 1100a via the bus 200a (step S2402b). Note that in FIG. 24, the process of transferring frames between buses by the gateway 1300 is omitted, and the transfer of frames between buses will not be described below.
The ECU 1100a receives the boot ROM data from the ECU 1100d (step S2402b), stores a copy in the FW cache holding unit 371 (step S1403), and creates update ROM data based on the boot ROM data and the FW data (step S1404).
Next, the ECU 1100a transmits the created update ROM data (step S2405a), and the ECU 1100d receives this update ROM data (step S2405b).
The ECU 1100d that has received the update ROM data updates the data in the boot ROM with the update ROM data (step S1406), and restarts the processor of the ECU 1100d by resetting it (step S1407). Note that the ECU 1100d is set in advance to request retransmission of the boot ROM data if booting from the boot ROM is unsuccessful at the time of restart, and requests retransmission of the boot ROM data (step S2409a) if the restart in step S1407 is unsuccessful (step S1408). In response to this, when the ECU 1100a receives a retransmission request for the boot ROM data (step S2409b), it transmits the boot ROM data stored in the FW cache holding unit 371 (step S2410a). As a result, the ECU 1100d receives the boot ROM data (step S2410b), updates the data in the boot ROM with the boot ROM data (step S1406), restores the firmware to the original firmware, and restarts (step S1407). If the restart is successful in step S1408, the ECU 1100d ends the firmware update process.
[2.5 Effects of the second embodiment]
In the in-vehicle network system 20 according to the second embodiment, the gateway 1300 controls the ECU connected to the in-vehicle network (buses 200a, 200b) to select another ECU capable of processing the functions related to the ECU that is the target of firmware update and have the ECU select and perform the processing instead of the ECU that does not have the functions for updating (signature verification function, FW cache function). This makes it possible to effectively utilize the resources of the ECU and safely update the firmware even in an ECU that does not have the functions required for a secure firmware update. In addition, the gateway 1300 does not need to have the ability to perform the substitution, which is useful in terms of cost reduction.
(Other embodiments) As described above, the first and second embodiments have been described as examples of the technology according to the present invention. However, the technology according to the present invention is not limited to these, and can be applied to embodiments in which appropriate changes, substitutions, additions, omissions, etc. are made. For example, the following modified examples are also included in one embodiment of the present invention.
(1) Although the ECUs such as ECUs 100a to 100d, 1100a to 1100d shown in the above embodiment are, for example, devices including digital circuits such as a processor and a memory, an analog circuit, a communication circuit, etc., they may also include other hardware components such as a hard disk drive, a display, a keyboard, a mouse, etc. Also, instead of a control program stored in a memory being executed by a processor to realize a function in a software manner, the function may be realized by dedicated hardware (digital circuit, etc.).
Furthermore, among the ECUs such as ECUs 100a to 100d, 1100a to 1100d, etc., a plurality of ECUs may be realized by a virtual environment constructed by one physical device (computer), etc. Fig. 25 is a diagram showing an example of a software configuration of a virtual environment realized by a computer 800 as an example of an ECU configuration.
As shown in the figure, the software running on computer 800 includes a virtual machine monitor 801, virtual machines 802, 803, 804, 805, virtual hardware 810, 820, 830, 840, general-purpose OSs (operating systems) 811, 821, an RTOS (real-time operating system) 831, firmware 841, app (application program) A 812, app B 813, app C 814, app D 822, and app E 832.
The computer 800 is a computer that executes software (such as a virtual machine monitor 801) on a processor. The virtual machine monitor 801 has a virtual machine control function that controls virtual machines 802 to 805 so that they operate independently of one another on the virtual machine monitor 801, a resource management function that allocates and manages hardware resources such as memory and CPU to the virtual machines, a device access function that accesses devices in response to requests from the virtual machines, and a scheduling function that schedules the virtual machines. Each of the virtual machines 802 to 805 is configured to include 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 provide virtual hardware functions to each virtual machine virtually, and also provide an IPL (Initial Program Loader), a BIOS (Basic Input/Output The general-purpose OS 811 has a function of loading and executing applications (application A 812, application B 813, application C 814) on memory, or deleting (unloading) each application from memory, and provides each application with a network communication function by the CAN protocol. The general-purpose OS 821 is similar. The RTOS 831 is an OS for running applications that emphasize real-timeness. The application A 812, application B 813, application C 814, application D 822, and application E 832 have various functions for automobiles, such as a car navigation function, a driving assistance function, a steering control function, an engine control function, a brake control function, and a function for acquiring sensor information (torque, angle, speed, rotation speed, etc.). Each of these functions for automobiles may be executed by one application or may be executed by multiple applications. The firmware 841 is software or the like that operates functions that do not require an OS. The firmware 841 may include an OS, or may have a function of becoming an operating environment for other applications and controlling the execution of the other applications. 25 is merely an example, and more applications may be run. Also, although the figure shows two virtual machines running a general-purpose OS, one virtual machine running an RTOS, and one virtual machine running firmware, this is merely an example. The virtual environment may be configured, for example, only with a virtual machine running firmware, or only with a virtual machine running firmware and a virtual machine running RTOS.
In the computer 800, all or some of the ECUs among the ECUs 100a-100d, 1100a-1100d, etc. are realized by one virtual machine such as the above-mentioned virtual machines 802-805. For example, a plurality of virtual machines 805 (as many as the number of ECUs constituting the operating environment) are generated and operated on the virtual machine monitor 801, and the operation of the hardware aspect of one ECU is realized by the virtual hardware 840 of each virtual machine 805, and for example, the firmware 841 has the same content as the firmware implemented in that ECU. For example, the virtual machine monitor 801 is configured to realize communication between the ECUs via a bus between the plurality of virtual hardware operating thereon.
(2) In the above embodiment, the gateway 300, 1300 having the external communication unit 375 (external communication function) communicates with the server 500 via the network 400 outside the vehicle, but this is merely one example. For example, the gateway 300, 1300 may communicate with the server 500 via another ECU (e.g., a head unit) having a function of communicating with the outside. The head unit is a type of ECU equipped with a relatively high-performance processor, includes a display device such as a liquid crystal display provided on the instrument panel of the vehicle, and is a device that can notify the driver of the vehicle. Note that the in-vehicle network may include an OBD2 (On-Board Display 2) There is a diagnostic port, which is an interface for communicating with an external device such as a diagnostic tool, called a diagnostics port 2, etc., and is used for diagnosing the ECU. Therefore, the gateway 300, 1300 may indirectly communicate with the server 500 by communicating with an external device that can communicate with the server 500 and is connected to the diagnostic port. In these cases, the gateway 300, 1300 does not necessarily have an external communication function for communicating with the outside of the vehicle, and FW update information and the like can be exchanged between the gateway 300, 1300 and the server 500 via another ECU or an external device. The gateway 300, 1300 may also acquire FW update information stored in an external storage medium (such as a non-volatile memory) connected to the gateway 300, 1300 itself or another ECU.
(3) In the above embodiment, an in-vehicle network is shown as an example of a network communication system that communicates according to the CAN protocol. The technology according to the present invention is not limited to an in-vehicle network, but can also be applied to networks of robots, industrial equipment, and other network communication systems that communicate according to the CAN protocol other than an in-vehicle network. In addition, the CAN protocol should be treated in a broad sense as including CANOpen, which is used in embedded systems in automation systems, or derivative protocols such as TTCAN (Time-Triggered CAN) and CANFD (CAN with Flexible Data Rate). In addition, in the above embodiment, an example is shown in which firmware-related data (frames) are transmitted and received over a bus based on the CAN protocol, but another protocol may be applied, and any communication path and communication method for communicating firmware-related data can be used.
(4) In the above embodiment, a signature is attached to the data (FW data, FW update information, etc.) to ensure the integrity of the data, but the data may be encrypted to further ensure confidentiality. The signature key and the encryption key may be separate keys.
(5) In the above embodiment, the same key is used to generate the signature for the FW update information and the signature for the FW data, but different keys may be used for each. For example, the signature for the entire FW update information as distribution data (FW update information signature) may be generated using a key held by the automobile manufacturer, and the signature for each piece of FW data (FW data signature) may be generated using a key held by the manufacturer of the ECU that implements the firmware related to the FW data (or the manufacturer of the firmware). In response to this, in order for the gateway 300 to substitute for the verification of the signature of the ECU, the gateway 300 is configured to hold a necessary key in advance. Also, if the key used for the signature of the FW data in the server 500 is a key determined for each manufacturer of the ECU that implements the firmware, the gateway 1300 may select an ECU made by the same manufacturer as the ECU to be updated with firmware (an ECU that holds a key necessary for signature verification of the manufacturer) as a substitute ECU based on the list of ECU information (see FIG. 6). In addition, the ECU information may include information on whether or not the ECU has the ability to act as a proxy for signature verification function (whether or not the ECU has a key to act as a proxy for signature verification for firmware other than its own device), and gateway 1300 may select an acting ECU based on that information.
(6) In the above embodiment, the gateway 300, 1300 determines whether to control the processing of the ECU to be updated by an ECU other than the ECU or a gateway, or to have the ECU to be updated execute the processing (i.e., whether or not substitution is necessary) based on the list of ECU information held by the ECU information holding unit 372. This determination of whether or not substitution is necessary (determination of whether or not the ECU to be updated satisfies a predetermined condition) can be made, for example, based on information indicating the processing capacity of the ECU for each ECU (e.g., whether or not it has a function to execute a predetermined process). Substitution is necessary when the predetermined condition is not satisfied. The presence or absence of a function to execute a predetermined process refers to, for example, the presence or absence of a signature verification function, a FW cache function, etc. The FW update processing unit 370 (control unit) of the gateway 300, 1300 can determine that an ECU to which the update firmware is applied (i.e., the update target) satisfies the predetermined condition when it has the function to execute the predetermined process, and does not satisfy the predetermined condition when it does not have the function to execute the predetermined process. The information indicating the processing capacity of the ECU may be information on the presence or absence of a signature verification function and a FW cache function, as well as information on the memory capacity and processing performance of the ECU. The gateways 300 and 1300 may make this determination based on the communication load status in the in-vehicle network, the load status of the processor of the ECU, etc. For example, even if there is processing capacity, if the processor load is higher than a certain level, it may be determined that substitution is necessary.
(7) The update firmware (binary data) shown in the above embodiment may be the entire firmware implemented in the ECU or a part of it. When the update firmware is a part of the firmware implemented in the ECU, it is overwritten on a part of the existing firmware in the ECU. In this case, the update firmware may be configured to include difference data (binary data) and information (e.g., address information, etc.) indicating which part it is applied to. In this case, the difference data may be merged with the existing firmware in the gateway 300, the ECU to be updated, or the substitute ECU, and then the firmware in the boot ROM of the ECU may be replaced.
(8) The order of execution of the various processing steps shown in the above embodiments (e.g., the steps shown in Figures 14 to 20 and Figures 22 to 24) is not necessarily limited to the order as described above, and the order of execution may be changed, multiple steps may be performed in parallel, or some of the steps may be omitted, without departing from the spirit of the invention.
(9) Some or all of the components constituting each device in the above embodiments may be composed of one system LSI (Large Scale Integration). The system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on one chip, and specifically, a computer system including a microprocessor, a ROM, a RAM, etc. A computer program is recorded in the RAM. The microprocessor operates according to the computer program, and the system LSI achieves its functions. Each component constituting each device may be individually integrated into one chip, or may be integrated into one chip including some or all of the components. Although the system LSI is used here, it may be called an IC, an LSI, a super LSI, or an ultra LSI depending on the degree of integration. The method of integration is not limited to an LSI, and may be realized by a dedicated circuit or a general-purpose processor. After the LSI is manufactured, a field programmable gate array (FPGA) that can be programmed may be used. It is also possible to use a reconfigurable processor that can reconfigure the connections and settings of circuit cells inside an LSI. Furthermore, if an integrated circuit technology that can replace LSI appears due to the progress of semiconductor technology or a different derived technology, it is natural that such technology can be used to integrate functional blocks. The application of biotechnology is also a possibility.
(10) Some or all of the components constituting each of the above devices may be composed of an IC card or a standalone module that can be attached to each device. The IC card or the module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or the module may include the above-mentioned ultra-multifunction LSI. The microprocessor operates according to a computer program, causing the IC card or the module to achieve its functions. This IC card or this module may be tamper-resistant.
(11) One aspect of the present invention may be a firmware update method including all or part of the processing procedures shown in, for example, Figures 14 to 20, Figures 22 to 24, etc. The firmware update method may include, for example, a receiving step of receiving FW update information including update firmware from an external device outside the vehicle, such as step S1106b. The firmware update method may also include a control step of determining whether an ECU to be updated with firmware satisfies a predetermined condition, such as steps S1204 to S1207 or steps S1210 to S1213, and causing the ECU to execute a predetermined process related to firmware update if the predetermined condition is satisfied, and controlling the ECU to execute the predetermined process other than the ECU if the predetermined condition is not satisfied. The method may also be a computer program (control program) that realizes the method by a computer, or a digital signal consisting of the computer program. For example, the firmware update method may be a control program for executing firmware update processing including the receiving step and the control step in the firmware update method. As another aspect of the present invention, the computer program or the digital signal may be recorded on 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, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, or the like. Alternatively, the digital signal may be recorded on such a recording medium. As another aspect of the present invention, the computer program or the digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like. As another aspect of the present invention, a computer system having a microprocessor and a memory, the memory having the computer program recorded therein, and the microprocessor operating according to the computer program. Alternatively, the program or the digital signal may be recorded on the recording medium and transferred, or the program or the digital signal may be transferred via the network, or the like, to be implemented by another independent computer system.
(12) The scope of the present invention also includes configurations realized by arbitrarily combining the components and functions shown in the above embodiment and modified examples.
INDUSTRIAL APPLICABILITY The present invention can be used to appropriately update firmware of an ECU connected to an in-vehicle network.
10, 20 In-vehicle network system
100a~100d, 1100a~1100d Electronic control unit (ECU)
101 engine
102 brake
103 Door Open/Close Sensor
104 Window open/close sensor
110, 310 Frame transmitter/receiver
120, 320 Frame Interpretation Section
130, 330 Reception ID determination unit
140, 340 Reception ID list storage section
150, 350 frame processing section
160, 165-167, 370 FW update processing unit
161, 371 FW cache holder
163, 373 Signature Verification Department
164, 374, 591 Key holder
170 Data Acquisition Section
180, 380 Frame Generation Unit
200a, 200b bus
300, 1300 Gateway
360 Transfer rule storage
372 ECU information storage unit
375 External Communications Department
400 network
500 server
510 Data transmission/reception unit
570 Distribution data generation unit
571 FW holding part
572 ECU management information storage unit
590 Signature Generation Unit
800 computer
801 Virtual Machine Monitor
802~805 Virtual Machine
810, 820, 830, 840 Virtual Hardware
841 firmware
25 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2015103163A | Cites | Japan |
| JP2014182571A | Cites | Japan |
| JP2007528067A | Cites | Japan |
| JP2012218621A | Cites | Japan |
| JP2005259023A | Cites | Japan |
| JP2004038766A | Cites | Japan |
| KR1020130046904A | Cites | Republic of Korea |
| JP2012185541A | Cites | Japan |
| JP2010170320A | Cites | Japan |
27 members in 5 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 201562218111 | United States of America | P | |
| 62218111 | United States of America | – | |
| 2016109585 | Japan | A | |
| 2022076389 | Japan | A |
Members27
| Document | Office | Kind | |
|---|---|---|---|
| JP2017059211A | Japan | A | |
| WO2017046980A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CN106796538A | China | A | |
| US2017192770A1 | United States of America | A1 | |
| EP3352079A1 | European Patent Office (EPO) | A1 | |
| EP3352079A4 | European Patent Office (EPO) | A4 | |
| JP6675271B2 | Japan | B2 | |
| JP2020107355A | Japan | A | |
| US10725762B2 | United States of America | B2 | |
| US2020310782A1 | United States of America | A1 | |
| JP6889296B2 | Japan | B2 | |
| JP2021121963A | Japan | A | |
| JP7071574B2 | Japan | B2 | |
| JP2022093680A | Japan | A | |
| EP3352079B1 | European Patent Office (EPO) | B1 | |
| EP4113287A1 | European Patent Office (EPO) | A1 | |
| US11599349B2 | United States of America | B2 | |
| US2023153099A1 | United States of America | A1 | |
| JP7280412B2 | Japan | B2 | |
| JP2023090981A | Japan | A | |
| US11842185B2 | United States of America | B2 | |
| US2024053977A1 | United States of America | A1 | |
| EP4113287B1 | European Patent Office (EPO) | B1 | |
| CN106796538B | China | B | |
| CN118312196A | China | A | |
| JP7585387B2This record | Japan | B2 | |
| US12169708B2 | United States of America | B2 |
8 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 7585387
- Application
- 78587
Titles2
- Japanese
- ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
- English
- Gateway device, in-vehicle network system, and firmware update method
Classification
- CPC, 13
- G06F8/65
- G06F8/654
- B60R16/023
- B60R16/02
- G06F11/00
- G06F11/1433
- G06F21/64
- G06F2201/83
- H04L12/40006
- H04L12/4625
- H04L67/12
- H04L67/34
- H04W4/48
- IPC, 4
- G06F8 65
- G06F9 455
- G06F21 57
- B60R16 02
