Software update device and system

Abstract

To provide a software update device and system with which user application data can be maintained or at least a user can recognize the possibility of losing the data after changing a software unit in a target system to another unit.SOLUTION: A software update device comprises: a storage unit that stores a conversion function for converting a data format of data including user data of an application when the data version of the application is changed; a conversion function acquisition unit that acquires the conversion function that meets a request for a change in the application; and a data conversion unit that converts the data format of the application into a desired data format using the received conversion function. The data conversion unit changes a process relating to user data of the application depending on the presence or absence of the conversion function during the application change.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a software update apparatus and system that allows components to ensure that user application data continues to be available on a target system despite software changes made during the target system's lifecycle. [Background technology]

[0002] Software is increasingly being used in the traditional functional safety domain to provide personalized enhancements for consumers and vehicle operators. These capabilities are increasingly being leveraged through the use of user-generated application data. In the automotive domain, the use of user application data has increased in recent years to better personalize software-based features such as Adaptive Cruise Control (ACC), Automatic Emergency Steering (AES), Automatic Parking (AP), and Advanced Driving Assistant Systems (ADAS), as well as Autonomous Driving Systems (AD).

[0003] As the number of vehicles equipped with these features continues to increase, automakers' need to differentiate themselves from their competitors requires them to continuously and seamlessly maintain or improve the personalized user experience that specific users have become accustomed to. Long-term maintenance of user application data will play a major role in realizing the personalized user experience.

[0004] In many functional safety areas, safety requirements are largely established and can be easily inspected, even with increasing software complexity. However, software-related errors are discovered and fixed after products are sold. In the automotive sector, software-related errors directly affect the core functions of many vehicles, potentially causing service outages for automotive suppliers and reducing the quality of the user experience. In this regard, half of all vehicle recalls in 2019 were related to software-based defects.

[0005] The rise of ubiquitous connectivity through 4G and 5G cellular technology, and the increasing use of higher bandwidth internet combined with Wi-Fi in many homes, has enabled software updates via Firmware Over The Air (FOTA) and Software Over the Air (SOTA). These update mechanisms allow device manufacturers to update software without having to return the device to the manufacturer. This technology is of great importance in the automotive sector for two main reasons:

[0006] First, with FOTA / SOTA solutions, most features are software-enabled, allowing users to take advantage of the latest features. Second, users can use FOTA / SOTA solutions to get the latest fixes and fix their vehicles to function properly. The only requirement for this is an internet connection. Especially in the automotive sector, software updates of any kind have traditionally been performed by users physically visiting locations such as car dealerships. This has been a logistical burden for manufacturers and a concern for the consumer user experience.

[0007] 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, authentication and authorization are required to perform the update, which adds additional time for the end user to complete the update.

[0008] In these particular cases, a user experience focused solution is to roll back to a known safe and secure application version. However, in the automotive domain, where personalized user experience is increasingly important, simply rolling back the application is not enough; we also need to ensure that user application data is preserved and as usable as possible. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-287055 [Patent Document 2] Japanese Patent Application Laid-Open No. 2005-332301 [Patent Document 3] Japanese Patent Application Laid-Open No. 2005-309548 Summary of the Invention [Problem to be solved by the invention]

[0010] The present invention aims to provide a software update device and system that allows user application data to be maintained when changing a software unit of a target system to another unit, or at least makes it possible to recognize that data may be lost after changing the software unit. [Means for solving the problem]

[0011] In order to solve the above problems, the software update device of the present invention comprises a memory unit that stores a conversion function that converts the data format of data including user data of an application when changing the data version of the application, a conversion function acquisition unit that acquires a conversion function that conforms to the requirements of the application change, and a data conversion unit that converts the data format of the application to a desired data format using the received conversion function, and the data conversion unit changes the processing of the user data of the application depending on whether or not the conversion function is available when the application is changed. [Effects of the Invention]

[0012] According to the present invention, it is possible to provide a software update device and system that allows user application data to be maintained when changing a software unit of a target system to another unit, or at least makes it possible to recognize that data may be lost after changing the software unit. Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Furthermore, problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a schematic block diagram showing the overall configuration of a software update system to which a software update device according to the present invention is applied; [Figure 2] FIG. 2 is a functional block diagram showing the configuration of a target system V1000. [Figure 3] FIG. 3 is a functional block diagram showing the configuration of a data conversion management unit XYZ300. [Figure 4] FIG. 3 is a functional block diagram showing the configuration of a data conversion unit XYZ320. [Figure 5] FIG. 1 is a functional block diagram showing the configuration of an OTA center C1000. [Figure 6]FIG. 1 is a functional block diagram showing the configuration of an infotainment system I1000 that presents a rollback screen I1200. [Figure 7] FIG. 1 is a functional block diagram showing the configuration of an infotainment system I1000 that presents an update screen I1300. [Figure 8] FIG. 1 is a functional block diagram illustrating the configuration of an infotainment system I1000 that presents a replacement screen I1400. [Figure 9] FIG. 2 is a functional block diagram showing the configuration of a software unit UX000. [Figure 10] FIG. 2 is a functional block diagram showing the configuration of a notification N1000. [Figure 11] 10 is a flowchart showing a process executed by the software update device. [Figure 12] 10 is a flowchart showing a process for updating a software storage unit. [Figure 13] 10 is a flowchart showing a notification process by a target device. [Figure 14] 10 is a flowchart showing data conversion processing for updating. [Figure 15] 10 is a flowchart showing an update process of application data. [Figure 16] 10 is a flowchart showing a conversion process of application data. [Figure 17] 10 is a flowchart showing a process of disabling an application. [Figure 18] 10 is a flowchart showing application conversion processing when an entry in the data conversion management unit is valid. [Figure 19] 10 is a flowchart showing a rollback process when data conversion fails. [Figure 20] 10 is a flowchart illustrating the application data conversion process during application rollback / replacement. DETAILED DESCRIPTION OF THE INVENTION

[0014] [Example 1] An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing the overall components of a 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 and an OTA center C1000 (detailed in FIG. 5) connected to the target system V1000 via a predetermined communication system. The OTA center C1000 can transfer required software to the target system V1000 via a notification N1000 (detailed in FIG. 10). The target system V1000, detailed in FIG. 2, is any system composed of information processing units, which may be separate devices, to perform specific functions.

[0015] Figure 2 is a block diagram showing the configuration of the target system V1000. The target system V1000 is a system that can be composed of multiple devices, each with its own software. The target system V1000 is composed of an infotainment system I1000 that provides an interface between the user and the system, a software update device E1000 that provides software changes, user application data conversion, and system rollback functions, and an arbitrary number of ECUs EX000 that implement the functions provided by the target system V1000.

[0016] The infotainment system I1000 is shown as a block diagram in FIG. 6. The system comprises an internal network unit I1100 for communicating with components within the target system V1000, a network unit I1300 for communicating with external devices, and a screen as a user interface for displaying information to and receiving information from the user. Depending on the type of software unit change, the information displayed on the screen changes. FIG. 6 shows screen I1200 as an example of a software unit rollback, FIG. 7 shows screen I1300 as an example of a software unit update, and FIG. 8 shows screen I1400 as an example of a software unit replacement.

[0017] The configuration of the software update device E1000 is shown in Figure 2. The software update device E1000 has a network unit E11000 that allows network access outside the target system V1000, an internal network unit E12000 that allows network access within the target system V1000, an update control unit E14000 that is responsible for changing software units within the target system V1000, an initial software unit management unit E15000, and a rollback management unit E16000. The initial software unit management unit E15000 is responsible for tracking the software units installed within the target system V1000 and the ECU EX000 on which they are running.

[0018] The initial software unit management unit E15000 further includes a software unit storage unit E15200. This storage unit stores software units E153XX that may be used later in the life cycle of the target system V1000, as well as files of any format that may be used during the life cycle of the target system V1000. The rollback management unit E16000 is responsible for processing notifications N1000. This unit includes a notification management unit E16100 that directly processes notifications N1000, and an application disablement unit E16200 that cooperates with the initial software unit management unit E15000 and the ECU EX000-specific software management unit EX200 to determine where to send a signal when a specific application EX40Y should be disabled. This unit also includes a data conversion management unit E16300 that maintains information regarding the conversion of user application data used by a specific application EX40Y.

[0019] The data conversion management unit XYZ300 is shown in detail in Figure 3. The data conversion management unit XYZ300 has an application data conversion management table XYZ310. This table indicates the information required to allow conversion of user application data used in a particular application EX40Y. This table consists of Application Name XYZ311 (a unique name that identifies a particular binary within ECU EX000), Version XYZ312 which is the version specified by the creator of the binary, Application Data Version XYZ313 which is the version specified by the creator of the user application data stored by the binary, Conversion Destination Application Name XYZ314 which is the unique name of the destination to which Application Name XYZ311 is converted, Conversion Destination Application Version XYZ315 which is the version of the converted destination, Conversion Destination Data Version XYZ316 which is the version specified by the creator of the destination binary to which Application Name XYZ311 is converted, Conversion Function XYZ317 which is the unique name of the function that allows for the physical conversion of the user application data, and Conversion Function Location XYZ318 which is a Uniform Resource Identifier (URI) that notifies the location where Conversion Function XYZ317 can be accessed.

[0020] Because different binary versions may require user application data conversion, the conversion destination application name XYZ314 may be the same as the application name XYZ311. Similarly, because different binaries may use the same user application data, version XYZ312 and conversion destination data version XYZ316 may be the same. The conversion function location XYZ318 is not limited in its implementation. This information may lead to another tool, binary, or API that can complete the user application data conversion. The data conversion management unit E16300 also includes components responsible for executing the user application data conversion on a particular system via the data conversion resource unit XYZ321 and data conversion execution unit XYZ322, which track resources to determine whether the user application data conversion can be performed on a particular system via the data conversion resource unit XYZ321 and components, as shown in Figure 4. The data conversion unit XYZ320 also includes a data location unit XYZ323, which is a table that tracks the user application data used by application EX40Y in the system.

[0021] The ECU EX000 comprises any number of applications EX40Y that implement the functionality of the target system V1000, installed via software units UX000, a software management unit EX200 that keeps track of the software units UX000 on the ECU EX000, and a network unit EX100 that provides connections between components in the target system V1000. The ECU EX000 may also include a local data conversion unit EX300 that mimics components found in the software update device E1000.

[0022] The OTA center C1000 is shown in more detail in Figure 5. The OTA center C1000 contains the information and authorizations required to modify the software installation on the target system V1000. The OTA center C1000 consists of a network unit C1100, which is used to communicate with the target system V1000 and provide information to modify the system; a software unit storage unit C1200, which is used to store the software units UX000 used to modify the software on the target system V1000; a target system management unit C13000, which is used to maintain information about the target system V1000; a software unit distribution unit C1400, which sends the required notifications N1000 and software units UX000 to the target system V1000; a notification unit C1500, which creates the notifications N1000; and a data conversion management unit C1600, which is responsible for maintaining information about the conversion of user application data used in a specific application EX40Y.

[0023] The target system management section C13000 consists of a list of target systems C13X00. Each entry contains information about the system ID C13X10, a unique identifier of the target system V1000, system software information C13X20, and detailed information about the software units used within the target system V1000 and its logical or physical internal components.

[0024] The details of notification N1000 are shown in Figure 10. Notification N1000 is a format used to send information from OTA center C1000 to target system V1000 so that the target system V1000 can correctly process the system software change request. Specifically, notification N1000 forwards software unit UX000 to the initial software unit management unit E15000 and linked software management unit EX200 of target system V1000 for processing. Notification N1000 consists of notification type N1100, which determines the type of notification to be sent; authentication information N1300, which is used by target system V1000 to authenticate the notification; and unit N1500, which is the software unit UX000 linked to the notification.

[0025] The software unit UX000 is a format used by the software unit storage and notification N1000 to transmit information necessary to change the software installed in the target system V1000. This format is used to create a component that can track data transformations of user applications within the target system V1000. In the present invention, the software unit UX000 is shown in FIG. 9.

[0026] The software unit UX000 includes an application name UX100, which is the generic name of the software; a version UX200, which is a versioning scheme used to signal normal changes to binaries and source code; binary data UX300, which substantially contains binary data used to replace a specified binary in the target system V1000; an application data version UX400, which is a versioning scheme used to signal normal changes to the way user application data is collected and stored; a conversion attempt section UX500, which is a flag that signals that a data conversion should occur within the software unit; an invalidation section UX600, which is a flag that signals that the associated software unit should be invalidated; and zero or more data conversion sections UXY00, which contain information related to the data conversion of the user application.

[0027] The data conversion unit UX700 includes a conversion application name UX710 that determines the common application name to be used after the user application data is converted, a conversion application version UX720 that determines the version of the common application name, a conversion data version UX730 that is the application data version to which the current data will be converted, a conversion function UX740 that is the generic name of the function that allows the user application data conversion, and a conversion function location UX750 that is a URI that gives access to the function that allows the data conversion.

[0028] For software units used in notification N1000, the binary data UX300 is included only if notification type N1100 requests its use, since its inclusion would result in unnecessary costs during data transmission. The flags conversion attempt part UX500 and invalidation part UX600 are also used only if notification type N1100 requests their use. If the data conversion part UXY00 is used, the application name UX100, version UX200, and application data version UX400 must be included.

[0029] 11 shows the process performed by the OTA center C1000 in the first embodiment when it receives a notification N1000 that a particular software unit needs to be modified. Using the necessary communication technology, the notification is received by the OTA center C1000, specifically, the notification unit C1500 (step S1000). At this point, the notification unit C1500 determines whether the notification type N1100 is an update (step S1100), a replacement (step S1200), or a rollback (step S1300). If the notification type N1100 is an update or replacement, the OTA center C1000 must update its software unit storage C1200. If the notification type N1100 is a rollback, the update of the software unit storage C1200 is skipped.

[0030] The software unit storage unit C1200 is updated using the flow shown in Figure 12. The software unit UX000 in the notification N1000 is extracted by the notification unit C1500 and transferred to the software unit storage unit C1200 (step S1410). The software unit storage unit C1200 extracts the application name UX100, version UX200, application data version UX400, conversion attempt part UX500, invalidation part UX600, and available data conversion part UXY00 of the software unit UX000, and uses the extracted information to compare with the information already available in the software unit storage unit C1200 (step S1420).

[0031] If version UX200 of software unit UX000 is not found in step S1420, i.e., if step S1430 returns "No," software unit UX000 is stored in software unit storage C1200 (step S1440). Information about software unit UX000's application name UX100, version UX200, application data version UX400, and data conversion unit UXY00 is used to check whether such information is already in application data conversion management table XYZ310 (step S1450). If the information is not in table XYZ310, the information is added to the table for later use (step S1460).

[0032] 11, if the notification type N1100 is rollback, the target system management unit C13000 of the OTA center C1000 retrieves system software information C13X20 by searching its internal structure to find systems that use the software unit found in unit N1500. From this search, the OTA center C1000 retrieves a list of target systems C13X00 to which notification N1000 must be distributed (step S1500).

[0033] This information is passed to the software unit distribution unit C1400, which uses the list to create the necessary notifications N1000, particularly the software units used in the notification unit N1500, since each target system V1000 may have a different configuration due to additional software units required for specific changes or additional authentication (step S1600). Once the notification N1000 is created, it is sent to the corresponding target system C13X00 via the network unit C1100 of the OTA center C1000 (step S1700).

[0034] When notification N1000 reaches the target system V1000 in step S1700, the process proceeds to the flowchart in Fig. 13. The network unit E11000 receives notification N1000 for the target system V1000 (step S1800). Next, notification N1000 is passed to notification management unit E16100 of the rollback management unit E16000, which determines what procedure is required (step S1900).

[0035] Next, the type of notification type N1100 is determined again, and if this is an update ("Yes" in step S2000), this will be described later as embodiment 2. If the notification type N1100 of notification N1000 is a rollback or a replacement ("Yes" in step S2500 or S2700), the flow proceeds to Fig. 20 (step S2600).

[0036] In FIG. 20, first, the notification management unit E16100 transfers the software unit N15XX to the initial software unit management unit E15000, and extracts a list of software units having the same application name UX100 in the target system V1000 (step S2601).

[0037] Furthermore, the list is narrowed down by filtering to the same version UX200 of the software unit N15XX (step S2602). The OTA center C1000 or the notification N1000 may not want to convert the data of the user application, which is why it is checked whether the conversion trial unit UX500 is enabled. If the conversion trial unit UX500 is not enabled, the user application data conversion is skipped (step S2603). If the conversion trial unit UX500 is enabled, it is moved to the software unit S1 in the list (step S2604), and it is checked whether it is disabled (step S2605).

[0038] If S1 is invalid, no user application data conversion is performed. If S1 is not invalid, the application data version UX400 of each software unit is checked to see if it is the same as the application data version UX400 of software unit N15XX (step S2606). If there is no change in the application data version UX400, i.e., if they are the same ("Yes" in step S2606), no user application data conversion is performed, and the next software unit in the list is checked (step S2609).

[0039] If a mismatch in application data version UX400 is found (step S2606: No), the application data conversion management table XYZ310 is checked for an entry that maps the listed software unit's application name UX100, version UX200, application data version UX400, and software unit N15XX's converted destination application name XYZ314, converted destination application version XYZ315, and converted destination data version XYZ316 to application name XYZ311, version XYZ312, application data version XYZ313, converted destination application name XYZ314, converted destination application version XYZ315, and converted destination data version XYZ316 (step S2607). If an entry exists, the operational flow continues with FIG. 15 (step S2608). If an entry does not exist, the operational flow continues with FIG. 18 (step S2610).

[0040] The operational flow in Figure 15 begins by retrieving the entry in the application data conversion management table XYZ310 found in step S2607 (step S2009). Next, the data conversion management unit XYZ300 reads from the update control unit E14000 the ECU EX000 linked to the application name UX100, version UX200, and application data version UX400 in the application data conversion management table XYZ310 entry (step S2010). Upon finding the target ECU EX000, the data conversion management unit XYZ300 extracts the conversion function XYZ317 and the conversion function location XYZ318 for later use (step S2011).

[0041] At this point, using any available means, the local data conversion resource unit XYZ321 updates information from the data conversion resource unit EX310 of ECU EX000 (step S2012) so that it can determine whether ECU EX000 has available resources to execute the conversion function XYZ317 (step S2013). The present invention does not limit the type or method of resources for this determination.

[0042] If the data conversion management unit XYZ300 determines that the ECU EX000 can execute the conversion function XYZ317 (has the resources), it creates a single-entry list with the data conversion units XYZ320 of the ECU EX000 (step S2014). If the data conversion management unit XYZ300 determines that the ECU EX000 cannot execute the conversion function XYZ317 (does not have the resources), it creates a list with all connected data conversion units XYZ320 from which the component can obtain information.

[0043] The present invention does not limit the resources or methods for obtaining other possible candidates for performing user application data conversion. The list of components that can perform user application data conversion can include other ECUs EX000 in the target system V1000, the software update device E1000 itself, the OTA center C1000, or other systems connected to the target system V1000 and that have data of the data conversion unit XYZ320 (step S2016). Regardless of where the execution takes place, the created list is used in the operational flow that follows in FIG. 16 (step S2015).

[0044] In the flow of Figure 16, the data conversion unit XYZ320 (DC) in the created list is checked (step S2017) to confirm that it is not invalid (step S2018). If the list is invalid ("Yes" in step S2018), the data conversion management unit E16300 is notified that data conversion could not be performed (step S2028). The options available after the data conversion fails are processed according to the operational flow of Figure 19 (step S2029).

[0045] If the list is not invalid ("No" in step S2018), then it is necessary to verify that the potential data conversion unit XYZ320 candidates have the resources to perform the conversion function XYZ317 (step S2019). If the currently selected data conversion unit XYZ320 does not have the resources, then the flow proceeds to the next data conversion unit XYZ320 in the list (step S2027). Thus, if there is no data conversion unit XYZ320 in the list that can correctly perform the conversion function XYZ317, then the data conversion fails and the flow proceeds to step S2028 as described above.

[0046] If it is confirmed that the selected data conversion unit XYZ320 has the resources to execute the conversion function XYZ317 (“Yes” in step S2019), the ECU EX000, which is the original owner of the user application data, via the network unit EX100, transfers the information in the data location E2334 associated with the application name E2331 and version E2332 in the referenced application data conversion management table XYZ310 entry to the selected data conversion unit UX320 by whatever means available (step S2020).

[0047] The present invention has no limitations regarding the method used to transmit this information. The selected data conversion unit UX320 receives this information and retrieves the conversion function XYZ317 from the conversion function location XYZ318 (step S2021). There are no limitations regarding the method of obtaining the conversion function XYZ317. The selected data conversion unit XYZ320, now equipped with the information necessary to convert the specified user application data, waits until the system is ready to perform the data conversion (step S2022).

[0048] This procedure ensures that the resources required for the conversion of user application data do not interfere with the functionality of the target system V1000 or its components. There are no limitations on how the state of this step can be defined. Once the desired state is reached, the authentication information N1200 is verified (step S2023).

[0049] Validation of the authentication information N1200 is a method for ensuring that the data conversion and subsequent binary modification of the user application are performed reliably. There are no limitations on how this validation can be implemented. Once the authentication information N1200 is validated, the selected data conversion unit XYZ320 executes the conversion function XYZ317 to convert the application data version E2333 information of the application name E2331 from the data location E2334 to the conversion destination data version XYZ316 of the selected application data conversion management table XYZ310 entry (step S2024). Upon completion of the execution, a final verification of the user application data is performed (step S2025). If the result is successful, the converted data is returned to the target ECU EX000 (step S2026). If the result is unsuccessful, the process flow continues to verify other data conversion units XYZ320 (step S2027).

[0050] 20, once the user application data has been successfully converted for a particular software unit, the initial software unit management unit E15000 continues to process other software units in the list using steps S2605 through S2609 until there are no more software units to process, which causes the operational flow to proceed to step S2200 of FIG.

[0051] Step S2200 is the same operation as the software unit store update described above, considering that this step is performed on the target system V1000. After updating the software unit store, the system again verifies authentication information N1200 to ensure that the next step, the actual modification of binaries on the system, has permission to execute (step S2300). If authentication information N1200 is unavailable ("No" in step S2300), the operational flow ends. If authentication information N1200 satisfies the requirement that it is available ("Yes" in step S2300), the operational flow continues to FIG. 17 (step S2400).

[0052] The operational flow of FIG. 17 begins with the initial software unit management unit E15000 determining a list of ECUs EX000 in which the software unit is used and transferring this list to the update control unit E14000 (step S2401). Depending on an event that occurred during the data conversion phase of the user application, it may become necessary to disable a particular software unit. This check is performed in step S2402. If there is no need to disable a software unit ("No" in step S2402), the update control unit E14000 obtains a list of software units N15XX and ECUs EX000 and transfers information to each element of the list via the internal network unit E12000 (step S2403). The target ECU EX000 passes the software unit to the software management unit EX200 via the network unit EX100 (step S2404).

[0053] Since the ECU EX000 may be in a state that does not allow software modification, it may need to wait until a state that does allow modification is reached (step S2405). Once the desired state is reached, the actual replacement of the relevant binary data UX300 from the software unit N15XX can take place on the ECU EX000 (step S2406). Once the modification is complete, the software management unit EX200 sends the processing result to the update control unit E14000 via the network unit EX100 (step S2407), which in turn notifies the notification management unit E16100 of the processing result (step S2408). The notification management unit E16100, which was the component that processed the incoming request, then reports the processing result to the designated sender via its network unit E11000 (step S2409), and the processing flow ends.

[0054] Returning to the flow of Figure 20, during the user application data conversion attempt, in step S2607, it is possible that the application data conversion management table XYZ310 is not available for the software unit that requires rollback. In this case, the operational flow continues to Figure 18 (step S2610).

[0055] In the flow, Over the Air (OTA) functionality is required to connect to an external information repository such as OTA center C1000 (step S2050). This is because it has already been determined that target system V1000, for some reason, does not have the information necessary to continue the process of user application data conversion. If OTA functionality is not available, the operational flow continues to Figure 19 (step S2055). If OTA functionality is available, the application name UX100, version UX200, and application data version UX400 of the target software unit and the application name UX100, version UX200, and application data version UX400 of software unit N15XX received in notification N1000 are forwarded to OTA client E13000 (step S2051).

[0056] The information is sent via network unit E11000 to OTA center C1000, where it is used to check application data conversion management table XYZ310 in data conversion management unit C1600 of the OTA center (step S2052), and further search for a matching entry (step S2053).

[0057] If there is an entry in the application data conversion management table XYZ310 of the OTA center C1000, that information is placed in the newly created notification N1000, with the data conversion unit UXY00 information updated and the conversion attempt unit UX500 set to enabled (step S2054). This requires the notification N1000 to be processed again by the OTA center C1000 and the target system V1000, i.e., going through the flow of Figure 11 again (step S2055).

[0058] If the OTA function is not available ("No" in step S2050), or if the OTA center C1000 selected for polling does not have an application data conversion management table XYZ310 for the combination of the application name UX100, version UX200, and application data version UX400 of the target software unit and the application name UX100, version UX200, and application data version UX400 of the software unit N15XX ("No" in step S2053), the processing flow proceeds to Figure 19 (step S2056).

[0059] 19, the data conversion management unit E16300 needs to notify the rollback management unit E16000 of the failure of the user application's data conversion (step S3001). At this point, the user application data conversion has failed, but a rollback is required, so the rollback management unit E16000 recompiles the available information in the application data conversion management table XYZ310 and obtains a list of software units that match the information for the converted destination application name XYZ314 and the converted destination application version XYZ315 from the application data conversion management table XYZ310 entry having the application name E2331 and version E2332 that match the application name XYZ311 and version XYZ312 in the table (step S3002).

[0060] In normal processing, the entries and their information would lead to the conversion of the user application's data. However, in this processing flow, these entries also indicate selected rollback targets that can be used if the user application's data conversion cannot be realized. The list is then sent by the notification management unit E16100 via the internal network unit E12000 to the infotainment system I1000 (step S3003), and the end user selects what to do if the user application data cannot be converted. Depending on the backup strategy used for the user application data, different options may be available.

[0061] In this example, the initial notification type N1100 was a rollback, so step S3008 returns "Yes," and a series of options are displayed on screen I1200 (see FIG. 6) (step S3009). The affected software units are displayed on screen I1210, and the options on I1220 may include, but are not limited to, using the selected rollback with previously backed-up data or without any data, or disabling the software unit, since it is important for the rollback procedure that the current software unit is not running in the system. An option is selected by the user (step S3010), and notification N1000 is created with the information necessary to modify the system (step S3007). If the software unit is to be disabled, disabler UX600 is set to enabled.

[0062] When using the software unit without attempting data conversion of the user application, the conversion attempt unit UX500 is set to enabled. When backed-up information is utilized, the data conversion unit uses any method to obtain backed-up information related to the software unit and its particular version. The modified notification N1000 is sent back via link 21 to step S2300 of FIG. 13, where the authentication information N1200 is again verified.

[0063] Regardless of the final outcome of the processing flow, the end user knows how the user application data has been processed, and the target system V1000 is configured as desired by the user, with safety and security approvals from the system provider.

[0064] [Example 2] Next, a software update system according to a second embodiment of the present invention will be described. As described above, in the second embodiment, notification N1000 has notification type N1100 of upgrade ("Yes" in step S2000 of FIG. 13). In this case, the system must perform and verify user application data conversion before any binaries are changed. This is the process that transitions to FIG. 14 (step S2100).

[0065] 14, the notification management unit E16100 transfers the software unit N15XX to the initial software unit management unit E15000 and extracts a list of software units with the same application name UX100 in the target system V1000 (step S2101). This is because there is a possibility that multiple systems are executing the software unit in the target system V1000. The notification management unit E16100 then further narrows the list by filtering the version UX200 in the list to be lower than the version UX200 of the software unit N15XX (step S2102).

[0066] It is possible that the OTA center C1000 or the notification N1000 does not want to convert the data of the user application, which is why it is checked whether the conversion attempt unit UX500 is enabled (step S2103). If the conversion attempt unit UX500 is not enabled, the user application data conversion is skipped ("No" in step S2103). If enabled, the list is checked (step S2104) and it is checked whether the list is invalid (step S2105). If the list is invalid, no user application data conversion is realized. If the list is not invalid, the application data version UX400 of each software unit is checked against the application data version UX400 of the software unit N15XX (step S2106).

[0067] If no change is found in the application data version UX400, no user application data conversion is performed, and the next software unit in the list is checked (step S2109). If a mismatch in the application data version UX400 is found, a check is made for an entry in the application data conversion management table XYZ310 that maps the application name UX100, version UX200, and application data version UX400 of software unit N15XX and the application name UX100, version UX200, and application data version UX400 of software unit S1 to the application name XYZ311, version XYZ312, application data version XYZ313, conversion destination application name XYZ314, conversion destination application version XYZ315, and conversion destination data version XYZ316 (step S2107). If an entry exists, the flow proceeds to FIG. 15 (step S2108). If an entry does not exist, the operation flow proceeds to FIG. 18 (step S2110). The flows in FIGS. 15 and 18 are flows for executing the same processes as in the first embodiment.

[0068] In this embodiment, if the user application data conversion fails, the process proceeds to step S3004 of FIG. 19. If the answer is "Yes" at this step, a series of options are presented on screen I1300 (see FIG. 7) (step S3005). The affected software units are displayed in indicator I1310. Options at I1320 include, but are not limited to, accepting that the update will be performed and all data will be lost, or stopping the update. If the user accepts that the user application data will be lost, the conversion attempt section UX500 of notification N1000 is set to invalid, and the modified notification N1000 is returned via link 21 (step S3007) to step S2300 of FIG. 13 for authentication. In this step, the authentication information N1200 is verified again to continue processing the notification. If the update is aborted, the notification management unit E16100 is notified of the result of the attempt, and the system continues processing as it did before notification N1000 was notified. If an update is absolutely necessary regardless of the data conversion of the user application, it is possible to include an option to disable a specific software unit as in the first embodiment.

[0069] [Example 3] Next, a software update system according to a third embodiment of the present invention will be described. In the third embodiment, the notification type N1100 of the notification N1000 is a replacement ("Yes" in step S2700 of FIG. 13). The process flow follows FIG. 20, as with rollback. This embodiment differs from the previous embodiment in that, in step S2108 of FIG. 14, the conversion destination application name XYZ314 searched for in the application data conversion management table XYZ310 is different from the application name XYZ311. The existence of this entry enables seamless application provider changes while at the same time centering user application data and informing the user whether their information will be continuously used. The other process flows of this embodiment are similar to those of the first embodiment, provided they do not deviate from those of the first embodiment.

[0070] In this embodiment, if the user application data conversion fails, the replacement failure proceeds to step S3011 of Figure 19. If the answer is "Yes" at this step, a series of options are presented on screen I1400 (see Figure 8) (step S3012).

[0071] Referring to FIG. 8, the affected software units are displayed on screen I1410. Choices I1420 include, but are not limited to, accepting that the replacement will be made and that all data will be lost, or stopping the replacement. If the user accepts that the user application data will be lost, the conversion attempt section UX500 of notification N1000 is set to invalid, and the modified notification N1000 is returned via link 21 (step S3007) to step S2300 of FIG. 13, where the authentication information N1200 is verified again to continue processing the notification. If the replacement is stopped, the notification management unit E16100 is notified of the result of the attempt, and the system continues processing as it did before notification N1000 was notified.

[0072] According to the embodiment of the present invention described above, the following advantageous effects are achieved. (1) The software update device of the present invention comprises a memory unit that stores a conversion function for converting the data format of data including user data of an application when changing the data version of the application, a conversion function acquisition unit that acquires a conversion function that conforms to the requirements of the application change, and a data conversion unit that converts the data format of the application to a desired data format using the received conversion function, and the data conversion unit changes the processing of the user data of the application depending on whether or not the conversion function is available when the application is changed.

[0073] The above configuration makes it possible to maintain user application data when changing a software unit of a target system to another unit, or at least to recognize that data may be lost after changing the software unit.

[0074] (2) The system further includes a rollback management unit that rolls back the application's data version after applying changes to the application, and the data conversion unit converts the application's data format into a desired data format during rollback, thereby preventing data from being deleted during rollback.

[0075] (3) The data conversion unit converts the data format of the user data using the conversion function when the conversion function is available, and when the conversion function is not available, disables the application and stops the rollback without converting the data format of the user data, or deletes the user data and executes the rollback based on the user's permission. This makes it possible to change the way data is handled depending on whether the conversion function is available, and is expected to enable flexible responses.

[0076] (4) In addition, a software update device according to another embodiment of the present invention includes a memory unit that stores a conversion function for converting the data format of an application when changing the data version of the application, and a data conversion unit that acquires a conversion function that conforms to the requirements of the application change, and the data conversion unit determines whether or not to send the conversion function to an electronic device on which the application is installed depending on whether or not the conversion function for converting the data format to a desired data format is available.

[0077] As with (1), the above configuration makes it possible to maintain user application data when changing a software unit of a target system to another unit, or at least to recognize that data may be lost after changing the software unit.

[0078] (5) The present invention further includes a notification unit that outputs information about the loss of user data of the application when the conversion function is not present, thereby allowing the user to select the subsequent process.

[0079] (6) The present invention further includes a disabling unit that disables an application without changing the application when the conversion function is not present. This makes it possible to reliably disable applications that should be disabled.

[0080] (7) The invalidation unit determines whether to disable an application based on the user's selection, regardless of whether the application has a conversion function. This allows the user to select whether to disable an application, making it possible to, for example, save an application that may be updated later without disabling it.

[0081] (8) The storage unit stores previously used conversion functions received from a server that distributes application update data, and the data conversion unit has an updatable table that indicates the conversion functions required for application changes. This makes it possible to easily and quickly implement the above-mentioned functions.

[0082] (9) When the data conversion unit cannot acquire the conversion function, it requests the server to send the conversion function. This prevents the application from forgetting to convert data due to not receiving the conversion function.

[0083] (10) Yet another embodiment of the present invention provides a software update system comprising a server and at least one in-vehicle device, wherein the server distributes to the in-vehicle device an update package including a conversion function for converting the data format of data including user data of the application when changing the data version of the application installed in the in-vehicle device, and the at least one in-vehicle device comprises: a memory unit for storing the conversion function received from the server; a conversion function acquisition unit for acquiring a conversion function that conforms to the request for the application change; a data conversion unit for acquiring the conversion function from the data conversion unit and converting the data format to a desired data format; and a rollback management unit for rolling back the data version of the application after applying the change to the application, wherein the data conversion unit converts the data format, including the user data of the application, to the desired data format during rollback, and changes the processing of the user data depending on whether or not the conversion function is available when changing the application.

[0084] As with (1), the above configuration makes it possible to maintain user application data when changing a software unit of a target system to another unit, or at least to recognize that data may be lost after changing the software unit.

[0085] 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 embodiments including all of the described configurations. Furthermore, it is possible to replace 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 part of the configuration of each embodiment, or to add or replace other configurations. [Explanation of symbols]

[0086] C1000 OTA center (software management system), C1200 software unit storage unit (memory unit), C1500 notification unit (notification unit), E16000 rollback management unit (rollback management unit), EX000 ECU (on-board device), UX500 conversion trial unit (conversion function acquisition unit), UX600 invalidation unit, UX700 data conversion unit, UX740 conversion function (conversion function)

Claims

1. a storage unit that stores a conversion function for converting a data format of data including user data of an application when changing the data version of the application; a conversion function acquisition unit that acquires the conversion function that conforms to the change request of the application; a data conversion unit that converts the data format of the application into a desired data format using the received conversion function, the data conversion unit changes the processing of the application on the user data depending on whether or not the conversion function is present when the application is changed. A software update device comprising:

2. 2. The software update device according to claim 1, a rollback manager that rolls back a data version of the application after applying the changes to the application; the data conversion unit converts the data format of the application into the desired data format during the rollback. A software update device comprising:

3. 3. The software update device according to claim 2, the data conversion unit, when the conversion function exists, converts the data format of the user data by the conversion function, and, when the conversion function does not exist, disables the application and stops the rollback without converting the data format of the user data, or deletes the user data and executes the rollback based on the user's permission. A software update device comprising:

4. a storage unit that stores a conversion function for converting a data format of an application when changing the data version of the application; a data conversion unit that obtains the conversion function that conforms to the change request of the application, the data conversion unit determines whether or not to transmit the conversion function to the electronic device in which the application is installed, depending on whether or not the conversion function for converting the data format into a desired data format is present. A software update device comprising:

5. 5. The software update device according to claim 4, a notification unit that outputs information about a loss of user data of the application when the conversion function is not present; A software update device comprising:

6. 5. The software update device according to claim 4, further comprising a disabling unit that disables the application without changing the application when the conversion function is not present; A software update device comprising:

7. 7. The software update device according to claim 6, the disabling unit determines whether or not to disable the application based on a user selection, regardless of whether or not the application has the conversion function. A software update device comprising:

8. 5. The software update device according to claim 4, the storage unit holds a conversion function that has been used in the past and that is received from a server that distributes update data for the application; the data conversion unit has an updatable table indicating conversion functions required for the change of the application; A software update device comprising:

9. 9. The software update device according to claim 8, When the data conversion unit cannot acquire the conversion function, the data conversion unit requests the server to transmit the conversion function. A software update device comprising:

10. A software update system comprising a server and at least one in-vehicle device, the server distributes to the in-vehicle device an update package including a conversion function for converting a data format of data including user data of the application when changing a data version of the application installed in the in-vehicle device; The at least one in-vehicle device a storage unit that stores the conversion function received from the server; a conversion function acquisition unit that acquires the conversion function that conforms to the change request of the application; a data conversion unit that acquires the conversion function from the conversion function acquisition unit and converts the data format into a desired data format; a rollback manager that rolls back a data version of the application after applying the changes to the application; the data conversion unit converts the data format including the user data of the application into the desired data format during the rollback, and changes the processing of the user data depending on whether the conversion function is present or not when the application is changed. A software update system comprising:

Images