Cooperative system and processing system

Abstract

To provide a technique for properly eliminating mismatches of versions of software on electronic control devices in a cooperative system.SOLUTION: A cooperative system 13 updates software of a plurality of electronic control devices 15, 17 using software from an OTA master 11. The cooperative system 13 includes update units 73, 83, a checked data storage unit 70, checking units 75, 85 and processing units 77, 87. The checked data storage unit 70 stores version information of software updated. The checking units 75, 85 are configured to check consistency of versions of software programs used for starting the electronic control devices 15, 17, based on a version consistency table. The processing unit 77 is configured to perform processing to keep consistency of the software versions.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to a technology such as a cooperative system in which a plurality of electronic control units function in cooperation with each other. [Background technology]

[0002] Conventionally, in the field related to cooperative systems consisting of multiple electronic control units (i.e., ECUs), etc., OTA technology has been known, in which data is transmitted and received via wireless communication between a center having server functions and the ECU. ECU stands for Electronic Central Unit, and OTA stands for Over The Air.

[0003] With this OTA technology, it is desirable that all software versions on all ECUs (i.e., target machines) be consistent after the software update, and multiple target machines must be updated simultaneously. The ECUs whose software is to be updated are called target machines. As is well known, a version is a code such as a number that distinguishes between old and new software products (e.g., versions).

[0004] However, if the timing of resetting each target machine is shifted due to an abnormality or the like, the software upgrade may be completed only on one of the target machines.

[0005] This may result in the target machine booting up with a different combination of new and old versions, and in such a case, the booted target machine may be unable to communicate with the OTA master or other target machines in the cooperative system due to version inconsistencies. Note that the OTA master is a device that controls OTA (for example, controls the sending and receiving of data such as software between the cooperative system).

[0006] For example, if communication with other target machines in a cooperative system becomes impossible, various controls performed in cooperation with other target machines may become impossible. Also, if communication with the OTA master is impossible, it is not possible to roll back the target machines in the cooperative system in response to a rollback request from the OTA master.

[0007] Recently, various techniques have been proposed for updating the software of each ECU in a system equipped with an OTA master and multiple ECUs (see, for example, Patent Document 1 below). The technique described in Patent Document 1 updates the software of multiple ECUs in order for each type of memory. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Publication No. 2022-168477 Summary of the Invention [Problem to be solved by the invention]

[0009] However, as a result of detailed investigation by the inventors, the following problems were found in the conventional techniques. The technology described in Patent Document 1 simply updates the software of each ECU in order, and therefore has the problem of being unable to take appropriate action in the event of a software version mismatch. For example, with this technology, if communication with the OTA master is not possible, the technology has the problem of being unable to resolve the software version mismatch through a lookback request from the OTA master.

[0010] An object of one aspect of the present disclosure is to provide a technology that can suitably resolve inconsistencies in the software versions of electronic control units in a cooperative system. [Means for solving the problem]

[0011] (a) One aspect of the present disclosure relates to a cooperative system (13) that updates software in multiple electronic control devices using software transmitted from an OTA master (11) that controls software updates in the electronic control devices (15, 17). The cooperative system includes multiple electronic control devices, and includes an update unit (73, 83), a memory unit (70), a verification unit (75, 85), and a processing unit (77, 87).

[0012] The update unit is configured to perform updates of respective software that can be used at startup of the respective electronic control units. The storage unit is configured to store at least updated software version information as version information indicating the version of software that can be used when starting up each electronic control unit.

[0013] The checking unit is configured to check the consistency of the versions of each piece of software stored in the storage unit based on consistency data indicating the consistency of the versions. The processing unit is configured to perform processing to maintain consistency between versions of each piece of software based on the check result by the checking unit.

[0014] With the above-described configuration, even if the versions of each software stored in the memory unit (i.e., the versions of each software that can actually be used at startup) in each target machine (i.e., electronic control device) in the collaborative system are inconsistent, processing to maintain version consistency can be performed to eliminate problems caused by version inconsistency (e.g., problems such as the inability to start the collaborative system).

[0015] For example, even if communication between the OTA master and the cooperative system is not possible due to a version inconsistency (for example, even if software in an electronic control unit of the cooperative system cannot be rolled back in response to an instruction from the OTA master), processing to maintain version consistency can be performed based on the check results by the verification unit. For example, for an electronic control unit that requires software rollback processing, the software can be rolled back. This makes it possible to resolve problems caused by version inconsistencies.

[0016] (b) Another aspect of the present disclosure is a processing system (5) including the above-described cooperative system and an OTA master. As described above, in this processing system, even if the software versions of each target machine in the collaborative system are inconsistent, problems caused by version inconsistency can be resolved by performing processing to maintain version consistency.

[0017] Furthermore, the symbols in parentheses in this column and in the claims indicate a correspondence with the specific means described in the embodiments described later as one aspect, and do not limit the technical scope of the present disclosure. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is an explanatory diagram illustrating the overall configuration of a network system according to a first embodiment. [Figure 2] 1 is a block diagram functionally illustrating an in-vehicle system according to a first embodiment. [Figure 3] FIG. 3A is an explanatory diagram showing a version consistency table, and FIG. 3B is an explanatory diagram showing a version record table. [Figure 4] FIG. 4 is a sequence diagram showing the overall processing under normal conditions (that is, a normal sequence) in the first embodiment. [Figure 5] FIG. 4 is a sequence diagram showing a process of checking system synchronization normally in the first embodiment. [Figure 6] FIG. 4 is a sequence diagram showing the overall process (that is, the abnormality sequence) when an abnormality occurs in the first embodiment. [Figure 7] FIG. 10 is a sequence diagram showing a process of checking system synchronization when an abnormality occurs in the first embodiment. [Figure 8] FIG. 10 is a functional block diagram showing an in-vehicle system according to a second embodiment. [Figure 9] FIG. 10 is a sequence diagram showing the overall processing under normal conditions (that is, a normal sequence) in the second embodiment. [Figure 10] FIG. 11 is a sequence diagram showing a process of checking system synchronization normally in the second embodiment. [Figure 11] FIG. 10 is a sequence diagram showing the overall process (that is, the abnormality sequence) when an abnormality occurs in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the drawings. [1. First embodiment] In the first embodiment, a technique for updating software of a plurality of electronic control units in a cooperative system using OTA technology will be described.

[0020] [1-1. Overall hardware configuration] As shown in Fig. 1, the network system 1 in the first embodiment includes a center 3, an in-vehicle system 5, and a network 7. The in-vehicle system 5 includes an external communication device 9, an OTA master 11, and a cooperative system 13. The cooperative system 13 includes a plurality of electronic control units (i.e., ECUs) 15, 17, and a shared memory 19. Each component will be described in detail below.

[0021] <Center> The center 3 can wirelessly communicate with the OTA master 11 of the in-vehicle system 5 via a network 7 such as the Internet, and functions as a server. The OTA master 11 is capable of wireless communication via an external communication device 9. The center 3 is configured to transmit software update data for the electronic control devices 15 and 17 of the cooperative system 13 to the OTA master 11.

[0022] <In-vehicle systems> The in-vehicle system 5 is a network mounted on a vehicle (for example, an automobile). Note that, although the first embodiment takes an example of an in-vehicle system mounted on a vehicle, the present invention is not limited to a vehicle.

[0023] The OTA master 11 and the cooperative system 13 are connected by a wired communication line 21 so as to be able to send and receive data. The electronic control units 15 and 17 are connected by a wired communication line 23 so as to be able to send and receive data. The electronic control units 15 and 17 are connected to the shared memory 19 by wired communication lines 25 and 27 so as to be able to send and receive data.

[0024] <OTAマスタ> The OTA master 11 is an electronic control device including a known CPU 31, RAM 33, ROM 35, a nonvolatile memory (for example, a data-rewritable nonvolatile memory) 37, a communication device 39, etc. The CPU 31, RAM 33, ROM 35, etc. constitute a calculation unit 40 that performs calculations for various controls, etc. The calculation unit 40 may be a known microcomputer (hereinafter referred to as a microcomputer).

[0025] As is well known, the OTA master 11 wirelessly transmits and receives data to and from the center 3 (for example, receives software update data from the center 3) and manages the OTA status. It also has a function of controlling the software update process and updating the software of the electronic control devices 15 and 17 to be updated in the cooperative system 13. Note that, hereinafter, the electronic control device 15 to be updated may be referred to as target A, and the other electronic control device 17 to be updated may be referred to as target B.

[0026] <Collaborative System> The cooperative system 13 has a function of updating the software of the electronic control units 15 and 17 using software transmitted from the OTA master 11 via a wired connection.

[0027] Target A of cooperative system 13 includes a well-known communication device 41, a CPU 43, a RAM 45, a ROM 47, and a nonvolatile memory (for example, a rewritable nonvolatile memory) 49. This nonvolatile memory 49 may be a two-sided memory having a first storage area 49a and a second storage area 49b as areas for storing data. The CPU 43, RAM 45, ROM 47, etc. constitute a calculation unit 51 that performs calculations for various controls, etc. The calculation unit 51 may be a well-known microcomputer.

[0028] Similarly, target B includes a well-known communication device 53, a CPU 55, a RAM 57, a ROM 59, and a nonvolatile memory (for example, a rewritable nonvolatile memory) 61. This nonvolatile memory 61 may be a two-sided memory having a first storage area 61a and a second storage area 61b as areas for storing data. The CPU 55, RAM 57, ROM 59, etc. constitute a calculation unit 63 that performs calculations for various controls, etc. The calculation unit 63 may be a well-known microcomputer.

[0029] Note that data can be transmitted and received between the communicator 41 of target A and the communicator 53 of target B. Data can also be transmitted and received between the communicator 41 of target A and the communicator 39 of the OTA master 11.

[0030] Furthermore, a nonvolatile memory (for example, a data-rewritable nonvolatile memory) can be used as the shared memory 19. The shared memory 19 is accessible from the target A and the target B. In other words, the target A and the target B can write data to the shared memory 19, and the target A and the target B can read data from the shared memory 19.

[0031] The various functions of the OTA master 11, target A, and target B are realized by the CPUs 31, 43, and 55 executing programs stored in non-transient physical recording media. In this example, for example, the ROMs 35, 47, and 59 correspond to the non-transient physical recording media storing the programs. Furthermore, by executing these programs, the methods corresponding to the programs are performed.

[0032] The number of microcomputers constituting the OTA master 11, target A, and target B may be one or more. Furthermore, the method of realizing the various functions possessed by the OTA master 11, target A, and target B is not limited to software, and some or all of the elements may be realized using one or more pieces of hardware. For example, when the above functions are realized by electronic circuits that are hardware, the electronic circuits may be realized by digital circuits including multiple logic circuits, analog circuits, or a combination of these.

[0033] [1-2. Functional structure of the collaborative system] Next, the functional configuration of the collaborative system 13 will be described. As shown in FIG. 2, the cooperative system 13 includes a target A, a target B, and a verification data storage unit 70.

[0034] The target A includes a communication unit 71 , a software update unit 73 , a confirmation unit 75 , a processing unit 77 , and a software storage unit 79 . The communication unit 71 has a function of driving the communication device 41 to transmit and receive data to and from the target B.

[0035] The software update unit 73 performs processing to update the software received from the OTA master 11. That is, it performs processing to update the software stored in the nonvolatile memory 49. Note that the software update unit 73 also performs processing to reset the target A and secure boot, as will be described later.

[0036] As will be described later, the confirmation unit 75 has a function of checking the consistency of the versions of both software that can be used when starting up target A and target B (i.e., that are actually used when starting up) based on consistency data that indicates the consistency of the versions. In other words, it has a function of checking the consistency of the versions of both software stored in the version record table of the shared memory 19 based on the consistency data stored in the version consistency table of the shared memory 19.

[0037] The processing unit 77 has a function of performing processing to maintain the consistency of the versions (for example, rolling back the software of target A) if, for example, there is inconsistency between the versions of the software of target A and target B based on the check result by the confirmation unit 75. As is well known, rollback is processing to return software, etc., to the state before the update.

[0038] The software storage unit 79 corresponds to the nonvolatile memory 49, and has a function of storing (that is, holding) updated software and the like. Similarly, target B includes a communication unit 81 , a software update unit 83 , a confirmation unit 85 , a processing unit 87 , and a software storage unit 89 .

[0039] The communication unit 81 has a function of driving the communication device 53 to transmit and receive data to and from the target A. The software update unit 83 performs a process of updating the software received from the target A. That is, it performs a process of updating the software stored in the nonvolatile memory 49. Note that the software update unit 83 also performs a reset of the target B and a secure boot process, as will be described later.

[0040] As will be described later, the verification unit has the function of checking the consistency of the versions of both software used when starting up target A and target B (i.e., the versions of both software stored in the version record table of shared memory 19) based on consistency data indicating the consistency of the versions (i.e., the consistency data stored in the version consistency table of shared memory 19).

[0041] The processing unit 87 has the function of performing processing to maintain version consistency (for example, rolling back the software of target B) if, for example, there is inconsistency in the versions of target A and target B based on the check results by the confirmation unit 85.

[0042] The software storage unit 89 corresponds to the nonvolatile memory 61, and has a function of storing (that is, holding) updated software and the like. The confirmation data storage unit 70 corresponds to the shared memory 19, and has the function of storing (that is, holding) the version consistency table and the version record table.

[0043] 3A, the version consistency table is a table (i.e., consistency data) that indicates the consistency (i.e., consistency) of the versions of the software of target A and target B. Note that version consistency means that, as will be described later, when cooperative system 13 is started, that is, when both software are used when target A and target B are started, cooperative system 13 can be started without any problems (i.e., normal system start-up without any abnormalities in communication, etc. is possible).

[0044] For example, as in pattern 2, if the software version of target A is Ver. 1.00 and the software version of target B is Ver. 1.00 (i.e., the versions match), it is considered to be consistent. Also, as in pattern 3, if the software version of target A is Ver. 2.00 and the software version of target B is Ver. 2.00, it is considered to be consistent. In other words, it is considered to be consistent if both versions are versions that correspond to each pattern.

[0045] In addition, the version record table is a table (i.e., recorded data) that shows version information indicating the version of each software used when starting up target A and target B (i.e., the latest version to be used for the next start-up).

[0046] In the version record table, version information indicating the actual version of the software transmitted from target A or target B (i.e., the latest version after update) is written.

[0047] Furthermore, the software before the update and its version information are stored separately from the version record table. For example, if the software before the update and its version information are stored in the first storage areas 49a and 61a, and the updated software and its version information are stored in the second storage areas 41b and 61b, the software before the update and its version information are still stored in the first storage areas 41a and 61a.

[0048] If the latest version of the software for both Target A and Target B is Ver. 2.00, then Target A in the version record table will be Ver. 2.00 and Target B will be Ver. 2.00. However, if for some reason, for example, the latest version of Target B's software is Ver. 1.00, then Target A's software in the version record table will be Ver. 2.00 and Target B's software will be Ver. 1.00.

[0049] Therefore, as will be described later, the confirmation units 75 and 85 can check (i.e., confirm) the consistency of the versions of both software based on the version consistency table and the version record table stored in the confirmation data storage unit 70. In other words, it can be confirmed whether the software versions of target A and target B (i.e., the latest versions after update) are consistent as described in the version consistency table.

[0050] Then, based on the check results by the confirmation units 75 and 85, if there is no consistency between the versions of target A and target B, the processing units 77 and 87 can maintain the consistency of the versions by performing processing to maintain the consistency of the versions (for example, rolling back the software of target A or target B). In other words, it is possible to maintain the consistency of the versions of both pieces of software.

[0051] If the versions of the software in both target A and target B are consistent, there is no need to perform processing to maintain consistency. [1-3. Processing procedures in in-vehicle systems] Next, the processing procedure in the in-vehicle system 5 will be described.

[0052] [1-3-1. Normal processing procedure] Here, an example of a normal sequence when there is version consistency will be described.

[0053] <Overall processing procedure> First, the overall processing procedure in the in-vehicle system 5 will be described. As shown in Fig. 4, first, the following software update process is performed in SH1. Note that the process will be referred to as SH below.

[0054] Specifically, the OTA master 11 transmits update data for the software of the target A and the target B to the target A. The target A receives the update data for the software of the target A and the target B transmitted from the OTA master 11.

[0055] Target A performs software update processing using the update data for the target A's software received from the OTA master 11. Specifically, the update data is stored in nonvolatile memory 49. That is, the update data is downloaded and installed. Note that, for example, if the software before the update is stored in the first storage area 49a of nonvolatile memory 49, the software to be updated this time is stored in the second storage area 49b.

[0056] Furthermore, target A transmits to target B the update data for the software of target B received from the OTA master 11. Target B performs software update processing using the update data for the software of target B received from target A. Specifically, the update data is stored in nonvolatile memory 61. That is, the update data is downloaded and installed. Note that, for example, if the software before the update is stored in the first storage area 61a of nonvolatile memory 61, the software to be updated this time is stored in the second storage area 61b.

[0057] Next, in SH2, the OTA master 11 sends an activation request to target A. This activation request includes an activation request that is sent not only to target A but also to target B via target A, as will be described later. Note that this activation request is a request for activation settings, which will be described later.

[0058] When an activation request is made, the OTA master 11 sends a startup version to target A. This startup version is a version that is compatible with the next startup. In other words, it is a version that has correct compatibility with both the software of target A and target B. Here, the startup version is, for example, the content shown in FIG. 4.

[0059] Next, target A adds the next startup version to the version consistency table in SH3, for example, adding the contents of pattern 3 to the version consistency table in FIG. Next, the SH4 processes an activation request from target A to target B. That is, a request for activation setting, which will be described later, is made.

[0060] Next, in SH5, target B performs activation setting processing. This activation setting processing is processing for switching the bank (hereinafter referred to as bank) at the next startup (i.e., switching the storage area of the software to be used). For example, if software in the first storage area 61a is used before the software update and software in the second storage area 61b is used after the update, this is processing for setting the software stored in the second storage area 61b to be used at the next startup (i.e., bank switching processing).

[0061] Next, in SH6, target B notifies target A that activation setting of target B is complete. Next, in SH7, activation setting processing is performed for target A. That is, in target A, the bank to be used at the next startup is switched.

[0062] Next, in SH8, target A notifies OTA master 11 that activation setting of target A and target B has been completed. Next, target A performs a reset process using SH9. That is, it performs the processes required for startup such as rebooting. For example, it performs a process to select the software in the memory area where the bank switching has been performed as the software to be used at startup.

[0063] Then, SH10 checks whether there are any problems with the startup (i.e., performs a self-check) and performs the startup process (i.e., secure boot process). In this way, when resetting, the reset is performed using the updated software of target A (i.e., the software in the memory area where the bank has been switched). In other words, the process of starting up using the updated software is performed.

[0064] Similarly, in target B, SH11 performs reset processing, and SH12 performs self-check processing. During this reset, the updated software of target B (i.e., the software in the memory area where the bank has been switched) is used. In other words, the updated software is used during startup.

[0065] Next, in target A and target B, the SH 13 performs a system synchronization check process. This system synchronization check is a process of checking the consistency of the versions of the software in target A and target B, as will be described later.

[0066] Next, the SH 14 performs processing (that is, a command) for reading the software versions of the targets A and B from the OTA master 11 to the target A.

[0067] Therefore, target A accesses the shared memory 19 using SH15 and performs a process of reading the actual (i.e., latest updated) versions of each piece of software of target A and target B from the version record table. In other words, a process of reading the version information of each piece of software of target A and target B from the version record table.

[0068] Next, the SH 16 performs a process of transmitting the updated versions (i.e., version information) of the software of the target A and the target B from the target A to the OTA master 11.

[0069] In this manner, in the above-described sequence, the versions of both software are consistent, and therefore normal operation of the in-vehicle system 5 (for example, normal startup operation of the cooperative system 13) is possible.

[0070] <System synchronization check procedure> Next, the procedure for checking system synchronization will be described. As shown in FIG. 5, the SH 21 performs a process of writing the updated software version of the target A from the target A to the version record table in the shared memory 19 .

[0071] Next, in SH22, target A accesses the version record table in shared memory 19 and performs processing to check the updated software version of target B (that is, processing to read out the latest software version information of target B).

[0072] Here, if the updated software version of target B is not written in the version record table of the shared memory 19 in the SH 23, processing for waiting for a predetermined time is performed.

[0073] On the other hand, the SH 24 performs a process of writing the updated software version of the target B from the target B to the version record table of the shared memory 19 . Next, in SH25, target B accesses the version record table in shared memory 19 and performs a process to check the updated software version of target A. In other words, a process is performed to obtain the latest software version information of target A from the version record table in shared memory 19.

[0074] Then, in target B, SH26 compares the updated version information of both target A and target B stored in the version record table with the consistent version information of both target A and target B stored in the version consistency table (for example, the version information of both software in pattern 3).

[0075] Specifically, it checks whether the version information for both target A and target B in the version record table matches (i.e., whether there is consistency) the version information for both target A and target B in the version consistency table (for example, both version information for pattern 3). In other words, it checks whether the versions of both software for target A and target B after update (i.e., used at startup) are consistent.

[0076] It should be noted that the updated software version information here is not the past version information (i.e., prior to the current update) but the latest version information of the software that is actually used at startup.

[0077] Meanwhile, in SH27, target A accesses the version record table in shared memory 19 and performs processing to check the updated software version of target B. In other words, processing is performed to obtain the updated software version information of target B from the version record table in shared memory 19.

[0078] Then, in target A, in SH28, as in target B, the version information of both the updated software of target A and target B stored in the version record table is compared with the version information that is consistent with the version information of both the software of target A and target B stored in the version consistency table.

[0079] Specifically, it checks whether the version information for both target A and target B in the version record table matches (i.e., whether there is consistency) the version information for both target A and target B in the version consistency table (for example, both version information for pattern 3). In other words, it checks whether the versions of both software for target A and target B after update (i.e., used at startup) are consistent.

[0080] If the updated versions of the software on target A and target B are consistent, there is no need to perform a rollback, etc. (described later), and the next stage of processing that normally occurs is carried out. For example, various control processes that target A and target B normally perform in cooperation with each other are carried out.

[0081] [1-3-2. Procedures for handling abnormalities] <If there is an abnormality in the overall process> Here, the description of the same contents as those shown in FIG. 4 will be omitted or simplified.

[0082] As shown in FIG. 6, an activation request is sent from the OTA master 11 to the target A in the SH 31. Next, in S32, target A performs a process of adding the next activation version to the version consistency table, similar to the process shown in Fig. 4. Note that in this process, target A does not perform activation setting process, reset process, or self-check process.

[0083] Next, target A sends an activation request to target B in SH33. Next, in SH34, target B performs activation setting for itself.

[0084] Let us consider the case where some abnormality occurs in target B and target B is reset. That is, let us consider the case where the reset is performed using the updated software (i.e., software version 2.00) stored in the second storage area 61b. Note that the software before the update (i.e., software version 1.00) is stored in the first storage area 61a.

[0085] In this case, target B performs a self-check and starts up using SH35 (that is, performs a secure boot). As a result, the software version of target B is updated to, for example, Ver. 2.00. As described above, the software of target A has not been activated or reset, so the software version of target A remains, for example, Ver. 1.00.

[0086] Furthermore, even after a predetermined time has elapsed, target A does not receive any communication from target B indicating that the activation setting has been completed. Therefore, target A does not perform its own activation setting process. Therefore, target A transmits to the OTA master 11 via SH36 a message that the activation setting at target A and target B has failed.

[0087] Then, SH37 performs a system synchronization check. As described above, the software version of target B is, for example, Ver. 2.00 after the update, while the software version of target A is, for example, Ver. 1.00. In other words, as is clear from the version consistency table, the software versions of target A and target B are not consistent.

[0088] Therefore, if the version combination does not match, it is determined that the system startup of the cooperative system 13 is not possible. In such a case, as shown in SH38, the software of target B is rolled back. That is, the version of the software used when starting target B is returned to, for example, Ver. 1.00.

[0089] Next, the SH39 performs processing such as resetting the Ver. 1.00 software of the target B. This ensures that the versions of the software on both target A and target B are consistent, making it possible to start the system.

[0090] Here, when there is an inconsistency between the software on target A and the software on target B, the software on target B is rolled back, but a different method of ensuring consistency may be used.

[0091] For example, if there is an inconsistency between the two pieces of software, the update data for target A can be used to perform a reset or self-check as described above, and the software version of target A can be updated to Ver. 2.00. If it is possible to start target A in this way, it is possible to ensure the consistency between the two pieces of software.

[0092] <If there is an abnormality in the system synchronization check> Here, the description of the same contents as those shown in FIG. 5 will be omitted or simplified.

[0093] As shown in FIG. 7, the SH 41 performs a process of writing the updated software version of the target A from the target A to the version record table in the shared memory 19 . Next, in the SH42, target A accesses the version record table in the shared memory 19 and performs processing to check the version of the software of target B after the update.

[0094] If the updated software version of target B is not written in the version record table of shared memory 19, SH43 performs a process of waiting for a predetermined time.

[0095] Here, consider the case where the updated software version of target B has not been written to the version record table in shared memory 19 even after waiting for a predetermined time (that is, a timeout has occurred).

[0096] In this case, the SH44 of target A checks whether communication is possible. That is, in order to check whether communication is possible, target A transmits a predetermined signal to target B and requests a reply to that signal.

[0097] If communication is possible, a predetermined reply is sent from target B to target A via SH45, so that target A can confirm that communication is possible.

[0098] Next, target A checks the version of the software of target B. That is, SH46 requests target B to transmit the version information of the updated software.

[0099] Next, in SH47, target B transmits to target A version information of the updated software of target B. Next, in SH48, target A compares the version information of target A's software stored in the version record table and the version information of the software obtained from target B with the version information of target A and target B stored in the version consistency table, and checks whether the versions of both target A's and target B's software are consistent.

[0100] If a version inconsistency is confirmed, the new software (i.e., the software with the newer version) is rolled back, similar to the rollback process in Figure 6, to maintain the consistency of both the target A and target B software.

[0101] [1-4.Effects] According to the first embodiment, the following effects can be obtained. (1a) In this first embodiment, even if the versions of the software used at the time of startup or other operations are inconsistent between target A and target B in the collaborative system 13, by performing processing to maintain version consistency, it is possible to resolve problems caused by version inconsistency (for example, problems such as the inability to start the collaborative system 13).

[0102] For example, even if communication between the OTA master 11 and the cooperative system 13 is not possible due to a version mismatch, and therefore even if software rollback of target A or target B of the cooperative system 13 cannot be performed in response to an instruction from the OTA master 11, processing to maintain version consistency can be performed based on the check results by the confirmation units 75 and 85. For example, for target A or target B that requires software rollback processing, the software can be rolled back. This makes it possible to resolve problems caused by version mismatch.

[0103] (1b) In this first embodiment, the confirmation data storage unit 70 stores consistency data (e.g., a version consistency table) indicating the consistency of the versions of the software of both target A and target B, and record data (e.g., a version record table) indicating the version information of each software used when starting up target A and target B.

[0104] Therefore, by comparing the recorded data with the consistency data, it is possible to check the consistency of the versions, i.e., to confirm whether or not the versions are consistent. Furthermore, this version record table stores the version information of the updated software, but if the update fails, the version information of the software before the update is not deleted but is retained.

[0105] That is, the version record table stores the version information of the updated software as the version information of the software to be used at startup, and if the software is not updated, the version information of the software before the update is stored as the version information of the software to be used at startup.

[0106] Therefore, even in such a case, the consistency of the versions can be checked by comparing the recorded data with the consistency data, that is, it can be confirmed whether or not the versions are consistent.

[0107] (1c) In the first embodiment, the shared memory 19 accessible by the target A and the target B can be used as the confirmation data storage unit 70. Therefore, the target A and the target B can write version information of the software of the target A and the target B to the shared memory 19. In addition, the target A and the target B can read version information of the software of the target A and the target B from the shared memory 19.

[0108] This version information includes data in a version consistency table sent from the OTA master 11 and updated software version information for targets A and B used when starting up targets A and B.

[0109] (1d) In the first embodiment, if the confirmation data storage unit 70 does not store the version information of the software of target A or target B that should be stored after the update (for example, if either version information used when checking the version consistency is not stored), the possibility of communication between target A and target B, whose consistency is being checked, is checked. If the communication is possible, communication is performed between target A and target B, and the version information of the software that is not stored can be obtained.

[0110] (1e) In this first embodiment, if the versions of software in target A and target B, which are the targets for checking the consistency of the software versions, are inconsistent, the new software side (i.e., the updated software side) can be rolled back.

[0111] For example, if target A's software has been updated but target B's software has not, the software on target A is rolled back to the version before the update. This ensures consistency between the software versions on both target A and target B.

[0112] [1-5. Correspondence] Next, the relationship between the first embodiment and the present disclosure will be described. The in-vehicle system 5 corresponds to the processing system, the OTA master 11 corresponds to the OTA master, the cooperative system 13 corresponds to the cooperative system, the electronic control devices 15, 17 of the target A and the target B correspond to the electronic control devices, the software update units 73, 83 correspond to the update unit, the confirmation data storage unit 70 corresponds to the storage unit, the confirmation units 75, 85 correspond to the confirmation unit, and the processing units 77, 87 correspond to the processing unit.

[0113] [2. Second Embodiment] The second embodiment has the same basic configuration as the first embodiment, and therefore the following mainly describes the differences from the first embodiment. Note that the same reference numerals as those in the first embodiment indicate the same configuration, and reference is made to the preceding description.

[0114] In the second embodiment, the version consistency table and the like are stored not in the shared memory but, for example, in target A. The following description will focus on the differences from the first embodiment. [2-1.Configuration] As shown in FIG. 8, the second embodiment includes an OTA master 11 and a cooperative system 13 as an in-vehicle system 5, similar to the first embodiment. The cooperative system 13 includes a target A and a target B.

[0115] Similar to the first embodiment, target A includes a communication unit 71, a software update unit 73, a confirmation unit 75, a processing unit 77, and a software storage unit 79. Furthermore, target A includes a version record table storage unit 91 and a version consistency table storage unit 93.

[0116] The version record table storage unit 91 is a memory that stores a version record table. More specifically, it is a memory that stores the version of the latest software of target A (i.e., the updated software used at startup). This memory may be a rewritable nonvolatile memory.

[0117] The version consistency table storage unit 93 is a memory that stores the above-mentioned version consistency table. Note that this memory may be a rewritable nonvolatile memory, but may also be shared with the memory of the version record table storage unit 91.

[0118] Similar to the first embodiment, the target B includes a communication unit 81, a software update unit 83, a confirmation unit 85, a processing unit 87, and a software storage unit 89. Furthermore, the target B includes a version record table storage unit 95.

[0119] The version record table storage unit 95 is a memory that stores a version record table. More specifically, it is a memory that stores the version of the latest software of target B (i.e., the updated software used at startup). This memory may be a rewritable nonvolatile memory.

[0120] The communication unit 71 of the target A and the communication unit 81 of the target B have a function capable of transmitting and receiving various data such as version information. [2-2. Processing procedures in vehicle systems] Next, the processing procedure in the in-vehicle system 5 will be described.

[0121] [2-2-1. Normal processing procedure] Here, a normal sequence when the software versions are consistent will be described as an example, but descriptions of the same content as in the first embodiment will be omitted or simplified.

[0122] <Overall processing procedure> First, the overall processing procedure in the in-vehicle system 5 will be described. As shown in FIG. 9, first, the SH 51 performs the same software update process as in the first embodiment.

[0123] Next, the SH 52 sends an activate request from the OTA master 11 to target A. This activate request includes an activate request sent not only to target A but also to target B via target A.

[0124] Also, when an activation request is made, the activation version is sent from the OTA master 11 to the target A. Next, target A adds the next startup version to the version consistency table in SH53.

[0125] Next, the SH54 processes an activation request from target A to target B. Next, in the SH55, the target B performs the activation setting process.

[0126] Next, in SH56, target B notifies target A that activation setting of target B is complete. Next, in the SH57, target A performs activation setting processing.

[0127] Next, in the SH58, target A notifies the OTA master 11 that activation setting of target A and target B has been completed. Next, target A performs a reset process in SH59 and a self-check in SH60, i.e., performs a secure boot.

[0128] Similarly, in target B, SH61 performs reset processing, and SH62 performs self-check processing. That is, secure boot is performed. Next, in target A and target B, the SH63 performs a system synchronization check process. This system synchronization check is a process that checks the consistency of the versions of the software in target A and target B, as will be described later.

[0129] As will be described later (see, for example, FIG. 10), if the system synchronization check is performed normally, target A can obtain from target B the version information of target B's software.

[0130] Next, the SH64 performs processing (that is, a command) for reading the software versions of the targets A and B from the OTA master 11 to the target A.

[0131] Next, the SH 65 performs a process of transmitting the actual versions of the software of the target A and the target B from the target A to the OTA master 11. In addition, when the SH64 performs processing to read the versions of the software of target A and target B from the OTA master 11 to target A, the actual version of the software of target B read from the version record table memory unit 95 may be transmitted from target B to target A by SH66 and SH67.

[0132] As described above, in the above sequence, the version information is consistent, so that the in-vehicle system 5 can operate normally (for example, the cooperative system 13 can start up normally).

[0133] <System synchronization check procedure> Next, the procedure for checking system synchronization will be described. 10, target A checks the possibility of communication using SH 71. That is, in order to check the possibility of communication, target A transmits a predetermined signal to target B and requests a reply to that signal.

[0134] If communication is possible, the SH 72 sends a predetermined reply from target B to target A. Next, the target A checks the response content (i.e., the reply content) using the SH73, thereby making it possible to confirm that communication is possible.

[0135] Next, target A checks the version of the software of target B. That is, the SH74 requests target B to transmit the version information of the updated software.

[0136] Next, in the SH75, target B transmits to target A version information of the updated software of target B. This allows target A to obtain the updated software version of target B, and therefore allows the updated software versions of both target A and target B to be written to the version record table.

[0137] Then, in target A, the SH76 compares the version information of the updated software of both target A and target B stored in the version record table with the version information having consistency between the software of both target A and target B stored in the version consistency table, in the same manner as in Fig. 5. In other words, it checks whether the versions of the software used when starting up target A and target B are consistent.

[0138] In addition, the SH77 transmits the updated software version of target A from target A to target B. In this process, since the software versions are consistent, as described below, rollback processing (i.e., processing to maintain the consistency of the software on both target A and target B) is not required when a version inconsistency is confirmed.

[0139] [2-2-2. Procedures for when an abnormality occurs] <If there is an abnormality in the overall process> Here, explanations of the same contents as those shown in FIG. 4 and FIG. 6 will be omitted or simplified.

[0140] As shown in FIG. 11, an activation request is sent from the OTA master 11 to the target A in the SH 81. Next, in S82, target A performs a process of adding the next activation version to the version consistency table, similar to the process shown in Fig. 6. Note that in this process, target A does not perform activation setting process, reset process, or self-check process.

[0141] Next, the SH83 sends an activation request from target A to target B. Next, in SH84, target B performs activation setting for itself.

[0142] Let us consider the case where some abnormality occurs in target B and target B is reset. That is, let us consider the case where the reset is performed using the updated software (i.e., software version 2.00) stored in the second storage area 61b. Note that the software before the update (i.e., software version 1.00) is stored in the first storage area 61a.

[0143] In this case, the target B performs a self-check (that is, a secure boot) in the SH85. As a result, the software version of target B is updated to, for example, Ver. 2.00. As described above, the software of target A has not been activated or reset, so the software version of target A remains, for example, Ver. 1.00.

[0144] In SH86, even after a predetermined time has elapsed, there is no communication from target B indicating that the activation setting has been completed, so target A transmits to OTA master 11 that the activation setting at target A and target B has failed.

[0145] Then, the SH87 performs a system synchronization check. As described above, the software version of target B is, for example, Ver. 2.00 after the update, while the software version of target A is, for example, Ver. 1.00. In other words, as is clear from the version consistency table, the software versions of target A and target B are not consistent.

[0146] Therefore, if the combination of versions does not match, it is determined that the system startup of the cooperative system 13 is not possible. In such a case, as shown in SH88, the software of target B is rolled back. That is, the version of the software used when starting target B is returned to, for example, Ver. 1.00.

[0147] Next, the SH89 performs processing such as resetting the Ver. 1.00 software of the target B. This ensures that the versions of the software on both target A and target B are consistent, making it possible to start the system.

[0148] [2-3. Effects] The second embodiment has the same effects as the first embodiment. Furthermore, in the second embodiment, it is not necessary to use the shared memory 19 as in the first embodiment. That is, by storing the version information of each piece of software after updating in the version record table storage units 91 and 95 of target A and target B, respectively, and storing the version consistency table in the version consistency table storage unit 93 of target A, it is possible to check the consistency of the software versions. Furthermore, if the versions are not consistent, processing can be performed to ensure version consistency by rollback or the like.

[0149] 3. Other Embodiments Although the embodiments of the present disclosure have been described above, it goes without saying that the present disclosure is not limited to the above-described embodiments and can take on various forms.

[0150] (3a) In the above embodiment, the electronic control devices of the cooperative system are two, target A and target B, but there is no limitation on the number. For example, the cooperative system may include three or more electronic control devices.

[0151] (3b) In the above embodiment, target A transmits software update data to target B. However, the OTA master may transmit software update data to target A and target B, respectively.

[0152] (3c) The processes and techniques in the collaborative system and processing system (e.g., in-vehicle system) described in this disclosure may be implemented by a special purpose computer provided by configuring a processor and memory programmed to perform one or more functions embodied in a computer program.

[0153] Alternatively, the processes and techniques in the collaborative system and processing system (e.g., an in-vehicle system) described in this disclosure may be implemented by a special-purpose computer provided by configuring a processor with one or more dedicated hardware logic circuits.

[0154] Alternatively, the processes and techniques in the collaborative system and processing system (e.g., an in-vehicle system) described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured by one or more hardware logic circuits.

[0155] The computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium. The method for realizing the functions of each unit included in the collaboration system and the processing system (e.g., an in-vehicle system) does not necessarily have to include software, and all of the functions may be realized using one or more pieces of hardware.

[0156] (3d) The above-mentioned cooperative system and processing system (e.g., an in-vehicle system) can also be realized in various forms, such as a cooperative system and processing system, a configuration that includes the cooperative system and processing system as components, a program for causing the computer of the cooperative system and processing system to function, a non-transitory tangible recording medium such as a semiconductor memory on which the program is recorded, and a control method.

[0157] (3e) Multiple functions possessed by one component in each of the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of each of the above embodiments may be omitted. Also, at least part of the configuration of each of the above embodiments may be added to or substituted for the configuration of another embodiment. [Technical idea disclosed in this specification] [Item 1] A cooperative system (13) that updates software in electronic control devices (15, 17) using software transmitted from an OTA master (11) that controls software updates in the electronic control devices, The cooperative system (13) includes a plurality of the electronic control devices, an update unit (73, 83) configured to update the respective software that can be used at the start-up of the respective electronic control unit; a storage unit (70) configured to store at least the updated software version information as version information indicating the software version that can be used when starting up each of the electronic control units; a verification unit (75, 85) configured to check the consistency of the versions of the software stored in the storage unit based on consistency data indicating the consistency of the versions; a processing unit (77, 87) configured to perform processing to maintain the consistency of the versions of the software based on the check result by the confirmation unit; A collaborative system with

[0158] [Item 2] The cooperative system according to item 1, the storage unit is configured to store the version information of the software after the update as the version information of the software to be used at the time of the start-up, and, if the update has not been performed, to store the version information of the software before the update as the version information of the software to be used at the time of the start-up. Collaborative system.

[0159] [Item 3] The cooperative system according to item 1 or 2, The storage unit stores record data indicating the version information of each of the software in each of the electronic control units and consistency data indicating the consistency of the versions of each of the software in each of the electronic control units, the verification unit is configured to check the consistency of the version based on the recording data and the consistency data; Collaborative system.

[0160] [Item 4] A cooperative system according to any one of items 1 to 3, The storage unit is a shared memory accessible by each of the electronic control units. Collaborative system.

[0161] [Item 5] Item 4. A cooperative system according to item 4, The version information of each of the electronic control devices can be written to the shared memory from each of the electronic control devices. Collaborative system.

[0162] [Item 6] A cooperative system according to any one of items 1 to 3, Any of the electronic control devices is provided with the memory unit, Collaborative system.

[0163] [Item 7] A cooperative system according to any one of items 1 to 6, When the storage unit stores the updated version information of the software of the first electronic control unit and the updated version information of the software of the second electronic control unit is not stored, the storage unit checks whether communication between the first electronic control unit and the second electronic control unit is possible, and when communication is possible, the first electronic control unit obtains the updated version information of the software of the second electronic control unit from the second electronic control unit. Collaborative system.

[0164] [Item 8] A cooperative system according to any one of items 1 to 7, In each of the electronic control devices that are the targets of the consistency check, if the versions of the software are inconsistent, new software is rolled back. Collaborative system.

[0165] [Item 9] A processing system (5) comprising the cooperative system according to any one of items 1 to 8 and the OTA master. [Explanation of symbols]

[0166] 5...processing system, 11...OTA master, 13...cooperative system, 15...electronic control device of target A, 17...electronic control device of target B, 70...confirmation data storage unit, 73, 83...software update unit, 75, 85...confirmation unit, 77, 87...processing unit

Claims

1. A cooperative system (13) that updates software in electronic control units (15, 17) using software transmitted from an OTA master (11) that controls software updates in the electronic control units, The cooperative system (13) includes a plurality of the electronic control devices, an update unit (73, 83) configured to update the respective software that can be used at the start-up of the respective electronic control unit; a storage unit (70) configured to store at least the updated software version information as version information indicating the software version that can be used when starting up each of the electronic control units; a verification unit (75, 85) configured to check the consistency of the versions of the software stored in the storage unit based on consistency data indicating the consistency of the versions; a processing unit (77, 87) configured to perform processing to maintain the consistency of the versions of the software based on the check result by the confirmation unit; A collaborative system with

2. The cooperative system according to claim 1, the storage unit is configured to store the version information of the software after the update as the version information of the software to be used at the time of the start-up, and, if the update has not been performed, to store the version information of the software before the update as the version information of the software to be used at the time of the start-up. Collaborative system.

3. 2. The cooperative system of claim 1, The storage unit stores record data indicating the version information of each of the software in each of the electronic control units and consistency data indicating the consistency of the versions of each of the software in each of the electronic control units, the verification unit is configured to check the consistency of the version based on the recording data and the consistency data; Collaborative system.

4. 2. The cooperative system of claim 1, The storage unit is a shared memory accessible by each of the electronic control units. Collaborative system.

5. 5. The cooperative system of claim 4, The version information of each of the electronic control devices can be written to the shared memory from each of the electronic control devices. Collaborative system.

6. 2. The cooperative system of claim 1, Any of the electronic control devices is provided with the memory unit, Collaborative system.

7. 2. The cooperative system of claim 1, When the storage unit stores the updated version information of the software of the first electronic control unit and the updated version information of the software of the second electronic control unit is not stored, the storage unit checks whether communication between the first electronic control unit and the second electronic control unit is possible, and when communication is possible, the first electronic control unit obtains the updated version information of the software of the second electronic control unit from the second electronic control unit. Collaborative system.

8. 2. The cooperative system of claim 1, In each of the electronic control devices that are the targets of the consistency check, if the versions of the software are inconsistent, new software is rolled back. Collaborative system.

9. A processing system (5) comprising a collaboration system according to any one of claims 1 to 8 and the OTA master.

Images