Information processing apparatus

Abstract

To determine the consistency of associations between software versions.SOLUTION: A vehicle includes a plurality of slave ECUs on each of which software is to be updated. The slave ECU stores a version number and a consistency table. The version number is a numerical value indicating a version of software, and increases as the software is updated. The consistency table specifies combinations of versions numbers for the slave ECUs. The slave ECU acquires, from the slave ECUs, version numbers corresponding to current software stored in the slave ECU (S11). When one or more acquired version numbers are smaller than the version numbers specified in the consistency table, the slave ECU determines that the association between the software versions for the slave ECUs does not maintain consistency (S12).SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an information processing device. [Background technology]

[0002] The update system includes a server and a vehicle. The vehicle includes a master ECU and a plurality of slave ECUs. The master ECU executes software updates for the plurality of slave ECUs. Specifically, the master ECU downloads new software from the server. Then, the master ECU installs the new software in the slave ECUs. Then, the master ECU instructs the slave ECUs to activate the new software. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2023-053358 A Summary of the Invention [Problem to be solved by the invention]

[0004] In a vehicle such as that described in Patent Document 1, for example, the data of some ECUs may be initialized, causing the software of the ECUs to be downgraded. In this case, the correspondence between the software versions of the multiple ECUs may become inconsistent. The update system described in Patent Document 1 does not pay any attention to the fact that the correspondence between the software versions of the multiple ECUs becomes inconsistent as described above. [Means for solving the problem]

[0005] An information processing device for solving the above problem includes a plurality of ECUs whose software is updated, each of the plurality of ECUs stores the software of the ECU, a version number corresponding to the software, and a consistency table corresponding to the software, wherein the version number is a numerical value indicating the version of the software corresponding to the version number and is a numerical value that increases each time the software corresponding to the version number is updated, and the consistency table specifies combinations of the version numbers for the plurality of ECUs that indicate the correspondence of software versions when software is normally stored in the plurality of ECUs, and executes the following steps: acquiring from the plurality of ECUs the version numbers corresponding to the current software stored in the ECU; comparing the acquired plurality of version numbers with the plurality of version numbers specified in the consistency table; and determining that the correspondence of software versions for the plurality of ECUs is not consistent if one or more of the acquired plurality of version numbers is smaller than the version number specified in the consistency table. Effect of the Invention

[0006] In the above configuration, if the software of an ECU is downgraded, the version number after downgrading will be smaller than the version number before downgrading. According to the above configuration, if one or more of the acquired version numbers is smaller than the version number specified in the consistency table, that is, if the software of one or more ECUs is downgraded, it is determined that the correspondence between the software versions is inconsistent. As a result, even if the correspondence between the software versions of multiple ECUs becomes inconsistent due to, for example, downgrading the software of one or more ECUs, it can be determined that the correspondence is inconsistent. [Brief description of the drawings]

[0007] [Figure 1]FIG. 1 is a schematic diagram of an update system. [Diagram 2] FIG. 2 is an explanatory diagram showing changes in version numbers. [Diagram 3] FIG. 3 is a sequence diagram showing the consistency check control. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] <Outline of update system configuration> An embodiment of the present invention will now be described with reference to Figures 1 to 3. First, a schematic configuration of an update system US will be described.

[0009] As shown in Fig. 1, the update system US includes a plurality of vehicles 100. The vehicles 100 are, for example, automobiles owned by users. Note that Fig. 1 illustrates only one representative vehicle 100. In this embodiment, the vehicle 100 is a vehicle equipped with an engine and a motor generator as a driving source, that is, a so-called hybrid vehicle.

[0010] The vehicle 100 includes a master ECU 10, multiple slave ECUs 20, a DCM 50, a first external bus 61, a second external bus 62, and a display 71. The first external bus 61 connects the master ECU 10 and the DCM 50 so that they can communicate with each other. The second external bus 62 connects the master ECU 10 and the multiple slave ECUs 20 so that they can communicate with each other. Note that "ECU" is an abbreviation for Electronic Control Unit. Also, "DCM" is an abbreviation for Data Communication Module.

[0011] The master ECU 10 manages software updates in the slave ECU 20. The master ECU 10 includes an execution device 11 and a storage device 12. An example of the execution device 11 is a CPU. The storage device 12 includes a read-only ROM, a readable and writable volatile RAM, and a readable and writable non-volatile storage. The storage device 12 stores various programs and various data in advance. The execution device 11 executes the programs stored in the storage device 12 to realize various processes described later. The master ECU 10 can wirelessly communicate with devices outside the vehicle 100 via the DCM 50 and the communication network NW.

[0012] The slave ECU 20 is managed by the master ECU 10 for software updates. The slave ECU 20 includes an execution device 21 and a storage device 22. An example of the execution device 21 is a CPU. The storage device 22 includes a ROM, a RAM, and a storage. The storage device 22 stores various programs and various data in advance. Specifically, the storage device 22 stores a version number NV and a matching table TM in advance as various data. The version number NV and the matching table TM will be described in detail later. The execution device 21 executes the programs stored in the storage device 22 to realize various processes described later. In this embodiment, the vehicle 100 includes four slave ECUs 20. Examples of the four slave ECUs 20 are a hybrid ECU, an engine ECU, a motor ECU, and a battery ECU. In this specification, when a plurality of slave ECUs 20 are collectively described, they are simply referred to as slave ECUs 20. In addition, when the multiple slave ECUs 20 are described separately, they are called a first slave ECU 20A, a second slave ECU 20B, a third slave ECU 20C, and a fourth slave ECU 20D. In this embodiment, the multiple slave ECUs 20 correspond to multiple ECUs whose software is updated. Therefore, the multiple slave ECUs 20 constitute an information processing device.

[0013] The display 71 is capable of displaying various types of information. In this embodiment, the display 71 is located near the driver's seat of the vehicle 100. The master ECU 10 outputs a control signal to the display 71 to cause the display 71 to display various types of information.

[0014] As shown in FIG. 1, the update system US includes a server 200. The server 200 includes an execution device 210, a storage device 220, and a communication device 230. The communication device 230 is capable of communicating with devices external to the server 200 via a communication network NW. An example of the execution device 210 is a CPU. The storage device 220 includes a ROM, a RAM, and storage. The storage device 220 stores various programs and various data in advance. The execution device 210 executes the programs stored in the storage device 220 to realize various processes described below.

[0015] <Update control> Next, a description will be given of update control executed by the server 200 and the master ECU 10 of the vehicle 100. The update control is control related to software updates in the slave ECU 20 of the vehicle 100. Moreover, the update control is executed in parallel between one server 200 and the master ECU 10 of a plurality of vehicles 100.

[0016] In this embodiment, when a request for updating software occurs for the vehicle 100, the master ECU 10 of the vehicle 100 executes update control. First, the execution device 11 of the master ECU 10 downloads new software, a version number NV corresponding to the software, and a consistency table TM corresponding to the software from the server 200. Next, the execution device 11 of the master ECU 10 installs the new software, the version number NV, and the consistency table TM in the storage device 22 of the slave ECU 20 to be updated. Then, the execution device 11 of the master ECU 10 instructs the slave ECU 20 to be updated to activate the new software. As a result, the software, the version number NV, and the consistency table TM in the slave ECU 20 to be updated are updated every time update control is executed.

[0017] Here, the version number NV and the consistency table TM will be described. The version number NV is a numerical value indicating the version of the software corresponding to the version number NV. Furthermore, the version number NV is a numerical value that increases every time the software corresponding to the version number NV is updated. Furthermore, the consistency table TM specifies combinations of the version numbers NV for a plurality of slave ECUs 20 that indicate the correspondence between the software versions when the software is normally stored in the plurality of slave ECUs 20. In other words, the consistency table TM specifies combinations of the version numbers NV that are allowed for combinations of the version numbers NV of a plurality of slave ECUs 20.

[0018] For example, assume that the number of software updates for the vehicle 100 increases from 0th to 1st to 2nd, etc., as shown in Fig. 2. In this case, each time the software of the slave ECU 20 is updated, the version number NV corresponding to the software increases.

[0019] Therefore, in the example of FIG. 2, the version number NV changes as follows. First, when the first software update for the vehicle 100 is executed, the software of the first slave ECU 20A and the second slave ECU 20B is updated. Then, the version numbers NV of the first slave ECU 20A and the second slave ECU 20B are also updated. As a result, the version numbers NV after the update are "1", "1", "0", and "0" for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Furthermore, when the second software update for the vehicle 100 is executed, the software of the first slave ECU 20A and the third slave ECU 20C is updated. Then, the version numbers NV of the first slave ECU 20A and the third slave ECU 20C are also updated. As a result, the updated version numbers NV of the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D are "2", "1", "2", and "0", respectively.

[0020] In the example of FIG. 2, the consistency table TM changes as follows. First, when the first software update for the vehicle 100 is performed, the software for the first slave ECU 20A and the second slave ECU 20B is updated. Then, the consistency tables TM for the first slave ECU 20A and the second slave ECU 20B are also updated. As a result, the consistency tables TM for the first slave ECU 20A and the second slave ECU 20B after the update specify "1", "1", "0", and "0" as the permissible combinations of version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. On the other hand, the consistency tables TM for the third slave ECU 20C and the fourth slave ECU 20D specify "0", "0", "0", and "0" as the permissible combinations of version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Furthermore, when the second software update for the vehicle 100 is executed, the software of the first slave ECU 20A and the third slave ECU 20C is updated. Then, the consistency tables TM of the first slave ECU 20A and the third slave ECU 20C are also updated. As a result, the consistency tables TM of the first slave ECU 20A and the third slave ECU 20C after the update prescribe "2", "1", "2", and "0" as the combinations of the version numbers NV of the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. On the other hand, the consistency table TM of the second slave ECU 20B prescribes "1", "1", "0", and "0" as the combinations of the version numbers NV of the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. In addition, the consistency table TM of the fourth slave ECU 20D specifies the allowable combinations of version numbers NV as "0", "0", "0", and "0" for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order.

[0021] Therefore, if the software is properly stored in the multiple slave ECUs 20 , the version number NV actually stored in the slave ECU 20 will be equal to or greater than the version number NV specified in the consistency table TM of the slave ECU 20 .

[0022] <Validation control> Next, the consistency check control executed by the master ECU 10 and the multiple slave ECUs 20 will be described with reference to Fig. 3. The consistency check control is a control for determining whether or not the correspondence relationship between the software versions of the multiple slave ECUs 20 is consistent. In this embodiment, the slave ECU 20 starts the consistency check control when a request is made to start the system of the vehicle 100. Note that an example of a request to start the system of the vehicle 100 is when a main switch of the vehicle 100 is operated by a user of the vehicle 100.

[0023] As shown in Fig. 3, when the execution unit 21 of the slave ECU 20 starts the consistency check control, it executes the process of step S11. In step S11, the execution unit 21 of the slave ECU 20 acquires the version number NV corresponding to the current software stored in the slave ECU 20. At this time, the execution unit 21 of the slave ECU 20 acquires a total of four version numbers NV from the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D. Note that each of the execution units 21 of the four slave ECUs 20 executes the processes of steps S11 to S13 (described later) in parallel. After step S11, the execution unit 21 of the slave ECU 20 advances the process to step S12.

[0024] In step S12, the execution unit 21 of the slave ECU 20 compares the four acquired version numbers NV with the four version numbers NV defined in the consistency table TM. If each of the four acquired version numbers NV is equal to or greater than the version numbers NV defined in the consistency table TM, the execution unit 21 of the slave ECU 20 determines that the correspondence between the software versions of the multiple slave ECUs 20 is consistent. On the other hand, if one or more of the acquired version numbers NV is smaller than the version numbers NV defined in the consistency table TM, the execution unit 21 of the slave ECU 20 determines that the correspondence between the software versions of the multiple slave ECUs 20 is not consistent.

[0025] For example, it is assumed that the second software update for the vehicle 100 has been completed. Furthermore, it is assumed that the software is normally stored in the multiple slave ECUs 20. At this time, as shown in FIG. 2, the four version numbers NV acquired by the execution device 21 of the slave ECU 20 are "2", "1", "2", and "0" for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Also, the consistency table TM of the first slave ECU 20A specifies "2", "1", "2", and "0" as permissible combinations of version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Therefore, in the above situation, the execution device 21 of the first slave ECU 20A determines that each of the acquired four version numbers NV is equal to or greater than the version numbers NV specified in the consistency table TM. Then, the execution device 21 of the first slave ECU 20A determines that the correspondence relationship between the software versions of the multiple slave ECUs 20 is consistent.

[0026] In the above situation, the consistency table TM of the second slave ECU 20B specifies "1", "1", "0", and "0" as permissible combinations of version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Therefore, in the above situation, the execution unit 21 of the second slave ECU 20B determines that each of the acquired four version numbers NV is equal to or greater than the version numbers NV specified in the consistency table TM. Then, the execution unit 21 of the second slave ECU 20B determines that the correspondence relationships between the software versions for the multiple slave ECUs 20 are consistent.

[0027] Also, for example, it is assumed that the second software update for the vehicle 100 has been completed. Furthermore, it is assumed that the software of the third slave ECU 20C among the multiple slave ECUs 20 has been downgraded due to the initialization of the data of the third slave ECU 20C. At this time, the four version numbers NV acquired by the execution device 21 of the slave ECU 20 are "2", "1", "0", and "0" for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Furthermore, the consistency table TM of the first slave ECU 20A specifies "2", "1", "2", and "0" as permissible combinations of version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Therefore, in the above situation, the execution unit 21 of the first slave ECU 20A determines that the version number NV of the third slave ECU 20C, "0", among the four acquired version numbers NV, is smaller than the version number NV of the third slave ECU 20C, "2", defined in the consistency table TM. Then, the execution unit 21 of the first slave ECU 20A determines that the correspondence relationship between the software versions of the multiple slave ECUs 20 is not consistent. As shown in FIG 3, after step S12, the execution unit 21 of the slave ECU 20 advances the process to step S13.

[0028] In step S13, the execution unit 21 of the slave ECU 20 transmits a signal indicating the result of the consistency check in step S12 to the master ECU 10. Then, when the execution unit 11 of the master ECU 10 acquires signals indicating the result of the consistency check in step S12 from the four slave ECUs 20, the execution unit 11 of the master ECU 10 advances the process to step S21.

[0029] In step S21, the execution unit 11 of the master ECU 10 determines whether or not all of the results of the consistency checks are normal based on the results of the four obtained consistency checks. Specifically, if all of the results of the four consistency checks indicate that the correspondence relationships between the software versions of the multiple slave ECUs 20 are consistent, the execution unit 11 of the master ECU 10 determines that all of the results of the consistency checks are normal. In step S21, if the execution unit 11 determines that all of the results of the consistency checks are normal (S21: YES), the execution unit 11 advances the process to step S31.

[0030] In step S31, the execution unit 11 of the master ECU 10 starts the system of the vehicle 100. Specifically, the execution unit 11 of the master ECU 10 allows the execution of various controls related to the running of the vehicle 100 by the multiple slave ECUs 20. After step S31, the execution unit 11 of the master ECU 10 ends the current consistency check control.

[0031] On the other hand, if the execution unit 11 determines in step S21 that one or more of the results of the consistency check are not normal (S21: NO), the execution unit 11 advances the process to step S41.

[0032] In step S41, the execution device 11 of the master ECU 10 notifies the user of the vehicle 100 that the correspondence between the software versions of the multiple slave ECUs 20 is not consistent. Specifically, the execution device 11 of the master ECU 10 outputs a control signal to the display 71 to display on the display 71 that the correspondence between the software versions of the multiple slave ECUs 20 is not consistent. In addition, the execution device 11 of the master ECU 10 outputs a control signal to the display 71 to display on the display 71 the slave ECU 20 whose software is assumed to have been downgraded. Furthermore, in step S41, the execution device 11 of the master ECU 10 prohibits the execution of various controls related to the running of the vehicle 100 by the multiple slave ECUs 20. After step S41, the execution device 11 of the master ECU 10 ends the current consistency check control.

[0033] <Action of this embodiment> For example, as shown in FIG. 2, it is assumed that the second software update for the vehicle 100 is completed. Then, it is assumed that the software of the third slave ECU 20C, among the multiple slave ECUs 20, is downgraded due to the initialization of the data of the third slave ECU 20C. When the software of the third slave ECU 20C is downgraded in this way, the version number NV of the third slave ECU 20C after downgrading becomes smaller than the version number NV before downgrading. Here, when a start of the system of the vehicle 100 is requested, the slave ECU 20 starts a consistency check control as shown in FIG. 3. In step S11, the execution device 21 of the slave ECU 20 acquires the version number NV corresponding to the current software stored in the slave ECU 20. At this time, for example, the four version numbers NV acquired by the execution device 21 of the first slave ECU 20A are "2", "1", "0", and "0" in the order of the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D. In step S12, the execution unit 21 of the slave ECU 20 compares the four acquired version numbers NV with the four version numbers NV defined in the consistency table TM. At this time, for example, the consistency table TM of the first slave ECU 20A defines "2", "1", "2", and "0" as combinations of permissible version numbers NV for the first slave ECU 20A, the second slave ECU 20B, the third slave ECU 20C, and the fourth slave ECU 20D, in that order. Therefore, in the above situation, the execution unit 21 of the first slave ECU 20A determines that "0", which is the version number NV of the third slave ECU 20C, among the four acquired version numbers NV, is smaller than "2", which is the version number NV of the third slave ECU 20C defined in the consistency table TM. Then, the execution unit 21 of the first slave ECU 20A determines that the correspondence relationship between the software versions of the multiple slave ECUs 20 is not consistent.

[0034] <Effects of this embodiment> (1) According to this embodiment, the execution device 21 of the slave ECU 20 determines that the correspondence relationship between the software versions of the multiple slave ECUs 20 is inconsistent when one or more of the four acquired version numbers NV are smaller than the version number NV specified in the consistency table TM. In other words, the execution device 21 of the slave ECU 20 determines that the correspondence relationship between the software versions of the multiple slave ECUs 20 is inconsistent when the version number NV acquired from the third slave ECU 20C becomes smaller as a result of downgrading the software of the third slave ECU 20C. As a result, even if the correspondence relationship between the software versions of the multiple slave ECUs 20 becomes inconsistent due to downgrading of the software of one or more slave ECUs 20, for example, it can be determined that the correspondence relationship is inconsistent.

[0035] (2) In the case where the consistency check control is performed, only the execution device 11 of the first slave ECU 20A executes the processes of steps S11 to S13. If the data in the storage device 22 of the first slave ECU 20A is initialized, the data in the consistency table TM is also initialized, which may prevent the determination in step S12 from being properly performed. As a result, the system of the vehicle 100 may be started up even when the correspondence between the software versions of the multiple slave ECUs 20 is not consistent.

[0036] In this regard, in this embodiment, each of the execution devices 21 of the four slave ECUs 20 executes the processes of steps S11 to S13 in parallel. Next, in step S21, if all of the acquired four consistency check results are normal, the execution device 11 of the master ECU 10 advances the process to step S31. Then, in step S31, the execution device 11 of the master ECU 10 starts up the system of the vehicle 100. This makes it possible to prevent the system of the vehicle 100 from being started up in a situation where the correspondence between the software versions of the multiple slave ECUs 20 is not consistent.

[0037] (3) In this embodiment, the consistency check control is executed by the master ECU 10 and the multiple slave ECUs 20 included in the vehicle 100. In other words, the consistency check control does not require communication between the vehicle 100 and the server 200. As a result, even in a situation where communication between the vehicle 100 and the server 200 cannot be executed, for example, it is possible to determine whether the correspondence between the software versions of the multiple slave ECUs 20 is consistent.

[0038] <Example of change> This embodiment can be modified as follows: This embodiment and the following modifications can be combined with each other to the extent that there is no technical contradiction.

[0039] In the above embodiment, the consistency check control may be changed. For example, the entity that executes the processes of steps S11 to S13 may be changed. As a specific example, only the execution devices 21 of some of the slave ECUs 20 among the multiple slave ECUs 20 may execute the processes of steps S11 to S13.

[0040] For example, the process of step S13 may be changed. As a specific example, first, the slave ECU 20 may execute the processes of steps S21 to S41 instead of the master ECU 10. In this case, in step S13, the slave ECU 20 that does not execute the processes of steps S21 to S41 may transmit a signal indicating the result of the consistency check of step S12 to the slave ECU 20 that executes the processes of steps S21 to S41 instead of the master ECU 10.

[0041] For example, the processes of steps S13 to S41 may be omitted. As a specific example, from the viewpoint of only determining whether the correspondence relationship between the software versions of the multiple slave ECUs 20 is consistent, the processes of steps S13 to S41 may be omitted.

[0042] In the above embodiment, the configuration of the update system US may be changed. For example, the update system US does not need to include the server 200. Specifically, the present technology may be applied to a configuration in which software of the slave ECU 20 is updated via a cable in a factory or the like that performs maintenance on the vehicle 100. In addition, the present technology may be applied to any information processing device that includes multiple ECUs whose software is updated, regardless of the vehicle 100. [Explanation of symbols]

[0043] NW...communication network US...update system 10...master ECU 11...execution device 12...storage device 20...slave ECU 21...execution device 22...storage device 50...DCM 61...first external bus 62...second external bus 71...display 100...vehicle 200...server 210...execution device 220...storage device 230...communication device

Claims

[Claim 1] A plurality of ECUs whose software is updated are provided, Each of the plurality of ECUs stores software for the ECU, a version number corresponding to the software, and a consistency table corresponding to the software; The version number is a number indicating a version of the software corresponding to the version number, and is a number that increases every time the software corresponding to the version number is updated, the consistency table defines combinations of the version numbers for the plurality of ECUs, which indicate a correspondence relationship between software versions when software is normally stored in the plurality of ECUs; obtaining from a plurality of said ECUs the version numbers corresponding to current software stored in said ECUs; comparing the acquired version numbers with a plurality of version numbers defined in the consistency table; determining that the correspondence relationship between the software versions of the plurality of ECUs is not consistent when one or more of the acquired plurality of version numbers is smaller than the version number defined in the consistency table; Run Information processing device.

Images