Mobile control device, mobile control method, and program

Abstract

To prevent operation of a mobile body from becoming disabled due to failure in updating software of a plurality of processors in a mobile body controller.SOLUTION: A mobile body controller 1 comprises: a software update part 11, 21 executing update processing of first software or a second software; a software abnormality recognition part 11, 21 recognizing presence / absence of abnormality of the first software and the second software, after executing the update processing; and a software abnormality corresponding part 11, 21 making a first processor 11 or a second processor 21 execute abnormality corresponding processing for actuating a target mobile body 100 that is a control object according to the mobile body controller 1, in a prescribed abnormality corresponding mode, if the software abnormality recognition part recognizes abnormality of the first software stored in a first memory, or a second software stored in a second memory.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a movement control device, a movement control method, and a program.

Background Art

[0002] Conventionally, in a control device mounted on a moving body such as a vehicle, a technique for supporting software update has been proposed. For example, Patent Document 1 discloses a configuration in which a storage unit that stores a program executed by an ECU (Electronic Control Unit) mounted on a vehicle sets an area for storing a program being executed and an area for storing an update program. According to this configuration, it is possible to store the update program in the storage unit even while the program is being executed, and it is said that the constraints on the timing for updating the program can be reduced.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Since the software such as programs used in the mobile control device includes important software for performing basic operations of the mobile object, if the software update is not performed properly, it may cause problems in the operation of the mobile object. For example, when updating multiple software programs individually executed by multiple processors, if the update of the software for any one of the processors is not completed properly, or if an abnormality occurs in the updated software, synchronization between the processors by the new version of the software cannot be achieved, and the operation of the mobile object becomes impossible. Therefore, it is an object of the present application to prevent the operation of the mobile object from becoming impossible due to a software update failure of a plurality of processors in the mobile control device. The present application is for the purpose of improving safety in order to solve the above problems. And by extension, it contributes to the development of a sustainable transportation system by further improving traffic safety.

Means for Solving the Problems

[0005] As a first aspect for achieving the above object, a mobile control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, the mobile control device comprising: a software update unit that executes an update process for the first software and the second software; a software abnormality recognition unit that recognizes the 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 process is executed; and a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a target mobile object that is a control target by the mobile control device in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit. When the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of the secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When the software abnormality response unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal by the software abnormality recognition unit, as the abnormality response process, the first processor causes the old version of the first software stored in the first memory to be executed, and the second processor causes the old version of the second software stored in the second memory to be executed Examples of the mobile control device are given.

[0008] As a second aspect for achieving the above object, a movement control device includes a first processor, a first memory in which first software used by the first processor is stored, a second processor, and a second memory in which second software used by the second processor is stored. The movement control device further includes a software update unit that executes an update process for the first software and the second software, a software abnormality recognition unit that recognizes the 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 process is executed, and a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a target moving body, which is a control target of the movement control device, in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit. The software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal when the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective. When the software abnormality handling unit recognizes that the secure boot result of the valid first software stored in the first memory is defective and the secure boot result of the valid second software stored in the second memory is good by the software abnormality recognition unit, as the abnormality handling, the software abnormality handling unit performs a process of prohibiting execution of the first software by the first processor and causing the second processor to execute the second software. Examples include a movement control device .

[0009] In the above movement control device, the software abnormality handling unit may be configured to notify, by a notification unit provided in the target moving body, that the abnormality handling is being executed.

[0011] For achieving the above object, a 3 movement control method executed by a movement control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, the movement control method including: a software update step of executing an update process of the first software and the second software; a software abnormality recognition step of recognizing the 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 process is executed; and a software abnormality handling step of causing the first processor or the second processor to execute an abnormality handling process for operating a moving body, which is a control target of the movement control device, in a predetermined abnormality handling mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition step. See, when the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of the secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, it is recognized that the first software stored in the first memory or the second software stored in the second memory is abnormal. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When it is recognized by the software abnormality recognition step that the first software stored in the first memory or the second software stored in the second memory is abnormal, the software abnormality handling step performs, as the abnormality handling process, a process of causing the first processor to execute the first software of the old version stored in the first memory and causing the second processor to execute the second software of the old version stored in the second memory The movement control method includes the above steps. As a fourth aspect for achieving the above object, a movement control method executed by a movement control device including a first processor, a first memory in which first software used by the first processor is stored, a second processor, and a second memory in which second software used by the second processor is stored, the method including: a software update step of executing an update process for the first software and the second software; a software abnormality recognition step of recognizing the 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 process is executed; and a software abnormality response step of causing the first processor or the second processor to execute an abnormality response process for operating a moving body that is a control target of the movement control device in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition step. The software abnormality recognition step recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal when a secure boot result of the valid first software stored in the first memory or the valid second software stored in the second memory is defective. The software abnormality response step, when it is recognized by the software abnormality recognition step that the secure boot result of the valid first software stored in the first memory is defective and the secure boot result of the valid second software stored in the second memory is good, performs, as the abnormality response process, a process of prohibiting execution of the first software by the first processor and causing the second processor to execute the second software.

[0012] For achieving the above object, a 5As an aspect, a movement control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, a software update unit that executes update processing of the first software and the second software, and after the update processing is executed, a software abnormality recognition unit that recognizes the presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, and when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit, a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a moving body, which is a control target of the movement control device, in a predetermined abnormality response mode, is made to function When the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of the secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When the software abnormality response unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal by the software abnormality recognition unit, as the abnormality response process, the first processor is caused to execute the first software of the old version stored in the first memory, and the second processor is caused to execute the second software of the old version stored in the second memory A program is included. As a sixth aspect for achieving the above object, a movement control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, a software update unit that executes update processing of the first software and the second software, and after the update processing is executed, a software abnormality recognition unit that recognizes the presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory, and when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit, a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a moving body that is a control target by the movement control device in a predetermined abnormality response mode, and the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal when the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective. When the software abnormality recognition unit recognizes that the result of secure boot of the valid first software stored in the first memory is defective and the result of secure boot of the valid second software stored in the second memory is good, the software abnormality response unit includes a program that prohibits execution of the first software by the first processor and causes the second processor to execute the second software as the abnormality response process.

Effect of the Invention

[0013] According to the above movement control device, movement control method, and program, it is possible to suppress the operation of the moving body from becoming impossible when the update of the software in the movement control device is not completed normally.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Embodiment for Carrying Out the Invention

[0015] [1. Configuration of Movement Control Device] With reference to FIG. 1, the configuration of the movement control device 1 of the present embodiment will be described. The movement control device 1 is an ECU (Electronic Control Unit) that controls the operation of a moving body 100 (corresponding to the target moving body of the present disclosure). The moving body 100 is a vehicle, an aircraft, a ship, or the like. The moving body 100 is provided with a communication unit 5 that performs wireless communication with a moving body management server 310 or the like via a communication network 300, and a display 6 (corresponding to the notification unit of the present disclosure). The communication unit 5 and the display 6 are connected to the movement control device 1.

[0016] The movement control device 1 includes a first microcomputer 10 and a second microcomputer 20. The first microcomputer 10 has a first processor 11, a first memory 12, a first communication circuit 13, etc., and the second microcomputer 20 has a second processor 21, a second memory 22, a second communication circuit 23, etc. The first memory 12 stores an old version of the first software 121 and a new version of the first software 122 executed by the first processor 11. The first memory 12 and the second memory 22 are, for example, code flash memories.

[0017] The old version of the first software 121 and the new version of the first software 122 are software used by the first processor 11, and include a program for controlling the moving body 100, a dataset used for controlling the moving body 100, and the like.

[0018] In the second memory 22, the old version of the second software 221 and the new version of the second software 222 are software used by the second processor 21, and include a control program for the mobile body 100, a data set used for the control of the mobile body 100, and the like.

[0019] The old version of the first software 121 is stored in the area 12a of the first memory 12, and the new version of the first software 122 is stored in the area 12b of the first memory 12. In the area 12c of the first memory 12, a program for the boot (bootstrap) process of the first microcomputer 10 is stored. Also, the old version of the second software 221 is stored in the area 22a of the second memory 22, and the new version of the second software 222 is stored in the area 22b of the second memory 22. In the area 22c of the second memory 22, a program for the boot process of the second microcomputer 20 is stored.

[0020] In this way, by configuring the storage areas of the first software and the second software in the first memory 12 and the second memory 22 as a two-sided structure so that both the old version and the new version of the first software and the second software can be stored, as will be described later, when the update from the old version to the new version fails, the operation of the mobile body 100 can be continued using the old version of the first software and the second software.

[0021] An SS (start / stop) switch 2 for instructing the switching between the IG (IGNITION) on (power-on state) and IG off (power-off state) of the mobile body 100 is connected to the first microcomputer 10, and an operation signal of the SS switch 2 is input to the first microcomputer 10 via the input circuit 30. An IG relay 3 is connected to the second microcomputer 20, and the on and off of the IG relay 3 are controlled by a control signal output from the second microcomputer 20 via the output circuit 35, so that the IG on and IG off of the mobile body 100 are switched.

[0022] The output section of the output circuit 35 is connected to the input circuit 32, and a detection signal of the output state of the output circuit 35 (ON / OFF state of the IG relay 3) is input from the input circuit 32 to the second microcomputer 20. The output section of the IG relay 3 is connected to the input circuit 31, and a detection signal of the ON / OFF of the IG relay 3 is input from the input circuit 31 to the first microcomputer 10.

[0023] Further, the movement control device 1 is connected to another ECU 40 mounted on the moving body 100 by a communication line 41. The communication specifications between the movement control device 1 and another ECU 40 by the communication line 41 are, for example, CAN (Controller Area Network, registered trademark), CAN FD (CAN with Flexible Data Rate), LIN (Local Interconnect Network), Ethernet (registered trademark), FlexRay (registered trademark), etc.

[0024] The movement control device 1 can be connected to the terminal device 50 by a connection cable 51, and the operator W can operate the terminal device 50 to update from the old version to the new version of the first software and update from the old version to the new version of the second software.

[0025] Further, the movement control device 1 performs wireless communication with the moving body management server 310 via the communication network 300 by the communication unit 5 to update the first software and the second software by OTA (Over The Air). That is, the movement control device 1 downloads the new version of the first software from the moving body management server 310 to update the first software, and downloads the new version of the second software from the moving body management server 310 to update the second software.

[0026] [2. Software Update Timing] Referring to FIG. 2, the update timing of the first software and the second software will be described. Since the updates of the first software and the second software are performed by the same processing at the same timing, here, the first software and the second software are collectively referred to as software, the first microcontroller 10 and the second microcontroller 20 are collectively referred to as a microcontroller, and the first memory 12 and the second memory 22 are collectively referred to as a memory for description. The update of the first software is performed by the first processor 11 executing the program of the boot process stored in the area 12c of the first memory 12. The update of the second software is performed by the second processor 21 executing the program of the boot process stored in the area 22c of the second memory 22.

[0027] FIG. 2 shows, in chronological order along the time axis t, the sequence of the software update process by OTA. When the movement control device 1 recognizes the IG-ON operation of the SS switch 2 at t1, it starts the OTA sequence and executes configuration synchronization → download of repro data (data of the new version of the software) from the mobile body management server 310 → deletion of the software.

[0028] In FIG. 2, an example is shown in which the movement control device 1 performs software update by OTA when it recognizes the IG-ON operation of the SS switch 2. However, the software may be updated at other timings. For example, when the movement control device 1 receives a software update instruction signal transmitted from another ECU 40 via the communication line 41, a series of processes for software update by OTA, that is, startup and stop of the movement control device 1, and switching of the old and new version programs (including restart of the movement control device 1) may be performed.

[0029] In Figure 2, as shown by C1 to C5, the area of the memory where the old version of the software before update is stored is regarded as the A side, and the area of the memory where the new version of the software after update is stored is regarded as the B side. C1 shows the situation where the B side for storing the new version of the software is erased, and the erased area sequentially becomes a free area. The old version of the software that is valid (during startup) is stored on the A side.

[0030] Subsequently, the microcomputer starts writing the new version of the software to the B side, and after the writing is completed, it waits in the IG - OFF state. C2 shows the situation where the new version of the software is being written to the B side. At t2, when the microcomputer recognizes the IG - OFF operation of the SS switch 2, it performs a confirmation of permission to activate (such as confirming the presence or absence of errors in the downloaded new version of the software). Then, when the permission is confirmed, the microcomputer activates the new version of the software and resets itself. C3 shows the state where the writing of the new version of the software to the B side is completed, and the new version of the software becomes valid when the microcomputer is restarted next.

[0031] At t3, when the microcomputer recognizes the IG - ON operation of the SS switch 2, it confirms that the update of the software from the old version to the new version is completed, and switches the software to be started from the old version to the new version. C5 shows the state where the software that the microcomputer starts when IG - ON is switched from the old version of the software stored on the A side to the new version stored on the B side.

[0032] In the example shown in Figure 2, control for switching between IG - ON and IG - OFF is performed using the input of the operation of the SS switch 2 as a trigger, but it is not limited to this. The input means serving as the trigger can be replaced with other means. For example, a door switch, a switch (physical switch or touch switch) of a display unit provided inside the vehicle, a brake lever, an accelerator lever, or a portable device (such as a smartphone or a vehicle terminal) may be configured to perform control for switching between IG-ON and IG-OFF as input means triggered thereby.

[0033] Here, FIG. 3 shows the storage modes of the old version of the first software 121 and the new version of the first software 122 in the first memory 12, and the storage modes of the old version of the second software 221 and the new version of the second software 222 in the second memory 22. In the first memory 12, valid codes "01" are recorded in the headers and footers of the old version of the first software 121 stored on the A side. Also, valid codes "02" are recorded in the headers and footers of the new version of the first software 122 stored on the B side.

[0034] The valid code is recorded by adding 1 each time the software version is updated. For the footer, the valid code is recorded when the software activation is completed. Therefore, it is possible to confirm whether the software activation is completed or not based on the presence or absence of the recording of the valid code in the footer. In the example of FIG. 3, for the first software, since valid codes are recorded in the footers of the old version of the first software 121 and the new version of the first software 122, it can be confirmed that both activations are completed.

[0035] On the other hand, for the second software stored in the second memory 22, for the old version of the second software 221, valid codes "01" are recorded in the header and footer, but for the new version of the second software 222, no valid code is recorded in the footer (indeterminate). Therefore, it can be confirmed that the activation of the old version of the second software 221 is completed, but the activation of the new version of the second software 222 is not completed.

[0036] [3. Software Abnormality Handling] According to the flowcharts shown in FIGS. 4 to 6, the abnormality handling of the first software and the second software executed by the first processor 11 of the first microcomputer 10 and the second processor 21 of the second microcomputer 20 will be described. The first processor 11 functions as a software update unit, a software abnormality recognition unit, and a software abnormality handling unit of the present disclosure by executing the program of the boot process stored in the area 12c of the first memory 12, and the second processor 21 functions as such by executing the program of the boot process stored in the area 22c of the second memory 22, and executes the processing according to the flowcharts shown in FIGS. 4 to 6.

[0037] The processing executed by the software update unit corresponds to the software update step in the movement control method of the present disclosure, and the processing executed by the software abnormality recognition unit corresponds to the software abnormality recognition step in the movement control method of the present disclosure. The processing executed by the software abnormality handling unit corresponds to the software abnormality handling step in the movement control method of the present disclosure.

[0038] As shown in FIG. 3, the processing according to the flowcharts of FIGS. 4 to 6 is an abnormality handling process for dealing with the case where the update of the first software from the old version to the new version in the first microcomputer 10 was completed normally, but the update of the second software from the old version to the new version in the second microcomputer 20 was not completed normally.

[0039] As described above with reference to FIG. 2, when the IG-ON of the SS switch 2 is recognized at t1 and it is the update timing of the first software and the second software by OTA, the first processor 11 and the second processor 21 execute the processing according to the flowcharts shown in FIGS. 4 to 6.

[0040] In the example shown in FIG. 2, control for switching between IG-ON and IG-OFF is performed using the input of the operation of the SS switch 2 as a trigger, but it is not limited to this. The input means serving as the trigger can be replaced with other means. For example, a door switch, a switch (physical switch or touch switch) of a display unit provided inside the vehicle, a brake lever, an accelerator lever, or a portable device (such as a smartphone or a vehicle terminal) may be configured to perform control for switching between IG-ON and IG-OFF as the input means serving as the trigger. The first processor 11 and the second processor 21 Moving body recognize IG-ON and IG-OFF from the state of the power supply of 100, and execute the processing according to the flowcharts of FIGS. 4 to 6 when it is the software update timing of the first software and the second software by OTA.

[0041] In step S1 of FIG. 4, the first processor 11 writes the new version of the first software 122 downloaded from the mobile body management server 310 to the B surface 12b of the first memory 12. In the subsequent step S2, the first processor 11 activates the new version of the first software 122 and completes the activation.

[0042] Similarly, in step S51, the second processor 21 writes the new version of the second software 222 downloaded from the mobile body management server 310 to the B surface 22b of the second memory 22. In the subsequent step S52, the second processor 21 starts the activation of the new version of the second software 222, but an abnormality of E1 (such as momentary interruption of the battery, reset of the WDT (Watchdog Timer), etc.) occurs before the activation is completed. Therefore, the activation of the new version of the second software 222 is in an incomplete state. The configuration for executing steps S1, S2 and steps S51, S52 corresponds to the software update unit of the present disclosure.

[0043] In step S3, the first processor 11 restarts the first microcomputer 10. In the subsequent step S 4 , the first processor 11 determines, by booting up, that the valid first software is a new version (see FIG. 3). Similarly, in step S54, the second processor 21 restarts the second microcomputer 20. In the subsequent step S54, the second microcomputer 20 determines, by booting up, that the valid second software is an old version (see FIG. 3).

[0044] In the next steps S5 and S55, the first processor 11 and the second processor 21 transmit and receive to each other the versions of the valid first software and the second software. Then, the first processor 11 and the second processor 21 determine whether the versions of the valid first software and the second software match.

[0045] In the subsequent step S6, the first processor 11 recognizes a mismatch between the versions of the valid first software and the second software. Here, as shown in FIG. 3, since the first software valid in the first microcomputer 10 is a new version, the first processor 11 recognizes that the version of the second software valid in the second microcomputer 20 is an old version. The processes of executing steps S4 to S6 and steps S54 to S56 correspond to the software abnormality recognition unit of the present disclosure.

[0046] The first processor 11 that has recognized a mismatch between the versions of the valid first software and the second software performs, in the next step S7, a rollback process of making the new version of the first software 122 stored on the B side 12b incomplete activation. The configuration for executing the process of step S7 corresponds to the software abnormality countermeasure unit of the present disclosure.

[0047] As a result, as shown in FIG. 3, the valid code recorded in the footer of the new version of the first software 122 stored on the B surface 12b of the first memory 12 is changed from "02" to "indeterminate". In the subsequent step S8, the first processor 11 resets the first microcomputer 10, and in step S9, the first microcomputer 10 restarts.

[0048] On the other hand, in step S56, the second processor 21 recognizes a version mismatch between the first software and the second software that are valid. Here, as shown in FIG. 3, since the second software that is valid in the second microcomputer 20 is the old version, the second processor 21 determines that a rollback process is unnecessary. In the subsequent step S21, the second processor 21 resets the second microcomputer 20, and in step S58, the second microcomputer 20 restarts.

[0049] In step S10 of FIG. 5, the first processor 11 determines the first software that is valid by boot-up, and determines that the old version of the first software 121 is valid. Also, in step S59, the second processor 21 determines the second software that is valid by boot-up, and determines that the old version of the second software 221 is valid.

[0050] In the next steps S11 and S60, the first processor 11 and the second processor 21 transmit and receive to each other the versions of the first software and the second software that are valid. Then, the first processor 11 and the second processor 21 determine whether the versions of the first software and the second software that are valid match.

[0051] In the subsequent step S12, the first processor 11 recognizes that the versions of the first software and the second software that are in effect match. Also, in step S61, the second processor 21 recognizes that the versions of the first software and the second software that are in effect match. In the next step S13, the first processor 11 performs secure boot processing on the first software 121 of the old version to verify the reliability (such as the presence or absence of forgery) of the first software 121 of the old version.

[0052] Also, in step S62, the second processor 21 performs secure boot processing on the second software 221 of the old version to detect the reliability of the second software 221 of the old version. In the subsequent steps S14 and S63, the first processor 11 and the second processor 21 transmit and receive the results of the secure boot processing to each other and compare the results of the secure boot processing of the first software 121 of the old version and the second software 221 of the old version. The configuration that executes the processes of steps S10 to S14 and steps S59 to S63 in FIG. 5 corresponds to the software abnormality countermeasure unit of the present disclosure.

[0053] In the subsequent step S15 in FIG. 6, the first processor 11 determines whether the result of the secure boot of itself (the first software 121 of the old version) is OK (no abnormality). Then, when the result of the secure boot is OK, the first processor 11 proceeds to step S16 for processing, and when the result of the secure boot is NG (abnormality exists), the first processor 11 proceeds to step S20 for processing.

[0054] In step S20, the first processor 11 resets the first microcomputer 10 and re-executes the processes after the secure boot processing in step S13 of FIG. 5. The first processor 11 retries the processes after the secure boot processing in step S13 of FIG. 5 a predetermined number of times until the result of the secure boot processing becomes OK.

[0055] In step S16, the first processor 11 determines whether the result of the secure boot of the counterpart (the second software 221 of the old version) is OK. Then, when the result of the secure boot of the counterpart is OK, the first processor 11 proceeds to step S17 and continues to control the normal operation of the moving body 100 by the first software 121 of the old version.

[0056] On the other hand, when the result of the secure boot of the counterpart is NG, the first processor 11 proceeds to step S21, executes the first software 121 of the old version, and activates only the functions of the moving body 100 assigned to itself (the first microcomputer 10) (function degradation). In the subsequent step S22, the first processor 11 notifies, by display on the display 6, that the moving body 100 is operating due to function degradation.

[0057] Here, the functions of the moving body 100 assigned to the first microcomputer 10 are, for example, wipers, headlights, security alarms, door locks, partial diagnosis, etc. Also, the normal operation of the first microcomputer 10, in addition to the above functions, includes updating (reprogramming) of the first software by wired or OTA, diagnosis (such as unlocking the security of the diagnostic line), etc.

[0058] Similarly, in step S64, the second processor 21 determines whether the result of the secure boot of itself (the second software 221 of the old version) is OK. Then, when the result of the secure boot is OK, the second processor 21 proceeds to step S65, and when the result of the secure boot is NG, the second processor 21 proceeds to step S70.

[0059] In step S70, the second processor 21 resets the second microcomputer 20 and executes again the processes after the secure boot process of step S62 in FIG. 5. The second processor 21 retries the processes after step S62 in FIG. 5 a predetermined number of times until the result of the secure boot process becomes OK.

[0060] In step S65, the second processor 21 determines whether or not the result of the secure boot of the counterpart (the first software 121 of the old version) is OK. Then, when the result of the secure boot of the counterpart is OK, the second processor 21 advances the process to step S66 and continues to control the normal operation of the moving body 100 by the second software 221 of the old version.

[0061] By the processes of step S17 and step S66, when the update of the second software fails, the operation of the moving body 100 can be continued using the first software and the second software of the old version. By step S17 and step S66, the mode of operating the moving body 100 using the first software 121 and the second software 221 of the old version corresponds to the abnormality handling mode of the present disclosure.

[0062] On the other hand, when the result of the secure boot of the counterpart is NG, the second processor 21 advances the process to step S71, executes the second software 221 of the old version, and operates only the functions of the moving body 100 assigned to itself (the second microcomputer 20) (function degradation). In subsequent step S72, the second processor 21 notifies, by display on the display 6, that the moving body 100 is operating due to function degradation.

[0063] By the processes of step S21 and step S71, when the result of the secure boot of the first software or the second software of the old version is NG, the operation of the moving body 100 can be continued by function degradation. The configuration that executes the processes of step S21, step S22 and step S71, step S72 in FIG. 6 corresponds to the software abnormality handling part of the present disclosure. In step S21 and step S71, the mode of operating the moving body 100 by function degradation using the first software 121 or the second software 221 of the old version corresponds to the abnormality handling mode of the present disclosure.

[0064] In the flowcharts of FIGS. 4 to 6, as shown in FIG. 3, the processes corresponding to the case where the update of the second software is not completed normally are shown. However, when the update of the first software is not completed normally, the second processor 21 executes a rollback process similar to step S7 in FIG. 5 for the second software. Then, the operation of the mobile body 100 is controlled using the old versions of the first software and the second software.

[0065] [4. Other Embodiments] In the above embodiment, when the update of the first software or the second software is not completed normally, the rollback process in step S7 of FIG. 4 and the function degradation processes in steps S21 and S71 of FIG. 6 are executed. However, a configuration may be adopted in which only one of the rollback process or the function degradation process is executed. When the rollback process is not performed, in the secure boot processes in steps S13 and S62 of FIG. 5, it is determined whether the first software and the second software that are enabled version match. If they do not match, a function degradation process is executed to operate the mobile body 100 by executing only one of the first software and the second software. When the rollback process is not performed, as shown in FIGS. 1 to 3, it is not necessary to configure the first memory 12 and the second memory 22 in a two-sided structure.

[0066] In the above embodiment, when the result of the secure boot of the first software or the second software is NG, the function degradation process is performed in steps S22 and S72 of FIG. 6. However, a configuration may be adopted in which a rollback process is performed similar to step S7 in FIG. 4, and the mobile body 100 is operated using the old versions of the first software and the second software.

[0067] In the above embodiment, in step S22 and step S72 of FIG. 6, it was notified by the display on the display 6 that the mobile body 100 was operating due to functional degradation. As another embodiment, instead of or in addition to the notification by the display 6, notification by voice output from a speaker provided in the mobile body 100 may be performed. Alternatively, the notification that the mobile body 100 is operating due to functional degradation may be omitted.

[0068] Note that FIG. 1 is a schematic diagram showing the configuration of the movement control device 1 divided according to the main processing contents for easy understanding of the present invention, and the movement control device 1 may be configured by other divisions. Further, the processing of each component may be executed by one hardware unit or by a plurality of hardware units. Also, the processing by each component shown in FIGS. 4 to 6 may be executed by one program or by a plurality of programs.

[0069] [5. Configuration Supported by the Above Embodiment] The above embodiment is a specific example of the following configuration.

[0070] (Configuration 1) A mobile control device comprising a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, the mobile control device further comprising: a software update unit that executes an update process for the first software and the second software; a software abnormality recognition unit that recognizes the 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 process has been executed; and a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a target moving body, which is a control target of the mobile control device, in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit. According to the mobile control device of Configuration 1, it is possible to suppress the operation of the target moving body from becoming impossible when the update of the first software or the second software is not completed normally.

[0071] (Configuration 2) The mobile control device according to Configuration 1, wherein the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal when the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective. According to the movement control device of Configuration 2, when the versions of the first software and the second software that are in effect are different because the update process of the first software or the second software has not been completed normally, it is possible to recognize that the first software or the second software is abnormal. Also, when the result of the secure boot of the first software or the second software that is in effect is defective, it is possible to recognize that the first software or the second software is abnormal.

[0072] (Configuration 3) In the first memory, an area for storing the new version of the first software updated by the update process and an area for storing the old version of the first software before being updated by the update process are set. In the second memory, an area for storing the new version of the second software updated by the update process and an area for storing the old version of the second software before being updated by the update process are set. When the software abnormality handling unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal because the versions of the effective first software and the second software stored in the second memory are different due to the software abnormality recognition unit, as the abnormality handling process, the first processor causes the first software of the old version stored in the first memory to be executed, and the second processor causes the second software of the old version stored in the second memory to be executed. The movement control device according to Configuration 2 that performs the process. According to the movement control device of Configuration 3, when the update to the new version of the first software or the second software has not been completed normally and the versions of the effective first software and the second software are different, the first processor and the second processor can execute the old versions of the first software and the second software respectively to operate the target moving body.

[0073] (Configuration 4) When the software abnormality handling unit recognizes that the secure boot result of the valid first software stored in the first memory is defective and the secure boot result of the valid first software stored in the second memory is good by the software abnormality recognition unit, as the abnormality handling process, the movement control device according to Configuration 2 or Configuration 3 that prohibits the execution of the first software by the first processor and causes the second software to be executed by the second processor. According to the movement control device of Configuration 4, when a defect in 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 defect has not been recognized.

[0074] (Configuration 5) The movement control device according to Configuration 4, wherein the software abnormality handling unit notifies the target moving body of the execution of the abnormality handling process by a notification unit provided in the target moving body. According to the movement control device of Configuration 5, for example, it is possible to notify a user riding on the target moving body that the operation of the target moving body is restricted because the first software is not being executed.

[0075] (Configuration 6) In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the previous old version updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the previous old version updated by the update process are set. When the software abnormality handling unit recognizes that the result of the secure boot of the first software of the new version stored in the first memory or the second software of the new version stored in the second memory is defective in a state where the first software of the new version is stored as the valid first software in the first memory and the second software of the new version is stored as the valid second software in the second memory, as the abnormality handling process, the first processor causes the first software of the old version stored in the first memory to be executed, and the second processor causes the second software of the old version stored in the second memory to be executed. The movement control device according to Configuration 2 or Configuration 3 as described above. According to the movement control device of Configuration 6, after the update to the new version of the first software or the second software is completed, when the result of the secure boot of the valid first software or second software becomes defective, the first processor and the second processor can execute the first software and the second software of the old version respectively to operate the target moving body.

[0076] (Configuration 7) A movement control method executed by a movement control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor, the method comprising: a software update step of executing an update process for the first software and the second software; a software abnormality recognition step of recognizing the 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 process is executed; and a software abnormality response step of causing the first processor or the second processor to execute an abnormality response process for operating a moving body that is a control target of the movement control device in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition step. By executing the movement control method of Configuration 7 by the movement control device, an operation configuration similar to that of the movement control device of Configuration 1 can be obtained.

[0077] (Configuration 8) A program for causing a movement control device including a first processor, a first memory storing first software used by the first processor, a second processor, and a second memory storing second software used by the second processor to function as a software update unit that executes an update process for the first software and the second software, a software abnormality recognition unit that recognizes the 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 process is executed, and a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a moving body that is a control target of the movement control device in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit. By executing the program of Configuration 8 with the movement control device, the configuration of the movement control device of Configuration 1 can be realized.

Explanation of Signs

[0078] 1…Movement control device, 2…SS switch, 3…IG relay, 5…Communication unit, 6…Display (notification unit), 10…First microcomputer, 11…First processor, 12…First memory, 13…First communication circuit, 20…Second microcomputer, 21…Second processor, 22…Second memory, 23…Second communication circuit, 30, 32, 33…Input circuit, 35…Output circuit, 50…Terminal device, 100…Moving body, 121…First software of old version, 122…First software of new version, 221…Second software of old version, 222…Second software of new version, 300…Communication network, 310…Moving body management server, W…Operator.

Claims

1. A first processor, a first memory storing first software used by the first processor, a second processor, a second memory storing second software used by the second processor, A mobile control device comprising: a software update unit that executes an update process for the first software and the second software; a software abnormality recognition unit that recognizes the 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 process is executed; a software abnormality response unit that causes the first processor or the second processor to execute an abnormality response process for operating a target moving body, which is a control target of the mobile control device, in a predetermined abnormality response mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit; and comprising: When the software abnormality recognition unit determines that the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When the software abnormality handling unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal by the software abnormality recognition unit, as the abnormality handling process, the first processor causes the first memory to execute the old version of the first software stored therein, and the second processor causes the second memory to execute the old version of the second software stored therein. Mobile control device.

2. A first processor, A first memory in which the first software used by the first processor is stored, A second processor, A second memory in which the second software used by the second processor is stored, A mobile control device comprising: A software update unit that executes an update process for the first software and the second software; After the update process is executed, a software abnormality recognition unit that recognizes the presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory; When the software abnormality recognition unit recognizes an abnormality in the first software stored in the first memory or the second software stored in the second memory, the first processor or the second processor executes an abnormality handling process for operating a target moving body, which is a control target of the mobile control device, in a predetermined abnormality handling mode. A software abnormality handling unit; Comprising When the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. When the software abnormality handling unit recognizes, based on the result of secure boot of the valid first software stored in the first memory being defective and the result of secure boot of the valid second software stored in the second memory being good, by the software abnormality recognition unit, as the abnormality handling process, it prohibits the execution of the first software by the first processor and causes the second processor to execute the second software. Mobile control device.

3. The software abnormality handling unit notifies, via a notification unit provided in the target mobile body, that the abnormality handling process is being executed. The mobile control device according to claim 2.

4. A first processor, A first memory in which the first software used by the first processor is stored, A second processor, A second memory in which the second software used by the second processor is stored, A mobile control method executed by a mobile control device including: A software update step of executing an update process for the first software and the second software; After the update process is executed, a software abnormality recognition step of recognizing the presence or absence of abnormalities in the first software stored in the first memory and the second software stored in the second memory; A software abnormality handling step of causing the first processor or the second processor to execute an abnormality handling process for operating a mobile body, which is a control target of the mobile control device, in a predetermined abnormality handling mode when an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized in the software abnormality recognition step; Including The software abnormality recognition step recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal when the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When the software abnormality response step recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal by the software abnormality recognition step, as the abnormality response process, the first processor causes the first software of the old version stored in the first memory to be executed, and the second processor causes the second software of the old version stored in the second memory to be executed. Mobile body control method.

5. A first processor, A first memory in which the first software used by the first processor is stored, A second processor, A second memory in which the second software used by the second processor is stored, A mobile body control method executed by a mobile body control device including: A software update step for executing an update process of the first software and the second software; After the update process is executed, a software abnormality recognition step for recognizing the presence or absence of an abnormality in the first software stored in the first memory and the second software stored in the second memory; When an abnormality in the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition step, a software abnormality response step for causing the first processor or the second processor to execute an abnormality response process for operating a mobile body, which is a control target of the mobile body control device, in a predetermined abnormality response mode; Including When the result of the secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective in the software abnormality recognition step, it is recognized that the first software stored in the first memory or the second software stored in the second memory is abnormal. When it is recognized in the software abnormality response step that the result of the secure boot of the valid first software stored in the first memory is defective and the result of the secure boot of the valid second software stored in the second memory is good in the software abnormality recognition step, as the abnormality response process, the execution of the first software by the first processor is prohibited and the second software is executed by the second processor. Moving body control method.

6. A first processor, A first memory in which the first software used by the first processor is stored, A second processor, A second memory in which the second software used by the second processor is stored, A mobile body control device comprising: A software update unit that executes the update process of the first software and the second software; After the update process is executed, a software abnormality recognition unit that recognizes the presence or absence of abnormality of the first software stored in the first memory and the second software stored in the second memory; When an abnormality of the first software stored in the first memory or the second software stored in the second memory is recognized by the software abnormality recognition unit, the first processor or the second processor executes an abnormality response process for operating the mobile body, which is a control target of the mobile body control device, in a predetermined abnormality response mode. When the version of the valid first software stored in the first memory is different from the version of the valid second software stored in the second memory, or when the result of the secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. In the first memory, an area for storing the first software of the new version updated by the update process and an area for storing the first software of the old version before being updated by the update process are set. In the second memory, an area for storing the second software of the new version updated by the update process and an area for storing the second software of the old version before being updated by the update process are set. When the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal, the software abnormality handling unit performs, as the abnormality handling process, a process of causing the first processor to execute the first software of the old version stored in the first memory and causing the second processor to execute the second software of the old version stored in the second memory. Program.

7. A first processor; A first memory in which the first software used by the first processor is stored; A second processor; A second memory in which the second software used by the second processor is stored; A mobile control device including: A software update unit that executes an update process for the first software and the second software; A software abnormality recognition unit that recognizes the presence or absence of abnormality of the first software stored in the first memory and the second software stored in the second memory after the update process is executed. When the software abnormality recognition unit recognizes an abnormality in the first software stored in the first memory or the second software stored in the second memory, the first processor or the second processor executes an abnormality handling process for operating the moving body, which is a control target of the movement control device, in a predetermined abnormality response mode, and functions as a software abnormality response unit. When the result of secure boot of the valid first software stored in the first memory or the valid second software stored in the second memory is defective, the software abnormality recognition unit recognizes that the first software stored in the first memory or the second software stored in the second memory is abnormal. When the software abnormality response unit recognizes that the result of secure boot of the valid first software stored in the first memory is defective and the result of secure boot of the valid second software stored in the second memory is good, as the abnormality handling process, the software abnormality response unit prohibits the execution of the first software by the first processor and causes the second processor to execute the second software. Program.

Images