Mobile body controller, mobile body 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 mobile object control device, a mobile object control method, and a program. [Background technology]

[0002] Conventionally, a technology for supporting software updates in a control device mounted on a moving body such as a vehicle has been proposed. For example, Patent Document 1 discloses a configuration in which an area for storing a program currently being executed and an area for storing an update program are set in a storage unit that stores a program executed by an ECU (Electronic Control Unit) mounted on a vehicle. With this configuration, it is possible to store an update program in the storage unit even while a program is being executed, and it is said that this reduces constraints on the timing of updating the program. [Prior art documents] [Patent documents]

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

[0004] Since the software such as programs used in the mobile object control device includes important software that performs the basic operation of the mobile object, if the software update is not performed normally, the operation of the mobile object may be hindered. For example, when updating multiple pieces of software executed individually by multiple processors, if the update of the software for any of the processors is not completed normally, or if an abnormality occurs in the software after the update, the processors cannot be synchronized with the new version of the software, and the mobile object cannot operate. Therefore, the object of the present application is to prevent the mobile object from becoming unable to operate due to a malfunction in updating the software of multiple processors in the mobile object control device. The present application aims to improve safety in order to solve the above problems, and by extension, to further improve traffic safety and contribute to the development of a sustainable transportation system. [Means for solving the problem]

[0005] As a first aspect for achieving the above-mentioned object, there is provided a mobile body control device comprising 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 mobile body control device comprising: a software update unit that executes an update process for the first software and the second software; a software anomaly recognition unit that recognizes the presence or absence of anomalies 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 anomaly response unit that, when an anomaly is recognized by the software anomaly recognition unit in the first software stored in the first memory or the second software stored in the second memory, causes the first processor or the second processor to execute an anomaly response process for operating a target mobile body that is the object of control by the mobile body control device in a predetermined anomaly response mode.

[0006] In the above-mentioned mobile object control device, the software abnormality recognition unit may be configured to recognize that the first software stored in the first memory or the second software stored in the second memory is abnormal when a version of the valid first software stored in the first memory is different from a version of the valid second software stored in the second memory, or when a 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 poor.

[0007] In the above-mentioned mobile body control device, the first memory is configured to store an area for storing a new version of the first software updated by the update process and an area for storing an old version of the first software before being updated by the update process, and the second memory is configured to store an area for storing a new version of the second software updated by the update process and an area for storing an old version of the second software before being updated by the update process, and the software abnormality response unit may be configured to perform, as the abnormality response process, a process of causing the first processor to execute the old version of the first software stored in the first memory and causing the second processor to execute the old version of the second software stored in the second memory 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 because a valid version of the first software stored in the first memory is different from a valid version of the second software stored in the second memory.

[0008] In the above-mentioned mobile body control device, the software anomaly response unit may be configured to perform, as the anomaly response processing, a process of prohibiting execution of the first software by the first processor and causing the second processor to execute the second software when the software anomaly recognition unit recognizes that the result of secure boot of the valid first software stored in the first memory is bad and the result of secure boot of the valid first software stored in the second memory is good.

[0009] In the above mobile object control device, the software anomaly response unit may be configured to notify the fact that the anomaly response process is being executed by a notification unit provided in the target mobile object.

[0010] In the above-mentioned mobile body control device, the first memory is configured to have an area for storing a new version of the first software updated by the update process and an area for storing an old version of the first software before being updated by the update process, and the second memory is configured to have an area for storing a new version of the second software updated by the update process and an area for storing an old version of the second software before being updated by the update process, and the software abnormality response unit may be configured to, when the new version of the first software is stored in the first memory as the valid first software and the new version of the second software is stored in the second memory as the valid second software, and when the software abnormality recognition unit recognizes that the result of 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 is poor, perform a process of causing the first processor to execute the old version of the first software stored in the first memory and causing the second processor to execute the old version of the second software stored in the second memory as the abnormality response process.

[0011] As a second aspect for achieving the above object, there is provided a mobile body control method executed by a mobile body control device having a first processor, a first memory in which first software used by the first processor is stored, and a second processor, a second memory in which second software used by the second processor is stored, the mobile body control method including: a software update step of executing an update process for the first software and the second software; a software anomaly recognition step of recognizing the presence or absence of anomalies 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 anomaly response step of causing the first processor or the second processor to execute an anomaly response process for operating a mobile body that is the target of control by the mobile body control device in a predetermined anomaly response mode when an anomaly is recognized in the software anomaly recognition step in the first software stored in the first memory or the second software stored in the second memory.

[0012] As a third aspect for achieving the above object, there is provided a program for causing a mobile body control device having 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 to function as a software update unit that executes an update process for the first software and the second software, a software anomaly recognition unit that recognizes the presence or absence of anomalies 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 anomaly response unit that causes the first processor or the second processor to execute an anomaly response process to operate a mobile body that is the target of control by the mobile body control device in a predetermined anomaly response mode when the software anomaly recognition unit recognizes an anomaly in the first software stored in the first memory or the second software stored in the second memory. Effect of the Invention

[0013] According to the above-described mobile body control device, mobile body control method, and program, it is possible to prevent the mobile body from becoming unable to operate when a software update in the mobile body control device is not completed normally. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a configuration diagram of a mobile object control device. [Diagram 2] FIG. 2 is a timing chart of the software update process in the mobile object control device. [Diagram 3] FIG. 3 is an explanatory diagram of how software is stored in memory. [Figure 4] FIG. 4 is a first flowchart of anomaly handling processing of the software executed in the first microcomputer and the second microcomputer. [Diagram 5] FIG. 5 is a second flowchart of the abnormality handling process of the software executed in the first microcomputer and the second microcomputer. [Figure 6] FIG. 6 is a third flowchart of the abnormality handling process of the software executed in the first microcomputer and the second microcomputer. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] [1. Configuration of the mobile control device] The configuration of a mobile object control device 1 of this embodiment will be described with reference to Fig. 1. The mobile object control device 1 is an ECU (Electronic Control Unit) that controls the operation of a mobile object 100 (corresponding to a target mobile object in this disclosure). The mobile object 100 is a vehicle, an aircraft, a ship, or the like. The mobile object 100 is equipped with a communication unit 5 that performs wireless communication with a mobile object management server 310, etc., via a communication network 300, and a display 6 (corresponding to a notification unit in this disclosure). The communication unit 5 and the display 6 are connected to the mobile object control device 1.

[0016] The mobile object 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, etc., and the second microcomputer 20 includes a second processor 21, a second memory 22, a second communication circuit 23, etc. The first memory 12 stores an old version of first software 121 executed by the first processor 11 and a new version of first software 122. 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 data set used to control 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 moving body 100, data sets used to control the moving body 100, etc.

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

[0020] In this way, the storage areas for the first software and the second software in the first memory 12 and the second memory 22 are configured as a two-sided structure capable of storing both old and new versions of the first software and the second software. As described below, if an update from an old version to a new version fails, the operation of the mobile body 100 can be continued using the old versions of the first software and the second software.

[0021] An SS (start / stop) switch 2 that instructs switching the IG (IGNITION) of the moving object 100 between on (power on state) and off (power off state) is connected to the first microcomputer 10, and an operation signal of the SS switch 2 is input to the first microcomputer 10 via an input circuit 30. An IG relay 3 is connected to the second microcomputer 20, and the 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, thereby switching the IG of the moving object 100 between on and off.

[0022] An 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. An output section of the IG relay 3 is connected to the input circuit 31, and a detection signal of the on / off state of the IG relay 3 is input from the input circuit 31 to the first microcomputer 10.

[0023] Furthermore, the mobile body control device 1 is connected to another ECU 40 mounted on the mobile body 100 via a communication line 41. The communication specifications between the mobile body control device 1 and the other ECU 40 via 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 mobile object control device 1 can be connected to a terminal device 50 via a connection cable 51, and a worker W can operate the terminal device 50 to update the first software from an old version to a new version, and update the second software from an old version to a new version.

[0025] Furthermore, the mobile object control device 1 performs over-the-air (OTA) updates of the first software and the second software by performing wireless communication with the mobile object management server 310 via the communication network 300 using the communication unit 5. That is, the mobile object control device 1 downloads a new version of the first software from the mobile object management server 310 to update the first software, and downloads a new version of the second software from the mobile object management server 310 to update the second software.

[0026] [2. Software update timing] The timing of updating the first software and the second software will be described with reference to Fig. 2. The first software and the second software are updated at the same timing by the same process, so that the first software and the second software will be collectively referred to as software, the first microcomputer 10 and the second microcomputer 20 will be collectively referred to as microcomputer, and the first memory 12 and the second memory 22 will be collectively referred to as memory. The first software is updated by the first processor 11 executing a boot process program stored in the area 12c of the first memory 12. The second software is updated by the second processor 21 executing a boot process program stored in the area 22c of the second memory 22.

[0027] 2 shows the sequence of the OTA software update process in chronological order along the time axis t. When the mobile 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 management server 310 → erasure of the software.

[0028] 2 shows an example in which the mobile object control device 1 performs software update by OTA when it recognizes the IG-ON operation of the SS switch 2, but software update may be performed at other times. For example, when the mobile object control device 1 receives a software update instruction signal transmitted from another ECU 40 via the communication line 41, a series of processes for updating software by OTA, that is, starting and stopping the mobile object control device 1 and switching between the old and new versions of the program (including restarting the mobile object control device 1), may be performed.

[0029] In Figure 2, as shown by C1 to C5, the memory area where the old version of the software before the update is stored is called side A, and the memory area where the new version of the software after the update is stored is called side B. C1 shows the situation where side B, which stores the new version of the software, is erased, and the erased area gradually becomes free space. The active (running) old version of the software is stored on side A.

[0030] Next, the microcontroller starts writing the new version of the software to side B, and after writing is complete, it enters a state of waiting for IG-OFF. C2 shows the state where the new version of the software has been written to side B. At t2, when the microcontroller recognizes the IG-OFF operation of SS switch 2, it checks for permission to activate (such as checking for errors in the downloaded new version of the software). Then, when permission is confirmed, the microcontroller activates the new version of the software and resets itself. C3 shows the state where writing of the new version of the software to side B has been completed, and the new version of the software will become effective the next time the microcontroller is restarted.

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

[0032] 2, the control for switching between IG-ON and IG-OFF is performed using the operation input of the SS switch 2 as a trigger, but this is not limited to this. The input means for the trigger can be replaced with other means. For example, the control for switching between IG-ON and IG-OFF may be performed using a door switch, a switch on a display unit installed inside the vehicle (a physical switch or a touch switch), a brake lever, an accelerator lever, or a mobile device (a smartphone, a vehicle terminal device, etc.) as an input means triggered by the door switch, or the switch on a display unit installed inside the vehicle (a physical switch or a touch switch), a brake lever, an accelerator lever, or a mobile device (a smartphone, a vehicle terminal device, etc.).

[0033] 3 shows how the old version of the first software 121 and the new version of the first software 122 are stored in the first memory 12, and how the old version of the second software 221 and the new version of the second software 222 are stored in the second memory 22. In the first memory 12, the validity code "01" is recorded in the header and footer of the old version of the first software 121 stored on side A. Also, the validity code "02" is recorded in the header and footer of the new version of the first software 122 stored on side B.

[0034] The validity code is incremented by one each time the software version is updated. For the footer, the validity code is recorded when the software activation is completed. Therefore, it is possible to confirm whether the software activation is completed or not by checking whether the validity code is recorded in the footer. In the example of FIG. 3, for the first software, the validity code is recorded in the footer of the old version of the first software 121 and the new version of the first software 122, so it is possible to confirm that the activation is completed for both.

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

[0036] [3. Software Abnormality Response Processing] 4 to 6, anomaly response processing 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 executes a boot process program stored in an area 12c of the first memory 12, and the second processor 21 executes a boot process program stored in an area 22c of the second memory 22, thereby functioning as a software update unit, a software anomaly recognition unit, and a software anomaly response unit of the present disclosure, respectively, and executes the processing according to the flowcharts shown in FIGS.

[0037] The process executed by the software update unit corresponds to a software update step in the mobile object control method of the present disclosure, the process executed by the software anomaly recognition unit corresponds to a software anomaly recognition step in the mobile object control method of the present disclosure, and the process executed by the software anomaly response unit corresponds to a software anomaly response step in the mobile object control method of the present disclosure.

[0038] The processing according to the flowcharts of Figures 4 to 6 is an abnormality response processing for dealing with the case where the update of the first software in the first microcontroller 10 from the old version to the new version is completed successfully, as shown in Figure 3, but the update of the second software in the second microcontroller 20 from the old version to the new version is not completed successfully.

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

[0040] 2, the control for switching between IG-ON and IG-OFF is performed using the operation input of the SS switch 2 as a trigger, but this is not limited to this. The input means for the trigger can be replaced with other means. For example, the control for switching between IG-ON and IG-OFF may be performed using a door switch, a switch on a display unit installed inside the vehicle (a physical switch or a touch switch), a brake lever, an accelerator lever, or a mobile device (a smartphone, a vehicle terminal device, etc.) as an input means triggered by the door switch, or the switch on a display unit installed inside the vehicle (a physical switch or a touch switch), a brake lever, an accelerator lever, or a mobile device (a smartphone, a vehicle terminal device, etc.). The first processor 11 and the second processor 21 recognize IG-ON or IG-OFF from the power supply state of the vehicle 100, and when it is time to update the first software and second software via OTA, execute the processing according to the flowcharts of Figures 4 to 6.

[0041] 4, the first processor 11 writes the new version of the first software 122 downloaded from the mobile unit management server 310 to the B side 12b of the first memory 12. In the following 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 unit management server 310 to the B side 22b of the second memory 22. In the following step S52, the second processor 21 starts activation of the new version of the second software 222, but before the activation is completed, an E1 abnormality (such as a battery interruption or a WDT (Watchdog Timer) reset) occurs. Therefore, the activation of the new version of the second software 222 is in an incomplete state. The configuration that executes steps S1, S2 and steps S51, S52 corresponds to a software update unit in the present disclosure.

[0043] In step S3, the first processor 11 restarts the first microcomputer 10. In the following step S3, the first processor 11 determines, through boot startup, that the valid first software is the new version (see FIG. 3). Similarly, in step S54, the second processor 21 restarts the second microcomputer 20. In the following step S54, the second microcomputer 20 determines, through boot startup, that the valid second software is the 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 the enabled first software version and the enabled second software version to each other. Then, the first processor 11 and the second processor 21 determine whether the enabled first software version and the enabled second software version match.

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

[0046] The first processor 11, having recognized the inconsistency between the enabled versions of the first software and the second software, performs a rollback process in the next step S7 to make the activation of the new version of the first software 122 stored on the B side 12b incomplete. The configuration that executes the process of step S7 corresponds to the software anomaly response unit of the present disclosure.

[0047] 3, the validity code recorded in the footer of the new version of the first software 122 stored on side B 12b of the first memory 12 is changed from "02" to "undefined." In the following step S8, the first processor 11 resets the first microcomputer 10, and in step S9, the first microcomputer 10 is restarted.

[0048] Meanwhile, the second processor 21 recognizes in step S56 that the versions of the enabled first software and the second software do not match. Here, as shown in Fig. 3, the second software enabled in the second microcomputer 20 is an older version, so the second processor 21 determines that rollback processing is unnecessary. In the following step S21, the second processor 21 resets the second microcomputer 20, and the second microcomputer 20 restarts in step S58.

[0049] 5, the first processor 11 determines which first software is valid by booting and determines that the old version of the first software 121 is valid. Also, in step S59, the second processor 21 determines which second software is valid by booting 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 the enabled first software version and the enabled second software version to each other. Then, the first processor 11 and the second processor 21 determine whether the enabled first software version and the enabled second software version match.

[0051] In the next step S12, the first processor 11 recognizes that the versions of the enabled first software and the second software match. In addition, in step S61, the second processor 21 recognizes that the versions of the enabled first software and the second software match. In the next step S13, the first processor 11 performs a secure boot process for the old version of the first software 121 to verify the reliability of the old version of the first software 121 (whether it has been tampered with, etc.).

[0052] Furthermore, in step S62, the second processor 21 performs secure boot processing of the old version of the second software 221 to detect the reliability of the old version of the second software 221. In the following 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 old version of the first software 121 and the old version of the second software 221. The configuration that executes the processing of steps S10 to S14 and steps S59 to S63 in Fig. 5 corresponds to a software anomaly response unit of the present disclosure.

[0053] 6, the first processor 11 determines whether the result of the secure boot of itself (the old version of the first software 121) is OK (no abnormality). If the result of the secure boot is OK, the first processor 11 proceeds to step S16, and if the result of the secure boot is NG (no abnormality), the first processor 11 proceeds to step S20.

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

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

[0056] On the other hand, if the result of the secure boot of the other party is NG, the first processor 11 advances the process to step S21, executes the old version of the first software 121, and operates only the functions of the moving object 100 assigned to itself (the first microcomputer 10) (functional degeneration). In the following step S22, the first processor 11 notifies the display 6 that the moving object 100 is operating with functional degeneration.

[0057] Here, the functions of the moving object 100 assigned to the first microcomputer 10 are, for example, windshield wipers, headlights, security alarms, door locks, partial diagnosis, etc. In addition to the above functions, the normal operation of the first microcomputer 10 is updating (reprogramming) the first software via wire or OTA, diagnosis (such as disabling security on the diagnostic line), etc.

[0058] Similarly, in step S64, the second processor 21 determines whether the result of the secure boot of itself (the old version of the second software 221) is OK or not. If the result of the secure boot is OK, the second processor 21 proceeds to step S65, and if 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 secure boot process in step S62 in Fig. 5 and subsequent processes. The second processor 21 retries the process in step S62 in Fig. 5 and subsequent processes a predetermined number of times until the result of the secure boot process is OK.

[0060] In step S65, the second processor 21 determines whether the result of the secure boot of the other party (the old version of the first software 121) is OK. If the result of the secure boot of the other party is OK, the second processor 21 proceeds to step S66 and continues to control the normal operation of the moving object 100 by the old version of the second software 221.

[0061] By the processes of steps S17 and S66, if the update of the second software fails, the operation of the mobile body 100 can be continued using the old versions of the first software and the second software. The mode in which the mobile body 100 operates using the old versions of the first software 121 and the second software 221 by steps S17 and S66 corresponds to the anomaly response mode of the present disclosure.

[0062] On the other hand, if the result of the secure boot of the other party is NG, the second processor 21 advances the process to step S71, executes the old version of the second software 221, and operates only the functions of the moving object 100 assigned to itself (the second microcomputer 20) (functional degeneration). In the following step S72, the second processor 21 notifies the display 6 that the moving object 100 is operating with functional degeneration.

[0063] By the processing of steps S21 and S71, when the result of secure boot is NG for the old version of the first software or the second software, it is possible to continue the operation of the mobile object 100 by degrading functions. The configuration that executes the processing of steps S21, S22 and steps S71, S72 in Fig. 6 corresponds to the software anomaly response unit of the present disclosure. The mode in steps S21 and S71 in which the mobile object 100 is operated by degrading functions using the old version of the first software 121 or the second software 221 corresponds to the anomaly response mode of the present disclosure.

[0064] 4 to 6 show the process for the case where the update of the second software is not completed normally as shown in Fig. 3, but if the update of the first software is not completed normally, the second processor 21 executes the rollback process for the second software similar to step S7 in Fig. 5. Then, the operation of the moving 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 normally completed, the rollback process in step S7 in Fig. 4 and the function degrading process in steps S21 and S71 in Fig. 6 are executed, but only either the rollback process or the function degrading process may be executed. When the rollback process is not executed, in the secure boot process in steps S13 and S62 in Fig. 5, it is determined whether the enabled first software and the second software match, and when they do not match, the function degrading process is executed to execute only one of the first software or the second software to operate the moving body 100. When the rollback process is not executed, it is not necessary to configure the first memory 12 and the second memory 22 as two faces as shown in Figs. 1 to 3.

[0066] In the above embodiment, if the result of the secure boot of the first software or the second software is NG, function degeneration processing is performed in steps S22 and S72 of Figure 6. However, a rollback processing may also be performed similarly to step S7 of Figure 4, and the moving body 100 may be operated using older versions of the first software and the second software.

[0067] 6, the fact that the moving object 100 is operating due to functional degeneration is notified by displaying on the display 6. In another embodiment, instead of or in addition to the notification by the display 6, a notification may be made by audio output from a speaker provided in the moving object 100. Alternatively, the notification that the moving object 100 is operating due to functional degeneration may be omitted.

[0068] 1 is a schematic diagram showing the configuration of the mobile object control device 1 divided according to the main processing contents in order to facilitate understanding of the present invention, and the mobile object control device 1 may be divided in other ways. Furthermore, the processing of each component may be executed by one hardware unit or by multiple hardware units. Furthermore, the processing of each component shown in FIGS. 4 to 6 may be executed by one program or by multiple 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 body control device comprising 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 mobile body control device comprising: a software update unit that executes an update process for the first software and the second software; a software anomaly recognition unit that recognizes whether or not there is an anomaly 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 anomaly response unit that, when an anomaly in the first software stored in the first memory or the second software stored in the second memory is recognized by the software anomaly recognition unit, causes the first processor or the second processor to execute an anomaly response process for operating a target mobile body that is the target of control by the mobile body control device in a predetermined anomaly response mode. According to the mobile object control device of configuration 1, it is possible to prevent the target mobile object from becoming unable to operate when the update of the first software or the second software is not completed normally.

[0071] (Configuration 2) The mobile control device of 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 a version of the valid first software stored in the first memory is different from a version of the valid second software stored in the second memory, or when a 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 poor. According to the mobile object control device of configuration 2, when the enabled first software and second software versions are different because the update process of the first software or the second software was not 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 enabled first software or the second software is poor, it is possible to recognize that the first software or the second software is abnormal.

[0072] (Configuration 3) The first memory is provided with an area for storing a new version of the first software updated by the update process, and an area for storing an old version of the first software before being updated by the update process, and the second memory is provided with an area for storing a new version of the second software updated by the update process, and an area for storing an old version of the second software before being updated by the update process, and the software abnormality response unit is configured to perform the abnormality response process by causing the first processor to execute the old version of the first software stored in the first memory and the second processor to execute the old version of the second software stored in the second memory 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 because a valid version of the first software stored in the first memory is different from a valid version of the second software stored in the second memory. According to the mobile object control device of configuration 3, when the effective versions of the first software and the second software are different because the update to the new version of the first software or the second software was not completed successfully, the first processor and the second processor can be made to execute the old versions of the first software and the second software, respectively, to operate the target mobile object.

[0073] (Configuration 4) A mobile body control device as described in Configuration 2 or Configuration 3, wherein when the software anomaly recognition unit recognizes that the result of secure boot of the valid first software stored in the first memory is bad and the result of secure boot of the valid first software stored in the second memory is good, the software anomaly response unit performs the anomaly response processing by prohibiting the first processor from executing the first software and causing the second processor to execute the second software. According to the mobile object control device of configuration 4, when a defect in the first software is recognized, the operation of the target mobile object can be ensured by having the second processor execute the second software in which a defect is not recognized.

[0074] (Configuration 5) The mobile object control device according to configuration 4, wherein the software anomaly response unit notifies the target mobile object that the anomaly response process is being executed by a notification unit provided in the target mobile object. According to the mobile body control device of configuration 5, for example, a user riding in the target moving body can be notified that the operation of the target moving body is restricted because the first software is not being executed.

[0075] (Configuration 6) The first memory is provided with an area for storing a new version of the first software updated by the update process, and an area for storing an old version of the first software before being updated by the update process, and the second memory is provided with an area for storing a new version of the second software updated by the update process, and an area for storing an old version of the second software before being updated by the update process, and the software abnormality response unit, when the new version of the first software is stored in the first memory as the valid first software and the new version of the second software is stored in the second memory as the valid second software, recognizes that the result of 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 is poor, as the abnormality response process, performs a process of having the first processor execute the old version of the first software stored in the first memory and having the second processor execute the old version of the second software stored in the second memory. According to the mobile object control device of configuration 6, if the result of the secure boot of the enabled first software or second software turns out to be poor after the update to a new version of the first software or second software is completed, the first processor and the second processor can be made to execute the old versions of the first software and the second software, respectively, to operate the target mobile object.

[0076] (Configuration 7) A mobile body control method executed by a mobile body control device having a first processor, a first memory in which first software used by the first processor is stored, and a second processor, a second memory in which second software used by the second processor is stored, the mobile body control method including: a software update step of executing an update process for the first software and the second software; a software anomaly recognition step of recognizing whether or not there is an anomaly 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 anomaly response step of causing the first processor or the second processor to execute an anomaly response process for operating a mobile body that is the target of control by the mobile body control device in a predetermined anomaly response mode when an anomaly is recognized in the software anomaly recognition step in the first software stored in the first memory or the second software stored in the second memory. By executing the moving body control method of configuration 7 by a moving body control device, it is possible to obtain an operational configuration similar to that of the moving body control device of configuration 1.

[0077] (Configuration 8) A program that causes a mobile object control device having a first processor, a first memory in which first software used by the first processor is stored, and a second processor, a second memory in which second software used by the second processor is stored to function as a software update unit that executes an update process for the first software and the second software, a software anomaly recognition unit that recognizes whether or not there is an anomaly 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 anomaly response unit that causes the first processor or the second processor to execute an anomaly response process to operate a mobile object that is the target of control by the mobile object control device in a predetermined anomaly response mode when the software anomaly recognition unit recognizes an anomaly in the first software stored in the first memory or the second software stored in the second memory. By executing the program of configuration 8 by a mobile object control device, the configuration of the mobile object control device of configuration 1 can be realized. [Explanation of symbols]

[0078] 1...mobile object control device, 2...SS switch, 3...IG relay, 5...communication unit, 6...display (alarm section), 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...mobile object, 121...old version of first software, 122...new version of first software, 221...old version of second software, 222...new version of second software, 300...communication network, 310...mobile object management server, W...operator.

Claims

1. A first processor; a first memory in which first software for use by the first processor is stored; A second processor; and a second memory in which second software for use by the second processor is stored; A mobile object control device comprising: a software update unit that executes an update process for the first software and the second software; a software anomaly recognition unit that recognizes the presence or absence of an anomaly 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 anomaly response unit that, when an anomaly in the first software stored in the first memory or the second software stored in the second memory is recognized by the software anomaly recognition unit, causes the first processor or the second processor to execute an anomaly response process for operating a target moving object that is a control target of the moving object control device in a predetermined anomaly response mode; A mobile object control device comprising:

2. 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 a version of the valid first software stored in the first memory is different from a version of the valid second software stored in the second memory, or when a 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 poor. The mobile object control device according to claim 1 .

3. In the first memory, an area for storing a new version of the first software updated by the update process and an area for storing an old version of the first software before being updated by the update process are set, In the second memory, an area for storing a new version of the second software updated by the update process and an area for storing an old version of the second software 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 because a valid version of the first software stored in the first memory is different from a valid version of the second software stored in the second memory, the software abnormality response unit executes, as the abnormality response process, a process of causing the first processor to execute an older version of the first software stored in the first memory and a process of causing the second processor to execute an older version of the second software stored in the second memory. The mobile object control device according to claim 2 .

4. When the software anomaly recognition unit recognizes that the result of the secure boot of the valid first software stored in the first memory is bad and the result of the secure boot of the valid first software stored in the second memory is good, the software anomaly response unit performs a process of prohibiting the first processor from executing the first software and causing the second processor to execute the second software, as the anomaly response process. The mobile object control device according to claim 2 .

5. The software anomaly response unit notifies the target moving object that the anomaly response process is being executed by a notification unit provided in the target moving object. The mobile object control device according to claim 4.

6. In the first memory, an area for storing a new version of the first software updated by the update process and an area for storing an old version of the first software before being updated by the update process are set, In the second memory, an area for storing a new version of the second software updated by the update process and an area for storing an old version of the second software before being updated by the update process are set, When the software abnormality recognition unit recognizes that a result of 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 is defective in a state in which the new version of the first software is stored in the first memory as the valid first software and the new version of the second software is stored in the second memory as the valid second software, the software abnormality response unit executes, as the abnormality response process, a process of causing the first processor to execute an old version of the first software stored in the first memory and a process of causing the second processor to execute an old version of the second software stored in the second memory. The mobile object control device according to claim 2 .

7. A first processor; a first memory in which first software for use by the first processor is stored; A second processor; and a second memory in which second software for use by the second processor is stored; A mobile object control method executed by a mobile object control device comprising: a software update step of executing an update process of the first software and the second software; a software anomaly recognition step of recognizing whether or not there is an anomaly in the first software stored in the first memory and in the second software stored in the second memory after the update process is executed; a software anomaly response step of causing the first processor or the second processor to execute an anomaly response process for operating a mobile object that is a control target of the mobile object control device in a predetermined anomaly response mode when an anomaly in the first software stored in the first memory or the second software stored in the second memory is recognized by the software anomaly recognition step; A mobile object control method including:

8. A first processor; a first memory in which first software for use by the first processor is stored; A second processor; and a second memory in which second software for use by the second processor is stored; A mobile object control device comprising: a software update unit that executes an update process for the first software and the second software; a software anomaly recognition unit that recognizes the presence or absence of an anomaly in 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 anomaly recognition unit recognizes an anomaly in the first software stored in the first memory or the second software stored in the second memory, the software anomaly recognition unit causes the first processor or the second processor to execute an anomaly response process for operating a mobile object that is a control target of the mobile object control device in a predetermined anomaly response mode. program.

Images