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 electronic control devices 15, 17 using software from an OTA master 11. The cooperative system 13 includes a plurality of electronic control devices and comprises software storage units 79, 89, a checked data storage unit 70, checking units 75, 85 and processing units 77, 87. The checked data storage unit 70 stores version information indicating versions of software in memory regions of the software storage units 79, 89, and stores actual start versions. The checking units 75, 85 are configured to check consistency of actual start versions based on a version consistency table. The processing units 77, 87 are configured to perform processing to keep consistency of the 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 collaborative 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 collaborative system includes multiple electronic control devices, as well as software storage units (79, 89), version storage units (70), verification units (75, 85), and processing units (77, 87).

[0012] The software storage unit is provided for each electronic control device, and has a first storage area and a second storage area capable of individually storing different versions of software, new and old.

[0013] The version memory unit is configured to store version information indicating the version of each software stored in each memory area of each software memory unit, and to identify and store the version information of each software used when starting up each electronic control device from the version information.

[0014] The checking unit is configured to check the consistency of the versions of the software used when starting up each electronic control unit based on consistency data indicating the consistency of the versions.

[0015] 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. With the above-described configuration, even if the versions of the software actually 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 (for example, problems such as the inability to start the collaborative system).

[0016] 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 various processes of the software of the electronic control device of the cooperative system cannot be performed in response to instructions from the OTA master), processing can be performed to maintain version consistency based on the check results by the verification unit.

[0017] For example, for an electronic control unit that requires software rollback or version upgrade processing, the software rollback or version upgrade processing can be selected and executed, thereby eliminating problems caused by version inconsistencies.

[0018] (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.

[0019] 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]

[0020] [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 of a version consistency table, FIG. 3B is an explanatory diagram of a version record table, and FIG. 3C is an explanatory diagram of a target activation version. [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. 10 is a sequence diagram showing the overall processing when an abnormality occurs in Example 1 in the first embodiment. [Figure 7] FIG. 10 is a sequence diagram showing the overall processing when an abnormality occurs in Example 2 in the first embodiment. [Figure 8] FIG. 10 is a sequence diagram showing the overall processing when an abnormality occurs in Example 3 in the first embodiment. [Figure 9] FIG. 10 is a functional block diagram showing an in-vehicle system according to a second embodiment. [Figure 10] FIG. 10 is a sequence diagram showing the overall processing under normal conditions (that is, a normal sequence) in the second embodiment. [Figure 11] FIG. 11 is a sequence diagram showing a process of checking system synchronization normally in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0021] 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.

[0022] [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.

[0023] <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.

[0024] <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.

[0025] 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.

[0026] <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).

[0027] 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.

[0028] <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.

[0029] 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 can 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. configure a calculation unit 51 that performs calculations for various controls, etc. The calculation unit 51 may be a well-known microcomputer.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] [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.

[0036] 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.

[0037] 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.

[0038] As will be described later, the confirmation unit 75 has the function of checking the consistency of the versions of each piece of software actually used when starting up target A and target B, i.e., checking the consistency of the version of the software actually used at startup out of 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., consistency data stored in the version consistency table of shared memory 19).

[0039] The processing unit 77 has a function of performing processing to maintain version consistency, for example, if there is inconsistency between the versions of software for target A and target B based on the check results by the confirmation unit 75. For example, the processing unit 77 has a function of selecting and performing either a rollback or a version upgrade of the software for target A. As is well known, rollback is a process of returning software to the state before the update. As is well known, version upgrade is a process of updating software to a newer version (for example, the latest version) than the current version.

[0040] The software storage unit 79 corresponds to the nonvolatile memory 49, and has the function of storing (i.e., retaining) updated software, etc. For example, the first storage area 49a (i.e., the first side of the two-sided memory) of the nonvolatile memory 49 of target A stores software that was written in the past (e.g., the last updated software), and the second storage area 49b (i.e., the second side of the two-sided memory) stores software that was written more recently than the old time (e.g., the latest updated software).

[0041] 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 . The communication unit 81 has a function of driving the communication device 53 to transmit and receive data to and from the target A.

[0042] 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 A and a secure boot process, as will be described later.

[0043] As will be described later, the confirmation unit 85 has the function of checking the consistency of the versions of each piece of software actually used when starting up target A and target B, i.e., checking the consistency of the version of the software actually used at startup out of 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., consistency data stored in the version consistency table of shared memory 19).

[0044] The processing unit 77 has a function of performing processing to maintain the consistency of the versions when, 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. For example, it has a function of selecting and executing either a rollback or a version upgrade of the software of target A.

[0045] The software storage unit 89 corresponds to the nonvolatile memory 61, and has a function of storing (i.e., a function of retaining) updated software, etc. For example, the first storage area 61a (i.e., the first side of the two-sided memory) of the nonvolatile memory 61 of target B stores software that was written in the past (e.g., the last updated software), and the second storage area 61bb (i.e., the second side of the two-sided memory) stores software that was written more recently than the old time (e.g., the latest updated software).

[0046] 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. 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).

[0047] 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.

[0048] As shown in FIG. 3B, the version record table is a table (that is, recorded data) showing version information indicating the versions of the software used in target A and target B.

[0049] Specifically, in the version record table of the first embodiment, for target A, the version (e.g., Ver. 1.00) of software written in the past (e.g., last updated) is stored in the first storage area 41a of the nonvolatile memory 49. Also, the version (e.g., Ver. 2.00) of software written more recently (e.g., currently updated) than the old version is stored in the second storage area 49b.

[0050] On the other hand, for target B, the version (e.g., Ver. 1.00) of software that was stored in the past (e.g., last updated) is stored in the first storage area 61a of the nonvolatile memory 61. Also, the version (e.g., Ver. 2.00) of software that was written more recently (e.g., updated this time) than the old version is stored in the second storage area 61b.

[0051] The version record table also stores information about which storage area stores the software that will actually be used the next time target A and target B are started up (i.e., the software that will be used the next time they are started up).

[0052] For example, Figure 3B shows that the version of the software enclosed in the double border will actually be used at the next startup. In other words, the version of the software enclosed in the double border is the software that is actually set to be used at startup.

[0053] However, the versions of the two pieces of software that will actually be usable at the next startup may or may not be consistent, so a consistency check is performed as described below. Hereinafter, the version that will be used at the next startup may be referred to as the actual startup version. This actual startup version is the identified version from the versions stored in the version record table.

[0054] As will be described later, the OTA master 11 normally transmits to the target A, etc., the software version (i.e., the target startup version: see FIG. 3C) that will be used the next time the target A, etc. is started up (i.e., when the updated software is properly reset, etc.). Hereinafter, this startup version may be referred to as the target startup version.

[0055] 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 (i.e., the actual activation versions) of target A and target B are consistent as described in the version consistency table.

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

[0057] 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.

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

[0059] <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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] Furthermore, 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 (i.e., the target startup version) is, for example, the content shown in FIG. 4.

[0065] Next, the SH3 processes an activation request from target A to target B. That is, a request for activation setting, which will be described later, is made. Next, in SH4, target B performs activation setting processing. This activation setting processing is processing to switch the bank (hereinafter referred to as bank) at the next startup (i.e., switch 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 processing sets the software stored in the second storage area 61b to be used at the next startup.

[0066] Next, in SH5, target B notifies target A that activation setting of target B is complete. Next, in SH6, activation setting processing is performed for target A. That is, in target A, the bank is switched at the next startup.

[0067] Next, in SH7, the next startup version is added to the version consistency table in target A. For example, the contents of pattern 3 are added to the version consistency table in FIG. 3A. Next, in SH8, target A notifies OTA master 11 that activation setting of target A and target B has been completed.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

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

[0074] Next, the SH 16 performs a process of transmitting the updated versions of the software of the targets A and B (that is, actual activation version information) from the target A to the OTA master 11.

[0075] 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.

[0076] <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 (that is, the actual activation version of the target A) from the target A to the version record table of the shared memory 19.

[0077] Next, at SH22, target A accesses the version record table in shared memory 19 and performs a process to check the updated software version of target B, that is, a process to read the updated software version of target B (i.e., the actual startup version of target B).

[0078] 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.

[0079] On the other hand, the SH 24 performs a process of writing the updated software version of the target B (that is, the actual activation version of the target B) from the target B to the version record table of the shared memory 19 .

[0080] Next, in SH25, target B accesses the version record table in shared memory 19 and performs processing to check the updated software version of target A. That is, processing is performed to obtain the updated software version of target A (i.e., the actual running version of target A) from the version record table in shared memory 19.

[0081] Then, in target B, the updated versions of both software of target A and target B stored in the version record table (i.e., both actual startup versions) are referenced in SH26 as compatible versions of both software of target A and target B stored in the version consistency table (e.g., both target startup versions of pattern 3).

[0082] Specifically, it checks whether the actual activation versions in the version record table match (i.e., whether they are consistent) with the target activation versions in pattern 3 in the version consistency table. In other words, it checks whether the versions (i.e., the actual activation versions) of both software after the update of target A and target B (i.e., used at startup) are consistent.

[0083] 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.

[0084] Then, in target A, similar to target B, the SH28 references the updated software versions of target A and target B stored in the version record table (i.e., both actual startup versions) as compatible versions of both software of target A and target B stored in the version consistency table (e.g., both target startup versions of pattern 3).

[0085] Specifically, it checks whether the actual activation versions in the version record table match (i.e., whether they are consistent) with the target activation versions in pattern 3 in the version consistency table. In other words, it checks whether the versions (i.e., the actual activation versions) of both software after the update of target A and target B (i.e., used at startup) are consistent.

[0086] 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.

[0087] [1-3-1. Procedures for handling abnormalities] <Example 1: When there is an abnormality in the overall process> In this example 1, a case where the version of the software of target A is not updated will be described, but the description of the same content as that described in FIG. 4 will be omitted or simplified.

[0088] 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 to add the next startup version to the version consistency table, similar to the process shown in SH7 in Fig. 4. Note that in this process, target A does not perform activation setting processes, resetting, or self-checking processes.

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

[0090] Consider the case where some abnormality occurs in target B and target B is reset. That is, consider the case where reset is performed using updated software (for example, software version 2.00) stored in the second storage area 61b. Note that the software before the update (for example, software version 1.00) is stored in the first storage area 61a.

[0091] In this case, target B performs a self-check and starts up using SH35 (i.e., secure boot is performed). In this case, the version of the software actually used at startup in target B is Ver. 2.00. Therefore, the actual startup version of target B is stored as Ver. 2.00 in the version record table.

[0092] As described above, the software of target A has not been activated or reset, so the version of the software of target A (i.e., the version actually activated) remains the same as before the update, for example, Ver. 1.00.

[0093] 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.

[0094] Then, SH37 performs a system synchronization check. As described above, the software version of target B (i.e., the actual startup version) is, for example, Ver. 2.00 after the update, while the software version of target A (i.e., the actual startup version) is, for example, Ver. 1.00. In other words, as is clear from the version consistency table and the target record table, there is a mismatch between the software versions of target A and target B (i.e., the actual startup versions of both software).

[0095] 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 SH38, processing is performed to make the versions of the software on target A and target B consistent. Specifically, the software on target A is upgraded. That is, processing is performed to update the version of the software used when starting target A (i.e., the actual startup version) to, for example, Ver. 2.00. For example, processing is performed to reset the Ver. 2.00 software on target A.

[0096] This ensures that the versions of the software on both target A and target B are consistent, making it possible to start the system. <Example 2: When there is an abnormality in the overall process> In this example 2, a case where the version of the software of target B is not updated will be described, but the description of the same content as that described in FIG. 4 will be omitted or simplified.

[0097] As shown in FIG. 7, the SH41 performs the same software update process as the SH1. Next, the SH42 sends an activation request from the OTA master 11 to the target A. When sending the activation request, the OTA master 11 sends the activation version (i.e., the target activation version) to the target A.

[0098] 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 (i.e., the target startup version) is, for example, the content shown in Figure 7.

[0099] Next, the SH43 processes an activation request from target A to target B. Next, in SH44, target B performs activation setting processing.

[0100] Next, the SH45 notifies target A from target B that activation setting for target B has been completed. Next, in SH46, target A performs activation setting processing.

[0101] Next, in SH47, target A adds the next startup version to the version consistency table. Next, the SH48 notifies the OTA master 11 from the target A that the activation settings for the target A and the target B have been completed.

[0102] Next, target A performs a reset process in SH49. Then, the SH50 performs a cure boot process. As a result, target A starts up using the updated Ver. 2.00 software. Therefore, the version record table stores the version of the software on the second side as the version of the software actually used at startup (i.e., the actual startup version).

[0103] On the other hand, in target B, the SH51 performs the reset process, but consider the case where the reset fails due to the occurrence of an abnormality or the like. In such a case, the SH52 performs a secure boot, but in that case, it starts up using the software on the first side, which is the previous software before the update.

[0104] Therefore, in such a case, the version of the software on the first side is stored in the version record table as the version of the software that is actually used at startup (that is, the actually started version).

[0105] Next, in target A and target B, the SH53 performs a system synchronization check process. As described above, this system synchronization check is a process of checking the consistency of the versions of the software in target A and target B.

[0106] Here, as is clear from the version record table, the software version of target B (i.e., the actual running version) is, for example, Ver. 1.00 before the update, while the software version of target A (i.e., the actual running version) is, for example, Ver. 2.00 after the update. In other words, as is clear from the version consistency table and the target record table, there is a mismatch between the software versions of target A and target B (i.e., the actual running versions of both software).

[0107] 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 SH54, processing is performed to ensure consistency between the versions of software on both target A and target B. Specifically, the software on target B is upgraded. In other words, processing is performed to update the software version used when starting target B (i.e., the actual startup version) to, for example, Ver. 2.00. For example, processing is performed to reset the Ver. 2.00 software on target B.

[0108] This ensures that the versions of the software on both target A and target B are consistent, making it possible to start the system. <Example 3: When there is an abnormality in the overall process> In this example 3, we will explain the case where the image on the second side of target A's non-volatile memory 49 is destroyed and the software version cannot be updated, but the explanation of the content similar to that described in Figure 4 will be omitted or simplified.

[0109] As shown in FIG. 8, the SH61 performs the same software update process as the SH1. Next, the SH 62 sends an activation request from the OTA master 11 to the target A. When sending the activation request, the OTA master 11 sends the activation version (i.e., the target activation version) to the target A.

[0110] Next, the SH63 processes the activation request from target A to target B. Next, in SH64, target B performs activation setting processing.

[0111] Next, the SH65 notifies target A from target B that activation setting for target B has been completed. Next, in SH66, target A performs activation setting processing.

[0112] Next, in SH67, target A adds the next startup version to the version consistency table. Next, the SH 68 notifies the OTA master 11 from the target A that the activation settings for the target A and the target B have been completed.

[0113] Next, target A performs a reset process using SH69, but consider the case where the reset fails due to an abnormality, etc. For example, consider the case where the image on the second side of the dual-sided memory is destroyed, causing the Ver. 2.00 software stored on the second side to be lost.

[0114] In such a case, the software on the first side, which is the previous software before the current update, is used for startup. Therefore, in such a case, the version of the software on the first side is stored in the version record table as the version of the software actually used at startup (i.e., the actual startup version).

[0115] Meanwhile, in target B, a reset process is performed by SH70, and a secure boot is performed by SH71. As a result, target B is booted using the updated Ver. 2.00 software. Therefore, the version record table stores the version of the software on the second side as the version of the software actually used at boot (i.e., the actual boot version).

[0116] Next, in target A and target B, the SH72 performs a system synchronization check process. As described above, this system synchronization check is a process of checking the consistency of the versions of the software in target A and target B.

[0117] Here, as is clear from the version record table, the software version of target A (i.e., the actual running version) is, for example, Ver. 1.00 before the update, while the software version of target B (i.e., the actual running version) is, for example, Ver. 2.00 after the update. In other words, as is clear from the version consistency table and the target record table, there is a mismatch between the software versions of target A and target B (i.e., the actual running versions of both software).

[0118] 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 SH73, processing is performed to ensure consistency between the versions of software on both targets A and B. Specifically, the software on target B is rolled back. In other words, processing is performed to return the version of the software used when starting target B (i.e., the actual startup version) to, for example, Ver. 1.00.

[0119] This ensures that the versions of the software on both target A and target B are consistent, making it possible to start the system. In addition, in the event that the image on the second side of the two-sided memory of target B is destroyed, version consistency can be achieved by rolling back the software on target A.

[0120] In addition, if the image on the second side of the two-sided memory of both target A and target B is destroyed, the version will be set to Ver. 1.00, so there will be version consistency. [1-4.Effects] According to the first embodiment, the following effects can be obtained.

[0121] (1a) In this first embodiment, even if the versions of the software used at startup (i.e., the actual startup version of the updated software actually used) at target A and target B in collaborative system 13 are inconsistent, by performing processing to maintain version consistency, it is possible to resolve problems caused by version inconsistency (e.g., problems such as inability to start collaborative system 13).

[0122] 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 or version upgrade 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, by selecting and performing software rollback or version upgrade processing for target A or target B that requires such processing, the problem caused by the version mismatch can be resolved.

[0123] (1b) In the 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 target A and target B, and recorded data (e.g., a version record table) indicating the version information of each piece of software after updating, which is used when starting up target A and target B. Therefore, by referring to the recorded data and the consistency data, it is possible to check the consistency of the versions. In other words, it is possible to confirm whether the versions are consistent.

[0124] (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.

[0125] Also, instead of the shared memory 19, the confirmation data storage unit 70 may be provided in either the target A or the target B. This version information includes the data in the version consistency table sent from the OTA master 11 (i.e., the target startup version), the version information of all new and old software on target A and target B, and the version information of the software actually used at startup (i.e., the actual startup version).

[0126] (1d) In this first embodiment, when checking the consistency of software versions between target A and target B, if the versions of the two software are inconsistent, it is possible to select and execute a process to roll back the new software (i.e., the newly updated software) or a process to upgrade the old software before the update to the new software.

[0127] For example, when software stored at an older time cannot be updated with software stored at a newer time, the software stored at the newer time may be rolled back.

[0128] [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 storage units 79, 89 correspond to the software storage units, the confirmation data storage unit 70 corresponds to the version storage unit, the confirmation units 75, 85 correspond to the confirmation units, and the processing units 77, 87 correspond to the processing units.

[0129] [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.

[0130] 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. 9, 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.

[0131] 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.

[0132] The version record table storage unit 91 is a memory that stores the versions of all software stored in the dual memory of target A (i.e., a memory that stores a version record table). As in the first embodiment, this version record table stores all software versions, and also stores data indicating which software version is the actual startup version that is actually used at startup. Note that this memory may be a rewritable nonvolatile memory.

[0133] 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.

[0134] Similar to target A, 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, target B includes a version record table storage unit 95.

[0135] The version record table storage unit 95 is a memory that stores the versions of all software stored in the dual memory of target B (i.e., a memory that stores a version record table). As in the first embodiment, this version record table stores all software versions, and also stores data indicating which software version is the actual startup version that is actually used at startup. Note that this memory may be a rewritable nonvolatile memory.

[0136] [2-2. Processing procedures in vehicle systems] Next, the processing procedure in the in-vehicle system 5 will be described. 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.

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

[0138] Next, the SH 82 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.

[0139] Furthermore, when an activation request is made, the OTA master 11 sends the activation version (i.e., the target activation version) to the target A. Next, the SH83 processes the activation request from target A to target B.

[0140] Next, in SH84, target B performs activation setting processing. Next, the SH85 notifies target A from target B that activation setting for target B has been completed.

[0141] Next, in the SH86, target A performs activation setting processing. Next, in SH87, target A adds the next startup version (ie, the target startup version) to the version consistency table.

[0142] Next, in the SH88, target A notifies the OTA master 11 that activation setting of target A and target B has been completed. Next, target A performs reset processing in SH89 and performs secure boot in SH90.

[0143] Similarly, in target B, the SH91 performs reset processing, and the SH92 performs secure boot. Next, in target A and target B, the SH93 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 in the first embodiment.

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

[0145] Next, the SH94 performs processing to transmit a command from the OTA master 11 to the target A to read the versions of the software of the target A and the target B.

[0146] Next, the SH95 performs processing to transmit 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 SH94 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 SH96 and SH97.

[0147] <System synchronization check procedure> Next, the procedure for checking system synchronization will be described. As shown in FIG. 11, target A checks the possibility of communication at SH 101.

[0148] If communication is possible, the SH 102 transmits a predetermined reply from target B to target A. Next, in target A, SH103 checks the response content.

[0149] Next, target A checks the version of target B's software using SH104. Next, in SH105, target B transmits to target A version information of the updated software of target B.

[0150] 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.

[0151] Then, in target A, SH106 compares the updated software versions of target A and target B stored in the version record table (i.e., actual startup versions) with the compatible versions of the software of target A and target B stored in the version consistency table (i.e., target startup versions). That is, it is checked whether the actual startup versions and the target startup versions match.

[0152] In addition, the target A transmits the updated software version of the target A to the target B at SH107. In this way, it is possible to check whether the versions of the software used when booting target A and target B (ie, the actual boot versions) are consistent.

[0153] Therefore, if both actual activation versions and both target activation versions match, it can be determined that both actual activation versions are consistent. On the other hand, if the two actual activation versions and the two target activation versions do not match, the two actual activation versions are not consistent, so a process can be selected and implemented to make the two actual activation versions consistent.

[0154] For example, if one live activation version is newer than the other live activation version, the newer software can be rolled back to align both live activation versions with the older software version, thereby making the two live activation versions consistent.

[0155] Also, for example, if one actual activation version is newer than the other actual activation version, the older software can be upgraded to align both actual activation versions with the newer software version, thereby making the two actual activation versions consistent.

[0156] [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 all versions of each software along with each actual activation version 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 there is inconsistency in the versions, the consistency of the versions can be ensured by rollback or version upgrade.

[0157] 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.

[0158] (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.

[0159] (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.

[0160] (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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] (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.

[0165] (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 includes a plurality of the electronic control devices, a software storage unit (79, 89) provided for each of the electronic control devices and having a first storage area and a second storage area capable of individually storing new and old versions of the software; a version storage unit (70) configured to store version information indicating the version of each piece of software stored in each storage area of each software storage unit, and to identify and store version information of each piece of software used when starting up each of the electronic control units from the version information; a verification unit (75, 85) configured to check the consistency of the versions of the software used when starting up each of the electronic control units 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

[0166] [Item 2] Item 1, a cooperative system according to the present invention, When there are a plurality of processes that can be performed by the processing unit, one of the plurality of processes can be selected. Collaborative system.

[0167] [Item 3] The cooperative system according to item 1 or 2, The version 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 version of each of the software in each of the electronic control units, the verification unit is configured to check the consistency of the versions based on the consistency data and version information of each piece of software actually used at startup, which is included in the recorded data; Collaborative system.

[0168] [Item 4] A cooperative system according to any one of items 1 to 3, When the versions of the software used at the time of the startup are inconsistent, the software stored at an older time is updated to the software stored at a newer time, or the software stored at the newer time is rolled back, and the software used at the time of the startup is selected. Collaborative system.

[0169] [Item 5] A cooperative system according to any one of items 1 to 4, and when the versions of the software used at the time of the startup are inconsistent and the software stored at an older time cannot be updated to the software stored at a newer time, the software stored at the newer time is rolled back. Collaborative system.

[0170] [Item 6] A cooperative system according to any one of items 1 to 5, A shared memory accessible by each of the electronic control devices is provided separately from each of the electronic control devices, and the shared memory is configured to store record data indicating the version information of each of the software of each of the electronic control devices and consistency data indicating the consistency of the version of each of the software of each of the electronic control devices. Collaborative system.

[0171] [Item 7] A cooperative system according to any one of items 1 to 5, Any one of the electronic control devices is configured to store record data indicating the version information of each of the software of each of the electronic control devices and consistency data indicating the consistency of the version of each of the software of each of the electronic control devices. Collaborative system.

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

[0173] 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, 75, 85...confirmation unit, 77, 87...processing unit, 79, 89...software storage 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 includes a plurality of the electronic control devices, a software storage unit (79, 89) provided for each of the electronic control devices, the software storage unit having a first storage area and a second storage area capable of individually storing new and old versions of the software; a version storage unit (70) configured to store version information indicating the version of each piece of software stored in each storage area of each software storage unit, and to identify and store version information of each piece of software used when starting up each of the electronic control units from the version information; a verification unit (75, 85) configured to check the consistency of the versions of the software used when starting up each of the electronic control units 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. 2. The cooperative system of claim 1, When there are a plurality of processes that can be performed by the processing unit, one of the plurality of processes can be selected. Collaborative system.

3. 2. The cooperative system of claim 1, The version 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 version of each of the software in each of the electronic control units, the verification unit is configured to check the consistency of the versions based on the consistency data and version information of each piece of software actually used at startup, which is included in the recorded data; Collaborative system.

4. 2. The cooperative system of claim 1, When the versions of the software used at the time of the startup are inconsistent, the software stored at an older time is updated to the software stored at a newer time, or the software stored at the newer time is rolled back, and the software used at the time of the startup is selected. Collaborative system.

5. 2. The cooperative system of claim 1, and when the versions of the software used at the time of the startup are inconsistent and the software stored at an older time cannot be updated to the software stored at a newer time, the software stored at the newer time is rolled back. Collaborative system.

6. 2. The cooperative system of claim 1, A shared memory accessible by each of the electronic control devices is provided separately from each of the electronic control devices, and the shared memory is configured to store record data indicating the version information of each of the software of each of the electronic control devices and consistency data indicating the consistency of the version of each of the software of each of the electronic control devices. Collaborative system.

7. 2. The cooperative system of claim 1, Any one of the electronic control devices is configured to store record data indicating the version information of each of the software of each of the electronic control devices and consistency data indicating the consistency of the version of each of the software of each of the electronic control devices. Collaborative system.

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

Images