COOPERATION SYSTEM AND PROCESSING SYSTEM

Abstract

A cooperation system (13) updates software of a plurality of electronic control units (15, 17) using software transmitted from an OTA master (11) that controls a software update of the plurality of electronic control units, the cooperation system comprising: the plurality of electronic control units; a software memory (79, 89) provided for each electronic control unit and having a first storage area and a second storage area configured to individually store software with a new version or software with an old version;a version storage (70) configured to store version information indicating the new version or the old version of each software stored in each storage area of each software storage, and to specify and store software version information used for starting each electronic control unit among the software version information; a confirmation unit (75, 85) configured to check version consistency of each software used when starting each electronic control unit based on consistency data indicating the version consistency; and a processing unit (77, 87) configured to execute a process for maintaining version consistency of each software based on a check result from the confirmation unit.

Description

[0001] The present disclosure relates to a technology such as a cooperative system in which multiple electronic control units cooperate with each other.

[0002] In the field of collaborative systems involving multiple electronic control units (ECUs), over-the-air (OTA) communication technology was previously known. This technology involves wireless communication of data with a central unit with server functions. Note that ECU is an abbreviation for Electronic Control Unit, and describes an electronic control unit, while OTA is an abbreviation for Over The Air, which describes "over the air."

[0003] With OTA technology, it is desirable that all software versions on all ECUs (i.e., target machines or computers) be consistent after the software update, and multiple target machines must be updated simultaneously. The ECU whose software is to be updated is a target machine. A version is known as a code, e.g., a number, that indicates whether a software product (e.g., a release) is new or old.

[0004] However, if the timing of the reset of the target machines is different due to the occurrence of an abnormality or the like, the software update may be completed for only one of the target machines.

[0005] As a result, the target machine may boot with a combination of the old and new versions. In such a case, the booted target machine may not be able to communicate with an OTA master or other target machines in the collaborative system because the versions do not match. The OTA master is a device that performs control related to OTA (e.g., control related to sending and receiving data, such as software with the collaborative system, or the like).

[0006] For example, if communication with other target machines in the collaborative system becomes impossible, various control operations performed in collaboration with the other target machines may become unexecutable. Furthermore, if communication with the OTA master is not possible, the target machine in the collaborative system cannot be rolled back in response to a rollback request from the OTA master.

[0007] Recently, for a system including the OTA master and multiple ECUs, various technologies for updating the software of each ECU have been proposed (see, for example, Patent Document 1, which will be described later). The technology described in Patent Document 1 updates the software of multiple ECUs sequentially for each memory type.

[0008] Patent document 1: JP 2022- 168 477 A

[0009] However, after a thorough investigation by the inventors, the following difficulties were identified with the conventional technology. The technology described in Patent Document 1 only updates the software of each ECU one by one, and therefore has the difficulty of not being able to take appropriate measures in the event of software version inconsistency. For example, this technology has the difficulty that if communication with the OTA master is not possible, the software version inconsistency cannot be resolved by a rollback request from the OTA master.

[0010] It is an object of the present disclosure to provide a technology capable of appropriately resolving inconsistencies in software versions of electronic control units in a cooperative system. (a) One aspect of the present disclosure relates to a collaborative system for updating software of multiple electronic control units using software transmitted from an OTA master that controls a software update of the multiple electronic control units, and the collaborative system. The collaborative system includes multiple electronic control units, a software memory, a version memory, a confirmation unit, and a processing unit.

[0011] The software memory is provided for each electronic control unit and has a first memory area and a second memory area configured to individually store software with a new version or software with an old version.

[0012] The version memory stores version information indicating the new version or the old version of each software stored in each storage area of each software storage unit, and specifies and stores software version information used for startup of each electronic control unit under the version information of the software.

[0013] The confirmation unit checks a version consistency of each software used at the start of each electronic ECU based on consistency data indicating the version consistency.

[0014] The processing unit executes a process to maintain version consistency of each software based on a check result from the confirmation unit. According to the configuration described above, even if the versions of the software actually used upon activation in each target machine (i.e., electronic control unit) in the collaborative system are inconsistent, processes are executed to maintain version consistency. This makes it possible to resolve difficulties caused by version inconsistency (e.g., difficulties such as the collaborative system's activation impossibility).

[0015] For example, even if communication between the OTA master and the cooperation system is not possible due to version inconsistency (e.g., if various processes of the software of the electronic control unit of the cooperation system cannot be executed in response to commands from the OTA master), it is possible to execute the process of maintaining version consistency based on the check result of the confirmation unit.

[0016] For example, for an electronic control unit that requires a software rollback or version update process, the software rollback or version update process can be selected and executed. This makes it possible to resolve the error caused by version inconsistencies.

[0017] (b) According to another aspect of the present disclosure, a processing system includes the above-described collaborative system and the OTA master. In this processing system, as described above, the process is executed to maintain consistency even if the software versions of each target machine in the collaborative system are inconsistent, so that it is possible to resolve the error caused by version inconsistency.

[0018] The objects, features and advantages of the present disclosure will become more apparent from the following detailed description with reference to the accompanying drawings in which like parts are designated by like reference numerals. Fig. 1 is an explanatory diagram showing an overall configuration of a network system according to a first embodiment. Fig. 2 shows a functional block diagram illustrating an in-vehicle system according to the first embodiment. Fig. Figure 3A shows a figure illustrating a version consistency table. Fig. Figure 3B shows a figure illustrating a version record table. Fig. Figure 3C shows an illustration of a target launch version. Fig. 4 is a sequence diagram illustrating an overall process in a normal state (ie, a normal sequence) according to the first embodiment. Fig. 5 is a sequence diagram illustrating a process of a system synchronization check in the normal state according to the first embodiment. Fig. 6 is a sequence diagram illustrating an overall process in an abnormal state in a first example according to the first embodiment. Fig. 7 is a sequence diagram illustrating an overall process in the abnormal state in a second example according to the first embodiment. Fig. 8 is a sequence diagram illustrating the overall process in the abnormal state in a third example according to the first embodiment. Fig. 9 shows a functional block diagram illustrating an in-vehicle system according to a second embodiment. Fig. 10 is a sequence diagram illustrating an overall process in the normal state (ie, the normal sequence) according to the second embodiment. Fig. 11 is a sequence diagram illustrating a process of a system synchronization check in the normal state according to the second embodiment.

[0019] Hereinafter, exemplary embodiments of the present disclosure are described with reference to the drawings. (1. First embodiment)

[0020] In the first embodiment, a technology for updating software of a plurality of electronic control units in a cooperative system using OTA technology is described. (1-1. Overall hardware configuration)

[0021] As in Fig. 1, a 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 cooperation system 13. The cooperation system 13 includes a plurality of electronic control units (or ECUs) 15, 17, and a shared memory 19. Each configuration will be described below. (Headquarters)

[0022] The control center 3 is capable of wirelessly communicating with the OTA master 11 of the in-vehicle system 5 via the network 7, e.g., the Internet, and functions as a server. The OTA master 11 is capable of wirelessly communicating via the external communication device 9. The control center 3 is configured to transmit software update data for the electronic control units 15 and 17 of the cooperation system 13 to the OTA master 11. (In-vehicle system)

[0023] The in-vehicle system 5 is a network installed in a vehicle (e.g., an automobile). In the first embodiment, an in-vehicle system installed in a vehicle is taken as an example, but the present disclosure is not limited to a vehicle.

[0024] The OTA master 11 and the cooperation system 13 are connected via a wired communication line 21 for transmitting and receiving data. The two electronic control units 15, 17 are connected via a wired communication line 23 for transmitting and receiving data. The electronic control units 15, 17 and the shared memory 19 are connected to each other via wired communication lines 25 and 27, respectively, for transmitting and receiving data. (OTA Master)

[0025] The OTA master 11 is a known electronic control unit including a CPU 31, a RAM 33, a ROM 35, a non-volatile memory (e.g., a non-volatile memory capable of data rewriting) 37, a communication device 39, and the like. The CPU 31, the RAM 33, the ROM 35, and the like constitute a computing unit 40 that performs calculations for various controls and the like. The computing unit 40 may be a known microcomputer (hereinafter referred to as a microcomputer).

[0026] The OTA master 11 performs wireless data communication with the control center 3 (e.g., receives software update data from the control center 3) and manages the OTA status. The OTA master 11 also has a function of controlling the software update process and updating the software of the electronic control units 15 and 17, which are the update targets of the cooperative system 13. Hereinafter, the electronic control unit 15, which is the update target, is also referred to as a target A, and the other electronic control unit 17, which is another update target, is also referred to as a target B. (cooperation system)

[0027] The cooperation system 13 has a function for updating the software of the electronic control units 15 and 17 using software transmitted from the OTA master 11 via the wired connection.

[0028] The target A of the collaborative system 13 includes a communication device 41, a CPU 43, a RAM 45, a ROM 47, and a non-volatile memory (e.g., a data-rewritable non-volatile memory) 49. The non-volatile memory 49 may be a dual-bank memory having a first storage area 49a and a second storage area 49b as areas for storing data. The CPU 43, the RAM 45, the ROM 47, and the like constitute a computing unit 51 that performs calculations for various controls and the like. The computing unit 51 may be a microcomputer.

[0029] Similarly, the target B includes a communication device 53, a CPU 55, a RAM 57, a ROM 59, and a non-volatile memory (e.g., a data-rewritable non-volatile memory) 61. The non-volatile memory 61 may be a two-bank memory having a first storage area 61a and a second storage area 61b as areas for storing data. The CPU 55, the RAM 57, the ROM 59, and the like constitute an arithmetic unit 63 that performs calculations for various controls and the like. The arithmetic unit 63 may be a microcomputer.

[0030] Note that data can be sent and received between the communication device 41 of the target A and the communication device 53 of the target B. In addition, data can be sent and received between the communication device 41 of the target A and the communication device 39 of the OTA master 11.

[0031] Furthermore, the shared memory 19 may be a non-volatile memory (e.g., a data-rewritable non-volatile memory). The shared memory 19 can be accessed from targets A and B. In other words, data can be written to the shared memory 19 by target A and target B, and read from the shared memory 19 by target A and target B.

[0032] The various functions of the OTA master 11, target A, and target B are implemented by CPUs 31, 43, and 55, which execute a program stored in a non-volatile, tangible storage medium. In this example, ROMs 35, 47, and 59 correspond to the non-volatile, tangible storage medium on which the program is stored. Furthermore, by executing this program, a process corresponding to the program is executed.

[0033] The number of microcomputers constituting the OTA master 11, the target A, and the target B may be one or more. Furthermore, the method for implementing the various functions of the OTA master 11, the target A, and the target B is not limited to software, and some or all of the elements may be implemented with one or more hardware elements. For example, when the above-described functions are implemented by an electronic circuit in the form of hardware, the electronic circuit may be implemented by a digital circuit with a large number of logic circuits, an analog circuit, or a combination thereof. (1-2. Functional configuration of cooperation system)

[0034] The following describes the functions and configurations of the cooperation system 13. As described in Fig. 2, the cooperation system 13 comprises a target A, a target B and a confirmation data store 70.

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

[0036] The software update unit 73 performs a process for updating the software received from the OTA master 11. That is, a process for updating the software stored in the non-volatile memory 49 is performed. In addition, this software update unit 73 also performs processes such as resetting Target A and secure booting, as described below.

[0037] As described later, the confirmation unit 75 has a function of checking the consistency of the version of each software actually used at the start of the target A and the target B, in other words, the consistency of the version of the software actually used at the start, among versions of both software stored in the version record table of the shared memory 19, based on consistency data indicating the consistency of the versions (ie, the consistency data stored in the version consistency table of the shared memory 19).

[0038] The processing unit 77 has a function of performing the version consistency maintenance process when, for example, there is a lack of consistency between the versions of the software of target A and target B based on the check result of the confirmation unit 75. For example, it has a function of selectively performing either a rollback or an update of the software of target A. As is known, rollback is a process of returning software or the like to the state before the update. Version update is a process of updating software to a newer version (e.g., the latest version).

[0039] The software memory 79 corresponds to the non-volatile memory 49 and has a function of storing (i.e., holding) updated software and the like. For example, the first storage area 49a (i.e., a first bank of the two-bank memory) of the non-volatile memory 49 of the target A stores software written in the past (e.g., the last time it was updated), and the second storage area 49b (i.e., a second bank of the two-bank memory) stores software written more recently (e.g., the most recently updated).

[0040] Similarly, the target B includes a communication unit 81, a software update unit 83, a confirmation unit 85, a processing unit 87, and a software memory 89. The communication unit 81 has a function of controlling the communication device 53 to send and receive data to and from the target A.

[0041] The software update unit 83 executes a process for updating the software received from the target A. That is, a process for updating the software stored in the non-volatile memory 49 is executed. In addition, this software update unit 83 also executes processes such as resetting the target A and secure booting, as described below.

[0042] As described later, the confirmation unit 85 has a function of checking the consistency of the version of each software actually used at the start of the target A and the target B, in other words, the consistency of the version of the software actually used at the start, among versions of both software stored in the version record table of the shared memory 19, based on consistency data indicating the consistency of the versions (ie, the consistency data stored in the version consistency table of the shared memory 19).

[0043] The processing unit 77 has a function of performing the version consistency maintenance process when, for example, there is inconsistency between the versions of the software of target A and target B based on the check result of the confirmation unit 75. For example, it has a function of selectively performing either a rollback or an update of the software of target A.

[0044] The software memory 89 corresponds to the non-volatile memory 61 and has a function of storing (i.e., holding) updated software and the like. For example, the first storage area 61a (i.e., a first bank of the two-bank memory) of the non-volatile memory 61 of the target B stores software written in the past (e.g., the last time it was updated), and the second storage area 61b (i.e., a second bank of the two-bank memory) stores software written more recently (e.g., the most recently updated).

[0045] The confirmation data storage 70 corresponds to the shared memory 19 and has a function of storing (ie, a function of holding) the version consistency table and the version record table. As shown in Fig. 3A, the version consistency table is a table (i.e., consistency data) indicating the consistency (i.e., the existence of consistency) of the software versions of both Target A and Target B. Furthermore, the existence of version consistency means that, as described below, at the startup time of the cooperation system 13, and thus at the startup time of Targets A and B, when both software programs are used, the cooperation system 13 can be activated without difficulty (i.e., normal activation is possible without communication abnormalities and the like).

[0046] For example, in the case of 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., if the versions match), it is determined that the versions are consistent. If, as in the case of Pattern 3, the software of Target A is Ver.2.00 and the software of Target B is Ver.2.00, it is determined that the versions are consistent. In other words, if both versions match each pattern, they are considered consistent.

[0047] As in Fig. As shown in Figure 3B, the version record table is a table (ie, record data) of version information indicating the version of each software used in Target A and Target B.

[0048] Specifically, in the version recording table of the first embodiment, for target A, the first storage area 49a of the nonvolatile memory 49 stores the version (e.g., Ver.1.00) of software written at the older time (e.g., at the last update). Furthermore, the second storage area 49b stores the version (e.g., Ver.2.00) of the software (e.g., the software updated this time) written more recently than the older time.

[0049] For Target B, however, the first storage area 61a of the non-volatile memory 61 stores the version (e.g., Ver.1.00) of software saved at the earlier time (e.g., the last update). Furthermore, the second storage area 61b stores the version (e.g., Ver.2.00) of the software (e.g., the software updated this time) written more recently than the earlier time.

[0050] The version record table also stores information about which memory area contains the software that will actually be used at the next boot of targets A and B (i.e., the software that will be used at the next boot time or boot time).

[0051] Fig. For example, Figure 3B shows that the software version enclosed in a double frame is actually used at the next boot. This means that the software version enclosed in the double frame is the software version actually used at boot.

[0052] However, for both software that is actually usable at the next startup, there may be cases where the versions are consistent, but there may also be cases where the versions are inconsistent. Therefore, a consistency check is performed, as described below. The version used at the next startup is referred to as the actual startup version. Note that this actual startup version is the identified version among the versions stored in the version record table.

[0053] As described below (i.e., if the updated software has been correctly reset, etc.), the OTA Master 11 would normally use the software version used at the next boot of the target A and the like (i.e., a target boot version: see Fig. 3C) to the target A, etc. This initial version is also referred to as the target initial version.

[0054] As described below, the confirmation units 75 and 85 can check (in other words, 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 70. In other words, it is possible to check whether the software versions (ie, the actual launch versions) of target A and target B are consistent, as shown in the version consistency table.

[0055] Based on the check results of the confirmation units 75, 85, if version consistency is not present between target A and target B, the processing units 77, 87 can execute the process to maintain version consistency (e.g., rollback or upgrade the software of target A or target B). This makes it possible to maintain version consistency. In other words, the versions of both software can be made consistent.

[0056] If the versions of the software in Goal A and Goal B are consistent, there is no need to run the process to maintain consistency. (1-3. Processing procedure in the in-vehicle system)

[0057] The processing procedure in the in-vehicle system 5 is described below. (1-3-1. Processing procedure in normal state)

[0058] An example of a normal sequence with version consistency is described below. (Overall processing procedure)

[0059] First, the overall processing procedure in the in-vehicle system 5 is described. As in Fig. As shown in Figure 4, the following software update process is first executed in SH1. The process is referred to as SH in the following.

[0060] Specifically, update data for the software of target A and target B is transmitted from the OTA master 11 to target A. Target A receives the update data for the software of targets A and B transmitted from the OTA master 11.

[0061] In Target A, the software update process is performed using the update data for the software of Target A, and the update data is received from the OTA master 11. Specifically, the update data is stored in the non-volatile memory 49. That is, the update data is downloaded and installed. For example, if the pre-update software is stored in the first storage area 49a of the non-volatile memory 49, the software to be updated this time is stored in the second storage area 49b.

[0062] Furthermore, target A transmits the software update data for target B received from the OTA master 11 to target B. At target B, the software update process is executed using the software update data for target B received from target A. Specifically, the update data is stored in the non-volatile memory 61. That is, the update data is downloaded and installed. For example, if the pre-update software is stored in the first storage area 61a of the non-volatile memory 61, the software to be updated this time is stored in the second storage area 61b.

[0063] Next, the OTA master 11 in SH2 sends an activation request to target A. This activation request includes an activation request sent not only to target A but also to target B via target A, as described below. The activation request is a request for activation settings, which are described below.

[0064] Likewise, the OTA master 11 transmits the start version to target A upon activation request. This start version is the consistent version for the next start. That is, the correct, consistent version for both target A and target B software. The start version (i.e., the target start version) is, for example, the version specified in Fig. 4 presented content adopted.

[0065] Next, in SH3, an activation request process is executed from target A to target B. That is, an activation setting request is made, as described below. Then, in SH4, target B executes the activation setting process. This activation setting process is a process for switching the bank (hereinafter referred to as bank) at the next startup (that is, switching the storage area of the software to be used). For example, in the process, in a case where software in the first storage area 61a is used before the software update, or in a case where software in the second storage area 61b is used after the update, the software stored in the second storage area 61b is set as the software to be used at the next startup.

[0066] Then, in SH5, Target B notifies Target A that Target B's activation setting is complete. Next, Target A performs the activation setting process in SH6. That is, in Target A, the bank will be switched at the next startup.

[0067] Then, target A in SH7 adds the next starting version to the version consistency table. For example, the contents of pattern 3 are added to the version consistency table of Fig. 3A added. Next, Target A in SH8 reports to OTA Master 11 that the activation setting for Target A and Target B is complete.

[0068] Target A then executes the reset process in SH9. In other words, the necessary process is executed at startup, such as a reboot. For example, at startup, a process is executed to select the software in the memory area where the bank switch was performed as the software to be used.

[0069] Subsequently, a process is executed in SH10 to check for any boot issues (i.e., a self-test) and to perform the boot (i.e., a secure boot process). This way, at the time of the reset, the updated software of Target A (i.e., the software in the memory area where the bank was switched) is used to perform the reset. That is, a boot process is executed using the updated software.

[0070] Similarly, in Target B, the reset process is executed in SH11 and the self-test process is executed in SH12. This reset uses the updated software from Target B (i.e., the software in the bank-switched memory area). This means that the updated software is used at boot time.

[0071] Subsequently, a system synchronization check process is executed in SH13 on Target A and Target B. This system synchronization check is a process for verifying the consistency of the software versions in Target A and B, as described below.

[0072] Next, the OTA master 11 in SH14 issues a process (ie, a command) to the target A to read the software versions of the targets A and B.

[0073] Then, the target A in SH15 accesses the shared memory 19 and executes the process to read the latest version after updating each software of target A and target B from the version record table. That is, the version information (ie, the actually activated version) of each software of target A and target B is read from the version record table.

[0074] Subsequently, a process is executed in SH16 in which target A transmits the updated versions (ie, the actual launch version information) of the software of targets A and B to the OTA master 11.

[0075] In this way, normal operation of the in-vehicle system 5 (e.g., normal start-up operation of the cooperation system 13) is possible in the sequence described above, since the versions of both software are consistent. (System synchronization check process procedure)

[0076] The system synchronization check procedure is described below. As described in Fig. 5, the target A executes a process in SH21 for writing the updated software version of the target A (ie, the actually activated version of the target A) into the version record table of the shared memory 19.

[0077] Then, in SH22, the target A accesses the version record table in the shared memory 19 and executes the process of checking the updated software version of target B, that is, a process of reading the updated software version of target B (that is, the actual boot version of target B).

[0078] Here, in case that the updated software version of target B in SH23 has not been written into the version record table of the shared memory 19, a process is performed to wait a predetermined time.

[0079] On the other hand, in SH24, the target B executes a process of writing the updated software version of the target B (ie, the actually activated version of the target B) into the version record table of the shared memory 19.

[0080] Next, the target B in SH25 accesses the version record table in the shared memory 19 and executes the process to check the version of the updated software of target A. That is, a process is executed to obtain the updated software version of target A (ie, the actual boot version of target A) from the version record table in the shared memory 19.

[0081] Subsequently, in SH26, Target B refers to the updated versions of both software of Target A and Target B stored in the version record table (i.e., both actual launch versions) as the consistent versions of both software of Target A and Target B stored in the version consistency table (e.g., both target launch versions of Pattern 3).

[0082] Specifically, it checks whether both actual launch versions in the version record table match (i.e., whether they are consistent) with both target launch versions of Pattern 3 in the version consistency table. This means that it checks whether the updated software versions (i.e., the actual launch versions) of both targets A and B (i.e., the versions used at launch) match each other.

[0083] On the other hand, in SH27, the target A accesses the version record table in the shared memory 19 and executes the process to check the version of the updated software of target B. That is, a process is executed to obtain the updated software version information of target B from the version record table in the shared memory 19.

[0084] Similar to Target B, Target B subsequently refers in SH28 to the updated versions of both software of Target A and Target B stored in the version record table (i.e., both actual launch versions) as the consistent versions of both software of Target A and Target B stored in the version consistency table (e.g., both target launch versions of Pattern 3).

[0085] Specifically, it checks whether the two actual launch versions in the version record table match (i.e., whether they are consistent) with the two target launch versions of Pattern 3 in the version consistency table. That is, it checks whether the updated software versions (i.e., the actual launch versions) of both targets A and B (i.e., the versions used at launch) match each other.

[0086] If the updated software versions on Targets A and B are consistent, no rollback or the like (as described below) is required, and the next process in the normal state is executed. For example, various control processes and the like that are normally performed by Target A and Target B in cooperation with each other are executed. (1-3-1. Processing procedure in case of abnormality occurrence) (First example: case of abnormality occurrence in the overall process)

[0087] In this first example, a case is described where the version of the software of target A is not updated, but the description of the same contents as in Fig. 4 is omitted or simplified.

[0088] As in Fig. 6, the OTA master 11 sends an activation request to the target A in SH31. Then, the target A executes a process in S32 to add the next boot version to the version consistency table, similar to that in SH7 of Fig. 4. This process assumes that the activation setting process, the reset process, and the self-test process are not executed by Target A.

[0089] Then, in SH33, target A sends the activation request to target B. Following this, in SH34, target B executes the activation setting for itself.

[0090] Next, assume a case where the reset of target B occurs after some abnormality has occurred in target B. That is, assume a case where the reset is performed using the updated software (e.g., software version 2.00) stored in the second storage area 61b. The first storage area 61a stores the software before the update (e.g., software version 1.00).

[0091] In this case, Target B performs the self-test and boots in SH35 (i.e., it performs a secure boot). In this case, the actual software version used when Target B boots is Ver.2.00. Therefore, the actual or actual boot version of Target B is stored in the version record table as Ver.2.00.

[0092] Since, as described above, no activation or reset of the software in Target A has occurred, the software version of Target A (i.e., the actually activated version) remains the same as before the current update, e.g., Ver.1.00.

[0093] Furthermore, even after a predetermined time has elapsed, Target A does not receive data transmission from Target B indicating the completion of the activation setting. Therefore, Target A does not execute the process such as the activation setting. Consequently, Target A sends a message to OTA Master 11 in SH36, indicating that the activation setting has failed in Target A and Target B.

[0094] The system synchronization check then runs in SH37. As described above, the software version of Target B (i.e., the actual or current activation version) after the update is, for example, Ver.2.00, while the software version of Target A (i.e., the actually activated version) is, for example, Ver.1.00. In other words, as can be seen from the version consistency table and the target record table, there is no consistency between the software versions of Target A and Target B (i.e., the current activation versions of both software).

[0095] Accordingly, if the version combination does not match in this way, it is determined that the system startup of the cooperation system 13 is impossible. In such a case, as shown in SH38, a process is executed to ensure consistency between the versions of the software in target A and B. Specifically, an upgrade of the software of target A is performed. That is, the version (i.e., the actual startup version) of the software used when starting target A is upgraded to Ver.2.00, for example. For example, a process is executed to roll back the Ver.2.00 software of target A.

[0096] This way, the software versions of Target A and Target B become consistent. Therefore, it is possible to start the system. (Second example: case of abnormality occurrence in the overall process)

[0097] In this second example, a case is described where the version of the software of target B is not updated, but the description of the same contents as in Fig. 4 is omitted or simplified.

[0098] As in Fig. As shown in Figure 7, the same software update process as in SH1 is performed in SH41. Subsequently, in SH42, the OTA master 11 transmits the activation request to the target A. When the activation request is made, the OTA master 11 also transmits the launch version (i.e., the target launch version) to the target A.

[0099] This start version is the consistent version for the next start. This means that the version is the correct and consistent software version for both Target A and Target B. The start version (i.e. the target start version) is, for example, the version specified in Fig. 7 presented content adopted.

[0100] Then, target A executes the activation request process on target B in SH43. Next, target B executes the activation setting process in SH44.

[0101] Following this, in SH45, Target B notifies Target A of the completion of Target B's activation setting. Next, in SH46, Target A executes the activation setting process.

[0102] Target A then adds the next launch version to the version consistency table in SH47. Next, Target A reports the completion of the activation settings for Target A and Target B to OTA Master 11 in SH48.

[0103] Target A then performs the reset process in SH49. Then, a secure boot process is performed in SH50. As a result, Target A boots using the updated software version 2.00. Therefore, the software version in the second bank in the version record table is stored as the version (i.e., the actual boot version) of the software actually used at boot.

[0104] On the other hand, SH51 assumes a case where target B executes the reset process and the reset fails due to an abnormality or the like. In such a case, SH52 performs a secure boot process. Then, booting is performed using the software of the first bank, where the software is the previous software before the current update.

[0105] Therefore, in such a case, the version of the software of the first bank is stored in the version record table as the version (i.e., the actual startup version) of the software actually used at startup.

[0106] Subsequently, a system synchronization check process is executed in SH53 on Target A and Target B. This system synchronization check, as described above, is a process for checking the consistency of the software versions in Targets A and B.

[0107] As shown in the version record table, the software version of Target B (i.e., the actual activation version) before the update is, for example, Ver.1.00, while the software version of Target A (i.e., the actually activated version) after the update is, for example, Ver.2.00. In other words, as shown in the version consistency table and the target record table, there is no consistency between the software versions of Target A and Target B (i.e., the actual activation versions of both software).

[0108] Accordingly, if the version combination does not match in this way, it is determined that the system startup of the cooperation system 13 is impossible. In such a case, as shown in SH54, a process is executed to ensure consistency between the versions of the software in target A and B. Specifically, an upgrade of the software of target B is performed. That is, the version (i.e., the actual startup version) of the software used when starting target B is upgraded to Ver.2.00, for example. For example, a process is executed to roll back the Ver.2.00 software of target B.

[0109] This way, the software versions of Target A and Target B become consistent. Therefore, it is possible to start the system. (Third example: case of abnormality occurrence in the overall process)

[0110] In this third example, a case is described in which images in the second bank of the non-volatile memory 49 of the target A are damaged, where the version of the software of the target A is not updated, but the description of the same content as in Fig. 4 is omitted or simplified.

[0111] As in Fig. As shown in Figure 8, the same software update process as in SH1 is performed in SH61. Subsequently, in SH62, the OTA master 11 transmits the activation request to the target A. When the activation request is made, the OTA master 11 also transmits the launch version (i.e., the target launch version) to the target A.

[0112] Then, target A executes the activation request process on target B in SH63. Next, target B executes the activation setting process in SH64.

[0113] Following this, in SH65, Target B notifies Target A of the completion of Target B's activation setting. Next, in SH66, Target A executes the activation setting process.

[0114] Target A then adds the next launch version to the version consistency table in SH67. Next, Target A reports to OTA Master 11 in SH68 that the activation setup for Target A and Target B is complete.

[0115] Next, SH69 assumes a case where target A executes the reset process and the reset fails due to an abnormality or something similar. For example, in this case, the image in the second bank of the dual-bank memory is corrupted, and the Ver.2.00 software stored in the second bank is lost.

[0116] In such a case, booting is performed using the software of the first bank, which is the previous software before the current update. Therefore, in such a case, the version of the software of the first bank is stored in the version record table as the version (i.e., the actual boot version) of the software actually used at boot.

[0117] On the other hand, in Target B, the reset process is performed in SH70 and the secure boot process is performed in SH71. As a result, in Target B, booting is performed using the updated Ver.2.00 software. Therefore, the second bank's software version is stored in the version record table as the version (i.e., the actual boot version) of the software actually used at boot.

[0118] Subsequently, a system synchronization check process is executed in SH72 on Target A and Target B. This system synchronization check is, as described above, a process for checking the consistency of the software versions in Targets A and B.

[0119] As shown in the version record table, the software version of Target A (i.e., the actual activation version) before the upgrade is, for example, Ver.1.00, while the software version of Target B (i.e., the actually activated version) after the upgrade is, for example, Ver.2.00. In other words, as shown in the version consistency table and the target record table, there is no consistency between the software versions of Target A and Target B (i.e., the actual activation versions of both software).

[0120] Accordingly, if the version combination does not match in this way, it is determined that the system startup of the cooperation system 13 is not possible. In such a case, as shown in SH73, a process is executed to ensure consistency between the versions of the software in target A and B. Specifically, a rollback of the software of target B is performed. That is, the version (i.e., the actual startup version) of the software used when starting target B is reset to, for example, Ver.1.00.

[0121] In this way, the software versions of Target A and Target B become consistent. Therefore, it is possible to boot the system. Regardless, in a case where the image in the second bank of Target B's dual-bank memory is corrupted, it is possible to achieve version consistency by rolling back the software of Target A.

[0122] In addition, in case the image in the second bank of the dual-bank memory is corrupted by both Target A and Target B, the versions are set to Ver.1.00 so that the versions become consistent. (1-4. Effects)

[0123] According to the present first embodiment, the following effects can be achieved.

[0124] (1a) According to the first embodiment, in the targets A and B of the collaboration system 13, even if the versions of each software actually used at the time of activation (ie, the actual launch versions of the software actually used after the update) are inconsistent, the processes are executed to maintain version consistency. This makes it possible to resolve difficulties caused by the version inconsistency (e.g., difficulties such as the activation impossibility state of the collaboration system 13).

[0125] For example, even if communication between the OTA master 11 and the collaboration system 13 is not possible due to version inconsistency, and therefore the software of target A or target B of the collaboration system 13 cannot be rolled back or upgraded by commands from the OTA master 11, the processes for maintaining version consistency can be executed based on the check results by the confirmation units 75 and 85. By selecting and executing the software rollback or version upgrade process for target A or target B requiring such processing, difficulties caused by the version inconsistency, for example, can be resolved.

[0126] (1b) In the first embodiment, the confirmation data storage 70 stores the consistency data (e.g., the version consistency table) indicating the consistency of the versions of the software of target A and target B, and record data (e.g., the version record table) indicating the version information after update of each software used when starting target A and target B. Thus, the version consistency can be verified by referencing the record data with the consistency data. That is, it is possible to check whether the versions are consistent.

[0127] (1c) In the first embodiment, the shared memory 19 accessible to target A and target B can be used as the confirmation data memory 70. Therefore, version information of the software of targets A and B can be written from targets A and B into the shared memory 19. Furthermore, the version information of the software of targets A and B can be read from the shared memory 19 to targets A and B.

[0128] Instead of the shared memory 19, the confirmation data memory 70 may also be present in either the target A or the target B. This version information includes data from the version consistency table transmitted by the OTA master 11 (ie, the target launch version), version information for all new and old software of the targets A and B, and version information for the software actually used at launch (ie, the actual launch version).

[0129] (1d) In the present first embodiment, when the software version consistency of the targets A and B is checked and the versions of both software do not match, it is possible to selectively execute the process of rolling back the new software (ie, the newly updated software) or the process of upgrading the old software that has not been updated to the new software.

[0130] For example, if software saved at an earlier time cannot be updated with software saved at a more recent time, the software saved at the more recent time can be rolled back. (1-5. Correspondence relationship)

[0131] The relationship between the first embodiment and the present disclosure is described below. The in-vehicle system 5 corresponds to a processing system, the OTA master 11 corresponds to an OTA master, the cooperation system 13 corresponds to a cooperation system, the electronic control units 15, 17 of the target A and the target B correspond to an electronic control unit, the software memories 79, 89 correspond to a software memory, the confirmation data memory 70 corresponds to a version memory, the confirmation units 75, 85 correspond to a confirmation unit, and the processing units 77, 87 correspond to a processing unit. (2. Second embodiment)

[0132] A basic configuration of a second embodiment is similar to that of the first embodiment, so the following mainly describes a difference from the first embodiment. Note that configurations similar to those in the first embodiment are denoted by the same reference numerals and refer to the previous descriptions.

[0133] In the second embodiment, the version consistency table and the like are not stored in the shared memory, but, for example, in Target A. The following description focuses on the differences from the first embodiment. (2-1. Configuration)

[0134] As in Fig. As shown in Figure 9, the in-vehicle system 5 in the second embodiment includes, similarly to the first embodiment, the OTA master 11 and the cooperation system 13. The cooperation system 13 includes the target A and the target B.

[0135] Similar to the first embodiment, the target A includes the communication unit 71, the software update unit 73, the confirmation unit 75, the processing unit 77, and the software memory 79. In addition, the target A includes a version recording table memory 91 and a version consistency table memory 93.

[0136] The version record table memory 91 is a memory that stores the versions of all software versions stored in the dual-bank memory of Target A (i.e., a memory that stores the version record table). Similar to the first embodiment, all software versions are stored in the version record table. In addition, data indicating which software version is the actual boot version actually used at boot is also stored. The memory may be a rewritable non-volatile memory.

[0137] The version consistency table memory 93 is a memory that stores the version consistency table described above. This memory may be a rewritable non-volatile memory, but may also be used jointly with the version record table memory 91.

[0138] Similar to Target A, Target B includes the communication unit 81, the software update unit 83, the confirmation unit 85, the processing unit 87, and the software memory 89. In addition, Target B includes a version record table memory 95.

[0139] The version record table memory 95 is a memory that stores the versions of all software versions stored in the dual-bank memory of Target B (i.e., a memory that stores the version record table). Similar to the first embodiment, all software versions are stored in the version record table. In addition, data indicating which software version is the actual boot version actually used at boot is also stored. The memory may be a rewritable non-volatile memory. (2-2. Processing procedure in in-vehicle system)

[0140] The following describes the processing procedure in the in-vehicle system 5. As an example, a normal sequence is described here for the case where the software versions are consistent, with descriptions similar to those in the first embodiment omitted or simplified. (Overall processing procedure)

[0141] First, the overall processing procedure in the in-vehicle system 5 is described. As in Fig. 10, first, a software update process similar to that of the first embodiment is executed in SH81.

[0142] Then, the OTA master 11 in SH82 sends the activation request to destination A. This activation request includes an activation request that is sent not only to destination A but also to destination B via destination A.

[0143] When the activation request is made, the OTA master 11 also sends the launch version (ie, the target launch version) to the target A. Then, the target A executes the activation request process on the target B in SH83.

[0144] Target B then performs the activation setting process in SH84. In SH85, Target B informs Target A of the completion of Target B's activation setting.

[0145] Next, Target A performs the activation setting process in SH86. Next, Target A adds the next launch version (i.e., the target launch version) to the version consistency table in SH87.

[0146] Then, in SH88, Target A notifies OTA Master 11 of the completion of the activation setting for Target A and Target B. Following this, Target A performs the reset process in SH89 and the secure boot process in SH90.

[0147] Similarly, in Target B, the reset process is executed in SH91 and the secure boot process is executed in SH92. Subsequently, a system synchronization check process is executed in SH93 in Target A and Target B. This system synchronization check, similar to the first embodiment, is a process for checking the consistency of the software versions in Targets A and B.

[0148] As described below (see e.g. Fig. 11), Target A can obtain Target B's software version information when the system synchronization check is performed normally.

[0149] The OTA master 11 then issues a process in SH94 to send commands to target A to read the software versions of targets A and B.

[0150] Following this, a process is executed in SH95 in which the target A transmits the current or actual versions of each software of target A and B to the OTA master 11. Further, when the OTA master 11 executes the process in SH94 on the target A to read the software versions of the targets A and B, the target B can transmit the actual software version of the target B read in SH96 and SH97 from the version recording table memory 95. (System synchronization check process procedure)

[0151] The system synchronization check process procedure is described below. As described in Fig.As shown in Figure 11, target A checks the communication possibility in SH101.

[0152] If communication is possible, a predetermined response is sent from destination B to destination A in SH102. Destination A then confirms the response contents in SH103.

[0153] Target A then checks the software version of Target B in SH104. Following this, Target B transmits version information of the updated software from Target B to Target A in SH105.

[0154] This allows Target A to receive the updated software version of Target B and write the updated software versions of Target A and Target B to the version record table.

[0155] Then, in SH106, Target A compares the updated versions of both Target A and Target B software stored in the version record table (i.e., the actual launch versions) with the consistent versions of both Target A and Target B software stored in the version consistency table (i.e., the target launch versions). That is, it checks whether both actual launch versions match both target launch versions.

[0156] In addition, in SH107, Target A transmits the updated software version of Target A to Target B. In this way, it can be verified whether the versions (ie, the actual boot versions) of the software used at boot time of Target A and Target B are consistent.

[0157] Consequently, if both actual start versions and both target start versions match, it can be determined that both actual start versions are consistent. Conversely, if both actual start versions do not match both target start versions, both actual start versions are inconsistent. Therefore, a process can be selected and implemented to make the two actual start versions consistent.

[0158] For example, if one actual launch version is newer than the other, the newer software can be rolled back to align both actual launch versions with the older software version. This makes it possible to make the two actual launch versions consistent.

[0159] Furthermore, if one actual launch version is older than the other, the older software can be updated to align both actual launch versions with the newer software version. This makes it possible to make the two actual launch versions consistent. (2-3. Effects)

[0160] The present second embodiment produces a similar effect to the first embodiment. Furthermore, in the present second embodiment, it is not necessary to use the shared memory 19 as in the first embodiment. That is, all versions of each software are stored, along with each actual activation version, in each version record table storage 91, 95 of the target A and target B, respectively. By storing the version consistency table in the version consistency table storage 93 of the target A, it is possible to check the consistency of the software versions. Furthermore, when version consistency is inconsistent, version consistency can be ensured through rollback or version upgrade. (3. Further embodiments)

[0161] Although the embodiment of the present disclosure is described above, the present disclosure is not limited to the above embodiment but can be modified in various ways.

[0162] (3a) In the embodiments, the cooperation system includes two electronic control units for target A and target B, but the number of electronic control units is not limited. For example, there may be three or more cooperation systems.

[0163] (3b) In the above embodiment, target A sends software update data to target B. However, software update data may be sent to target A and target B by the OTA master.

[0164] (3c) The process of the cooperation system and the processing system (e.g., in-vehicle system) and the methods described in the present disclosure are realizable by a dedicated computer provided by configuring a processor and a memory programmed to perform one or more functions embodied by a computer program.

[0165] The process of the cooperation system, the processing system (e.g., in-vehicle system), and the associated method described in the present disclosure is implementable by a dedicated computer having a processor implemented by one or more dedicated hardware logic circuits.

[0166] Alternatively, the process of the cooperation system and the processing system (e.g., in-vehicle system) and the associated method described in the present disclosure is implementable by one or more dedicated computers configured by a combination of a processor and a memory programmed to perform one or more functions, and a processor configured by one or more hardware logic circuits.

[0167] The computer program may be stored on a computer-readable, non-transitory, tangible storage medium as computer-executable instructions. The technology for implementing the functions of each unit in the collaboration system and the processing system (e.g., in-vehicle system) does not necessarily have to involve software, and all of the functions can be implemented using one or more hardware circuits.

[0168] (3d) The cooperation system and the processing system (e.g., in-vehicle system) of the present disclosure described above are also realizable in various forms, including, in addition to the cooperation system and the processing system, a configuration including the cooperation system and the processing system as components, a program for causing a computer in the cooperation system and the processing system to operate, a non-volatile tangible storage medium such as a semiconductor memory on which the program is stored, and a control method, and the like.

[0169] (3e) Multiple functions of an element in each embodiment can be realized by multiple elements, or one function of an element can be realized by multiple elements. Moreover, multiple functions of multiple components can be realized by one component, or a single function realized by multiple components can be realized by one component. Part of the configuration according to the embodiment described above may be omitted. At least part of the configuration of each embodiment may be supplemented or replaced by the configuration of another embodiment. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] JP 2022

[0008] JP 168 477 A

[0008]

Claims

[1] A cooperation system (13) for updating software of a plurality of electronic control units (15, 17) using software transmitted by an over-the-air (OTA) master (11) controlling a software update of the plurality of electronic control units, the cooperation system comprising: - the several electronic control units; - a software memory (79, 89) provided for each electronic control unit and having a first memory area and a second memory area configured to individually store software with a new version or software with an old version; - a version store (70) configured to - to store version information indicating the new version or the old version of each software stored in each storage area of each software memory, and - To specify and store software version information used for starting each electronic control unit under the software version information; - a confirmation unit (75, 85) configured to check a version consistency of each software used when starting each electronic control unit based on consistency data indicating the version consistency; and - a processing unit (77, 87) configured to execute a process for maintaining version consistency of each software based on a check result from the confirmation unit. [2] The cooperation system according to claim 1, wherein, when the process executable by the processing unit is a plurality of processes, one of the plurality of processes is selectable. [3] Cooperation system according to claim 1 or 2, wherein - the version memory stores record data indicating the software version information of each electronic control unit and consistency data indicating the version consistency of each software in each electronic control unit, and - the confirmation unit is configured to check the version consistency based on the version information of each software actually used at startup and the consistency data in the recording data. [4] A cooperation system according to any one of claims 1 to 3, wherein, when the version of each software used at startup is inconsistent, an update of the software stored at an older time to the software stored at a more recent time than the software used at startup or a rollback of the software stored at the more recent time is selectable. [5] The cooperation system according to any one of claims 1 to 4, wherein in a case where the version of each software used at startup is inconsistent, when updating the software stored at an older time to the software stored at a more recent time is not possible, rollback of the software stored at the more recent time is performed. [6] Cooperation system according to one of claims 1 to 5, comprising: - a common memory which is not provided in each electronic control unit and which can be accessed by each electronic control unit, - the common memory stores record data indicating the software version information of each electronic control unit and consistency data indicating the version consistency of each software in each electronic control unit. [7] The cooperation system according to any one of claims 1 to 5, wherein record data indicating the software version information of each electronic control unit and the consistency data indicating the version consistency of the software in each electronic control unit are stored in any one of the plurality of electronic control units. [8] Processing system (5), comprising: - the cooperation system according to one of claims 1 to 7; and - the OTA master.

Images