In-vehicle software management system, in-vehicle software management server, and in-vehicle software management method

Abstract

The software installed in the vehicle is managed and verified on the server side. [Solution] An in-vehicle software management system comprising a server and a terminal, wherein the terminal has a permission request unit that acquires information on whether software can be written to the vehicle and a write command unit that commands the writing of software to the vehicle, and the server has a verification unit that verifies software uploaded from the terminal, a registration determination unit that determines whether the software uploaded from the terminal can be registered based on the verification results of the verification unit, a software management unit that issues a registration number to software determined to be registrable by the registration determination unit and manages the software, and a permission notification unit that notifies the terminal of write permission information indicating that software registered with the software management unit can be written and software not registered with the software management unit cannot be written.

Description

Technical Field

[0001] The present invention relates to an in-vehicle software management system for managing and verifying vehicle software.

Background Art

[0002] Since the software installed in a vehicle is managed for each in-vehicle control device installed in the vehicle, efforts are being made to realize a Software-Defined Vehicle (SDV) that connects the in-vehicle control device to the Internet and improves functions and performance through software updates. In SDV, detailed management of the software installed in the vehicle is required, but currently, detailed management of software corresponding to SDV has not been realized.

[0003] The following prior art exists as background technology for this field. Patent Document 1 (Japanese Patent Application Publication No. 2020-27670) describes a vehicle information communication system comprising an on-board device having a central device for managing data to be written to a plurality of electronic control devices mounted on a vehicle, an in-vehicle communication unit mounted on the vehicle and communicating with the plurality of electronic control devices, and an external communication unit for wireless communication with the central device. The on-board device receives configuration information indicating the configuration of the software and hardware of each device from the plurality of electronic control devices, and transmits a configuration information list containing the plurality of configuration information to the central device. The central device has a configuration information storage unit that stores a configuration information list which is a regular combination of the plurality of configuration information for a vehicle model, an update notification information storage unit that stores notification information regarding vehicle program updates, and compares the configuration information list received from the on-board device with the configuration information list stored in the configuration information storage unit to determine whether the configuration information list received from the on-board device is a regular combination or not. If it is determined to be an irregular combination, it sends a message to the on-board device indicating that it is abnormal. The vehicle information communication system includes a configuration information confirmation unit, an update confirmation unit that checks whether or not a program update has been made for the vehicle by referring to the update notification information storage unit, and a package distribution unit that distributes a package containing an update program to the in-vehicle device if the configuration information confirmation unit determines that it is a valid combination and the update confirmation unit confirms that an update has been made. The system further includes a configuration information list that is transmitted from the in-vehicle device upon completion of a program update based on the package, the configuration information confirmation unit compares the configuration information list received from the in-vehicle device with the configuration information list stored in the configuration information storage unit, determines whether or not the configuration information list received from the in-vehicle device is a valid combination, and if it determines that it is an invalid combination, it transmits a message to the in-vehicle device indicating that there is an abnormality. The update confirmation unit then checks whether or not a program update has been made for the vehicle, and if the configuration information confirmation unit determines that it is a valid combination and the update confirmation unit confirms that an update has been made, the package distribution unit distributes a new package containing an update program to the in-vehicle device. [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2020-27670 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] Currently, when updating vehicle software, the software is managed separately for each on-board control unit. With SDV, it is necessary to manage each individual software installed in each on-board control unit.

[0006] To solve the aforementioned problems, the present invention aims to connect a vehicle and a server via a network, and to manage and verify the software installed in the vehicle on the server side. [Means for solving the problem]

[0007] A typical example of the invention disclosed in this application is as follows: an in-vehicle software management system comprising: a server composed of a computer having an arithmetic unit that performs predetermined processing and a storage device connected to the arithmetic unit; and a terminal connected to the server, wherein the terminal has a permission request unit that uploads software to the server and obtains information on whether the software can be written to the vehicle; and a write command unit that commands the writing of the software to the vehicle based on the information on whether the software can be written to the vehicle transmitted from the server; wherein the server has a verification unit that verifies the software uploaded from the terminal; a registration determination unit that determines whether the software uploaded from the terminal can be registered based on the verification result of the verification unit; a software management unit that issues a registration number to software determined to be registrable by the registration determination unit and manages the software; and a permission notification unit that notifies the terminal of write permission information indicating that software registered in the software management unit is writable and software not registered in the software management unit is not writable. [Effects of the Invention]

[0008] According to one aspect of this disclosure, the software of the in-vehicle control device is managed and verified by a server, thereby preventing tampering with the software of the in-vehicle control device. Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram showing the overall configuration of an in-vehicle software management system according to one embodiment of the present disclosure. [Figure 2] This is a block diagram showing the schematic configuration of the server in this embodiment. [Figure 3] This is a block diagram showing the schematic configuration of the terminal in this embodiment. [Figure 4] This is a block diagram showing the schematic configuration of the vehicle according to this embodiment. [Figure 5] This is a flowchart of the processes executed on the server in this embodiment. [Figure 6] This is a flowchart of the processes executed on the server in this embodiment. [Figure 7] This is a flowchart of the processes executed on the server in this embodiment. [Modes for carrying out the invention]

[0010] The embodiments will be described in detail below with reference to the drawings.

[0011] <Embodiment> [System Configuration] Figure 1 is a block diagram showing the overall configuration of an in-vehicle software management system according to one embodiment of the present disclosure.

[0012] The in-vehicle software management system shown in Figure 1 is a system for updating the software installed in the vehicle 30, and includes a server 10 located outside the vehicle and a terminal 20.

[0013] Server 10 is connected to the vehicle 30 and terminal 20 via the internet 100, enabling communication. Server 10 can transmit software update data for the control device (e.g., ECU: Electric Control Unit) installed in the vehicle 30, as well as management information for the update data. Server 10 can provide the terminal 20 with the software update status and management information for the update data. Before transmitting the software update data provided by terminal 20 to the vehicle 30, Server 10 verifies the software and assigns a registration number.

[0014] Figure 2 is a block diagram showing the schematic configuration of the server 10 in this embodiment.

[0015] Server 10 includes a pass / fail notification unit 12, a vehicle-mounted software information recording unit 13, a verification unit 14, a registration determination unit 15, and a software management unit 16.

[0016] The permission / failure notification unit 12 notifies the terminal 20 of the write permission information, indicating whether software registered in the software management unit 16 is writable and software not registered is not writable, along with the reason for the write permission / failure. The vehicle-mounted software information recording unit 13 records information about the software installed on the control device mounted in the vehicle 30 (for example, the registration number of the installed software, a list of software that can be added) for each vehicle and provides a list of software installed in the vehicle. The verification unit 14 verifies the software uploaded from the terminal 20. The registration determination unit 15 determines whether the software uploaded from the terminal 20 can be registered based on the verification results of the verification unit 14. The software management unit 16 issues a registration number to the software determined to be registrable by the registration determination unit 15, registers the software, and manages it. The software management unit 16 also manages attribute information (which software it is an updated version of, which software it is an option for) of the software determined to be registrable by the registration determination unit 15.

[0017] Server 10 may have a function of transmitting the registered software to vehicle 30 to update the software installed in the control device mounted on vehicle 30.

[0018] Server 10 is composed of a computer having a processor (CPU), a memory, an auxiliary storage device, and a communication interface.

[0019] The processor is an arithmetic unit that executes programs stored in the memory. By the processor executing various programs, the functions of each functional unit of server 10 (for example, the approval notification unit 12, the vehicle-mounted software information recording unit 13, the verification unit 14, the registration determination unit 15, the software management unit 16) are realized. Note that a part of the processing performed by the processor executing a program may be executed by another arithmetic unit (for example, hardware such as an ASIC or FPGA).

[0020] The memory includes a non-volatile storage element ROM to which the processor can be accessibly connected and a volatile storage element RAM. The ROM stores invariant programs (for example, BIOS). The RAM is a high-speed and volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores the programs executed by processor 1 and the data used during program execution.

[0021] The auxiliary storage device is, for example, a large-capacity and non-volatile storage device such as a magnetic storage device (HDD) or a flash memory (SSD) to which the processor can be accessibly connected. The auxiliary storage device also stores the data used by the processor during program execution and the programs executed by the processor. That is, the programs are read from the auxiliary storage device 3, loaded into the memory, and executed by the processor to realize each function of server 10.

[0022] The communication interface is a network interface device that controls communication with other devices according to a predetermined protocol.

[0023] The program executed by the processor is provided to the server 10 via removable media (such as a CD-ROM or flash memory) or a network, and stored in a non-volatile auxiliary storage device 3, which is a non-temporary storage medium. For this reason, the server 10 should have an interface for reading data from the removable media.

[0024] Server 10 is a computer system that consists of one physical computer or multiple logically or physically configured computers, and may operate on a virtual computer built on multiple physical computing resources. For example, multiple programs that implement the functions of Server 10 may each operate on separate physical or logical computers, or multiple programs may be combined and operate on a single physical or logical computer.

[0025] Figure 3 is a block diagram showing the schematic configuration of terminal 20 in this embodiment.

[0026] Terminal 20 is a computer used by users of vehicle 30, maintenance personnel, developers from vehicle manufacturers and vehicle parts manufacturers, etc., to operate software managed by server 10. It has a processor (CPU) that executes programs stored in memory, memory accessible to the processor, auxiliary storage device accessible to the processor, and a communication interface.

[0027] Terminal 20 includes a write command unit 21, a permission / rejection display unit 22, an update notification unit 23, a software list notification unit 24, and a permission / rejection request unit 25. The write command unit 21 commands the writing of software to the vehicle 30 based on the write permission / rejection information for the software to be written to the vehicle 30 notified by the server 10's write permission / rejection notification unit 11. The permission / rejection display unit 22 outputs data to display the write permission / rejection information and the reason for the write permission / rejection, which has been notified by the server 10's permission / rejection notification unit 12. The update notification unit 23 outputs data to indicate the completion of the software update for the software installed on the vehicle 30, i.e., the completion of the software installation on the vehicle 30. The software list notification unit 24 compares the registration number of the software installed on the vehicle 30, which is recorded in the server 10's vehicle-mounted software information recording unit 13, with the registration number of the software registered in the server 10's software management unit 16, and outputs data to display a list of software registered in the server 10 that can be added to the vehicle 30. The permission / request unit 25 uploads the software to the server 10, compares the attributes of the uploaded software with the attributes of the software installed in the vehicle 30 recorded in the vehicle-mounted software information recording unit 13 of the server 10, and obtains information on whether or not it is possible to write to the vehicle 30.

[0028] Figure 4 is a block diagram showing the schematic configuration of the vehicle 30 in this embodiment.

[0029] Vehicle 30 includes a vehicle information transmission unit 31 and a software startup determination unit 32. The vehicle information transmission unit 31 transmits a registration number, which is information unique to the software installed in vehicle 30, to the server 10 via an in-vehicle gateway (not shown). The software startup determination unit 32 determines whether the software installed in vehicle 30 can be started based on the determination result from the server 10. For example, if the determination result transmitted from the server 10 indicates that the software is legitimate, the software is started normally. On the other hand, if the determination result indicates that the software is not legitimate, the software is started in a mode that prohibits the vehicle 30 from driving.

[0030] Each functional unit of the vehicle 30 is implemented in an electronic control unit (ECU). The ECU has an arithmetic unit, a memory device, and a communication interface. The arithmetic unit is a processor (e.g., a microcontroller) that executes programs stored in the memory device. The arithmetic unit provides various functions of the vehicle 30 by executing a predetermined program. The memory device includes a non-volatile memory area and a volatile memory area. The non-volatile memory area is accessible to the arithmetic unit and includes a program area that stores programs executed by the arithmetic unit, and a data area that temporarily stores data used by the arithmetic unit when executing programs. The volatile memory area stores data used by the arithmetic unit when executing programs. The communication interface connects to other electronic control units via a network such as CAN or Ethernet.

[0031] [Overview of Software Update Process] Figure 5 is a flowchart of the process executed by the server 10 in this embodiment. The process shown in Figure 5 is executed repeatedly at predetermined time intervals.

[0032] After power is turned on, the vehicle 30 transmits software-specific information (vehicle ID, software registration number) of the software installed in the vehicle from the vehicle information transmission unit 31 to the server 10. The server 10 receives the vehicle ID and software registration number from the vehicle 30 (S101).

[0033] When server 10 receives the vehicle ID and software registration number from vehicle 30 (S101, "Yes"), software management unit 16 compares the vehicle ID and software registration number stored in vehicle-mounted software information recording unit 13 with the vehicle ID and software registration number transmitted from vehicle 30, and stores the comparison result in server 10 (S102).

[0034] If the software management unit 16 finds that the vehicle ID and software registration number combination does not match (resulting in "No" in S103), it sends the mismatched software registration number to the vehicle 30 (S104). The software startup determination unit 32 of the vehicle 30 starts the notified software in a mode that prohibits the vehicle 30 from driving. The vehicle 30 also receives the correct software from the server 10 and updates the electronic control unit with the correct software. After the update is complete, the vehicle information transmission unit 31 of the vehicle 30 sends the software's unique information (vehicle ID, software registration number) to the server 10. The software management unit 16 records and manages the software's unique information, including the software registration number and vehicle ID, as well as the software's creator, destination, etc., in the vehicle-mounted software information recording unit 13.

[0035] Figure 6 is a flowchart of the process executed by the server 10 in this embodiment. The process shown in Figure 6 is executed repeatedly at predetermined time intervals.

[0036] Server 10 waits for a software update request sent from the terminal 20's acceptance / rejection request unit 25 (S111). When Server 10 receives a software update request from terminal 20 ("Yes" in S111), it receives the update software following the software update request (S112). Verification unit 14 performs a static analysis of the received update software to verify whether an infinite loop or memory corruption occurs (S113).

[0037] If the verification result of the update software is normal ("No" in S114), the registration determination unit 15 determines that the update software can be registered with the software management unit 16 and issues a registration number for the update software (S115). The software management unit 16 then registers the update software and creates data for transmission from the update software to the vehicle (S116). On the other hand, if the verification result of the update software is abnormal ("Yes" in S114), the registration determination unit 15 determines that the update software cannot be registered with the software management unit 16 and proceeds to step S117.

[0038] Subsequently, the server 10's permission / failure notification unit 12 notifies the terminal 20 of write update permission / failure information, which is determined based on whether the verification result is normal or abnormal (S117). If the verification result is normal, the permission / failure notification unit 12 notifies the terminal 20 of the registration number issued to the software; if the verification result is abnormal, it notifies the terminal 20 of the reason why the verification result was determined to be abnormal (verification item, location of abnormality).

[0039] Figure 7 is a flowchart of the processes executed by server 10 in this embodiment.

[0040] When terminal 20 receives the registration number of software that can be added to vehicle 30 from the software management unit 16 of server 10, it can send a write request to server 10 for each registration number from the list of addable software.

[0041] Server 10 waits for software data to be sent from terminal 20 (S121). When server 10 receives software data from terminal 20 (Yes in S121), it sends the received software data and the registration number of the software to vehicle 30 (S122).

[0042] Vehicle 30 updates the control device software using software data received from server 10, and notifies server 10 of the completion of the update after the update is finished.

[0043] The software management unit 16 records the software, registration number, creator, destination, and vehicle ID as software-specific information in the vehicle-mounted software information recording unit 13, and then notifies the update notification unit 23 of the terminal 30 that the software update for the vehicle 30 is complete.

[0044] The user can operate terminal 20 to obtain the registration number of the software installed in vehicle 30 from the vehicle-mounted software information recording unit 13 of server 10, and view it on the software list notification unit 24 of terminal 20. Furthermore, the user can compare the software list registered in the software management unit 16 of server 10 with the software registration number installed in vehicle 30, and confirm a list of software that can be added.

[0045] <Effects and Actions> As described above, according to one embodiment of this disclosure, the server 10 verifies the software of the vehicle 30 and manages the software data and software management number, thereby preventing malfunctions in the vehicle and the writing of illegal software, and preventing serious problems with the software of the in-vehicle control device in advance. In addition, since the software installed in the vehicle 30 is managed for each vehicle ID, when a problem occurs in the vehicle 30, the problem can be investigated efficiently.

[0046] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and the present invention is not necessarily limited to having all the described configurations. Furthermore, some of the configurations of one embodiment may be replaced with those of another embodiment. Furthermore, configurations of other embodiments may be added to the configuration of one embodiment. Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with those of other embodiments.

[0047] Furthermore, each of the aforementioned configurations, functions, processing units, and processing means may be implemented in hardware, for example, by designing them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each function.

[0048] Information such as programs, tables, and files that implement each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other storage media such as IC cards, SD cards, and DVDs.

[0049] Furthermore, the control lines and information lines shown are those deemed necessary for explanation purposes and do not necessarily represent all control lines and information lines required for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0050] 10 servers 20 devices 30 vehicles 100 Internet 12 Approval Notification Department 13. Vehicle-mounted software information recording unit 14 Verification Department 15 Registration Determination Unit 16. Software Management Department 21 Writing Command Unit 22 Availability display section 23 Update Notification Department 24 Software List Notification Section 25 Availability request section 31 Vehicle Information Transmission Unit 32 Software Startup Determination Unit

Claims

1. In-vehicle software management system, A server comprising a computer having a computing unit that performs predetermined processing and a storage device connected to the computing unit, The system comprises a terminal connected to the aforementioned server, The aforementioned terminal is A request unit that uploads software to a server and obtains information on whether the software can be written to the vehicle, The system includes a write command unit that commands the writing of the software to the vehicle based on information on whether the software can be written to the vehicle, transmitted from the server, The aforementioned server, A verification unit that verifies the software uploaded from the aforementioned terminal, A registration determination unit determines whether the software uploaded from the terminal can be registered based on the verification results of the verification unit, The software management unit issues a registration number to software that the registration determination unit has determined to be eligible for registration, and manages the software. An in-vehicle software management system characterized by having a writeability notification unit that notifies a terminal of writeability information, indicating whether software registered in the software management unit is writable and software not registered in the software management unit is not writable.

2. An in-vehicle software management system according to claim 1, The registration determination unit, If the verification results of the software by the verification unit are found to be normal, the software management unit determines that the updated software can be registered. An in-vehicle software management system characterized in that, if the verification result of the software by the verification unit is abnormal, the software management unit determines whether or not to register the update software.

3. An in-vehicle software management system according to claim 1, The in-vehicle software management system is characterized in that the software management unit manages the issued registration number as unique information of the software and associates it with the software.

4. An in-vehicle software management system according to claim 1, The in-vehicle software management system is characterized in that the verification unit verifies whether infinite loops and memory corruption occur by static analysis of the software uploaded from the terminal.

5. An in-vehicle software management system according to claim 2, The aforementioned vehicle is A vehicle information transmission unit that transmits the registration number of the software installed in the vehicle to the server, The system includes a software startup determination unit that determines whether or not the software installed in the vehicle can be started, based on the result of the determination from the server. The in-vehicle software management system is characterized in that the software management unit uses the registration number transmitted from the vehicle to verify whether the software installed in the vehicle is registered on the server, and notifies the vehicle of the result of the verification.

6. An in-vehicle software management system according to claim 1, The server has a software information recording unit that records the registration number of the software installed in the vehicle for each vehicle and provides a list of the software installed in the vehicle. The vehicle is characterized by having a vehicle information transmission unit that transmits the registration number of the software installed in the vehicle to the server.

7. An in-vehicle software management system according to claim 1, The in-vehicle software management system is characterized in that the software management unit manages the registration number, creator, and destination information for each piece of software.

8. An in-vehicle software management system according to claim 1, The permission / failure notification unit notifies the terminal of the write permission / failure information and the reason for the write permission / failure. The in-vehicle software management system is characterized in that the terminal has a permission / failure display unit that outputs data for displaying the write permission / failure information notified by the permission / failure notification unit and the reason for the write permission / failure.

9. An in-vehicle software management system according to claim 1, The in-vehicle software management system is characterized in that the terminal has an update notification unit that outputs data for displaying software updates installed in the vehicle.

10. An in-vehicle software management system according to claim 1, The in-vehicle software management system is characterized in that the terminal has a software list notification unit that outputs data for displaying a list of software that is registered with the server and can be added to the vehicle.

11. It is an in-vehicle software management server, It is composed of a computer having an arithmetic unit that performs predetermined processing and a storage device connected to the arithmetic unit, The aforementioned computing device includes a verification unit that verifies the software uploaded from the terminal, The aforementioned computing device includes a registration determination unit that determines whether or not the software uploaded from the terminal can be registered based on the verification results of the verification unit, The aforementioned computing device issues a registration number to the software that the registration determination unit has determined to be eligible for registration, and the software management unit manages the software, An in-vehicle software management server characterized in that the computing device comprises a permission / failure notification unit that notifies a terminal of write permission information indicating whether software registered in the software management unit is writable, and software not registered in the software management unit is not writable.

12. A method for managing in-vehicle software performed by an in-vehicle software management system, The in-vehicle software management system comprises a server composed of a computer having a computing device that performs predetermined processing and a storage device connected to the computing device, and a terminal connected to the server. The aforementioned in-vehicle software management method is: The aforementioned terminal uploads software to the server and obtains information on whether the software can be written to the vehicle; The server performs a verification procedure to verify the software uploaded from the terminal, The server performs a registration determination procedure to determine whether or not the software uploaded from the terminal can be registered, based on the verification results of the verification unit. The server issues a registration number to software that the registration determination unit has determined to be eligible for registration, and a software management procedure for managing the software, The server provides a notification procedure for notifying a terminal of write permission information, indicating that software registered in the software management unit is writable, and software not registered in the software management unit is not writable. An in-vehicle software management method characterized by comprising: a write command procedure in which the terminal commands the writing of the software to the vehicle based on information transmitted from the server regarding whether the software can be written to the vehicle; and so on.

Images