Software update system

Abstract

To provide a software update device that enables updating of a system while minimizing notifications sent to service software that depends on the system.SOLUTION: 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 configured to identify a service software dependency for each interface. The system includes: a base software update influence identification unit configured to identify an influence on the service software due to update of the base software; and a base software update control unit configured to control update of the base software based on 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 based on the service software dependency.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a technique for minimizing business interruption 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 modification is applied to the area to which the present invention is applied, an API - based impact analysis is performed, enabling the detection of specific software management systems affected. This allows for the notification of software within the affected independent management domain, minimizing overall notifications and reducing the frequency of business interruptions that may exist in the software of the independent management domain.

Background Art

[0002] Vehicle software is mainly developed in a decentralized manner. As a result, manufacturers can delegate software development to suppliers or departments as needed by defining interfaces and limiting the scope of software development to specific electronic control units. The next - generation vehicle software architecture is changing to cope with the increasing complexity of software development and the introduction of hardware that is being integrated through the electrical / electronic architecture. As a result, software development is becoming centralized around a single common software set. Although there are many software layers that may be integrated, due to the need for special services with functional safety and security requirements, attempts to integrate software development at the runtime level are increasing.

[0003] Examples of this integration include the development of Adaptive AUTOSAR and AUTOWARE. Due to the complexity of the required services and the changes to agile software development, where services need to be frequently updated to meet customer needs, a decentralized distributed software management system that allows the system to be updated freely without interrupting the service systems within other managed domains is required for each service. Of particular importance is to update the software that enables the update of the vehicle's overall functions while minimizing service interruptions, that is, the parts including Adaptive AUTOSAR, AUTOWARE, etc.

[0004] Much work has already been done to incorporate the SOTA (Software Over The Air) update function into systems such as Adaptive AUTOSAR and AUTOWARE. However, it is still not fully possible to achieve decentralized distributed software management. The software management scheme is obtained from state-of-the-art server systems where the server centrally manages all software and usually one main user manages all applications, so security is hardly required and functional safety is not that necessary either. Therefore, the need for a decentralized distributed software management system still exists.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0006] There is a need for a software update device that enables system updates while minimizing notifications sent to service software within the system.

Means for Solving the Problems

[0007] In order to solve the above problems, a software update system according to the present invention is a software update system for updating software installed in a vehicle. The software includes base software managed according to a first software management system, the base software being composed 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 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 the impact on the service software due to the 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, the impact on the service software due to the update of the base software based on the service software dependency.

Effects of the Invention

[0008] According to the present invention, it becomes possible to update the system while minimizing notifications sent to service software within the system. Further features related to the present invention will become apparent from the description in this specification and the accompanying drawings. Also, problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Mode for Carrying Out the Invention

[0010] [Example 1] [Both the OTA center C1000 and the vehicle system V1100 have a service software dependency identification unit B1300] FIG. 1 is an overall schematic diagram showing the main components of the present invention, including a target system V1000 equipped 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 FIG. 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 is a system that enables input / 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 having a power supply, a CPU (Central Processing Unit), etc., a human machine input / output unit V1220 having a display capable of inputting / outputting information, etc., and a human machine interface software V1230 for executing functions recorded in, for example, a ROM (Read Only Memory). In many vehicles, this is also called an infotainment system. This system is used in this embodiment to notify the user U3000 or to obtain the user's approval for an action. Note that this embodiment does not limit the configuration of the human machine interface system in any form or method.

[0012] FIG. 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 a plurality of vehicle electronic control units V111000, which is a set of electronic control units (ECUs) V11100X that store and process vehicle information. There is no limitation on the configuration of the vehicle electronic control unit V111000 of this embodiment. In the vehicle electronic control unit V111000, the base software B1000 is executed. 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 is no restriction on the implementation method of the base software B1000. The base software B1000 is composed of at least one set of application programming interfaces (API B1100) that enable communication between the service software I204X / I304X and the base software B1000, so as to change the state and operation of the vehicle system V1100. 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 know which APIs are being used by the running service software. The service software dependency identification unit B1300 is a unit that identifies the service software dependencies, which are the dependencies between the service software and the base software, for each API.

[0014] Figure 4 is a block diagram representing the connections between the service software and each API included in API B1100. There is no restriction on the method of obtaining information by the API usage tracker B1200, and it is sufficient for the tracker 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 sharing 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 Figure 5).

[0015] As shown in FIG. 5, the minimum information that the service software dependency identification unit B1300 should have is listed in the service software dependency table B1310. Specifically, it is the service name B1311 that can distinguish services, the service software update control unit name B1312 that determines the system that finally changes the service, the API label B1313 that indicates the connection between the service and the API being used, and the API characteristics B1314 desired by the service.

[0016] FIG. 6 is a block diagram showing the configuration of the 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 includes an OTA client E1100 connected to the OTA center C1000, a base software update control unit E1200 responsible for the update instruction of 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 the update 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 that contains dependency information on software modules and APIs. FIG. 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 method and granularity. The main idea in this embodiment is to track the update of the software that enables the API, which is the interface between the service and the underlying system, by the structure and label assigned to the update data, and analyze the impact of the update.

[0018] Return 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 who manages the base software B1000. There can be one or more independent management domains I2X00. Its configuration is similar to the software update system E1000 and includes an OTA client I2X10, a service software update control unit I2X20, and a service software control unit I2X30, and has the same functions as the software update system E1000, but its scope is limited. The service software I204X is sent to the IMD and executed within its scope, 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, especially to implement services such as valet parking, robot taxis, and robot delivery services. This type of system requires integration with the base software B1000 but is complex, so it is actually implemented by separate providers. Note that the service software update control unit I2X20 obtains operation guarantee service software information about the service software I204X whose operation is guaranteed within the management system of the independent management domain I2X00 from within 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] When the vehicle begins to function like a home computer, it is expected that the user U3000 will want to install, develop, or modify some parts of the vehicle. These areas are shown as the user management domain I3X00 in FIG. 3 in this embodiment and are regarded as software domains where the user U3000 is the final decision maker for changes. Although these types of software domains may restrict access to some APIs, this embodiment does not limit how this is implemented.

[0020] FIG. 8 is a block diagram showing details of the OTA center C1000. The OTA center C1000 includes a notification unit C1100 for sharing software change information, a software package distribution unit C1200 that processes the software package U1000 and sends it to the target system to change the base software B1000, a base software update impact identification unit E1400 that provides the same function as the component with the same name in the software update system E1000, and a target system management unit C130000 that maintains information shared between the target system V1000 and the OTA center C1000. This shared information includes a system ID, as well as installation and performance information.

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

[0022] FIG. 10 is a block diagram showing details of the OTA center C2000. The OTA center C2000 is similar to the OTA center C1000 in that the system is used to change the software on the vehicle. The application range of the OTA center C2000 includes updating software services on the IMD or user management domain using the software package U2000 (see FIG. 12). The OTA center C2000 of this embodiment can execute a plurality of methods for compiling the software package U2000 and using a separate dependency management system. The present invention does not limit the configurability of software dependency management of the software package U2000 for any of the plurality of OTA centers C2000 used by the target system V1000.

[0023] The software update to the base software B1000 is performed via the software package U1000 in the communication between the vehicle system V1100 and the OTA center C1000. The details of the software package U1000 are shown in FIG. 11. The software package U1000 includes a base software module label U1400 and components commonly used in software management systems such as a software name U1000, a version U1200, and binary data U1300 which is the actual data to be updated. Note that the service software dependency B1310 is composed of an identifier of an interface used by service software whose operation is guaranteed in the software management system of the independent management domain I2X00 and the base software version. The base software update control unit E1200 compares the software module versions of the software modules identified by the base software update impact identification unit E1400 in 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, thereby detecting the inapplicability of the base software update.

[0024] The notification between the vehicle system V1100 and the OTA center C1000 is realized by the message of the notification N1000 shown in detail in FIG. 13, and shares information about the service software dependency table B1310 between the two. The message by the notification N1000 is also a way to share impact information about the important base software B1000 between the OTA center C1000 and the OTA center C2000.

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

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

[0027] When it is determined in step S1002 that the OTA center C1000 has the table B1310, the process proceeds to the flowchart of FIG. 15. To analyze the impact of the base software of the software package U1000 on the target system, 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 the changed software components that make up a specific API. The types of information included in these labels and examples of their comparison targets are shown in FIG. 7.

[0028] The API label B1313 shown in FIG. 7 can directly notify the affected APIs or notify software components such as the software (SW) module - 01. In the case of the SW module - 01, the data in FIG. 7 indicates that changing this software component affects both API - 01 and API - 02, and it is necessary to verify the service software that uses these APIs. However, when the SW module - 02 is changed, only API - 01 is affected.

[0029] Similarly, in Figure 7, the software module of API-03 is not connected to other APIs. This means that changing this API will not affect other APIs within the system. In this embodiment, it is also possible to assign characteristics to the API. In Figure 7, it is shown that the response time of API-02 is 50 milliseconds and the data size is 5MB. Since changing these characteristics may cause unexpected problems, this information can be very important for the services that utilize this API. Changes to these characteristics can also be notified with 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 regarding the response characteristics of the API when the base software is updated, from within the management system of the base software, 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.

[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), and if nothing is found, OK is returned as having no impact (S2005). That is, the base software update impact identification unit E1400 identifies the impact on the service software due to the update of the base software for each API based on the service software dependency / base software dependency.

[0031] After the process of FIG. 15, the flow proceeds to S1003 of FIG. 14. If no impact is found in the process of FIG. 15 (Yes in S1003), the OTA center C1000 can confirm that the 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 the flow of FIG. 17. The software package U1000 sent to the vehicle system V1100 is acquired by the OTA client E1100 of the vehicle system V1100 (S4000). Then, the process shown in FIG. 15 is executed again. It should be noted that this is a means equipped with the latest information regarding the use of APIs in the IMD and user management domains. If no impact is found (Yes in S4001), the software package U1000 is prepared for installation by the base software update control unit E1200 (S4002). Then, the safety state of the target system V1000 is verified by the base software control unit E1300 (S4003). Also, the base software dependency identification information E1411 is updated with the information included in the base software module label U1400 for future use (S4004). Finally, when attempting to apply the software package U1000 to the target system, an affirmative notification N1000 is returned (S4005).

[0033] In the above, the process when no impact was found first was explained. However, when an impact is found, that is, when it is "No" in S1003 of FIG. 14 or S4001 of FIG. 17, the process migrates to the flow of FIG. 16. In the flow of FIG. 16, first, the matching API label B1313 is extracted from the check of the service software dependency relationship table B1310 and the base software module label U1400 from the software package U1000 (S3000). In the service software dependency relationship table B1310, the API label is linked to the service software and the service software update control unit that manages the update function of the service software. When an impact is found, this information can be notified to the service software update control unit to provide additional information regarding the problem affecting the update.

[0034] When the above-described impact detection is not performed by the OTA center C1000 ( "No" in S3001), it is possible to attempt to contact the IMD and the user domain after obtaining the consent of the user U3000 and attempt to obtain approval for the update from each component (S3004). When consent is obtained ( "Yes" in S3004), it becomes possible to access the service software and the service software update control unit, and it becomes possible to notify the affected software service of the change (S3005). When the consent of the user U3000 is not obtained ( "No" in S3004), the process proceeds to S7001 of FIG. 18 to create a rejection notice. Here, the service software update control unit can select to approve the change in consideration of the information on which API is affected (S3006). However, in the case of the user management domain I3X00, the approval must be performed by the user U3000 via the human-machine interface system V1200 (S3007). When this approval is also obtained ( "Yes" in S3007), the flow can proceed to S4003 and later of FIG. 17.

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

[0036] If an update based on software package U1000 of base software B1000 is prioritized (Yes in S7000), contact the service software update control unit I3X20 for each service software affected by the update of software package U1000 to disable the affected service software (S7003). Further, access to API B1100 from the service software is cancelled (S7004), and a notice N1000 including the updated service software dependency table B1310 is sent to the OTA center C1000 to support future changes (S7005). Finally, by executing the processing after step S4003 in Figure 17, the base software B1000 can be forcibly updated.

[0037] Return to the processing of Figure 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 and the service software update control unit I2X20 that manages 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 issues affecting the update (S3002). This additional information can be used to specifically verify the exact API changes or characteristic changes, giving developers the opportunity to minimize service outages across the board.

[0038] The use of the type N1100 notification N1000 of being affected is only one way of sharing information, and it can vary depending on what additional information the IMD administrator and the administrator of the base software B1000 want to share. In the flowchart, the option of contacting the affected service software administrator is shown, and for this, it is necessary to link the contact information to the service software dependency table B1310. There are no restrictions on the expansion of the information that can be included in this table and the way this information is securely shared with the relevant parties required by the present invention. When it is determined what to share with the IMD, the OTA center C1000 returns a negative response to the attempt to apply changes to the software package U1000 on the target system without sending the software package U1000 (S3003).

[0039] When the service software is changed within the IMD or the user management domain, these systems can utilize any software management system to confirm that the service software can run correctly on the base software B1000. The outline of the process of obtaining information on a certain service software IX04Y introduced into the service software dependency table B1310 is shown in FIG. 19.

[0040] From step S5001 to S5005, whether the software domain is independently managed or user-managed, it determines to obtain the software package U2000 and modify it. The operations of this embodiment start after S5005, and the newly modified service software links to API B1100 (S5006). After this, the API usage tracker B1200 starts tracking new accesses to the API (S5007). Since this embodiment targets a distributed software management system, if there is no information that needs to be shared, it is necessary to determine how much information is shared between the base software B1000 and the software domain operating on it (S5008). If there is no information to be shared (\"No\" in S5008), the API usage tracker B1200 can always include the API, and it can find the service software that accessed API B1100 within the base software B1000 as part of this information and introduce it 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), the information can be shared using the notification N1000 of which the type N1100 is an update, and the OTA center C1000 can be made to reflect the changes. If more information can be shared between the base software B1000 and the software domain operating 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, that is also executed (step S5010).

[0042] [Embodiment 2] [Only the vehicle system V1100 is equipped with the service software dependency identification unit B1300] In Example 1, it was premised that both the vehicle system V1100 and the OTA center C1000 were equipped with the service software dependency identification unit B1300. However, in Example 2, only the vehicle system V1100 is equipped with the service software dependency identification unit B1300.

[0043] Therefore, in this example, since the system software information C13X200 of the target system C13X000 of the OTA center C1000 does not have the service software dependency table B1310, S1002 and S1003 in FIG. 14 for making this determination are not executed and are skipped. Other processes are the same as in Example 1.

[0044] According to the embodiments of the present invention described above, the following operational effects can be obtained.

[0045] (1) The software update system according to the present invention is a software update system for updating the software installed in a vehicle. The software includes base software that is managed according to a first software management system and is composed of one or more software modules and a plurality of interfaces associated with the one or more software modules, and service software that is managed according to a second software management system and operates using any of the plurality of interfaces. The base software includes a service software dependency identification unit that identifies, for each interface, the service software dependency that is the dependency between the service software and the base software. The system includes a base software update impact identification unit that identifies the impact on the service software due to the 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, the impact on the service software due to the update of the base software based on the service software dependency.

[0046] With the above configuration, it becomes possible to update the system while minimizing the notifications sent to the service software that depends on the system.

[0047] (2) The apparatus further includes a base software dependency identification unit that identifies a base software dependency, which is a dependency between an interface and a software module within the base software. The base software update impact identification unit identifies, for each interface, service software that is affected by the update of the base software based on the base software dependency. This makes it possible to grasp the dependency between the service software and the base software in units of software modules included in the base software, and thus it becomes possible to analyze in more detail the impact of the update of the base software on the service software.

[0048] (3) The interface of the base software has, as a specification, the response characteristics of the base software at the time of calling the interface. The service software dependency identification unit acquires, from within the second software management system, service software response characteristic information, which is information regarding the response characteristics of each interface that has an impact on the service software. The base software update impact identification unit acquires, 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. Based on the service software response characteristic information and the interface characteristic element information, the base software update impact identification unit identifies the impact of the update of the base software on the service software. This makes it possible to analyze the impact of the update of the base software on the service 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. The service software dependency is composed of the identifier of the interface used by the service software whose operation is guaranteed in the second software management system and the base software version. The base software update control unit compares 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, and detects the incompatibility of the base software update. By comparing the versions of the software, it becomes possible to determine whether the base software should be updated based on the software with the latest version.

[0050] (5) 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 the update is possible with respect to the system of the second software management system. If the update is not possible, the update of the base software is postponed. This makes it possible to prevent the malfunction of the vehicle caused by the execution of the software update determined to be incompatible.

[0051] (6) 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 acquires the service software dependency from the service software update control unit. The service software update control unit acquires the 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. This makes it possible to always keep the service software dependency necessary for judging the influence on the service software as the latest information and suppress misdiagnosis.

[0052] Note that the present invention is not limited to the above-described embodiments, and various modifications are possible. For example, the above embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to the aspect including all the configurations described. Also, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment. In addition, the configuration of another embodiment can be added to the configuration of one embodiment. Further, a part of the configuration of each embodiment can be deleted, or other configurations can be added or replaced.

Explanation of Reference Numerals

[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 and 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 one of the plurality of interfaces, the base software comprising a service software dependency identification unit that identifies, for each interface, a service software dependency that is a dependency between the service software and the base software, the system comprising a base software update impact identification unit that identifies the 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 identifying, for each interface, the impact on the service software due to an update of the base software based on the service software dependency, characterized in that it is a software update system.

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 between the interface and the software module within the base software, the base software update impact identification unit identifying, for each interface, the service software affected by an update of the base software based on the base software dependency, characterized in that it is a software update system.

3. The software update system according to claim 2, wherein the interface of the base software has, as a specification, a response characteristic of the base software at the time of calling the interface, the service software dependency identification unit obtaining, from within the second software management system, service software response characteristic information that is information regarding the response characteristic 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, and the service software dependency relationship 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, the base software update control unit compares 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 relationship and the base software installed in the vehicle, and detects the non-conformity of the update of the base software. A software update system characterized by the above.

5. The software update system according to claim 1, wherein when the non-conformity of the base software is detected by the base software update impact identification unit, the base software update control unit confirms whether or not to update with respect to the system of the second software management system, and defers the update of the base software if the update is not allowed. A software update system characterized by the above.

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, and the service software dependency relationship identification unit obtains the service software dependency relationship from the service software update control unit. The service software update control unit acquires operation guarantee service software information regarding the service software whose operation has been 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 the above.

Images