JP2019164809A - Software updating system of mobile body using on-vehicle gateway device - Google Patents

Abstract

To provide a software updating system to be executed in a mobile body via an on-vehicle GW device.SOLUTION: A system includes: an on-vehicle GW device 200 to be connected to a predetermined system for controlling a mobile body; and a SW updating device 100 for delivering software to be executed in the predetermined system to the on-vehicle GW device 200. The SW updating device 100 delivers software to the on-vehicle GW device 200 on the basis of delivery side log information related to software to be delivered. The on-vehicle GW device 200 transmits mobile body side log information where a software reception result is recorded to the SW updating device 100. When it is determined that mobile body side log information is not coincident with delivery side log information after matching the respective pieces of log information, the SW updating device 100 performs control to allow the on-vehicle GW device 200 to update mobile body side log information and also re-delivers software to the on-vehicle GW device 200 on the basis of delivery side log information updated by non-coincidence of log information.SELECTED DRAWING: Figure 10

Description

  Embodiments described herein relate generally to a software update technique executed in a mobile body via an in-vehicle gateway device provided in the mobile body such as a vehicle.

  For example, the entire vehicle is managed by a vehicle control system. The vehicle control system controls a vehicle by executing a plurality of control programs. Software used in the vehicle control system (control program and data used for execution of the control program) may be appropriately updated (installation of a correction program or / and a new program). The software update can be performed by data communication via a network, or at a dealer or a factory.

JP 2004-254120 A JP-A-11-239126 International Publication No. 2004/028112

  Provided is a software update system executed in a mobile body via an in-vehicle gateway device provided in the mobile body.

  The software update system according to the embodiment updates software executed in a predetermined system for controlling a moving body. The software update system includes an in-vehicle gateway device provided in a moving body and connected to the predetermined system, and a software update device connected to the in-vehicle gateway device via a network. The software update device includes a software update control unit that performs distribution control for distributing the software to the in-vehicle gateway device based on distribution-side log information related to software distributed to the in-vehicle gateway device. The in-vehicle gateway device includes a software update management unit that transmits mobile-side log information in which a reception result of the software is recorded to the software update device. The software update control unit updates the log information of the delivery-side log information when the mobile-side log information and the delivery-side log information are matched and it is determined that the log information does not match, and The in-vehicle gateway device is controlled to update the log information in the mobile-side log information, and the software is retransmitted to the in-vehicle gateway device based on the distribution-side log information updated due to the mismatch of the log information. To deliver.

It is the schematic of the software update system of 1st Embodiment. 1 is a network configuration diagram inside and outside a vehicle to which an in-vehicle gateway device of a first embodiment is applied. It is a figure which shows the structural block of the vehicle-mounted gateway apparatus of 1st Embodiment. It is a figure which shows the structural block of the software update apparatus of 1st Embodiment. It is a figure which shows an example of the software management information of the Tree structure with respect to the some mobile body of 1st Embodiment. It is a figure for demonstrating the specific key of the moving body based on the group key encryption system of 1st Embodiment. It is a flowchart which shows the registration process of the moving body specific key based on the group key encryption system of 1st Embodiment. It is a figure for demonstrating the simultaneous update of the software by the specific key of the mobile body of 1st Embodiment. It is a figure for demonstrating the delivery control of the software using the delivery side log file and mobile body side log file of 1st Embodiment. It is a flowchart which shows the software update process via the vehicle-mounted gateway apparatus of 1st Embodiment. It is a flowchart which shows the software update process (difference update process) via the vehicle-mounted gateway apparatus of 1st Embodiment.

  Hereinafter, embodiments will be described with reference to the drawings.

(First embodiment)
FIG. 1 is a schematic diagram of a software update system according to the first embodiment. The software update system of the present embodiment is a software update system that is executed by a mobile body and used for control of the mobile body. In the present embodiment, a vehicle is described as an example of the moving body. However, the present invention can also be applied to other moving bodies (such as trains, robots or flying bodies operated automatically or wirelessly).

  The mobile body is provided with an in-vehicle gateway device 200 (hereinafter referred to as an in-vehicle GW device), and is connected to the software update device 100 via a predetermined network. The software updating apparatus 100 distributes software composed of one or a plurality of program modules to a plurality of mobile units. The mobile body receives the software distributed from the software updating apparatus 100 via the in-vehicle GW apparatus 200, and updates the software executed on the mobile body and the software used for controlling the mobile body.

  Note that the software distributed to the mobile object can include, for example, parameters, various data, procedures, and the like for controlling the execution of each program module, in addition to the program module such as a control program.

  FIG. 2 is a network configuration diagram of the inside and outside of a moving body to which the in-vehicle GW apparatus 200 is applied. In the present embodiment, the in-vehicle GW apparatus 200 provided in the moving body performs update control of software distributed from the software update apparatus 100 (software reception control and software update execution control).

<In-vehicle GW device 200>
First, the in-vehicle GW apparatus 200 will be described. The in-vehicle GW apparatus 200 is an in-vehicle device that is directly connected to an in-vehicle data source or connected to an in-vehicle network to which the data source is connected. The in-vehicle GW apparatus 200 can be connected to a network outside the vehicle, and is configured as a network node that relays between the inside and outside the vehicle. The in-vehicle GW apparatus 200 includes communication interfaces for wireless communication complying with a wireless LAN standard such as Wi-Fi via an access point, and mobile phone communication such as 3G and LTE (Long Term Evolution) relaying a base station. Yes. The in-vehicle GW apparatus 200 can be connected to an external network outside the vehicle through a plurality of communication paths (external communication methods).

  The outside-vehicle network is, for example, an IP (Internet Protocol) network. The in-vehicle GW apparatus 200 can be connected to the software update apparatus 100 via the IP network. The in-vehicle GW apparatus 200 can perform data communication with the software update apparatus 100 and can transmit a mobile log file (including information to be written to the log file), which will be described later, to the software update apparatus 100. Can do. In addition, data communication can be performed with an external service system other than the software update device 100, and various data acquired from an in-vehicle data source can be transmitted to the software update device 100 or a predetermined external service system.

  As shown in FIG. 2, the in-vehicle GW apparatus 200 can be connected to a network outside the vehicle via a portable information terminal having a Wi-Fi or 3G / LTE communication interface. The in-vehicle GW apparatus 200 can be connected to a portable information terminal by USB, or by short-range communication based on a standard such as wireless communication or Bluetooth (registered trademark) / NFC. The portable information terminal is a mobile device having a communication function such as a multi-function mobile phone such as a smartphone, a mobile phone, and a tablet terminal.

  The in-vehicle GW apparatus 200 can be connected to a data source in the vehicle directly or via an existing in-vehicle network. Data sources include, for example, microphones (sound collectors), sensor devices such as human sensors and vital sensors worn by users, drive recorders equipped with cameras (imaging devices), and in-vehicle cameras such as in-car cameras There are in-vehicle information terminals such as navigation systems equipped with display means such as liquid crystal display devices, and in-vehicle LANs. The in-vehicle LAN is connected to the vehicle control system 300, multimedia audio devices, and the like, and these are data sources.

  The in-vehicle GW apparatus 200 performs data communication using a different communication method for each data source according to a communication method provided in each data source or in-vehicle network. For example, the sensor device performs data communication by short-range wireless communication. The in-vehicle camera performs data communication by serial (UART) communication (RS232C, RS422, RS485) connected to the in-vehicle GW apparatus 200 with a cable. The in-vehicle information terminal performs data communication by Ethernet communication connected by a LAN cable.

  The in-vehicle LAN has a built-in in-vehicle network by a communication method such as CAN (Controlled Rare Network), FlexRay, LIN, and MOST (Mediaoriented Systems Transport). The in-vehicle GW apparatus 200 is connected to each of one or a plurality of in-vehicle networks constituting the in-vehicle LAN, and performs data communication by each communication method.

  FIG. 3 is a diagram illustrating a configuration block of the in-vehicle GW apparatus 200. The in-vehicle GW apparatus 200 includes, as a hardware configuration, a communication device 210 that configures a communication interface with each data source and a portable information terminal, and a control device 220 that controls the entire in-vehicle GW apparatus 200. .

  The communication device 210 includes an in-vehicle communication (internal communication) interface 211 such as Ethernet, CAN, UART, USB, and short-range wireless communication, and an external communication (external communication) interface 212 such as wireless communication and mobile phone communication. The in-vehicle communication interface 211 can include a wireless communication function with the portable information terminal and a connection interface such as a USB.

  The control device 220 is configured to include each functional unit that mainly operates by software. First, the control device 220 can control each data source. For example, sensor control (operation and data detection) of the sensor device, shooting control (including video output control) of the in-vehicle camera, and terminal control of the in-vehicle information terminal can be performed.

  Therefore, the control device 220 can output data received from the external network to each data source, or control each data source based on the received data. In addition, one or both data sources can be controlled between data sources. For example, it is possible to perform control for displaying detection data acquired by a sensor device or video captured by an in-vehicle camera on a display of the in-vehicle information terminal.

  The control device 220 according to the present embodiment includes an in-vehicle communication control unit 221, an out-of-vehicle communication control unit 222, a gateway control unit (GW control unit) 223, a software update management unit 224, and a storage unit 225.

  The in-vehicle GW apparatus 200 is installed with device drivers such as wireless communication, mobile phone communication, UART, USB, and short-range wireless communication. The in-vehicle communication control unit 221 and the out-of-vehicle communication control unit 222 perform communication control via the in-vehicle communication interface 211 and the out-of-vehicle communication interface 212 through each device driver. The in-vehicle communication control unit 221 can also control communication with, for example, an in-vehicle LAN (vehicle control system 300) without using a device driver.

  The outside-vehicle communication control unit 222 can perform an access point registration process for wireless communication such as Wi-Fi. For example, the out-of-vehicle communication control unit 222 can detect and register access points at various places as the vehicle physically moves.

  The GW control unit 223 includes a network control unit 223A and a communication control unit 223B. The network control unit 223A includes a routing control unit 2231, a protocol conversion unit 2232, and a security unit 2233. The routing control unit 2231 includes routing control when data collected from each data source (including the vehicle control system 300 via the in-vehicle LAN) is transmitted to the outside network, and data received from the outside network is each data source. Performs routing control when transmitting to. It also performs routing control in data communication between data sources in the in-vehicle network.

  The protocol conversion unit 2232 performs protocol conversion processing between different communication methods corresponding to each data source. A communication method for each data source can be stored in advance as a protocol conversion table. For example, protocol conversion is performed when data received from an external network is transmitted to a data source.

  The security unit 2233 performs communication setting and communication processing of SSL (Secure Sockets Layer) / TLS (Transport Layer Security) protocol. SSL / TLS communication can be set for each data source, and the security unit 2233 checks whether SSL / TLS is set and performs encryption processing when data is transmitted from the in-vehicle network to the external network. be able to.

  The communication control unit 223B includes a communication state monitoring unit 2234, a communication path selection unit 2235, a monitoring control unit 2236, and a Config setting control unit 2237. Based on the Config setting information, the communication control unit 223B can perform communication route selection control, data monitoring control, and data transmission control for transmitting data collected from the data source to the external network.

  The communication path selection unit 2235 can perform communication path selection control based on the communication connection config setting information. The communication connection Config setting information includes a communication path setting at the time of data reception from the outside network to the in-vehicle network and a communication path setting at the time of data transmission from the in-vehicle network to the outside network.

  The in-vehicle GW apparatus 200 of this embodiment is mounted on a moving body such as a vehicle. For this reason, for example, the in-vehicle GW apparatus 200 is assigned a dynamic IP address as a network node. The in-vehicle GW apparatus 200 actively connects to and establishes a connection with the software update apparatus 100 in the outside-vehicle network when transmitting and receiving data.

  The communication connection setting includes automatic setting and / or priority setting. The in-vehicle GW apparatus 200 can be connected to a network outside the vehicle through a plurality of communication method paths. For example, one can be selected from the three routes of Wi-Fi, via a portable information terminal, and 3G / LTE, or priority can be set for the three routes. In addition, the priority of “automatic” can be arbitrarily determined in advance, for example, Wi-fi> via mobile information terminal> 3G / LTE.

  The setting contents of the communication connection can be set to the type of data to be received. For example, the priority of the communication path is changed between the software distributed from the software update apparatus 100 and the data distributed from the other system, or the communication path is determined depending on the data capacity of the software distributed from the software update apparatus 100 You can change the priority.

  The same applies to the communication connection during data transmission from the in-vehicle network to the outside network. For example, automatic setting and / or priority setting can be similarly performed in a communication path for uploading vehicle information acquired from the vehicle control system 300 and a communication path for updating video and images taken by an in-vehicle camera. .

  In addition, the communication connection config setting includes URL designation (registration) of the software updating apparatus 100 that is a connection destination of the outside-vehicle network. A plurality of software updating apparatuses 100 can be provided at a plurality of bases. In this case, each URL of the software update device 100 at each site can be registered. The same applies to the external service system.

  Furthermore, the communication connection Config setting includes a setting for enabling / disabling each of a plurality of communication paths used by the in-vehicle GW apparatus 200. Wi-Fi communication use settings, 3G / LTE communication use settings, and portable information terminal communication use settings can be set to valid (ON) / invalid (OFF).

  The in-vehicle GW apparatus 200 (communication control unit 223B) acquires the communication connection config setting information after activation, and performs communication connection processing for the communication path whose connection flag is ON. The connection flag is valid (ON) / invalid (OFF) in the communication use setting of each communication method. When there are a plurality of communication paths whose connection flags are ON, control is performed so as to maintain communication connections of all the plurality of communication paths. That is, regardless of the monitoring control and data collection / transmission control of the in-vehicle GW apparatus 200, control is performed so as to always maintain a connection state for all of the plurality of communication paths whose connection flags are ON. For each data source, an appropriate communication path is selected based on the Config setting according to the communication state of each communication path, and data communication is performed with the network outside the vehicle.

  The communication state monitoring unit 2234 monitors the communication state (connected / blocked) of the communication path whose connection flag is ON. The communication state monitoring unit 2234 outputs the communication state of each communication path to the communication control unit 223B. Next, the communication state monitoring unit 2234 checks whether or not there is a connection state monitoring end signal (for example, an ignition switch OFF signal of the vehicle). When the monitoring is not terminated, the communication control unit 223B continues to monitor the communication state when it is determined that the communication path whose connection flag is ON is not blocked. On the other hand, when it is determined that the communication is interrupted, the communication control unit 223B performs the communication connection process again for the communication path whose connection flag is ON and is interrupted. On the other hand, when there is an input of a connection status monitoring end signal and the monitoring is ended, all the communication paths being connected are blocked.

  On the other hand, the monitoring control unit 2236 can monitor data output from each data source, and can also set Config setting information used by the monitoring control unit 2236. For example, the in-vehicle LANConfig setting information includes setting information such as a cycle in which vehicle information acquired from the vehicle control system 300 is uploaded to an external network (external system), an average vehicle speed threshold, and a driving time threshold. In addition, the sensor device can measure or / and calculate, for example, the user's heart rate, pulse interval, blood pressure, and the like and output the measured value to the in-vehicle GW apparatus 100. The sensor device Config setting information includes setting information such as a vital information transfer (upload) cycle, a heart rate transfer threshold, and a heart rate abnormality threshold.

  For example, the monitoring control unit 2236 performs monitoring control based on the Config setting information set for each data source. The data source can output time-sequential data to the in-vehicle GW apparatus 200. The monitoring control based on the Config setting information monitors the data collected from the data source. For example, when the data exceeding the threshold is detected, the abnormality detection control for detecting the occurrence of the abnormality and the data collected from the data source are used. And data collection / transmission control to be transmitted to the outside network.

  The monitoring control unit 2236 performs abnormality detection for each data source for data output from the data source, and when an abnormality is detected, for example, a notification process for displaying that the abnormality is detected on the in-vehicle information terminal It can be performed.

  The monitoring control can be performed by confirming the presence or absence of a signal for ending the monitoring control of the data source, such as an OFF signal of an ignition switch of the vehicle, as in the communication state monitoring.

  The Config setting information can be set in advance on the external service system side, or can be set by the user connecting to the external service system. The in-vehicle GW apparatus 200 can be activated by receiving power supply from a vehicle battery or the like in conjunction with ON / OFF of an ignition switch of the vehicle, for example. The in-vehicle GW apparatus 200 can acquire Config setting information by connecting to an external service system at the time of activation. At this time, the in-vehicle GW apparatus 200 can perform a communication route selection process based on the communication connection config setting information.

  The Config setting control unit 2237 sets (updates) the Config setting information input from the external service system to the control device 220 in the storage unit 225 so that the communication path selection unit 2235 and the monitoring control unit 2236 can use them.

  Note that data communication between the in-vehicle GW apparatus 200 and the software update apparatus 100 is performed by using both a user identification ID set in advance and a solid identifier (for example, a MAC address) of the vehicle GW apparatus 200 to perform authentication. It can be carried out. The in-vehicle GW apparatus 200 performs control so that a solid identifier is included in data communication with the software update apparatus 100.

  The storage unit 225 stores various data processed by the control device 220 including the software update management unit 224, information used for each process, data and information received from the outside network. In the example of FIG. 3, the storage unit 225 is built in the in-vehicle GW device 200, but the storage unit 225 may be externally attached to the in-vehicle GW device 200, for example.

<Software update via in-vehicle GW device 200>
In the present embodiment, the in-vehicle GW apparatus 200 is connected to the vehicle control system 300 via the in-vehicle LAN, and receives software executed by a control apparatus such as a vehicle ECU configuring the vehicle control system 300 from the software update apparatus 100. . The software update apparatus 100 can distribute not only software for updating existing software on a mobile body but also new software executed on the mobile body. The software update apparatus 100 can be executed on the mobile body. Therefore, it is positioned as a management device that performs distribution management of software used for control of a mobile object.

  FIG. 4 is a diagram illustrating a configuration block of the software update apparatus 100 according to the present embodiment. The software update device 100 includes a communication device 110, a control device 120, and a storage device 130.

  The communication device 110 controls data communication and connection with the in-vehicle GW device 200 as a mobile object. The communication device 110 communicates with the in-vehicle GW device 200 according to wireless LAN standards such as Wi-Fi via an access point, and mobile phones such as 3G and LTE (Long Term Evolution) that relay base stations. Communication can be performed. The software update device 100 can be connected to the mobile in-vehicle GW device 200 through a plurality of communication paths. For example, the update software can be distributed through an IP (Internet Protocol) network.

  The control device 120 includes a software management unit (SW management unit) 121, a key management unit 122, and a software update control unit (SW update control unit) 123.

  The software update system according to the present embodiment distributes software used for controlling each mobile object to a plurality of mobile objects. FIG. 5 is a diagram illustrating an example of software management information having a tree structure for a plurality of moving objects.

  As shown in FIG. 5, for example, the vehicle control system includes a plurality of control systems, and hardware operation control by software is performed in each control system. These control systems are, for example, commonly used among different vehicle types or commonly used in each year of the vehicle. Conversely, there may be differences between the same model and the same model year.

  Therefore, the software used for the control of the vehicle control system needs to be associated with the software used for each of the plurality of control systems and with the vehicle to which the software is applied. Management is extremely complex. Therefore, in this embodiment, as shown in the example of FIG. 5, the control system, the software used in the control system, the vehicle type to which the software is applied, the model year, and the vehicle body number are used as the nodes, and the nodes are connected in a tree structure. Group management.

  The SW management unit 121 receives input of attributes (vehicle type, model year, body number, etc.) of each of the plurality of moving objects and information regarding each software used in the control system of each moving object, and each node illustrated in FIG. And a group management function in which each node is linked by a tree structure. The software management information having a tree structure is stored in the storage device 130. In addition, the SW management unit 121 receives registration of update software in each node of the tree-structured software management information, and stores the update software in the storage device 130 in association with each node.

  On the other hand, when the number of mobile units that perform software management increases, software distribution control also becomes complicated. For example, for security reasons, it is necessary to set a different secret key for each mobile unit, encrypt software with a different secret key for each mobile unit, and distribute it individually to each target mobile unit. In addition, for example, tens of thousands and hundreds of thousands of vehicles are produced and sold annually, so it is not realistic to assign and manage a unique secret key to each vehicle. In particular, in recent years, software sharing among vehicle types and model years is also progressing, and efficient software management is required for a huge number of vehicles that are increasing every year.

  In the present embodiment, while managing each node of the software management information having a tree structure, a group key encryption method is applied, and the software to be distributed is encrypted using a common group key and transmitted to each mobile unit. FIG. 6 is a diagram for explaining a unique key of a mobile object based on the group key encryption method.

  The key management unit 122 assigns a node key to each node of the tree-structured software management information. The node key is an encryption key. For example, in comparison with the example of FIG. 4, energy control is managed as an upper node, and battery control software and heat management software are managed as lower nodes. Therefore, the node key “K0XXX” is assigned to the upper node, the node key “K00XXX” is assigned to the lower node “battery control software”, and the node key “K01XXX” is assigned to the “thermal management software”.

  Further, node keys “K000XX” and “K001XX” corresponding to a plurality of vehicle types that are lower nodes are assigned to the node “battery control software”, and further, the node key “K0000X” is assigned to “year” that is a lower node of the vehicle type. , “K0001X” is assigned. Then, node keys of “K00000” and “K00001” are assigned to the lowest node, that is, the vehicle body number that uniquely identifies the moving object.

  Therefore, the mobile body holds, for example, five encryption keys of “K00000”, “K0000X”, “K000XX”, “K00XXX”, and “K0XXX” as unique keys. The key management unit 122 generates a unique key for each mobile body by decrypting these encryption keys, and registers and manages them.

  FIG. 7 is a flowchart showing the registration process of the unique key of the mobile based on the group key encryption method. The SW management unit 121 accepts input of information about each software used in the control system, such as the attributes of the plurality of moving objects (vehicle type, year, body number, etc.), and sets each node and sets each node to a tree structure. The software management information having the Tree structure linked in the above is generated and stored in the storage device 130 (S101).

  The key management unit 122 assigns a node key to each node of the generated software management information of the Tree structure (S102), combines each node key from the highest node to the lowest node, A unique key is generated (S103). The key management unit 122 stores the generated unique keys of the mobile objects in the storage device 130 (S104), and also stores the unique keys of the mobile objects registered in the software updating apparatus 100 in the respective mobile objects (the in-vehicle GW device 200). (S105).

  The unique key possessed by each mobile unit is generated using a plurality of node keys based on the group key encryption method, and is shared between the software updating apparatus 100 and the mobile unit. FIG. 8 is a diagram for explaining simultaneous update of software using a unique key according to the present embodiment. As illustrated in FIG. 8, for example, when “battery control software” is updated, the SW update control unit 123 determines the node key “K00XXX” of “battery control software” from the correspondence between the software management information and the node key. The node key “K0XXXX” of the upper node is extracted. The SW update control unit 123 encrypts software to be distributed using a group key in which the node key “K00XXX” and the node key “K0XXX” are combined, and distributes it to each mobile unit belonging to the lower node of “battery control software” To do.

  Since the mobile body holds each node key in advance, the encrypted software received from the software updating apparatus 100 is decrypted with the group key obtained by decrypting the node key “K00XXX” and the node key “K0XXXX”. Return to plain text.

  As described above, in the present embodiment, when updating the “battery control software”, it is possible to ensure the security without specifying the lower-level node, that is, the mobile unit, by simply specifying the node key “K00XXX”. However, it is possible to distribute software for a plurality of mobile objects all at once.

  In addition, when updating the “battery control software” only for “car model A”, the SW update control unit 123 determines the node key “K000XX” corresponding to “car model A” from the correspondence between the software management information and the node key. Can be encrypted using group keys “K000XX”, “K00XXX”, and “K0XXX”, and distributed to each mobile unit belonging to the lower node of “car type A”.

  Next, the software update method of this embodiment will be described with reference to FIGS. In this embodiment, the reliability of software distribution to the mobile body is improved by sharing the log file between the software updating apparatus 100 and the mobile body (vehicle-mounted GW apparatus 200) and collating them. I am letting.

  FIG. 9 is a diagram for explaining software distribution control using the distribution-side log file and the mobile-side log file. First, the distribution-side log file is generated for each piece of software to be distributed, and the unique key (including the node key of the upper node) of the mobile object to be distributed is recorded. Distribution OK / NG is recorded for each of a plurality of program modules constituting the software.

  The mobile unit log file has the same configuration, in which the mobile unit's own key (including the node key of the upper node) is recorded, and the received OK / NG is recorded for each of a plurality of program modules constituting the software. Is done. The software update device 100 and the mobile unit each have the same log file. The distribution history indicating distribution OK / NG corresponds to the reception history indicating reception OK / NG, and the distribution history does not change from distribution NG to distribution OK just by distributing software from the software update device 100. Transition from distribution NG to distribution OK is based solely on the reception history (received record) on the mobile unit side.

  In the present embodiment, an example in which software is configured by a plurality of program modules has been described. However, the present invention is not limited to this, and includes, for example, a mode in which software is divided into a plurality of distributions. Further, in software composed of a plurality of program modules, an arbitrary program module can be distributed, or only one program module can be distributed.

  FIG. 10 is a flowchart showing software update processing via the in-vehicle GW apparatus 200. The in-vehicle GW apparatus 200 transmits an activation signal to the software updating apparatus 100 when the moving body is activated, for example, when an ignition switch of the vehicle is turned on (S301). When receiving the activation signal from the in-vehicle GW device 200 (YES in S111), the software update device 100 checks the distribution-side log file related to the fixed key of the mobile object (S112).

  For example, the correspondence between the fixed key of the mobile object and the in-vehicle GW apparatus 200 can be stored in the storage device 130 in advance. The SW update control unit 123 uses the MAC address and the vehicle body number of the in-vehicle GW device 200 included in the activation signal transmitted from the in-vehicle GW device 200 to identify the moving body and extract the corresponding distribution side log file. Can do. That is, the mobile body (vehicle-mounted GW apparatus 200), the distribution-side log file, and the fixed key are associated with each other.

  The SW update control unit 123 refers to the extracted delivery-side log file and checks whether or not the delivery NG is stored in the log file (S112). The distribution log file for which distribution has been completed has the distribution OK for each program module. If no distribution NG is recorded in the distribution-side log file, it is determined that there is no program module for distribution NG (S113), and it is determined whether update software to be newly updated is registered (S114).

  For example, the SW management unit 121 accepts registration of update software. At this time, the update flag of the update software before distribution can be set to “undistributed”. When the SW update control unit 123 refers to the update flag and determines that the software to be newly updated is registered (YES in S114), the SW update control unit 123 generates and stores a distribution-side log file related to the software to be updated. It memorize | stores in the apparatus 130 (S115).

  As shown in FIG. 9, update software information including a combination of the update software and its program module group is registered for the update software. The SW update control unit 123 can generate the distribution-side log file listing the program module groups of the software A to be updated with reference to the updated software information, for example. At this time, a distribution OK / NG recording area is set for each program module, and in the software log file distributed for the first time, “distribution NG” is written to all program modules by default.

  The update flag of the update software before distribution is set to “undistributed”, and when the distribution side log file is generated for the update software having the update flag of “undistributed”, the update flag is set to “distributed” The update flag becomes “distributed” when the distribution history of the distribution side log file is all distributed according to the reception history transmitted from the in-vehicle GW apparatus 200. These flag controls are performed by the SW management unit 121 or the SW update control unit 123.

  The SW update control unit 123 generates a group key for newly registered software from the correspondence between the software management information and the node key, and encrypts the software to be distributed (S116). When the software to be distributed is composed of a plurality of program modules, the SW update control unit 123 can individually encrypt the program modules and sequentially distribute the program modules.

  The distribution order of the plurality of program modules is arbitrary, and may be distributed in a predetermined order. Further, after confirming that one program module is received on the mobile unit side (after receiving the reception OK), the next program module may be distributed. Alternatively, each program module may be distributed in sequence without confirming that the program module has been received on the mobile unit side. Even in this case, the in-vehicle GW device 200 records the reception history for each received program module in the moving body side log file and transmits the reception history to the software update device 100.

  Next, on the mobile body side, the in-vehicle GW apparatus 200 receives each program module of the update software. At this time, the software update management unit 224 of the in-vehicle GW apparatus 200 returns the encrypted program module to plain text using the unique key stored in the storage unit 225 in advance. That is, key authentication using a unique key is performed on the mobile body side (S302). At this time, for example, the software update apparatus 100 that is a transmission source can be authenticated by a digital signature of a public key cryptosystem.

  The software update management unit 224 performs reception processing for storing the program module returned to plain text using the unique key in the storage unit 225 (S303), and generates a mobile log file (S304). The received program module may be stored in a predetermined storage area provided in the vehicle control system 300 instead of the storage unit 225.

  For example, when software that is to be newly updated is distributed, the software update device 100 can distribute the software by including a flag that represents new software for update. In this case, the software update management unit 224 newly generates the above-described mobile-side log file related to the update software. In addition, since the update software and the mobile log file are associated with each other, the software update management unit 224 searches the mobile log file already generated, and the mobile log related to the received update software. It is possible to determine whether or not a file exists. When it is determined that there is no corresponding mobile-side log file, a new mobile-side log file can be generated.

  In addition, a mobile log file corresponding to update software that has never been received on the mobile side can be provided from the software update device 100. That is, the software update apparatus 100 generates a distribution-side log file (a log file in which all logs are distribution NG) along with distribution, and transmits the log file to the mobile unit, thereby moving the mobile-side log file. Can be used as is.

  The SW update control unit 123 can also distribute the updated software information referred to when generating the distribution-side log file to the mobile body. In this case, the software update management unit 224 is the log file of the software that is distributed for the first time in the same way as the distribution-side log file. Therefore, the mobile-side log file in which “distribution NG” is written by default for all program modules is stored. Can be generated.

  Then, the software update management unit 224 records the received OK / NG in the mobile unit side log file for each received program module (S305). The software update management unit 224 transmits the reception history (reception OK / NG) recorded in the mobile log file to the software update device 100 (S306). The software update device 100 receives the reception history from the in-vehicle GW device 200, and records distribution OK / NG in the distribution-side log file for each corresponding program module (S118). In the present embodiment, unless a reception history is received from the in-vehicle GW device 200, the distribution history of the distribution side log file does not transition to “distribution OK”.

  The software update device 100 repeats steps S117 and S118 until the distribution process is completed (S119). Similarly, the in-vehicle GW apparatus 200 repeats steps S302 to S306 until the reception process is completed (S307). Note that the end of the distribution process and the end of the reception process include a distribution interruption due to interruption of the communication path.

  After completing the reception process, the software update management unit 224 refers to the mobile-side log file and determines whether all the program modules are “reception OK” (S308). The software update management unit 224 permits the update of the software corresponding to the moving body side log file in which all the program modules are “reception OK”. Specifically, the software update management unit 224 outputs the software stored in the storage unit 225 to the vehicle control system 300 and outputs a software update instruction (S309). In the vehicle control system 300, for example, a vehicle ECU that controls the entire vehicle executes software update at a predetermined timing or in real time. The execution result (update OK / NG) of the software update is output from the vehicle control system 300 to the software update management unit 224. The software update management unit 224 can transmit a software update execution result (update OK / NG) to the software update management apparatus 100.

  FIG. 11 is a flowchart showing the software update process via the in-vehicle GW apparatus 200, and shows the difference update process after the distribution of the update software is ended in an unfinished state in step S113 of FIG. The distribution incomplete state means that the distribution side log file is generated and the update software is distributed (the update flag is “distributing”), but at least one distribution NG is included in the distribution log of the distribution side log file. It is included.

  In the example of FIG. 11, whether or not all the program modules of the software have been received on the mobile unit side due to the relationship between the data capacity and the distribution timing is interrupted during the distribution of the update software. This is a process of differentially distributing an unknown program module.

  If the SW update control unit 123 determines in step S113 that the delivery NG is recorded in the created delivery side log file, the SW update control unit 123 transmits the mobile body side log file to the software update device 100 to the in-vehicle GW device 200. The transmission request to be output is output (S121). The in-vehicle GW apparatus 200 transmits the corresponding mobile body side log file to the software update apparatus 100 based on the transmission request (S321).

  The SW update control unit 123 compares the mobile-side log file received from the in-vehicle GW apparatus 200 with the distribution-side log file, and matches OK / NG of the distribution history and OK / NG of the reception history for each program module. (S122). The SW update control unit 123 performs a log file rewrite process when there is even one program module that does not match OK / NG in the distribution history and the reception history (YES in S123).

  The SW update control unit 123 transmits a request for discarding the moving body side log file to the in-vehicle GW apparatus 200 to the in-vehicle GW apparatus 200 (S124). The in-vehicle GW apparatus 200 discards (deletes) the stored mobile-side log file based on the log file discard request received from the software updating apparatus 100 (S323).

  In the distribution history of the distribution log file, the SW update control unit 123 specifies an OK / NG mismatch program module in the distribution history and the reception history (S125), and rewrites all the mismatched logs into the distribution NG (S126). The SW update control unit 123 rewrites the distribution-side log file, generates the same mobile-side log file as the distribution-side log file whose content has been rewritten, and transmits it to the in-vehicle GW apparatus 200 (S127). The in-vehicle GW apparatus 200 receives the log file having the same content as the distribution side log file from the software update apparatus 100 and stores it in the storage unit 225 as the mobile body side log file (S324).

  That is, in this embodiment, when there is a mismatch between the log contents of the distribution side log file and the mobile unit log file, both the distribution log of the distribution side log file and the reception history of the mobile unit log file for the mismatched program module are displayed. Rewrite to NG and control to resend the program module. For example, even if the reception history of the mobile log file is reception OK, the distribution log of the distribution log file is NG, or the distribution log of the distribution log file is distribution OK. If the reception history of NG is reception NG, the contents of the log file are reset once (rewritten to NG), and retransmission processing is performed.

  With this configuration, it is possible to realize an environment for reliably updating software. Since the communication environment of the mobile object changes, communication is cut off in the middle. That is, it is sufficient that the update software can be received collectively on the mobile unit side, but the entire update software (program module) may not be completely received due to a change in the communication environment. In such a case, only the distribution result managed by the software update apparatus 100 on the distribution side cannot grasp the reception state on the mobile unit side, and there is a possibility that the update software may be lost.

  Therefore, the software update method of this embodiment manages the distribution history and the reception history in both the distribution side log file and the mobile side log file, and when the distribution of the update software is interrupted for some reason, Control is performed so that the distribution history and reception history are rewritten to NG and reset for program modules whose histories do not match and are retransmitted.

  With this configuration, the update software can be reliably distributed to the mobile unit, and when all program modules are “receive OK” with reference to the mobile unit side log file, the corresponding software is updated. The software can be surely updated.

  On the other hand, in step S123, if it is determined that there is no OK / NG mismatch between the distribution history and the reception history, the SW update control unit 123 refers to the distribution-side log file and determines the program module of the distribution NG. To extract. Thereafter, the software update device 100 performs the processing from step S116 onward, and sequentially performs encryption, distribution based on the group key, and log recording processing of the reception history received from the in-vehicle GW device 200. Similarly, the in-vehicle GW apparatus 200 sequentially performs the processes from step S302 onward, and sequentially performs a reception history log recording process, a process of transmitting log records to the software update apparatus 100, and the like. Since the example of FIG. 11 is a difference update process, step S304 is omitted. If the retransmitted program module is duplicated, the software update management unit 224 can overwrite and save it.

  Although the present embodiment has been described above, the in-vehicle gateway device 200 can be configured as an in-vehicle gateway system. For example, the communication device 210 and the control device 220 can be configured as individual devices, and can be configured as an in-vehicle gateway system in which these are connected to each other. Similarly, each functional unit of the control device 220 can be appropriately configured as an individual processing device and configured as an in-vehicle gateway system.

  Each function of the software update device 100 and the control device 220 of the in-vehicle gateway device 200 can be realized by a program. A computer program prepared in advance for realizing each function is stored in the auxiliary storage device, and the CPU or the like. The control unit reads the program stored in the auxiliary storage device to the main storage device, and the control unit executes the program read to the main storage device, thereby enabling the functions of the respective units to operate.

  Further, the program can be provided to the in-vehicle GW apparatus 200 in a state where the program is recorded on a computer-readable recording medium. Computer-readable recording media include optical disks such as CD-ROM, phase change optical disks such as DVD-ROM, magneto-optical disks such as MO (Magnet Optical) and MD (Mini Disk), floppy (registered trademark) disks, Examples include magnetic disks such as removable hard disks, memory cards such as compact flash (registered trademark), smart media, SD memory cards, and memory sticks. A hardware device such as an integrated circuit (IC chip or the like) specially designed and configured for the purpose of the present invention is also included as a recording medium. In addition, a program for realizing each unit from the network outside the vehicle to the in-vehicle GW apparatus 200 can be provided and installed via the communication device 210.

  In addition, although embodiment of this invention was described, the said embodiment is shown as an example and is not intending limiting the range of invention. The novel embodiment can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

DESCRIPTION OF SYMBOLS 100 Software update apparatus 110 Communication apparatus 120 Control apparatus 121 Software management part (SW management part)
122 Key management unit 123 Software update control unit (SW update control unit)
200 In-vehicle gateway device (in-vehicle GW device)
210 Communication device 211 In-vehicle communication interface 212 In-vehicle communication interface 220 Control device 221 In-vehicle communication control unit 222 In-vehicle communication control unit 223 Gateway control unit (GW control unit)
223A Network control unit 2231 Routing control unit 2232 Protocol conversion unit 2233 Security unit 223B Communication control unit 2234 Communication state monitoring unit 2235 Communication path selection unit 2236 Monitoring control unit 2237 Config setting control unit 224 Software update management unit 225 Storage unit 300 Vehicle control system

Claims (3)

A software update system for updating software executed in a predetermined system for controlling a mobile body,
An in-vehicle gateway device provided in a mobile body and connected to the predetermined system; and a software update device connected to the in-vehicle gateway device via a network;
The software update device includes:
Based on distribution-side log information related to software distributed to the in-vehicle gateway device, the software update control unit for performing distribution control to distribute the software to the in-vehicle gateway device,
The in-vehicle gateway device is
A software update management unit for transmitting mobile side log information in which the reception result of the software is recorded to the software update device;
The software update control unit
When the mobile body side log information and the distribution side log information are matched and it is determined that the log information does not match, the log information of the distribution side log information is updated, and for the in-vehicle gateway device, Control to update the log information in the mobile log information,
A software update system, wherein the software is redistributed to the in-vehicle gateway device based on the distribution-side log information updated due to mismatch of log information. The software is composed of a plurality of program modules,
The software update control unit distributes each of the plurality of program modules to the in-vehicle gateway device, receives reception OK or reception NG of each of the plurality of program modules from the in-vehicle gateway device, and distributes the log information on the distribution side Recorded in
The software update management unit
Record the reception OK or reception NG of each of the plurality of program modules distributed from the software update device in the mobile body side log information,
The software update control unit
When the mobile body side log information and the delivery side log information are matched and it is determined that the reception OK or the reception NG of the log information of at least one of the program modules is inconsistent, Transmit the discard request to discard the mobile log information,
Regenerating the log information of the program module determined to be inconsistent with reception NG and generating the mobile side log information in which the log content is synchronized with the distribution side log information and transmitting it to the in-vehicle gateway device The software update system according to claim 1.   The software update management unit refers to the mobile side log information and permits the software update to the predetermined system when the reception history of the software is reception OK. Or the software update system according to 2;