Patent Application
20250153706
The present application claims priority under 35 U.S.C. § 119 to Japanese Patent Application No. 2023-191272 filed on Nov. 9, 2023. The content of the application is incorporated herein by reference in its entirety.
The present invention relates to a moving body control device, a moving body control method, and a recording medium.
A technique for supporting software update has been conventionally proposed in a control device to be mounted on a moving body such as a vehicle. For example, JP 2019-144669 A discloses a configuration in which an area for storing a program that is running and an area for storing an update program are set in a storage unit for storing programs to be executed by an electronic control unit (ECU) mounted on a vehicle. According to this configuration, the update program can be stored in the storage unit, also while the program is running, and restrictions on the timing of updating the program can be reduced.
Software such as a program or the like for use in a moving body control device includes important software that performs basic operations of the moving body. Hence, if the software is not normally updated, the operation of the moving body may be troubled. For example, in updating a plurality of pieces of software to be individually performed by a plurality of processors, when a software update for any of the processors is not normally completed, or an abnormality occurs in updated software, the processors are not capable of synchronizing each other in accordance with a new version of the software, and the moving body becomes inoperable. For this reason, it is an object of the present application to suppress a situation in which the moving body becomes inoperable because of a failure in updating the software on a plurality of processors in a moving body control device.
An object of the present application is to improve safety in order to address the above issue. In addition, such an object further improves traffic safety, and contributes to development of a sustainable transportation system, accordingly.
According to a first aspect for achieving the above object, a moving body control device includes: a first processor; a first memory in which first software to be used by the first processor is stored; a second processor; a second memory in which second software to be used by the second processor is stored; a software update unit configured to perform update processing of the first software and the second software; a software abnormality recognition unit configured to recognize presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, after the update processing is performed; and a software abnormality handling unit configured to cause either the first processor or the second processor to perform abnormality handling processing of operating a target moving body to be controlled by the moving body control device in a predetermined abnormality handling mode, in a case where the software abnormality recognition unit recognizes the abnormality of either the first software stored in the first memory or the second software stored in the second memory.
In the above moving body control device, in a case where a version of the first software that is valid and stored in the first memory is different from a version of the second software that is valid and stored in the second memory, or in a case where secure boot of either the first software that is valid and stored in the first memory or the second software that is valid and stored in the second memory results in a failure, the software abnormality recognition unit may recognize that either the first software stored in the first memory or the second software stored in the second memory is abnormal.
In the above moving body control device, an area for storing a new version of the first software that has been updated by the update processing and an area for storing an old version of the first software before being updated by the update processing may be set in the first memory, an area for storing a new version of the second software that has been updated by the update processing and an area for storing an old version of the second software before being updated by the update processing may be set in the second memory, and in a case where the software abnormality recognition unit recognizes that either the first software stored in the first memory or the second software stored in the second memory is abnormal because the version of the first software that is valid and stored in the first memory is different from the version of the second software that is valid and stored in the second memory, the software abnormality handling unit may cause the first processor to execute the old version of the first software stored in the first memory, and may also cause the second processor to execute the old version of the second software stored in the second memory, as the abnormality handling processing.
In the above moving body control device, in a case where the software abnormality recognition unit recognizes that the secure boot of the first software that is valid and stored in the first memory results in the failure and the secure boot of the first software that is valid and stored in the second memory results in a success, the software abnormality handling unit may perform processing of prohibiting the first processor from executing the first software and causing the second processor to execute the second software, as the abnormality handling processing.
In the above moving body control device, the software abnormality handling unit may cause a notification unit provided in the target moving body to notify that the abnormality handling processing is being performed.
In the above moving body control device, an area for storing a new version of the first software that has been updated by the update processing and an area for storing an old version of the first software before being updated by the update processing nay be set in the first memory, an area for storing a new version of the second software that has been updated by the update processing and an area for storing an old version of the second software before being updated by the update processing may be set in the second memory, and in a state in which the new version of the first software is stored in the first memory as the first software that is valid and the new version of the second software is stored in the second memory as the second software that is valid, and in a case where the software abnormality recognition unit recognizes that either the secure boot of the new version of the first software stored in the first memory or the new version of the second software stored in the second memory results in the failure, the software abnormality handling unit may cause the first processor to execute the old version of the first software stored in the first memory, and may also cause the second processor to execute the old version of the second software stored in the second memory, as the abnormality handling processing.
According to a second aspect for achieving the above object, a moving body control method to be performed by a moving body control device including: a first processor; a first memory in which first software to be used by the first processor is stored; a second processor; and a second memory in which second software to be used by the second processor is stored, and the moving body control method includes: a software update step of performing update processing of the first software and the second software; a software abnormality recognition step of recognizing presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, after the update processing is performed; and a software abnormality handling step of causing either the first processor or the second processor to perform abnormality handling processing of operating a target moving body to be controlled by the moving body control device in a predetermined abnormality handling mode, in a case where the software abnormality recognition step recognizes the abnormality of either the first software stored in the first memory or the second software stored in the second memory.
According to a third aspect for achieving the above object, a non-transitory recording medium storing a program that causes a moving body control device including:
According to the moving body control device, the moving body control method, and the recording medium, in a case where a software update in the moving body control device has not been normally completed, it is possible to suppress a situation in which the moving body becomes inoperable.
A configuration of a moving body control device 1 in the present embodiment will be described with reference to
The moving body control device 1 includes a first microcomputer 10 and a second microcomputer 20. The first microcomputer 10 includes a first processor 11, a first memory 12, a first communication circuit 13, and the like, and the second microcomputer 20 includes a second processor 21, a second memory 22, a second communication circuit 23, and the like. In the first memory 12, an old version of first software 121 and a new version of first software 122, which are to be executed by the first processor 11, are stored. The first memory 12 and the second memory 22 are each, for example, a code flash memory.
The old version of first software 121 and the new version of first software 122 are pieces of software to be used by the first processor 11, and each include a control program for the moving body 100, a data set used for controlling the moving body 100, and the like.
In the second memory 22, an old version of second software 221 and a new version of second software 222 are pieces of software to be used by the second processor 21, and each include a control program for the moving body 100, a data set used for controlling the moving body 100, and the like.
The old version of first software 121 is stored in an area 12a of the first memory 12, and the new version of first software 122 is stored in an area 12b of the first memory 12. A program of boot (bootstrap) processing of the first microcomputer 10 is stored in an area 12c of the first memory 12. In addition, the old version of second software 221 is stored in an area 22a of the second memory 22, and the new version of second software 222 is stored in an area 22b of the second memory 22. A program of boot processing of the second microcomputer 20 is stored in an area 22c of the second memory 22.
In this manner, the storage areas of the first software and the second software in the first memory 12 and the second memory 22 have a two-sided configuration, and both the old versions and the new versions of first software and the second software can be stored. Thus, as will be described later, when an update from the old version to the new version fails, the moving body 100 can be continuously operated by use of the old version of first software and the old version of second software.
The first microcomputer 10 is connected with a start/stop (SS) switch 2, which instructs switching between on (power on state) and off (power off state) of an ignition (IG) of the moving body 100, and an operation signal of the SS switch 2 is input into the first microcomputer 10 via an input circuit 30. An IG relay 3 is connected with the second microcomputer 20, and on and off of the IG relay 3 is controlled by a control signal output from the second microcomputer 20 via an output circuit 35 to switch on and off of the IG of the moving body 100.
An output portion of the output circuit 35 is connected with an input circuit 32, and a detection signal of an output state (on or off state of the IG relay 3) of the output circuit 35 is input into the second microcomputer 20 from the input circuit 32. An output portion of the IG relay 3 is connected with an input circuit 31, and a detection signal of on or off of the IG relay 3 is input into the first microcomputer 10 from the input circuit 31.
In addition, the moving body control device 1 is connected with another ECU 40, which is mounted on the moving body 100, through a communication line 41. Examples of communication specifications between the moving body control device 1 and another ECU 40 through the communication line 41 include, a controller area network (CAN, registered trademark), a CAN with flexible data rate (CAN FD), a local interconnect network (LIN), Ethernet (registered trademark), and FlexRay (registered trademark).
The moving body control device 1 is capable of connecting with a terminal device 50 through a connection cable 51, and a worker W is able to operate the terminal device 50 to update the first software from the old version to the new version and update the second software from the old version to the new version.
In addition, the moving body control device 1 causes the communication unit 5 to update the first software and the second software with use of over the air (OTA) on wireless communication with the moving body management server 310 through the communication network 300. That is, the moving body control device 1 downloads the new version of first software from the moving body management server 310, updates the first software, downloads the new version of second software from the moving body management server 310, and updates the second software.
Update timings of the first software and the second software will be described with reference to
Note that
In
Subsequently, the microcomputer starts writing the new version software into the B side, and is on standby of IG-OFF after the writing is completed. C2 indicates a situation in which the new version software is written in the B side. At t2, when recognizing an IG-OFF operation on the SS switch 2, the microcomputer checks permission of activation (checks whether there is an error in the downloaded new version software, or the like). The, upon confirmation of the permission, the microcomputer activates the new version software, and resets itself. C3 indicates a situation in which writing of the new version software into the B side is completed. When the microcomputer is restarted next time, the new version software is valid.
At t3, when recognizing the IG-ON operation on the SS switch 2, the microcomputer confirms that the update from the old version to the new version of the software has been completed, and switches the software to be activated to the new version from the old version. C5 indicates a state in which the software to be activated by the microcomputer at the time of IG-ON is switched to the new version software stored in the B side from the old version software stored in the A side.
In the example illustrated in
For example, a door switch, a switch (physical switch or touch switch) of a display unit provided in the vehicle, a brake lever, an accelerator lever, or a mobile device (a smartphone, a terminal device for a vehicle, or the like) may be configured for the input means used as the trigger in order to control switching between IG-ON and IG-OFF.
Here,
The valid code is recorded by incrementing by one, whenever the software version is updated. In the footer, a valid code is recorded, when the activation of the software is completed. Therefore, it is possible to check whether the activation of the software is completed in accordance with the presence or absence of the valid code recorded in the footer. In the example of
On the other hand, for the second software stored in the second memory 22, the valid code “01” is recorded in the header and the footer of the old version of second software 221, but the valid code is not recorded in the footer of the new version of second software 222 (indefinite). Therefore, it can be confirmed that the activation of the old version of second software 221 has been completed, but the activation of the new version of second software 222 has not been completed.
According to flowcharts illustrated in
The processing performed by the software update unit corresponds to a software update step in a moving body control method in the present disclosure, and the processing performed by the software abnormality recognition unit corresponds to a software abnormality recognition step in the moving body control method in the present disclosure. The processing performed by the software abnormality handling unit corresponds to a software abnormality handling step in the moving body control method in the present disclosure.
As illustrated in
As described above with reference to
In the example illustrated in
For example, a door switch, a switch (physical switch or touch switch) of a display unit provided in the vehicle, a brake lever, an accelerator lever, or a mobile device (a smartphone, a terminal device for a vehicle, or the like) may be configured for the input means used as the trigger in order to control switching between IG-ON and IG-OFF.
The first processor 11 and the second processor 21 recognize IG-ON or IG-OFF from the state of the power supply of the moving body 100, and perform the processing in accordance with the flowcharts of
In step S1 of
Similarly, in step S51, the second processor 21 writes the new version of second software 222, which has been downloaded from the moving body management server 310, into the B side 22b of the second memory 22. In subsequent step S52, the second processor 21 starts activation of the new version of second software 222, but an abnormality of E1 (instantaneous interruption of a battery, reset of a Watchdog Timer (WDT), or the like) is occurring, before the activation is completed. Therefore, the activation of the new version of second software 222 is in an incomplete state. The configuration for performing steps S1 and S2 and steps S51 and S52 corresponds to the software update unit in the present disclosure.
In step S3, the first processor 11 restarts the first microcomputer 10. In subsequent step S3, the first processor 11 determines that valid first software is the new version in accordance with boot startup (see
In next steps S5 and S55, the first processor 11 and the second processor 21 mutually transmit and receive the valid versions of the first software and the second software. Then, the first processor 11 and the second processor 21 determine whether the valid versions of the first software and the second software match each other.
In subsequent step S6, the first processor 11 recognizes a mismatch between the valid versions of the first software and the second software. As illustrated in
The first processor 11, which recognizes the mismatch between the valid versions of the first software and the second software, performs roll back processing of making the activation incomplete for the new version of first software 122, which is stored in the B side 12b, in the next step S7. The configuration for performing the processing of step S7 corresponds to the software abnormality handling unit in the present disclosure.
Accordingly, as illustrated in
On the other hand, in step S56, the second processor 21 recognizes that the valid versions of the first software and second software do not match each other. As illustrated in
In step S10 of
In the next steps S11 and S60, the first processor 11 and the second processor 21 mutually transmit and receive the valid versions of the first software and the second software. Then, the first processor 11 and the second processor 21 determine whether the valid versions of the first software and the second software match each other.
In subsequent step S12, the first processor 11 recognizes that the valid versions of the first software and second software match each other. In addition, in step S61, the second processor 21 recognizes that the valid versions of the first software and second software match each other. In next step S13, the first processor 11 performs secure boot processing of the old version of first software 121 to verify reliability (presence or absence of tampering or the like) of the old version of first software 121.
In addition, in step S62, the second processor 21 performs secure boot processing of the old version of second software 221, and detects the reliability of the old version of second software 221. In subsequent steps S14 and S63, the first processor 11 and the second processor 21 mutually transmit and receive results of the secure boot processing, and compare the results of the secure boot processing between the old version of first software 121 and the old version of second software 221. The configuration for performing the processing in steps S10 to S14 and steps S59 to S63 in
Subsequently, in step S15 in
In step S20, the first processor 11 resets the first microcomputer 10, and performs the processing of the secure boot processing in step S13 and later in
In step S16, the first processor 11 determines whether the result of the secure boot of the other (the old version of second software 221) is OK. Then, in a case where the result of the secure boot of the other is OK, the first processor 11 advances the processing to step S17, and continuously controls the normal operation of the moving body 100 in accordance with the old version of first software 121.
On the other hand, in a case where the result of the secure boot of the other is NG, the first processor 11 advances the processing to step S21, executes the old version of first software 121, and activates only the function of the moving body 100 that has been assigned to itself (the first microcomputer 10) (functional degeneration). In subsequent step S22, the first processor 11 notifies that the moving body 100 is operating in functional degeneration by displaying such a fact on the display 6.
Here, examples of the functions of the moving body 100 that are assigned to the first microcomputer 10 include wiper, headlight, security alarm, door lock, and partial diagnosis. In addition, the normal operations of the first microcomputer 10 include update (reprogramming) of the first software with use of a cable or the OTA, diagnosis (cancellation of security of diagnosis line or the like), and the like, in addition to the above functions.
Similarly, in step S64, the second processor 21 determines whether the result of the secure boot of itself (the old version of second software 221) is OK. Then, in a case where the result of the secure boot is OK, the second processor 21 advances the processing to step S65, and in a case where the result of the secure boot is NG, the second processor 21 advances the processing to step S70.
In step S70, the second processor 21 resets the second microcomputer 20, and performs the processing of the secure boot processing in step S62 and later in
In step S65, the second processor 21 determines whether the result of the secure boot of the other (the old version of first software 121) is OK. Then, in a case where the result of the secure boot of the other is OK, the second processor 21 advances the processing to step S66, and continuously controls the normal operation of the moving body 100 in accordance with the old version of second software 221.
In a case where the update of the second software fails in the processing of steps S17 and S66, the moving body 100 can be continuously operated with use of the old version of first software and the old version of second software. The mode of operating the moving body 100 with use of the old version of first software 121 and the old version of second software 221 in steps S17 and S66 corresponds to an abnormality handling mode in the present disclosure.
On the other hand, in a case where the result of the secure boot of the other is NG, the second processor 21 advances the processing to step S71, executes the old version of second software 221, and activates only the function of the moving body 100 that has been assigned to itself (the second microcomputer 20) (functional degeneration). In subsequent step S72, the second processor 21 notifies that the moving body 100 is operating in functional degeneration by displaying such a fact on the display 6.
In a case where the result of the secure boot is NG for the old version of first software or the old version of second software in the processing of steps S21 and S71, the moving body 100 can be continuously operated in functional degeneration. The configuration for performing the processing in steps S21 and S22 and steps S71 and S72 in
Note that in the flowcharts of
In the above embodiment, in a case where the update of one of the first software and the second software has not been normally completed, the roll back processing in step S7 of
In the above embodiment, in a case where the result of the secure boot of the first software or the second software is NG, the functional degeneration processing is performed in steps S22 and S72 of
In the above embodiment, in steps S22 and S72 of FIG. 6, the fact that the moving body 100 is operated in the functional degeneration is notified by being displayed on the display 6. As another embodiment, instead of the notification on the display 6 or in addition to the notification on the display 6, a notification may be given by sound to be output from a speaker provided in the moving body 100. Alternatively, the notification that the moving body 100 is operating in functional degeneration may be omitted.
Note that in order to facilitate understanding of the present invention,
The above embodiments are specific examples of the following configurations.
Configuration 1: A moving body control device includes: a first processor; a first memory in which first software to be used by the first processor is stored; a second processor; a second memory in which second software to be used by the second processor is stored; a software update unit configured to perform update processing of the first software and the second software; a software abnormality recognition unit configured to recognize presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, after the update processing is performed; and a software abnormality handling unit configured to cause either the first processor or the second processor to perform abnormality handling processing of operating a target moving body to be controlled by the moving body control device in a predetermined abnormality handling mode, in a case where the software abnormality recognition unit recognizes the abnormality of either the first software stored in the first memory or the second software stored in the second memory.
According to the moving body control device in the configuration 1, in the case where the update of either the first software or the second software has not been normally completed, it is possible to suppress a situation in which the target moving body becomes inoperable.
Configuration 2: The moving body control device described in the configuration 1, in which in a case where a version of the first software that is valid and stored in the first memory is different from a version of the second software that is valid and stored in the second memory, or in a case where secure boot of either the first software that is valid and stored in the first memory or the second software that is valid and stored in the second memory results in a failure, the software abnormality recognition unit recognizes that either the first software stored in the first memory or the second software stored in the second memory is abnormal.
According to the moving body control device in the configuration 2, in a case where the update processing of either the first software or the second software has not been normally completed, and thus the valid versions of the first software and the second software are different from each other, it is possible to recognize that either the first software or the second software is abnormal. In addition, in a case where the secure boot of the valid first software or the valid second software results in a failure, it is possible to recognize that either the first software or the second software is abnormal.
Configuration 3: The moving body control device described in the configuration 2, an area for storing a new version of the first software that has been updated by the update processing and an area for storing an old version of the first software before being updated by the update processing are set in the first memory, an area for storing a new version of the second software that has been updated by the update processing and an area for storing an old version of the second software before being updated by the update processing are set in the second memory, and in a case where the software abnormality recognition unit recognizes that either the first software stored in the first memory or the second software stored in the second memory is abnormal because the version of the first software that is valid and stored in the first memory is different from the version of the second software that is valid and stored in the second memory, the software abnormality handling unit causes the first processor to execute the old version of the first software stored in the first memory, and also causes the second processor to execute the old version of the second software stored in the second memory, as the abnormality handling processing.
According to the moving body control device in the configuration 3, in a case where the valid versions of the first software and the second software are different from each other because update of the first software or the second software to the new version has not been normally completed, it is possible to cause the first processor and the second processor to respectively execute the old version of first software and the old version of second software to operate the target moving body.
Configuration 4: The moving body control device described in the configuration 2 or 3, in which in a case where the software abnormality recognition unit recognizes that the secure boot of the first software that is valid and stored in the first memory results in the failure and the secure boot of the first software that is valid and stored in the second memory results in a success, the software abnormality handling unit performs processing of prohibiting the first processor from executing the first software and causing the second processor to execute the second software, as the abnormality handling processing.
According to the moving body control device in the configuration 4, in a case where a failure of the first software is recognized, the operation of the target moving body can be ensured by causing the second processor to execute the second software in which the failure is not recognized.
Configuration 5: The moving body control device described in the configuration 4, in which the software abnormality handling unit causes a notification unit provided in the target moving body to notify that the abnormality handling processing is being performed.
According to the moving body control device in the configuration 5, for example, it is possible to notify the user riding in the target moving body that the operation of the target moving body is limited, because the first software is not executed.
Configuration 6: The moving body control device described in the configuration 2 or 3, in which an area for storing a new version of the first software that has been updated by the update processing and an area for storing an old version of the first software before being updated by the update processing are set in the first memory, an area for storing a new version of the second software that has been updated by the update processing and an area for storing an old version of the second software before being updated by the update processing are set in the second memory, and in a state in which the new version of the first software is stored in the first memory as the first software that is valid and the new version of the second software is stored in the second memory as the second software that is valid, and in a case where the software abnormality recognition unit recognizes that either the secure boot of the new version of the first software stored in the first memory or the new version of the second software stored in the second memory results in the failure, the software abnormality handling unit causes the first processor to execute the old version of the first software stored in the first memory, and also causes the second processor to execute the old version of the second software stored in the second memory, as the abnormality handling processing.
According to the moving body control device in the configuration 6, after update of either the first software or the second software to the new version is completed, in a case where the secure boot of either the valid first software or the valid second software results in a failure, the first processor and the second processor are caused to respectively execute the old versions of the first software and the second software, so that the target moving body can be operated.
Configuration 7: A moving body control method to be performed by a moving body control device including: a first processor; a first memory in which first software to be used by the first processor is stored; a second processor; and a second memory in which second software to be used by the second processor is stored, and the moving body control method includes: a software update step of performing update processing of the first software and the second software; a software abnormality recognition step of recognizing presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, after the update processing is performed; and a software abnormality handling step of causing either the first processor or the second processor to perform abnormality handling processing of operating a target moving body to be controlled by the moving body control device in a predetermined abnormality handling mode, in a case where the software abnormality recognition step recognizes the abnormality of either the first software stored in the first memory or the second software stored in the second memory.
By causing the moving body control device to perform the moving body control method in the configuration 7, an operational configuration similar to that of the moving body control device in the configuration 1 is obtainable.
Configuration 8: A non-transitory recording medium storing a program that causes a moving body control device including: a first processor; a first memory in which first software to be used by the first processor is stored; a second processor; and a second memory in which second software to be used by the second processor is stored, to function as: a software update unit configured to perform update processing of the first software and the second software; a software abnormality recognition unit configured to recognize presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, after the update processing is performed; and a software abnormality handling unit configured to cause either the first processor or the second processor to perform abnormality handling processing of operating a target moving body to be controlled by the moving body control device in a predetermined abnormality handling mode, in a case where the software abnormality recognition unit recognizes the abnormality of either the first software stored in the first memory or the second software stored in the second memory.
By causing the moving body control device to execute the program in the configuration 8, the configuration of the moving body control device in the configuration 1 is achievable.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2023-191272 | Nov 2023 | JP | national |
