Software Update Device

Abstract

To identify software that is safe and determine what software can be rolled back while maintaining a high level of safety and security.SOLUTION: A software updating device E1000 comprises: software unit storage E1520 that stores a plurality of software units UX000 that include label information UX400; and an update control unit E1400 that controls software updates for a vehicle control device ECU_EX000. The label information UX400 includes at least safety-related information for the software units UX000. Upon receiving a rollback instruction, the update control unit E1400 selects, from the plurality of software units UX000, software that has safety-related label information UX400 that is identical to safety-related label information UX400 of software installed on the vehicle control device, as software to be rolled back.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to techniques that enable safe and reliable rollback on software units of a target system, maintaining the highest possible level of operability along with the highest possible level of safety and security. [Background technology]

[0002] With the development of technology related to autonomous driving, reliable functional safety is required, especially in terms of vehicle control. Software development to achieve reliable functional safety is also progressing, and the frequency of updates is becoming shorter. In the automotive field, the development of software-based functions such as Adaptive Cruise Control (ACC), Automatic Emergency Steering (AES), Advanced Driver Assistance System (ADAS), and Autonomous Driving (AD) has been progressing in recent years. In addition to complex functions such as ACC and AES, less complex but software-based electronic stability control (ESC) and backup cameras are also being installed in low-end vehicles. These vehicles integrate 100 Electronic Control Units (ECUs) with 100 million lines of code, introducing many software-enabled functions to users.

[0003] In many functional safety areas, safety requirements are largely well-established and can be easily tested even with the increasing complexity of software. However, software-related errors are discovered after the product is sold and corrected accordingly. In the automotive sector, software-related errors directly affect the core functions of many vehicles, increasing the possibility of causing service outages for automotive suppliers and reducing the quality of user experience. In this regard, half of the vehicle recalls that occurred in 2019 were related to software-based defects.

[0004] The rise of ubiquitous connectivity through 4G and 5G cellular technology, and the increasing use of higher bandwidth internet in many homes, has enabled software updates through Firmware Over The Air (FOTA) and Software Over the Air (SOTA). These update mechanisms allow product manufacturers to update software without having to ship the product back to the manufacturer. With FOTA / SOTA technology, users can simply connect to the internet to get the latest features and latest updates to keep their vehicle functioning properly. Particularly in the automotive sector, software updates and sorting have traditionally been done by physically traveling users to specific locations such as dealerships. This has been a logistical burden for manufacturers and a concern for consumers.

[0005] Even with FOTA / SOTA technology, software-related errors can occur when updating devices with complex software. In such cases, it can take weeks to resolve the issue due to the complexity of the software being updated. Particularly in the automotive sector, where the device being updated is a vehicle regulated by a government agency, certification and authorization are required to perform the update, which requires additional time for the end user to complete the update. This means that if a reliable fix is ​​desired, the vehicle with the error may not be usable for a long period of time.

[0006] Another solution in this case would be to disable the software suspected to be causing the problem until a patch is distributed to fix the error, but disabling the software could pose safety and security risks to the vehicle.

[0007] The above two approaches are at opposite ends of the spectrum, and it is desirable to develop a middle ground between the two approaches. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] JP 2020-027630 A Summary of the Invention [Problem to be solved by the invention]

[0009] In view of the above-mentioned problems, an object of the present invention is to provide a method for quickly changing all software on a target system to different software that is considered to be safe, while maintaining software functionality as much as possible. [Means for solving the problem]

[0010] In order to solve the above problems, the software update device of the present invention includes a software storage unit that stores multiple software programs including label information, and a software update control unit that controls software updates of a vehicle control device, wherein the label information includes at least information regarding the safety of the software, and when the software update control unit receives a rollback instruction, it selects from the multiple software programs software having safety label information that is the same as the safety label information of the software installed in the vehicle control device as the software to be rolled back. Effect of the Invention

[0011] According to the present invention, it is possible to identify safe software and determine software that can be used for rollback while maintaining a high level of safety and security. Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Furthermore, the objects, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0012] [Figure 1]1 is a schematic block diagram showing the overall configuration of a software updating system to which a software updating device according to the present invention is applied; [Diagram 2] FIG. 2 is a functional block diagram showing the configuration of a target system V1000. [Diagram 3] FIG. 1 is a functional block diagram showing the configuration of an infotainment system I1000. [Figure 4] FIG. 1 is a functional block diagram showing the configuration of an OTA center C1000. [Diagram 5] FIG. 3 is a functional block diagram showing the configuration of a software unit UX000. [Figure 6] FIG. 10 is a functional block diagram showing the configuration of a user device D1000. [Figure 7] FIG. 10 is a functional block diagram showing information contained in a notification N1000. [Figure 8] FIG. 4 is a flow chart showing a process performed by the software update device. [Figure 9] FIG. 11 is a flow diagram showing a process for updating a software unit storage unit. [Figure 10] FIG. 13 is a flow diagram illustrating a process for managing notifications by a target system. [Figure 11] FIG. 11 is a flow diagram showing a process for changing a software unit. [Figure 12] FIG. 11 is a flow diagram showing rollback processing in the target system. [Figure 13] FIG. 11 is a flow diagram showing a process for selecting software to be rolled back. [Figure 14] FIG. 13 is a flow diagram illustrating a process for selecting software to roll back via an infotainment system or user device. [Figure 15] FIG. 11 is a flow diagram showing a process of disabling a software unit in a target system. [Figure 16] 1 is a flow diagram illustrating a process in which the OTA center sends a notification to a user device. [Figure 17] 1 is a flow diagram illustrating a process for initiating a notification at a user device. [Figure 18]1 is a flow diagram illustrating a process for rolling back or replacing a software unit. [Figure 19] FIG. 11 is a flow diagram showing a process for reducing the capacity of a software unit storage section. [Figure 20] FIG. 11 is a block diagram showing another configuration of the notification N1000. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] [Example 1] An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing components of an entire software update system to which a software update device according to an embodiment of the present invention is applied. The software update system includes a target system V1000, a user device D1000, and an OTA center C1000. The target system V1000 is, for example, a system mounted on a vehicle, and may be composed of a plurality of information processing units for performing a specific function. The target system V1000 can be connected to an over-the-air update system via a communication system. The over-the-air update system is shown in FIG. 1 as an OTA center C1000. The OTA center (management server) C1000 can transfer required software to the target system V1000 by a notification N1000. Similarly, the user device D1000 can communicate between the OTA center C1000 and the target system V1000.

[0014] 2 is a block diagram showing the configuration of a target system V1000. The target system V1000 includes, for example, a software update device E1000, an arbitrary number of ECU_EX000, and an infotainment system I1000. The software update device E1000 is hardware having a processor and a memory, and is mounted on a vehicle. The software update device E1000 also provides software change and rollback functions for the system. An ECU (Electronic Control Unit) is a vehicle control device, and performs various functions for controlling the vehicle. The infotainment system I1000 provides an interface between a user and the system.

[0015] The configuration of the software update device E1000 will be described in more detail. The software update device E1000 has, for example, a network unit E1100, an internal network unit E1200, an update control unit E1400, an initial software unit management unit E1500, and a rollback management unit E1600. The network unit E1100 communicates with the outside of the target system V1000. The internal network unit E1200 communicates within the target system V1000. The update control unit E1400 manages software unit update processing within the target system V1000, the initial software unit management unit E1500, and the rollback management unit E1600.

[0016] The initial software unit management unit E1500 monitors and tracks the software units installed in the target system V1000 and in the running ECU_EX000. The initial software unit management unit E1500 further includes a software unit storage unit E1520 for storing software units E153X that may be used later in the life cycle of the target system V1000, and a rollback data management unit E1510 for managing a set of labels UX400 attached to the software units stored in the software unit storage unit E1520. The set of labels UX400 is used to determine whether a rollback using locally available information is possible.

[0017] The rollback management unit E1600 processes the notification N1000. The rollback management unit E1600 further includes a notification management unit E1610 that directly processes the notification N1000, and an application disabling unit E1620 that specifies a destination of a signal in cooperation with the initial software unit management unit E1500 and the local software unit management unit EX200 specific to the ECU_EX000 when it is desired to disable a specific application E30Y.

[0018] The ECU_EX000 may for example comprise any number of applications EX30Y, a local software unit management unit EX200 and a network unit EX100. The applications EX30Y are installed by the software units and implement various functions of the target system V1000. The local software unit management unit EX200 monitors and tracks the software units UX000 stored locally on the ECU_EX000. The network unit EX100 communicates with other components of the target system V1000.

[0019] 3 is a block diagram showing the configuration of an infotainment system I1000 included in the target system V1000. The infotainment system I1000 includes, for example, an internal network unit I1100, a network unit I1300, and a screen I1200. The internal network unit I1100 communicates with other components in the system. The network unit I1300 communicates with devices outside the system. The screen I1200 functions as a user interface, showing information to a user and receiving information from the user.

[0020] 4 is a block diagram showing a detailed configuration of the OTA center C1000. The OTA center C1000 includes information and authentication required to change software installation in the target system V1000. The OTA center C1000 includes a network unit C1100, a software unit storage unit C1200, a target system management unit C13000, a software unit distribution unit C1400, and a notification unit C1500.

[0021] The network unit C1100 communicates with the target system V1000 or the user device D1000 to provide information for modifying the system. The software unit storage C1200 stores the software units UX000 used to modify the software on the target system V1000. The target system management C13000 maintains information about the target system V1000 and registration information about the users. The software unit distribution C1400 handles sending the required notifications N1000 and software units UX000 to the target system V1000. The notification unit C1500 creates the notifications N1000.

[0022] The target system management unit C13000 further has a list including a number of target systems C13X00. Each list includes a system ID_C13X10, system software information C13X20, and user ID_C13X30. The system ID_C13X10 is an identifier for each target system V1000. The system software information C13X20 is detailed information about software units used in the associated target system V1000 as well as its logical or physical internal components. The user ID_C13X30 is information about the contact of the user of the associated target system V1000. The user ID_C13X30 also has contact information C13X31 about how to contact the user of the target system V1000. The contact information C13X31 also serves as a list of contacts in case a particular user ID_C13X30 has multiple contacts.

[0023] FIG. 5 shows the data structure of software unit UX000. Software unit UX000 includes software unit name UX100, which is the general name of the software, version UX200, binary data UX300, and label group UX400. Version UX200 is a management scheme used to notify changes to binaries and source code. Binary data UX300 is data for replacing a specified binary in target system V1000. Label group UX400 is additional information attached to software unit UX000 to track changes to the functionality of each binary and its safety.

[0024] Labels can only be compared between the same type. That is, between different software, functional labels, safety labels, and security labels can only be compared. Each function and its changes can be stored in the form of a label UX40Y so that they can be easily accessed when needed. Labels do not need to be attached to all software units. In the case of a software unit used in notification N1000, the binary data UX300 may incur unnecessary costs in network transmission if it includes a transmission type N1100.

[0025] FIG. 6 is a block diagram showing the configuration of a user device D1000. The user device D1000 is a component separate from the target system V1000 or the OTA center C1000, and can be used by an end user as a proxy for the notification N1000. The user device D1000 can take various forms. The user device D1000 has a network unit D1100, a method for communicating with the target system V1000 via a user-system authentication unit, a user-system authentication unit D1200 for ensuring secure communication with the target system V1000, and a screen D1300. The network unit D1100 is used by the user to communicate with the target system V1000. The screen D1300 functions as a user interface, where information is displayed to the user and where information is received from the user.

[0026] The notification N1000 is shown in detail in Figure 7. The notification N1000 is the format used to transmit information from the OTA center C1000 to the target system V1000 so that the target system V1000 can correctly process the changes in the software running in the system. In particular, the notification N1000 forwards the software unit UX000 to the initial software unit management unit E1500 of the target system V1000 and to the linked local software unit management unit EX200 for processing.

[0027] Notification N1000 has a transmission type N1100, text information N1200, authentication information N1300, an authentication token N1400, and a group of software units N1500. The transmission type N1100 indicates the type of notification being sent. The text information N1200 indicates readable information about the notification N1000. The authentication information N1300 is used by the target system V1000 to authenticate the notification. The authentication token N1400 is individual authentication information that requires higher security. The software unit N15XX included in the group of software units N1500 is the software unit UX000 linked within the notification N1000 (see FIG. 5).

[0028] Software unit UX000 is the format used by software unit storage and notification N1000 to transmit the information necessary to modify software installed on target system V1000. Following this format creates a traceable and secure method for modifying software on target system V1000.

[0029] FIG. 8 is a flow diagram showing a process in the OTA center C1000 that receives a notification N1000 that a specific software unit needs to be changed in the first embodiment. The notification N1000 is received by the notification unit C1500 of the OTA center C1000 (step S1000). The notification unit C1500 then judges whether the transmission type N1100 is an update (step S1100). If it is judged not to be an update, it judges whether the transmission type N1100 is a rollback (step S1200). If it is judged not to be a rollback, the process ends, and if it is judged to be a rollback, it proceeds to step S1400. If it is judged in step S1100 that the transmission type N1100 is an update, it proceeds to the process shown in FIG. 9 (step S1300). The fact that the transmission type N1100 is an update means that the software unit storage unit C1200 of the OTA center C1000 needs to be updated.

[0030] The process flow shown in Fig. 9 is applied to update the software unit storage C1200. The software unit N15XX of the notification N1000 is extracted by the notification unit C1500 and transferred to the software unit storage C1200 (step S1310). In the software unit storage C1200, the name UX100, the version UX200 and the label group UX400 of the software unit N15XX are extracted (step S1320). The extracted information is compared with the information already available in the software unit storage C1200 (step S1330). In particular, the versions UX200 are compared in step S1340 and the label group UX400 in step S1350.

[0031] If neither the software version UX200 nor the label group UX400 is new, i.e., if both steps S1340 and S1350 in Fig. 9 are "Yes", the process stops (step S1360). If neither information is in the software unit storage section C1200, the software unit N15XX is stored (step S1370). Then, the process proceeds to step S1380, where the process flow shown in Fig. 19 is executed.

[0032] FIG. 19 shows a process flow for reducing the storage area in the software unit storage unit C1200 by using the label group UX400 when the software unit storage unit C1200 is used for rollback purposes.

[0033] In order to reduce the storage area of ​​the software, the software unit storage unit C1200 first obtains the software unit name UX100 and then Storage section C1200 In step S5000, the label group UX400 with the highest safety and security levels is extracted (step S5000). This label group UX400 indicates that it has all the functions of the determined safety and security labels.

[0034] From the label group UX400 with the highest security and safety level, software units with matching safety and security labels can be identified in the software unit storage C1200, even if not all features are labeled. Based on this information, an integer N# can be selected and software units with at most N# fewer features and the same safety and security labels can be flagged (step S5001). Especially with regard to rollback, it is preferable to have an area in the target system V1000 where a small number of software units are stored, even if features are missing in any safety or security version.

[0035] Finally, all software units UX000 for which no flag has been set are deleted (step S5002). In this way, the storage area for the software units is reduced.

[0036] Returning to the flow of Fig. 8, the target system management unit C13000 of the OTA center C1000 searches the system software information C13X20, which is an internal structure, to find the target systems C13X00 that use the software units in the software unit group N1500. From this search, the OTA center C1000 obtains a list of the target systems C13X00 to which the notification N1000 is to be distributed (step S1400). This information is passed to the software unit distribution unit C1400.

[0037] The software unit distribution unit C1400 uses the obtained list to create the necessary notifications N1000, in particular the personalized text information N1200, the authentication information N1300, and the software units used in the software unit group N1500 (step S1500), because each of the target systems V1000 has a different configuration and updates may require additional software units or further authentication.

[0038] The created notification N1000 is sent to the corresponding target system C13X00 via the network unit C1100 of the OTA center C1000 (step S1600). Then, it becomes possible to determine whether the target system C13X00 can be accessed (step S1700). Thus, various options are provided to the OTA center C1000.

[0039] If the OTA center C1000 can access the target system C13X00, the flow of FIG. 10 is used. The network unit E1100 receives the notification N1000 of the target system V1000 (step S1800). The notification management unit E1610 determines whether the notification N1000 is sent from a known OTA center C1000 (step S1801). This is done by the notification management unit E1610 verifying the authentication token N1400 in the notification N1000. If the token can be verified by any authentication system, the process continues. If the token cannot be verified, the process ends. Note that if the target system V1000 is directly connected to the OTA center C1000, this process is skipped. Next, the notification N1000 is sent to the notification management unit E1610 of the rollback management unit E1600 (step S1900). Then, it is determined whether the transmission type N1100 is an update or not (step S2000).

[0040] If it is determined that the transmission type N1100 is an update, the process proceeds to step S2100. In step S2100, a check is made to see if the binary data UX300 of the software unit N15XX is available, since this is what will eventually be needed to modify the software unit in the target system V1000. If the binary data was not included in the notification N1000, the binary data UX300 is available from the corresponding OTA center C1000 (step S2600).

[0041] Regardless of the method of acquiring the software unit N15XX and the binary data UX300, the software unit N15XX is transferred to the initial software unit management unit E1500 (step S2200). Before the changes are applied, it is determined whether the initial software unit management unit E1500 has the authentication information N1300 available (step S2300). If the authentication information N1300 is not available to the initial software unit management unit E1500, i.e., if authentication has failed, the process ends. If the authentication is successful, the process returns to the process flow of FIG. 9, and an update sequence for the software unit storage section of the initial software unit management unit E1500 is executed (step S2400). Next, the process proceeds to the process flow of FIG. 11, where the software unit is changed within the target system V1000 (step S 2500).

[0042] FIG. 11 is a flow chart showing a method for modifying a software unit. First, the initial software unit management unit E1500 determines a list of ECU_EX000 in which the software unit N15XX is used. Then, it transmits the determined list and the software unit N15XX to the update control unit E1400 (step S2501). Using this information, the update control unit E1400 retrieves the software unit N15XX and transfers it to each ECU_EX000 in the list via the internal network unit E1200 (step S2502). Each ECU_EX000 in the list receives the software unit N15XX via the corresponding network unit EX100 and stores the software unit in the local software unit management unit EX200 (step S2503). The local software unit management unit EX200 performs a process of modifying the relevant binary data using information contained in the binary data UX300 of the ECU_EX000 (step S2504).

[0043] The local software unit management unit EX200 transmits the processing result to the update control unit E1400 via the network unit EX100 (step S2505). The update control unit E1400 acquires all of the processing results for each ECU_EX000 in the original list, and notifies the notification management unit E1610 of the processing results (step S2506). The notification management unit E1610 acquires the final processing result, notifies it to the sender of the initial notification N1000, and completes the software unit update procedure (step S2507).

[0044] Returning now to the flow of Fig. 10, if the transmission type N1100 of the notification N1000 is rollback (step S2700), the flow proceeds to Fig. 12 (step S2800). Fig. 12 shows the rollback process in the target system V1000.

[0045] The notification management unit E1610 notifies the rollback data management unit E1510 about the rollback of the software unit N15XX (step S2801). Since the rollback is more sensitive, the authentication information N1300 held by the notification N1000 is used again to determine whether the rollback process is possible (step S2802). If this authentication fails, the process is aborted. If the authentication is successful, the rollback data management unit E1510 extracts the name UX100 and the label group UX400 of the software unit N15XX in the notification N1000 (step S2803). Using this information, the rollback data management unit E1510 polls the software unit storage E1520 to retrieve a list of available software units 15YY (step S2804). The rollback data management unit E1510 compares the label group UY400 of the software unit 15YY in the searched list with the label group UX400 of the notification N1000 (step S2805).

[0046] For each software unit N15YY in the list, it is determined whether it is invalid (step S2806). If the software unit N15YY is not invalid, it is determined whether the label group UX400 of the software unit N15XX is included in the label group UY400 of the software unit 15YY (step S2807). If the label group UX400 is included in the label group UY400, it is further determined whether the label group UX400 is included in the label group UY 400 It is then determined whether the label set U has the same safety and security labels as X If label group UY400 contains the same safety and security labels as label group UY400, then software unit 15YY is saved in a separate list (R) (step S2809). This ensures that all security and safety labels of the functions associated with the software unit are the same, although it may not cover all functions. Note that the version of the software unit UX200 is not taken into account at this time.

[0047] If the result of step S2807 or step S2808 is "No", the next software unit in the list is processed as software unit 15YY (step S2810). When the processing is completed for all software units in the list, the processing proceeds to Fig. 13 (step S2806: "Yes").

[0048] 13 shows the process of selecting a rollback target. First, it is confirmed whether the list (R) is empty (step S2811). If the list (R) is not empty, it is checked whether automatic rollback is set (step S2812). If automatic rollback is set, the rollback data management unit E1510 selects the software unit J with the largest label group UX400 (step S2823). This means that the software unit has the largest number of labels UX40Y.

[0049] If the number of labels UX40Y included in the label group UX400 is the same, a comparison of the versions UX200 can be used. When the software unit J is selected, a flag is set (step S2824). The rollback data management unit E1510 reads the flag and notifies the update control unit E1400 that the software unit needs to be changed (step S2825). The change of the software unit follows the flow of FIG. 18.

[0050] 18, first, the initial software unit management unit E1500 determines and extracts a list of ECU_EX000 having software units N15XX to be rolled back, and transmits the extracted list to the update control unit E1400 (step S2826). Next, the update control unit E1400 uses the authentication information N1300 to transmit information about the required rollback procedure to the local software unit management units EX200 of all ECU_EX000 in the list, using the authentication information N1300 (step S2827).

[0051] For each local software unit management unit EX200 that has been successfully authenticated using the authentication information N1300, the update control unit E1400 transmits to it that the software unit is in an updatable state (step S2828). Note that how to handle the existing software unit N15XX is arbitrary, and the software unit N15XX does not have to be replaced. The update control unit E1400 transfers the software unit J to be rolled back to each ECU_EX000 via the internal network unit E1200 (step S2829).

[0052] In each ECU_EX000, the software unit J is transmitted to the local software unit management unit EX200 (step S2830). The local software unit management unit EX200 uses the binary data UX300 of the software unit J to perform the necessary update to the original software unit N15XX, i.e., rollback or replacement of the software unit (step S2831). The processing result is transmitted to the update control unit E1400 via the network unit EX100 (step S2832). The update control unit E1400 obtains the result of modifying all the software units N15XX by the software unit J and transmits the result to the notification management unit E1610 (step S2833). The notification management unit E1610 notifies the sender of the notification N1000 of the operation result via the network unit E1100 (step S2834). In this manner, the safe and highly secure rollback of the software units of the target system V1000 is completed.

[0053] Returning to the flow of FIG. 13 again. If step S2811 is "Yes", that is, if the list (R) is empty, it means that the software unit storage unit E1520 of the initial software unit management unit E1500 did not extract a software unit having the same safety and security level labels as the software unit 15XX in the process of FIG. 12. In that case, it is first determined whether the OTA function is available (step S2835). If the OTA function is available, the rollback data management unit E1510 attempts to obtain a software unit having at least the same safety label and security label (step S2836). This is performed by the rollback data management unit E1510 confirming whether the OTA client E1300 has such a software unit via the notification management unit E1610. In this case, it is not necessary for all the functions to match.

[0054] If the software unit can be acquired from the communication destination OTA client E1300 (step S2837, Yes), the process returns to the above-mentioned step S2824 and continues. If the OTA function cannot be used (step S2835) or if the connection to the specified OTA center C1000 has failed (step S2837, No), the rollback data management unit E1510 sets a flag indicating that rollback is unavailable (step S2838).

[0055] FIG. 15 shows the process performed when the unavailable flag is set in step S2838. Specifically, the target system V1000 executes a process to disable the problematic software unit N15XX when there is no executable rollback target. First, when the notification management unit E1610 receives a notification indicating that there is no rollback candidate, it notifies the application invalidation unit E1620 of the software unit N15XX to be disabled (step S2839). The application invalidation unit E1620, in cooperation with the initial software unit management unit E1500, determines which ECU_EX000 in the target system V1000 is executing the software unit N15XX and creates a list (step S2840). The created list is sent to the update control unit E1400 (step S2841).

[0056] The update control unit E1400 uses the authentication information N1300 to notify the local software unit management unit EX200 of each ECU_EX000 on the list created in step S2840 of the invalidation of the software unit N15XX via the network unit EX100 (step S2842). The application invalidation unit E1620 notifies, for each authenticated ECU_EX000, the internal network unit E1200 to invalidate the software unit N15XX (step S2843).

[0057] In each ECU_EX000, the local software unit management unit EX200 attempts to disable the software unit N15XX and transmits the result of the process to the application disable unit E1620 (step S2844). The application disable unit E1620 analyzes the received process result and transmits it to the notification management unit E1610 (step S2845). The application disable unit E1620 also notifies the update control unit E1400 about the status change of the software unit. This change is also recorded in the initial software unit management unit E1500 (step S2846). When the disablement of the software unit 15XX is completed, the target system V1000 is considered safe and secure, and the software unit 15XX stops functioning. The notification management unit E1610 notifies the designated sender of a notification N1000 indicating this result via the network unit E1100 (step S2847).

[0058] [Example 2] Next, a second embodiment of the present invention will be described. The second embodiment is a process performed when automatic rollback is not set in step S2812 of the flow shown in Fig. 13, and specifically, the software unit N15XX is rolled back in a non-automatic manner (step S2813). Normally, it is preferable to select automatic rollback, but it is also possible to allow the user to select the level of safety and security. That is, in this embodiment, the user himself selects the rollback candidate. The selection process of the rollback candidate is shown in Fig. 14.

[0059] The rollback candidates can be selected using the user device D1000 or the infotainment system I1000 of the target system V1000 (step S2814). When using the infotainment system I1000, the rollback data management unit E1510 transmits a list (R) of available software units to the infotainment system I1000 via the internal network unit E1200 (step S2815). The infotainment system I1000 displays information about the obtained list R on the screen I1200 (step S2816).

[0060] An example of a screen I1200 with the above information displayed is shown in Figure 3. The area indicated by I1210 shows information about the software units that need to be rolled back, indicated by the notification N1000. The rollback candidates are displayed in a dialog labeled I1220, where the features available in each software unit and the software unit version are displayed for the user's convenience. The user can select the software units to roll back on this screen I1200.

[0061] If one of the dialogs labeled I1220 is pressed, a more detailed description of the software unit is displayed as a dialog box labeled I1230. This is useful for the user to understand the changes that may occur due to the rollback of the software unit. The user uses the select button to select the software unit J to be rolled back (step S2817). The selected software unit J is sent to the rollback data management unit E1510 (step S2818). Then, step S2824 (see FIG. 13) described in the first embodiment is followed.

[0062] It is also possible to select the software unit to be rolled back using the user device D1000, as shown in steps S2819 to S2822 of Fig. 14. Steps S2819 to S2822 correspond to steps S2815 to S2818, respectively, when the infotainment system I1000 is used. The layout of the screen D1300 on which information about the rollback candidates is displayed does not substantially differ from the layout of the screen I1200 shown in Fig. 3, but may require minor adjustments due to the different sizes of the screen D1300 and the screen I1200.

[0063] [Example 3] Next, a third embodiment of the present invention will be described. The third embodiment is a process performed when the answer is "No" in step S1700 of the flow shown in Fig. 8, that is, when the target system V1000 is inaccessible, and specifically, the process flow shown in Fig. 16 is executed. When the target system V1000 is inaccessible, the OTA center C1000 checks the contact information C13X31 of the target system C13X00 listed in the target system management unit C13000, and selects the contact information C13X31 that can contact the user specified by the user ID_C13X30 (step S3800).

[0064] It is determined whether the user device D1000 identified by the selected contact has a notification storage unit D1210 (step S3801). If the user device D1000 has the notification storage unit D1210, it is determined whether the user device D1000 further has an authentication token storage unit D1211 (step S3802). If the user device D1000 does not have either the notification storage unit D1210 or the authentication token storage unit D1211, a notification N1000 including text information N1200 indicating that the OTA center C1000 cannot connect to the target system V1000 is sent to the user's contact extracted from the contact information C13X31 (step S3808).

[0065] If the user device D1000 has both the notification storage unit D1210 and the authentication token storage unit D1211, it is checked whether the transmission type N1100 of the notification N1000 to be sent is rollback or not (step S3803). If the transmission type N1100 is not rollback, a notification N1000 having a transmission type N1100 of update is created for the user ID_C13X30 using the software unit N15XX, and authentication information N1300 required for the target system V1000 to process the notification N1000 is attached (step S3807).

[0066] If the sending type N1100 is rollback, a notification N1000 with a sending type N1100 of rollback is created for the user ID_C13X30 (step S3804). The notification N1000 has a software unit N15XX without binary data UX300, authentication information N1300, and authentication token N1400. The authentication information N1300 is used to process the notification N1000, and the authentication token N1400 is used to authenticate the rollback. The notification N1000 created for all the above three cases is sent to the network unit C1100 (step S3805), and the user device D1000 retrieves and stores the notification N1000 via the network unit D1100 (step S3806), and the process is terminated from the OTA center C1000 side.

[0067] To continue the process thereafter, the flow in Fig. 17 is used. The user device D1000 is connected to the target system V1000 via the network unit D1100 of the user device D1000 (step S4001). When the connection is established, the user device D1000 transmits a notification N1000 to the target system V1000 (step S4002). After that, the process returns to Fig. 10 and continues. In this manner, the necessary notification N1000 can be obtained from the information safely and securely stored in the user device D1000.

[0068] [Example 4] Next, a fourth embodiment of the present invention will be described. The fourth embodiment differs from the first embodiment in that the notification N1000 includes various software units N15XX. It is common for changes in one software unit to depend on another software unit. Using the format described in FIG. 7, various software units can be delivered simultaneously. This feature can also be used to send a new safe and secure version of the previous software together with the new functionality, preventing rollback back to a much more limited version.

[0069] An example of the format of the notification N1000 used in this embodiment is shown in Figure 20. Looking at the software unit U1000, a virtual software unit U1000 including specific binary data U1300 and a label U1400 can be included in a notification N1000 with an update transmission type N1100. Within that notification N1000, a similar software unit U2000 can also be included with a label set U2400 that has a reduced number of labels while maintaining the safety and security labels, but with one less specific function (the label set U2400 does not include the label U1402).

[0070] Because the software unit U2000 is not the latest version and has limited functionality, it is not immediately installed in the target system V1000, and the software unit U1000 is given priority. However, because the software unit U2000 has the highest level of label U1401 in terms of safety and security, it is flagged, and both the software units U1000 and U2000 are stored in the software unit storage unit E1520 of the target system V1000. That is, the software unit U2000 can be one of the rollback candidates described with reference to FIG. 12. Using this function of the notification N1000 to simultaneously deliver the updated version and its most appropriate rollback candidate, the possibility of rollback without accessing the OTA center C1000 is greatly increased.

[0071] According to the embodiment of the present invention described above, the following advantageous effects are obtained. (1) The software update device of the present invention comprises a software storage unit that stores multiple pieces of software including label information, and a software update control unit that controls software updates of a vehicle control device, wherein the label information includes at least information regarding the safety of the software, and when the software update control unit receives a rollback instruction, it selects from the multiple pieces of software, software having safety label information that is identical to the safety label information of the software installed in the vehicle control device, as the software to be rolled back.

[0072] With the above configuration, it is possible to select software to be rolled back based on the effect on the safety of vehicle control and / or the security of the vehicle, thereby preventing the safety of the vehicle from being compromised.

[0073] (2) The software update control unit further includes an application disabling unit that disables software installed in the vehicle control device when the software update control unit cannot select software to be rolled back from the software storage unit. This makes it possible to prevent problematic software from continuing to run and posing a risk to the vehicle when the software update control unit cannot select software to be rolled back.

[0074] (3) The software storage unit further stores updates of the plurality of pieces of stored software, and the software update control unit uses one of the plurality of updates of the software to roll back the software installed in the vehicle control device. This allows the software storage unit to store software versions at each stage, making it possible to prevent the software to be rolled back from becoming an excessively old version.

[0075] (4) Safety-related information includes the reliability of vehicle control and security to prevent unauthorized access from outside. This makes it possible to subdivide label information and perform rollback with more strict safety assurance.

[0076] (5) A transmitting / receiving unit capable of communicating with a management server and a user terminal via a network is further provided, the software storage unit stores a plurality of programs received from the management server via the transmitting / receiving unit, and the software update control unit requests the management server to transmit additional software when the software to be rolled back cannot be selected from the software storage unit, thereby increasing the possibility of executing an appropriate rollback.

[0077] (6) A transmission / reception unit capable of communicating with a management server and a user terminal capable of communicating with the management server via the network is further provided, and the management server transmits a rollback instruction to the user terminal when communication between the transmission / reception unit and the management server is interrupted. This allows the user to manage the rollback by himself, improving convenience for the user.

[0078] The present invention is not limited to the above-described embodiments, and various modifications are possible. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to an embodiment having all of the configurations described. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment. It is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to delete a part of the configuration of each embodiment, or to add or replace another configuration. [Explanation of symbols]

[0079] C1000 OTA center (management server), D1000 user device, E1000 software update device, E1400 update control unit (software update control unit), E1520 software unit storage unit (software storage unit), E1620 application invalidation unit (application invalidation unit), EX000 ECU (vehicle control device), UX000 software unit (software), UX400 label information (label group)

Claims

1. A software update device for controlling software updates of a vehicle control device, a software storage unit for storing a plurality of pieces of software including label information; A software update control unit that controls software updates of the vehicle control device; Equipped with The label information includes at least information regarding the safety of the software, When the software update control unit receives a rollback instruction, the software update control unit selects, from the plurality of software, the software having the label information regarding safety that is the same as the label information regarding safety of the software installed in the vehicle control device, as the software to be rolled back. A software updating device comprising:

2. 2. The software update device according to claim 1, When the software update control unit cannot select software to be rolled back from the software storage unit, The vehicle control device further includes an application disabling unit that disables the software installed in the vehicle control device. A software updating device comprising:

3. 2. The software update device according to claim 1, the software storage unit further stores updates to the plurality of pieces of software stored therein; the software update control unit rolls back the software installed in the vehicle control device using any one of the updates of the plurality of software. A software updating device comprising:

4. 2. The software update device according to claim 1, The information regarding the safety includes the reliability of vehicle control and security for preventing unauthorized access from the outside. A software updating device comprising:

5. 2. The software update device according to claim 1, A transmitting / receiving unit capable of communicating with a management server via a network, the software storage unit stores the plurality of pieces of software received from the management server via the transmission / reception unit; the software update control unit, when unable to select the software to be rolled back from the software storage unit, requests the management server to transmit additional software. A software updating device comprising:

6. 2. The software update device according to claim 1, A transmitting / receiving unit capable of communicating with a management server and a user terminal capable of communicating with the management server via the network, the management server transmits the rollback instruction to the user terminal when communication between the transmission / reception unit and the management server is interrupted; A software updating device comprising:

Images