Software update system

Abstract

In a software update system according to the present invention, software includes base software and service software. The base software includes a service software dependency identification unit that identifies a service software dependency for each interface. The system includes: a base software update influence identification unit that identifies an influence on the service software due to update of the base software; and a base software update control unit that controls update of the base software on the basis of the influence on the service software. The base software update influence identification unit identifies an influence on the service software due to update of the base software for each interface on the basis of the service software dependency.

Description

Software Update System

[0001] The present invention relates to a technique for minimizing business disruptions in a decentralized, distributed software management system where each software management system is interdependent but does not share a unified dependency model. The system to which the present invention is applied manages API-based dependencies on other software management systems. When a fix is ​​applied to an area to which the present invention is applied, an API-based impact analysis is performed to enable detection of the specific software management systems that are affected. This enables notification of software in affected independent management domains, minimizing overall notifications and reducing the frequency of business disruptions that may exist for software in the independent management domains.

[0002] Vehicle software is primarily developed in a decentralized fashion. This allows manufacturers to define interfaces and limit the scope of software development to specific electronic control units, allowing them to delegate software development to suppliers or departments as needed. Next-generation vehicle software architectures are changing to address the increasing complexity of software development and the introduction of hardware that is increasingly integrated through electrical / electronic architectures. This will centralize software development around one common software set. While there are many software layers where integration can occur, the need for specialized services with functional safety and security requirements is driving an increasing effort to integrate software development at the runtime level.

[0003] An example of this integration is the development of Adaptive AUTOSAR and AUTOWARE. The complexity of the required services and the shift to agile software development, which requires services to be updated frequently to meet customer needs, necessitates a decentralized, distributed software management system for each service that allows systems to be updated freely without disrupting the systems of services in other managed domains. Of particular importance is the ability to update software that allows the functionality of the entire vehicle, including Adaptive AUTOSAR and AUTOWARE, with minimal disruption to services.

[0004] Much work has already been done to incorporate SOTA (Software Over the Air) update capabilities into systems like Adaptive AUTOSAR and AUTOWARE. However, decentralized, distributed software management is still not fully feasible. Software management schemes are derived from state-of-the-art server systems, where the server centrally manages all software and typically one main user manages all applications, resulting in little security and less functional safety. Therefore, the need for a decentralized, distributed software management system still exists.

[0005] JP 2022-100301 A JP 2021-082113 A JP 2018-045508 A

[0006] What is needed is a software update device that allows for updating a system while minimizing notifications sent to service software within the system.

[0007] In order to solve the above problem, the software update system of the present invention is a software update system that updates software installed in a vehicle, the software including base software managed according to a first software management system and consisting of one or more software modules and a plurality of interfaces associated with the one or more software modules, and service software managed according to a second software management system and operating using one of the plurality of interfaces, the base software having a service software dependency identification unit that identifies service software dependencies, which are dependencies between the service software and the base software, for each interface, the system having a base software update impact identification unit that identifies the impact of updating the base software on the service software, and a base software update control unit that controls the update of the base software based on the impact on the service software, and the base software update impact identification unit identifies the impact of updating the base software on the service software for each interface based on the service software dependencies.

[0008] According to the present invention, it is possible to update a system while minimizing notifications sent to service software within the system. Further features related to the present invention will become apparent from the description of this specification and the accompanying drawings. In addition, problems, configurations, and advantages other than those described above will become apparent from the following description of the embodiments.

[0009] 1 is a block diagram illustrating the main components according to an embodiment of the present invention. FIG. 1 is a block diagram illustrating the configuration of a human-machine interface system V1200. FIG. 2 is a block diagram illustrating the main components of a vehicle system V1100. FIG. 3 is a block diagram illustrating links between available APIs of service software and base software B1000. FIG. 4 is a block diagram illustrating the configuration of a service software dependency identification unit B1300 according to the present invention and sample information of a service software dependency table B1310. FIG. 5 is a block diagram illustrating the configuration of a software update system E1000. FIG. 6 is a block diagram illustrating the configuration of a base software dependency identification unit E1410 with APIs of base software dependency identification information E1411. FIG. 7 is a block diagram illustrating the configuration of an OTA center C1000. FIG. 8 is a block diagram illustrating the configuration of system software information C13X200. FIG. 9 is a block diagram illustrating the configuration of an OTA center C2000. FIG. 10 is a block diagram illustrating the configuration of a software package U1000. FIG. 11 is a block diagram illustrating the configuration of a software package U2000. FIG. 12 is a block diagram illustrating the configuration of a notification N1000. FIG. 13 is a flowchart illustrating a process performed in accordance with the present invention. 1 is a flow chart illustrating a process performed in accordance with the present invention. 2 is a flow chart illustrating a process performed in accordance with the present invention.

[0010] Example 1 Both the OTA Center C1000 and the Vehicle System V1100 Have a Service Software Dependency Identification Unit B1300 Figure 1 is an overall schematic diagram showing the main components of the present invention, including a target system V1000 with a human-machine interface system V1200 and a vehicle system V1100, an OTA Center C1000 for base software B1000, and an OTA Center C200X for an Independently Managed Domain (IMD) I2X00 or a User Managed Domain I3X00 (see Figure 3).

[0011] FIG. 2 is a block diagram showing the configuration of the human-machine interface system V1200. In this embodiment, the human-machine interface system V1200 enables input and output of information between the user U3000 and the target system V1000. As shown in FIG. 3, the human-machine interface system V1200 includes an electronic control unit (ECU) V1210 including a power supply, a central processing unit (CPU), etc.; a human-machine input / output unit V1220 including a display capable of inputting and outputting information; and human-machine interface software V1230 for executing functions, which is stored, for example, in a read-only memory (ROM). In many vehicles, this is also called an infotainment system. In this embodiment, this system is used to notify the user U3000 or obtain user approval for an action. Note that this embodiment does not limit the configuration of the human-machine interface system in any form or manner.

[0012] 3 is a block diagram showing the configuration of the vehicle system V1100. As shown in FIG. 3, the vehicle system V1100 has one or more vehicle electronic control units V111000, which are a set of electronic control units (ECUs) V11100X that store and process vehicle information. There are no limitations on the configuration of the vehicle electronic control units V111000 in this embodiment. The vehicle electronic control units V111000 execute base software B1000. The base software B1000 is a software component that enables rapid development and execution of vehicle software services.

[0013] The base software B1000 can be composed of any number of binaries, libraries, or applications. There are no limitations on how the base software B1000 can be implemented. The base software B1000 is composed of at least one set of application programming interfaces (APIs B1100) that enable communication between the service software I204X / I304X and the base software B1000 and enable the state and operation of the vehicle system V1100 to be changed. The base software B1000 has an API usage tracker B1200 and a service software dependency identification unit B1300. The API usage tracker B1200 is a system that can determine which APIs are being used by the service software being executed. The service software dependency identification unit B1300 is a unit that identifies service software dependencies, which are dependencies between the service software and the base software, for each API.

[0014] 4 is a block diagram representing the connections between the service software and each API included in the API B1100. There are no limitations on how the API usage tracker B1200 obtains the information; the tracker only needs to be able to distinguish which APIs are being used. If the API usage tracker B1200 has more functions, or if there is more information shared between the IMD and the base software B1000, more information can be stored in the service software dependency identification unit B1300 and its service software dependency table B1310 (details are shown in FIG. 5).

[0015] 5, the minimum information that the service software dependency identification unit B1300 should have is listed in a service software dependency table B1310. Specifically, the minimum information includes a service name B1311 that can distinguish services, a service software update control unit name B1312 that determines the system that will ultimately change the service, an API label B1313 that indicates the connection between the service and the API being used, and an API characteristic B1314 that the service desires.

[0016] Fig. 6 is a block diagram showing the configuration of a software update system E1000. The software update system E1000 is responsible for updating the base software B1000. As shown in Fig. 6, the software update system E1000 is composed of an OTA client E1100 connected to the OTA center C1000, a base software update control unit E1200 responsible for issuing update instructions for the base software B1000, a base software control unit E1300 responsible for monitoring, starting, and stopping the base software B1000, a base software update impact identification unit E1400, and a notification unit E1500 that reports the status and results of updates to the OTA center C1000 for the base software B1000.

[0017] The base software update impact identification unit E1400 includes a base software dependency identification unit E1410, which contains dependency information of software modules and APIs. Figure 7 is a block diagram showing the details of the base software dependency identification unit E1410. The base software dependency identification information E1411 stored in the base software dependency identification unit E1410 can be obtained in any manner and with any granularity. The main idea in this embodiment is to track software updates that enable APIs, which are interfaces between services and underlying systems, using structures and labels assigned to the update data and to analyze the impact of the updates.

[0018] Returning to the description of FIG. 3 , the independent management domain I2X00 is a software area of ​​the vehicle system V1100 that is independently managed by an administrator different from the administrator managing the base software B1000. There can be one or more independent management domains I2X00. Their configuration is similar to the software update system E1000, and they include an OTA client I2X10, a service software update control unit I2X20, and a service software control unit I2X30. They have similar functionality to the software update system E1000, but their scope is limited. The service software I204X is transmitted to the IMD and executed within it, and information about the software package U2000 for update is shared with the OTA center C200X. These IMDs are expected to be used by mobility service providers to implement services such as valet parking, robot taxis, and robot delivery services, among others. This type of system requires integration with the base software B1000, but due to the complexity involved, it is actually implemented by separate providers. In addition, the service software update control unit I2X20 obtains operation guarantee service software information regarding service software I204X whose operation is guaranteed in the management system of the independent management domain I2X00, and generates a service software dependency table B1310 based on the operation guarantee service software information.

[0019] Once the vehicle begins to function like a home computer, it is expected that user U3000 will want to install, develop, or modify some parts of the vehicle. These areas are considered software domains, shown in this example as user-managed domain I3X00 in Figure 3, with user U3000 being the ultimate arbiter of changes. While these types of software domains may restrict access to some APIs, this example does not restrict how this is implemented.

[0020] 8 is a block diagram showing the details of the OTA center C1000. The OTA center C1000 comprises a notification unit C1100, where software change information is shared, a software package distribution unit C1200, where software packages U1000 are processed and sent to target systems to modify base software B1000, a base software update impact identification unit E1400, which provides the same functionality as components of the same name in the software update system E1000, and a target system management unit C130000, which maintains information shared between the target system V1000 and the OTA center C1000. This shared information includes system IDs, as well as installation and performance information.

[0021] The system software information C13X200 of the OTA center C1000, shown in detail in FIG. 9, includes a service software dependency table B1310 with the same functions as the components described in the base software B1000. In the case of the OTA center C1000, this system may not have full access to the target system, so the information in the service software dependency table B1310 is shared between the target system V1000 and the OTA center C1000 via notification N1000 according to this embodiment. In this embodiment, the OTA center C1000 can implement multiple methods for organizing the software package U1000. Note that this embodiment does not in any way limit the configurability of the software dependency management system for the software package U1000.

[0022] FIG. 10 is a block diagram illustrating details of the OTA center C2000. The OTA center C2000 is similar to the OTA center C1000 in that the system is utilized to modify software on vehicles. The scope of the OTA center C2000 includes updating software services on IMDs or user management domains using software packages U2000 (see FIG. 12). The OTA center C2000 of this example can implement multiple methods for organizing the software packages U2000 and utilizing separate dependency management systems. The present invention does not limit the configurability of the software dependency management of the software packages U2000 to any of multiple OTA centers C2000 utilized by the target system V1000.

[0023] A software update to the base software B1000 is performed via a software package U1000 through communication between the vehicle system V1100 and the OTA center C1000. The software package U1000 is shown in detail in FIG. 11 . The software package U1000 includes components commonly used in software management systems, such as a base software module label U1400, a software name U1000, a version U1200, and binary data U1300, which is the actual data to be updated. The service software dependency B1310 is composed of an interface identifier and base software version used by service software whose operation is guaranteed in the software management system of the independent management domain I2X00. The base software update control unit E1200 detects base software update incompatibility by comparing the software module versions of the software modules identified by the base software update impact identification unit E1400 between the base software corresponding to the base software version included in the service software dependency table B1310 and the base software installed in the vehicle.

[0024] Notification between the vehicle system V1100 and the OTA center C1000 is realized by a notification N1000 message, which is shown in detail in Fig. 13, and information related to the service software dependency table B1310 is shared between the two. The notification N1000 message is also one way for the OTA center C1000 and the OTA center C2000 to share impact information related to the important base software B1000.

[0025] The OTA center C2000, shown in detail in Fig. 10, is an independent software management system that manages an independent management domain I2X00 or a user management domain I3X00 in which service software runs. The OTA center C2000 communicates with the independent management domain I2X00 using a software package U2000 that conforms to the most commonly used software management system. There is no limit to the type of software management system that can be used in this embodiment.

[0026] 14 is a flowchart illustrating a process executed by the OTA center C1000 in the first embodiment. First, the OTA center C1000 prepares a software package U1000 for transmission to the target system V1000 (S1000). The software package U1000 includes a label U1400 created after analyzing the updated software components from the perspective of APIs. Next, within the OTA center C1000, the target system management unit C130000 uses the target system C131000 to select the target system C13X000 to be updated (S1001). Next, it is determined whether the OTA center C1000 has a service software dependency table B1310 (S1002).

[0027] If it is determined in step S1002 that the OTA center C1000 has table B1310, the process proceeds to the flowchart of FIG. 15. To analyze the impact of the base software on the target system of the software package U1000, the base software module label U1400 included in the software package U1000 is extracted (S2000). At the same time, the API label B1313 is extracted (S2001). The extracted data is sent to the base software update impact identification unit E1400 (S2002). The base software module label U1400 includes labels of changed software components that make up specific APIs. Examples of the types of information included in these labels and their comparison targets are shown in FIG. 7.

[0028] The API label B1313 shown in Figure 7 can directly notify affected APIs or notify software components such as software (SW) module-01. For SW module-01, the data in Figure 7 indicates that changes to this software component will affect both API-01 and API-02, and service software that uses these APIs will need to be verified. However, if SW module-02 is changed, only API-01 will be affected.

[0029] Similarly, in FIG. 7 , the software module API-03 is not connected to other APIs. This means that changing this API will not affect other APIs in the system. In this embodiment, characteristics can also be assigned to APIs. In FIG. 7 , the response time of API-02 is shown to be 50 milliseconds, and the data size is 5 MB. Because changes in these characteristics may cause unexpected problems, this information may be very important to services that use this API. Changes in these characteristics can also be notified by the base software module label U1400. In other words, the base software update impact identification unit E1400 obtains interface characteristic element information, which is information about the response characteristics of APIs when the base software is updated, from the base software management system, and identifies the impact of the base software update on the service software based on the service software response characteristic information and the interface characteristic element information.

[0030] This process of verifying these labels against the information extracted from the service software dependency table B1310 of the target system is realized in S2003 (API / SW module) and S2004 (API characteristics) in Figure 15. After analyzing the base software dependency identification information E1411, if it is found that any one of the labels is linked to the service software dependency table B1310, the analysis is determined to have an impact (S2006); if none is found, OK is returned indicating no impact (S2005). That is, the base software update impact identification unit E1400 identifies the impact of the base software update on the service software for each API based on the service software dependency / base software dependency.

[0031] After the processing of Fig. 15, the process proceeds to S1003 of Fig. 14. If no impact is found in the processing of Fig. 15 ("Yes" in S1003), the OTA center C1000 can confirm that known service software running on the target system is not affected and send the software package U1000 to the selected target system V1000 (C13X000) (S1004).

[0032] After S1004, the flow proceeds to FIG. 17. The software package U1000 sent to the vehicle system V1100 is retrieved by the OTA client E1100 of the vehicle system V1100 (S4000). The process shown in FIG. 15 is then executed again. Note that this is a means of providing up-to-date information regarding API usage in the IMD and user management domains. If no impacts are found ("Yes" in S4001), the software package U1000 is prepared for installation by the base software update control unit E1200 (S4002). The safety status of the target system V1000 is then verified by the base software control unit E1300 (S4003). The base software dependency identification information E1411 is also updated with information contained in the base software module label U1400 for future use (S4004). Finally, an attempt to apply the software package U1000 to the target system returns a positive notification N1000 (S4005).

[0033] The above describes the process when no impact is found. However, if an impact is found, i.e., if S1003 in FIG. 14 or S4001 in FIG. 17 returns "No," the process proceeds to the flow in FIG. 16. In the flow in FIG. 16, a matching API label B1313 is extracted by checking the service software dependency table B1310 and the base software module label U1400 from the software package U1000 (S3000). In the service software dependency table B1310, the API label is linked to a service software update control unit that manages the service software and its update function. If an impact is found, this information can be notified to the service software update control unit to provide additional information about the problem affecting the update.

[0034] If the OTA center C1000 does not detect the impact (S3001: No), it can obtain the user U3000's consent and attempt to contact the IMD and user domain to approve the update from each component (S3004). If consent is obtained (S3004: Yes), the service software and the service software update control unit become accessible, and the affected software services can be notified of the change (S3005). If consent is not obtained from the user U3000 (S3004: No), the process proceeds to S7001 in FIG. 18 and a rejection notice is generated. Here, the service software update control unit can choose to approve the change, taking into account information about which APIs are affected (S3006). However, in the case of the user management domain I3X00, approval must be provided by the user U3000 via the human-machine interface system V1200 (S3007). If this approval is also obtained ("Yes" in S3007), the flow can proceed to S4003 and subsequent steps in FIG.

[0035] If approval for the API change is not obtained (No in S3006 or S3007), the vehicle has the option to prioritize an update of the base software B1000 based on the software package U1000 (S7000 in FIG. 18). If the base software B1000 is not prioritized (No in S7000), the service software dependency table B1310 entry for which the update was rejected is attached to a notification N1000 with a type N1100 of Postponed (S7001) and sent to the OTA center C1000 for further evaluation (S7002).

[0036] If the software package U1000-based update of the base software B1000 takes priority ("Yes" in S7000), the service software update control unit I3X20 of each service software affected by the update of the software package U1000 is contacted to disable the affected service software (S7003). Furthermore, access to the API B1100 from the service software is revoked (S7004), and a notification N1000 including an updated service software dependency table B1310 is sent to the OTA center C1000 to support future changes (S7005). Finally, the base software B1000 can be forcibly updated by executing the processes from step S4003 onward in FIG. 17 .

[0037] Returning to the processing of FIG. 16 , if an impact is detected by the OTA center C1000 ("Yes" in S3001), in the service software dependency table B1310, the API label is linked to the service software update control unit I2X20, which manages the service software and the update function of the service software. If an impact is detected, this information can be notified to the service software update control unit I2X20 to provide additional information about the problem affecting the update (S3002). This additional information can be used to specifically verify the exact API change or property change, giving the developer an opportunity to minimize interruptions to the entire service.

[0038] The use of notifications N1000 of type N1100 affected is just one way of sharing information and may vary depending on what additional information the IMD administrator and the administrator of the base software B1000 want to share. The selection of contacting affected service software administrators is shown as an option within the flowchart, which requires linking contact information to the service software dependency table B1310. There is no limit to the expansion of information that can be included in this table or how this information can be securely shared with the parties required by the present invention. Once it is determined what to share with the IMD, the OTA center C1000 returns a denial to an attempt to apply the changes in software package U1000 on the target system without transmitting the software package U1000 (S3003).

[0039] When service software is changed within the IMD or user management domain, these systems can utilize any software management system to verify that the service software can run correctly on the base software B1000. An overview of the process for obtaining information about a certain service software IX04Y to install in the service software dependency table B1310 is shown in Figure 19.

[0040] In steps S5001 to S5005, a software domain, whether independently managed or user-managed, acquires a software package U2000 and decides to modify it. The work of this embodiment begins after S5005, when the newly modified service software is linked to the API B1100 (S5006). After this, the API usage tracker B1200 begins tracking new accesses to the API (S5007). Because this embodiment targets a distributed software management system, if there is no information that is not to be shared, it is necessary to determine how much information is shared between the base software B1000 and the software domains running on it (S5008). If there is no information to be shared ("No" in S5008), the API usage tracker B1200 can always include the API. As part of this information, the service software that accessed the API B1100 can be found within the base software B1000 and introduced into the service software dependency table B1310 (S5011).

[0041] If the service software dependency table B1310 can be shared with the OTA center C1000 of the base software B1000 ("Yes" in S5008), information can be shared using a notification N1000 with a type N1100 of update, and the changes can be reflected in the OTA center C1000. If more information can be shared between the base software B1000 and the software domains running on it, this information, such as the service software update control unit name B1312 and the desired API characteristics B1314, can be added to the service software dependency table B1310 (S5009). Again, if that information can be shared with the OTA center C1000 of the base software B1000, this is also done (step S5010).

[0042] [Example 2] [Only the vehicle system V1100 has the service software dependency identification unit B1300] In Example 1, it was assumed that both the vehicle system V1100 and the OTA center C1000 have the service software dependency identification unit B1300. However, in Example 2, only the vehicle system V1100 has the service software dependency identification unit B1300.

[0043] Therefore, in this embodiment, the system software information C13X200 of the target system C13X000 of the OTA center C1000 does not have the service software dependency relationship table B1310, so steps S1002 and S1003 in Fig. 14, which determine this, are not executed and are skipped. The other processing is the same as in the first embodiment.

[0044] The above-described embodiment of the present invention provides the following advantageous effects.

[0045] (1) The software update system of the present invention is a software update system that updates software installed in a vehicle, the software including: base software managed according to a first software management system and consisting of one or more software modules and a plurality of interfaces associated with the one or more software modules; and service software managed according to a second software management system and operating using one of the plurality of interfaces; the base software has a service software dependency identification unit that identifies, for each interface, a service software dependency, which is a dependency relationship between the service software and the base software; the system has a base software update impact identification unit that identifies the impact on the service software of an update of the base software, and a base software update control unit that controls the update of the base software based on the impact on the service software; and the base software update impact identification unit identifies, for each interface, the impact on the service software of an update of the base software based on the service software dependency.

[0046] The above configuration allows the system to be updated while minimizing notifications sent to service software that depends on the system.

[0047] (2) The system further includes a base software dependency identification unit that identifies base software dependency relationships, which are dependency relationships between interfaces and software modules within the base software, and the base software update impact identification unit identifies service software affected by an update of the base software for each interface based on the base software dependency relationships. This makes it possible to grasp the dependency relationships between the service software and the base software for each software module included in the base software, thereby enabling a more detailed analysis of the impact of base software updates on the service software.

[0048] (3) The interface of the base software has, as its specifications, the response characteristics of the base software when the interface is called, and the service software dependency identification unit acquires, from within the second software management system, service software response characteristic information, which is information about the response characteristics of each interface that has an impact on the service software, and the base software update impact identification unit acquires, from within the first software management system, interface characteristic element information, which is information about the response characteristics of the interface when the base software is updated, and identifies the impact of the base software update on the service software based on the service software response characteristic information and the interface characteristic element information. This makes it possible to analyze the impact of updating the base software from a more detailed perspective.

[0049] (4) The software includes a software module version assigned to the software module and a base software version assigned to the base software, and the service software dependency relationship is composed of an interface identifier and the base software version used by the service software whose operation is guaranteed in the second software management system, and the base software update control unit detects update incompatibility of the base software by comparing the software module version of the software module identified by the base software update impact identification unit in the base software corresponding to the base software version included in the service software dependency relationship with the base software installed in the vehicle. By comparing the software versions, it is possible to determine whether the base software should be updated based on the software having the latest version.

[0050] (5) When the base software update impact identification unit detects incompatibility of the base software, the base software update control unit checks with the system of the second software management system whether the update is possible, and if not, postpones the base software update. This makes it possible to prevent a software update determined to be incompatible from being executed and causing a malfunction in the operation of the vehicle.

[0051] (6) The second software management system includes a service software update control unit that controls updates of the service software, and the service software dependency identification unit acquires service software dependency relationships from the service software update control unit, and the service software update control unit acquires operation guarantee service software information related to service software whose operation is guaranteed in the second software management system from within the second software management system, and generates service software dependency relationships based on the operation guarantee service software information. This makes it possible to always keep the service software dependency relationships necessary to determine the impact on the service software up to date, thereby reducing misdiagnosis.

[0052] It should be noted that 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 that include 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.

[0053] B1000 Base software, B1100 API (interface), B1300 Service software dependency identification unit (service software dependency identification section), E1000 Software update system, E1200 Base software update control unit (base software update control section), E1400 Base software update impact identification unit (base software update impact identification section), E1410 Base software dependency identification unit (base software dependency identification section)

Claims

1. A software update system for updating software installed in a vehicle, wherein the software includes: base software managed according to a first software management system, the base software comprising one or more software modules and a plurality of interfaces associated with the one or more software modules; and service software managed according to a second software management system and operating using any of the plurality of interfaces. The base software includes a service software dependency identification unit that identifies, for each interface, a service software dependency that is a dependency relationship between the service software and the base software. The system includes: a base software update impact identification unit that identifies an impact on the service software due to an update of the base software; and a base software update control unit that controls the update of the base software based on the impact on the service software. The base software update impact identification unit identifies, for each interface, an impact on the service software due to an update of the base software based on the service software dependency. A software update system characterized by the above.

2. The software update system according to claim 1, further comprising a base software dependency identification unit that identifies a base software dependency that is a dependency relationship between the interface and the software module within the base software. The base software update impact identification unit identifies, for each interface, the service software that is affected by an update of the base software based on the base software dependency. A software update system characterized by the above.

3. The software update system according to claim 2, wherein the interface of the base software has, as a specification, the response characteristics of the base software when the interface is called, the service software dependency identification unit obtains, from within the second software management system, service software response characteristic information which is information regarding the response characteristics of each interface having an impact on the service software, the base software update impact identification unit obtains, from within the first software management system, interface characteristic element information which is information regarding the response characteristics of the interface when the base software is updated, and identifies the impact on the service software due to the update of the base software based on the service software response characteristic information and the interface characteristic element information. A software update system characterized by the above.

4. The software update system according to claim 2, wherein the software comprises a software module version assigned to the software module and a base software version assigned to the base software, the service software dependency is composed of an identifier of the interface used by the service software whose operation is guaranteed in the second software management system and the base software version, and the base software update control unit detects the non - compatibility of the base software update by comparing the software module version of the software module identified by the base software update impact identification unit between the base software corresponding to the base software version included in the service software dependency and the base software installed in the vehicle. A software update system characterized by the above.

5. The software update system according to claim 1, wherein when the base software update control unit detects the incompatibility of the base software by the base software update impact identification unit, it confirms whether to update the system of the second software management system, and if the update is not allowed, it defers the update of the base software. A software update system characterized by this.

6. The software update system according to claim 2, wherein the second software management system includes a service software update control unit that controls the update of the service software, the service software dependency identification unit obtains the service software dependency from the service software update control unit, and the service software update control unit obtains operation guarantee service software information regarding the service software whose operation is guaranteed in the second software management system from within the second software management system, and generates the service software dependency based on the operation guarantee service software information. A software update system characterized by this.

Images