Mobile body control device, mobile body control method, and recording medium

Abstract

The invention provides a moving body control device, a moving body control method, and a recording medium. The purpose of the present invention is to suppress a case in which a moving body cannot be operated due to a failure in software update of a plurality of processors in a moving body control device. A mobile body control device (1) is provided with: software update units (11, 21) that execute update processing of first software or second software; a software abnormality recognition unit (11, 21) that recognizes the presence or absence of an abnormality in the first software and the second software after the update processing is executed; and a software abnormality response unit (11, 21) that responds to a software abnormality when the software abnormality recognition unit recognizes an abnormality of the first software stored in the first memory or the second software stored in the second memory. The first processor (11) or the second processor (21) executes an abnormality response process for operating a target moving body (100), which is a control target of the moving body control device (1), in a predetermined abnormality response mode.

Description

Technical Field

[0001] The present invention relates to a mobile body control device, a mobile body control method and a recording medium. Background Art

[0002] In the past, a technology for supporting software updates in a control device mounted on a mobile body such as a vehicle has been proposed. For example, Patent Document 1 discloses a structure in which an area for storing a program 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. According to this structure, the storage unit can store an update program even when a program is being executed, and the constraints on the timing of updating the program can be reduced.

[0003] Prior art literature

[0004] Patent Literature

[0005] Patent Document 1: Japanese Patent Application Publication No. 2019-144669 Summary of the invention

[0006] Problems to be solved by the invention

[0007] The software such as programs used in the mobile body control device includes important software for basic operations of the mobile body. Therefore, if the software is not updated normally, it may cause obstacles to the operation of the mobile body. For example, when updating multiple software that are independently executed by multiple processors, if the update of the software used by any processor is not completed normally, or if a software abnormality occurs after the update, it will become impossible to achieve synchronization between processors under the new version of the software, and the mobile body cannot operate. Therefore, the subject of the present application is to suppress the inability to operate the mobile body due to poor software updates of multiple processors in the mobile body control device.

[0008] The present application aims to improve safety in order to solve the above-mentioned problems and further improve traffic safety to contribute to the development of a sustainable transportation system.

[0009] Means for solving problems

[0010] As a first method for achieving the above-mentioned purpose, a mobile body control device is provided, which comprises: a first processor; a first memory, which stores a first software used by the first processor; a second processor; and a second memory, which stores a second software used by the second processor, wherein the mobile body control device comprises: a software update unit, which performs update processing of the first software and the second software; a software abnormality identification unit, which identifies whether there are abnormalities in the first software stored in the first memory and the second software stored in the second memory after performing the update processing; and a software abnormality response unit, which, when the software abnormality identification unit identifies an abnormality in the first software stored in the first memory or the second software stored in the second memory, executes an abnormality response processing for making the target mobile body, which is the control object of the mobile body control device, operate in a specified abnormality response mode through the first processor or the second processor.

[0011] In the above-mentioned mobile body control device, it can also be configured that, 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 startup of the valid first software stored in the first memory or the valid second software stored in the second memory is poor, the software abnormality identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal.

[0012] In the above-mentioned mobile body control device, it can also be configured that 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 first memory, and 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 in the second memory. 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, and the software abnormality identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal, the software abnormality response unit performs the following processing as the abnormality response processing: the old version of the first software stored in the first memory is executed by the first processor, and the old version of the second software stored in the second memory is executed by the second processor.

[0013] In the above-mentioned mobile body control device, it can also be configured that when the software exception identification unit identifies that the result of the safe startup of the valid first software stored in the first memory is poor and the result of the safe startup of the valid second software stored in the second memory is good, the software exception response unit performs the following processing as the exception response processing: prohibiting the first processor from executing the first software, and executing the second software through the second processor.

[0014] In the above-mentioned moving body control device, the software abnormality handling unit may be configured to notify, via a notification unit included in the target moving body, that the abnormality handling process is being executed.

[0015] In the above-mentioned mobile body control device, it can also be configured that 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 first memory, and 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 in the second memory. In the state where 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, when the software abnormality identification unit identifies that the result of the secure startup 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, the software abnormality response unit performs the following processing as the abnormality response processing: the old version of the first software stored in the first memory is executed by the first processor, and the old version of the second software stored in the second memory is executed by the second processor.

[0016] As a second method for achieving the above-mentioned purpose, a mobile body notification method is provided, which is executed by a mobile body control device, and the mobile body control device has: a first processor; a first memory, which stores a first software used by the first processor; a second processor; and a second memory, which stores a second software used by the second processor, wherein the mobile body control method includes: a software update step, executing update processing of the first software and the second software; a software abnormality identification step, after executing the update processing, identifying whether the first software stored in the first memory and the second software stored in the second memory have abnormalities; and a software abnormality response step, when the abnormality of the first software stored in the first memory or the second software stored in the second memory is identified by the software abnormality identification step, the first processor or the second processor executes abnormality response processing for making the mobile body, which is the control object of the mobile body control device, operate in a specified abnormality response mode.

[0017] As a third method for achieving the above-mentioned purpose, a recording medium is provided, which is a non-volatile recording medium, which records a program executed by a mobile body control device, wherein the mobile body control device has: a first processor; a first memory, which stores first software used by the first processor; a second processor; and a second memory, which stores second software used by the second processor, wherein the program enables the mobile body control device to function as the following parts: a software update unit, which executes update processing of the first software and the second software; a software abnormality identification unit, which identifies whether there are abnormalities in the first software stored in the first memory and the second software stored in the second memory after executing the update processing; and a software abnormality response unit, which, when the software abnormality identification unit identifies an abnormality in the first software stored in the first memory or the second software stored in the second memory, executes an abnormality response processing for causing the mobile body, which is the control object of the mobile body control device, to operate in a specified abnormality response mode through the first processor or the second processor.

[0018] Effects of the Invention

[0019] According to the above-described mobile body control device, mobile body control method, and recording medium, it is possible to prevent the mobile body from becoming inoperable when the update of software in the mobile body control device is not normally completed. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a structural diagram of a mobile body control device.

[0021] Figure 2This is a timing chart of the software update process in the mobile body control device.

[0022] Figure 3 This is a diagram for explaining how software is stored in the memory.

[0023] Figure 4 This is a first flowchart of abnormality handling processing of software executed in the first microcomputer and the second microcomputer.

[0024] Figure 5 This is a second flowchart of the abnormality handling process of the software executed in the first microcomputer and the second microcomputer.

[0025] Figure 6 This is a third flowchart of the abnormality handling process of the software executed in the first microcomputer and the second microcomputer.

[0026] Description of Reference Numerals

[0027] 1: Mobile body 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: Mobile body, 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 body management server, W: Operator. DETAILED DESCRIPTION

[0028] [1. Structure of mobile body control device]

[0029] Reference Figure 1 , the structure of the mobile body control device 1 of the present embodiment is described. The mobile body control device 1 is an ECU (Electronic Control Unit) that controls the operation of the mobile body 100 (equivalent to the target mobile body of the present disclosure). The mobile body 100 is a vehicle, an aircraft, a ship, etc. The mobile body 100 has a communication unit 5 and a display 6 (equivalent to the notification unit of the present disclosure) that perform wireless communication with the mobile body management server 310 via a communication network 300. The communication unit 5 and the display 6 are connected to the mobile body control device 1.

[0030] The mobile body control device 1 includes a first microcomputer 10 and a second microcomputer 20. The first microcomputer 10 includes a first processor 11, a first memory 12, a first communication circuit 13, 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 and a new version of first software 122 executed by the first processor 11. The first memory 12 and the second memory 22 are, for example, code flash memories.

[0031] 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 mobile body 100 , a data set for controlling the mobile body 100 , and the like.

[0032] 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 , including a program for controlling the mobile body 100 , a data set for controlling the mobile body 100 , and the like.

[0033] 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. The area 12c of the first memory 12 stores a program for the boot process of the first microcomputer 10. In addition, 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. The area 22c of the second memory 22 stores a program for the boot process of the second microcomputer 20.

[0034] In this way, the storage area of ​​the first software and the second software in the first memory 12 and the second memory 22 is set to a double-sided structure, so that it can be set to a structure that can store the old version and the new version of the first software and the second software together. Therefore, as described later, in the event that the update from the old version to the new version fails, the old version of the first software and the second software can be used to continue the operation of the mobile body 100.

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

[0036] The output portion 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 (the on / off state of the IG relay 3) is input to the second microcomputer 20 from the input circuit 32. The output portion 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 to the first microcomputer 10 from the input circuit 31.

[0037] In addition, the mobile body control device 1 is connected to other ECUs 40 mounted on the mobile body 100 via a communication line 41. The communication standard between the mobile body control device 1 and other ECUs 40 based on the communication line 41 is, for example, CAN (Controller Area Network: Controller Area Network (registered trademark)), CAN FD (CAN with Flexible Data Rate: Controller Area Network with Flexible Data Rate), LIN (Local Interconnect Network: Local Interconnect Network), Ethernet (registered trademark), FlexRay (registered trademark), etc.

[0038] The mobile body control device 1 can be connected to the terminal device 50 via the connection cable 51 , and the operator W can operate the terminal device 50 to update the first software from an old version to a new version and to update the second software from an old version to a new version.

[0039] In addition, the mobile body control device 1 performs wireless communication with the mobile body management server 310 via the communication network 300 using the communication unit 5, thereby updating the first software and the second software based on OTA (Over The Air). That is, the mobile body control device 1 downloads a new version of the first software from the mobile body management server 310 to update the first software, and downloads a new version of the second software from the mobile body management server 310 to update the second software.

[0040] [2. Timing of software update]

[0041] Reference Figure 2 , the update timing of the first software and the second software is described. The update of the first software and the second software is to be performed at the same timing through the same process, so the first software and the second software are collectively referred to as software, the first microcomputer 10 and the second microcomputer 20 are collectively referred to as microcomputers, and the first memory 12 and the second memory 22 are collectively referred to as memories for description. The update of the first software is performed by the first processor 11 executing a 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 a program of the boot process stored in the area 22c of the second memory 22.

[0042] Figure 2 The process of the software update process based on OTA is shown in time series by the time axis t. When the mobile body control device 1 recognizes the IG-ON operation of the SS switch 2 at t1, the OTA process starts, executes structure synchronization → downloads reprogramming data (data of the new version of software) from the mobile body management server 310 → deletes the software.

[0043] In addition, Figure 2 , an example is shown in which the mobile body control device 1 performs software update via OTA when the IG-ON operation of the SS switch 2 is recognized, but the software update may be performed at other times. For example, the mobile body control device 1 may perform a series of processes for software update based on OTA, i.e., start and stop of the mobile body control device 1, and switching between the new and old versions of the program (including restarting the mobile body control device 1), when receiving a software update instruction signal sent from another ECU 40 via the communication line 41.

[0044] exist Figure 2 In the example, as shown in C1 to C5, the area of ​​the memory storing the old version of the software before the update is set as the A side, and the area of ​​the memory storing the new version of the software after the update is set as the B side. C1 shows the situation where the B side storing the new version of the software is deleted, and the deleted areas become empty areas one by one. The old version of the software that is valid (being started) is stored on the A side.

[0045] Next, the microcomputer starts writing the new version of the software to the B side, and after the writing is completed, it enters the state of waiting for IG-OFF. C2 shows the state of writing the new version of the software to the B side. At t2, when the microcomputer recognizes the IG-OFF operation of the SS switch 2, it confirms the activation of the license (confirming whether the downloaded new version of the software has errors, etc.). Then, when the microcomputer confirms the license, it activates the new version of the software and resets itself. C3 shows the state of the new version of the software being written to the B side. When the microcomputer is restarted next, the new version of the software becomes effective.

[0046] At t3, when the microcomputer recognizes the IG-ON operation of the SS switch 2, it confirms that the software update from the old version to the new version has been completed, and switches the software to be started from the old version to the new version. C5 shows the state in which the software started by the microcomputer is switched from the old version of the software stored in the A side to the new version stored in the B side at IG-ON.

[0047] exist Figure 2 In the example shown, the switching between IG-ON and IG-OFF is controlled by using the input of the operation of the SS switch 2 as a trigger, but the present invention is not limited to this. The input means as a trigger can be replaced with other means.

[0048] For example, a door switch, a switch on a display unit inside the vehicle (physical switch or touch switch), a brake lever, an accelerator lever, a portable device (smartphone, vehicle terminal, etc.) may be used as a trigger input unit to control switching between IG-ON and IG-OFF.

[0049] Here, Figure 3 The storage method 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 method of the old version of the second software 221 and the new version of the second software 222 in the second memory 22 are shown. In the first memory 12, the header and footer of the old version of the first software 121 stored on the A side have a valid code "01" recorded. In addition, the header and footer of the new version of the first software 122 stored on the B side have a valid code "02" recorded.

[0050] Every time the software version is updated, the validity code is incremented by 1 and recorded. For the footer, the validity code is recorded when the software activation is completed. Therefore, it is possible to confirm whether the software activation has been completed by whether the validity code is recorded in the footer. Figure 3 In the example of FIG. 1 , for the first software, a valid 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 can be confirmed that both of them have completed activation.

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

[0052] [3. Software exception handling]

[0053] according to Figures 4 to 6 The flowchart shown in FIG. 1 illustrates the abnormality handling process 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. The first processor 11 executes the boot process program stored in the area 12c of the first memory 12, and the second processor 21 executes the boot process program stored in the area 22c of the second memory 22, thereby each of them functions as the software update unit, the software abnormality identification unit, and the software abnormality handling unit of the present disclosure, and executes Figures 4 to 6 The program may be read from a recording medium (disk, optical disk, flash memory, etc.) and stored in the first memory 12 and the second memory 22, or may be downloaded from an external server via the communication network 300 and stored in the first memory 12 and the second memory 22.

[0054] The processing performed by the software update unit is equivalent to the software update step in the mobile body control method disclosed in the present invention, and the processing performed by the software abnormality identification unit is equivalent to the software abnormality identification step in the mobile body control method disclosed in the present invention. The processing performed by the software abnormality response unit is equivalent to the software abnormality response step in the mobile body control method disclosed in the present invention.

[0055] like Figure 3 As shown, Figures 4 to 6 The processing of the flowchart is an abnormal processing for dealing with the following situation, that is, the update of the first software from the old version to the new version in the first microcomputer 10 is completed normally, but the update of the second software from the old version to the new version in the second microcomputer 20 is not completed normally.

[0056] Reference Figure 2 As described above, the first processor 11 and the second processor 21 recognize that the SS switch 2 is IG-ON at t1, and when it becomes an update opportunity to update the first software and the second software based on OTA, execute Figures 4 to 6 Flowchart of the process.

[0057] exist Figure 2 In the example shown, the control of switching between IG-ON and IG-OFF is performed using the input of the operation of the SS switch 2 as a trigger, but the present invention is not limited to this. The input means as a trigger can be replaced with other means.

[0058] For example, a door switch, a switch on a display unit inside the vehicle (physical switch or touch switch), a brake lever, an accelerator lever, a portable device (smartphone, vehicle terminal, etc.) may be used as a trigger input unit to control switching between IG-ON and IG-OFF.

[0059] The first processor 11 and the second processor 21 identify IG-ON and IG-OFF according to the power state of the mobile object 100, and execute the software update operation when it is the software update timing to update the first software and the second software by OTA. Figures 4 to 6 Flowchart of the process.

[0060] exist Figure 4 In step S1, the first processor 11 writes the new version of the first software 122 downloaded from the mobile management server 310 to the B side 12b of the first memory 12. In the next step S2, the first processor 11 activates the new version of the first software 122 to complete the activation.

[0061] Similarly, the second processor 21 writes the new version of the second software 222 downloaded from the mobile management server 310 to the B side 22b of the second memory 22 in step S51. In the next step S52, the second processor 21 starts the activation of the new version of the second software 222, but before the activation is completed, an abnormality of E1 occurs (a momentary battery failure, a reset of the WDT (Watchdog Timer), etc.). Therefore, the new version of the second software 222 becomes an incompletely activated state. The structure that executes steps S1, S2 and steps S51, S52 is equivalent to the software update unit of the present disclosure.

[0062] In step S3, the first processor 11 restarts the first microcomputer 10. In the next step S4, the first processor 11 boots up and determines that the first software that is valid is a new version (refer to Figure 3 ). Similarly, the second processor 21 restarts the second microcomputer 20 in step S54. In the next step S54, the second microcomputer 20 is booted and starts up, and determines that the valid second software is an old version (refer to Figure 3 ).

[0063] In the following steps S5 and S55, the first processor 11 and the second processor 21 transmit and receive the valid first software version and the second software version to each other. Then, the first processor 11 and the second processor 21 determine whether the valid first software and the second software versions are consistent.

[0064] In the next step S6, the first processor 11 identifies the inconsistency between the versions of the first and second software that are valid. Figure 3 As shown, since the first software valid in the first microcomputer 10 is a new version, the first processor 11 recognizes that the second software valid in the second microcomputer 20 is an old version. The processing of executing steps S4 to S6 and steps S54 to S56 corresponds to the software abnormality identification unit of the present disclosure.

[0065] The first processor 11 that recognizes the inconsistency between the versions of the first and second software that are valid performs a rollback process in the next step S7, in which the new version of the first software 122 stored in the B side 12b is set as incomplete activation. The structure that performs the process of step S7 is equivalent to the software abnormality handling unit of the present disclosure.

[0066] Therefore, if Figure 3 As shown, the valid code recorded in the footer of the new version of the first software 122 stored in the B side 12b of the first memory 12 is changed from "02" to "uncertain". In the next step S8, the first processor 11 resets the first microcomputer 10, and in step S9, the first microcomputer 10 is restarted.

[0067] On the other hand, the second processor 21 identifies the inconsistency between the versions of the first and second software in step S56. Figure 3 As shown, the second software valid in the second microcomputer 20 is an old version, so the second processor 21 determines that the rollback process is not required. In the next step S21, the second processor 21 resets the second microcomputer 20, and in step S58, the second microcomputer 20 restarts.

[0068] exist Figure 5 In step S10, the first processor 11 determines the valid first software by booting and determines that the old version of the first software 121 is valid. In addition, in step S59, the second processor 21 determines the valid second software by booting and determines that the old version of the second software 221 is valid.

[0069] In the following steps S11 and S60, the first processor 11 and the second processor 21 transmit and receive the valid first software version and the second software version to each other. Then, the first processor 11 and the second processor 21 determine whether the valid first software and the second software versions are consistent.

[0070] In the next step S12, the first processor 11 recognizes that the versions of the valid first software and the second software are consistent. In addition, in step S61, the second processor 21 recognizes that the versions of the valid first software and the second software are consistent. In the next step S13, the first processor 11 performs a secure boot process of 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.).

[0071] In addition, in step S62, the second processor 21 performs a secure boot process 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 send and receive the results of the secure boot process to each other and compare the results of the secure boot process of the old version of the first software 121 and the old version of the second software 221. Figure 5 The processing structure of steps S10 to S14 and steps S59 to S63 corresponds to the software abnormality handling unit of the present disclosure.

[0072] In the next Figure 6In step S15, 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). Then, the first processor 11 proceeds to step S16 when the result of the secure boot is OK, and proceeds to step S20 when the result of the secure boot is NG (there is an abnormality).

[0073] In step S20, the first processor 11 resets the first microcomputer 10 and executes Figure 5 The first processor 11 performs the following processing after the secure boot process of step S13. Figure 5 The processing after the safe boot processing of S13 is retried a specified number of times until the result of the safe boot processing is OK.

[0074] In step S16, the first processor 11 determines whether the result of the security boot of the other party (the old version of the second software 221) is OK. Then, when the result of the security boot of the other party is OK, the first processor 11 proceeds to step S17 and continues to control the normal operation of the mobile body 100 through the old version of the first software 121.

[0075] On the other hand, when the result of the other party's security boot 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 mobile body 100 assigned to itself (the first microcomputer 10) (reduced functions). In the next step S22, the first processor 11 notifies the mobile body 100 that it is operating in a state of reduced functions through the display 6.

[0076] Here, the functions of the mobile body 100 assigned to the first microcomputer 10 are, for example, windshield wipers, headlights, security alarms, door locks, local diagnosis, etc. In addition, the normal operations of the first microcomputer 10 include updating (reprogramming) of the first software based on wired or OTA, diagnosis (safety release of the diagnostic line, etc.), etc.

[0077] 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. Then, the second processor 21 advances the processing to step S65 when the result of the secure boot is OK, and advances the processing to step S70 when the result of the secure boot is NG.

[0078] In step S70, the second processor 21 resets the second microcomputer 20 and executes Figure 5 The second processor 21 performs the processing after the secure boot processing of step S62. Figure 5 The processing after step S62 is retried a specified number of times until the result of the safe boot processing is OK.

[0079] In step S65, the second processor 21 determines whether the result of the security boot of the other party (the old version of the first software 121) is OK. Then, when the result of the security boot of the other party is OK, the second processor 21 enters the process into step S66 and continues to control the normal operation of the mobile body 100 through the old version of the second software 221.

[0080] Through the processing of step S17 and step S66, when the update of the second software fails, the old version of the first software and the second software can be used to continue the operation of the mobile body 100. The mode of operating the mobile body 100 using the old version of the first software 121 and the second software 221 through step S17 and step S66 is equivalent to the abnormal response mode of the present disclosure.

[0081] On the other hand, when the result of the other party's security boot 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 mobile body 100 assigned to itself (the second microcomputer 20) (reduced functions). In the next step S72, the second processor 21 notifies the mobile body 100 that it is operating in a state of reduced functions through the display 6.

[0082] Through the processing of steps S21 and S71, when the result of the secure boot of the old version of the first software or the second software is NG, the mobile object 100 can continue to operate in a state with reduced functions. Figure 6 The processing structure of steps S21, S22 and steps S71, S72 is equivalent to the software abnormality response unit of the present disclosure. In steps S21, S71, the mode of using the old version of the first software 121 or the second software 221 to make the mobile body 100 operate in a state with reduced functions is equivalent to the abnormality response mode of the present disclosure.

[0083] In addition, Figures 4 to 6 In the flowchart, Figure 3 FIG. 1 shows a process corresponding to the case where the update of the second software is not completed normally. However, in the case where the update of the first software is not completed normally, the second processor 21 executes the same process as in FIG. 1 on the second software. Figure 5 Then, the operation control of the mobile body 100 is performed using the old versions of the first software and the second software.

[0084] [4. Other embodiments]

[0085] In the above embodiment, when the update of the first software or the second software is not completed normally, Figure 4 The rollback process of step S7, and Figure 6The function reduction processing of step S21 and step S71 can be performed, but it can also be configured to perform only one of the rollback processing or the function reduction processing. In the case of not performing the rollback processing, the structure becomes as follows: Figure 5 In the safe boot process of step S13 and step S62, it is determined whether the versions of the first software and the second software are consistent. If they are inconsistent, the function reduction process is performed, that is, only one of the first software or the second software is executed to make the mobile body 100 work. In the case of not performing the rollback process, such as Figure 1 to Figure 3 As shown, the first memory 12 and the second memory 22 do not need to be configured as a double-sided structure.

[0086] In the above embodiment, when the result of the secure boot of the first software or the second software is NG, Figure 6 In step S22 and step S72, function reduction processing is performed, but it can also be configured as Figure 4 In step S7, the rollback process is similarly performed, and the moving object 100 is operated using the old versions of the first software and the second software.

[0087] In the above embodiment, Figure 6 In step S22 and step S72, the fact that the mobile body 100 is operating in a state with reduced functions is notified by displaying on the display 6. As another embodiment, a notification based on sound output may be performed from a speaker provided in the mobile body 100 instead of or in addition to the notification based on the display 6. Alternatively, the notification that the mobile body 100 is operating in a state with reduced functions may be omitted.

[0088] in addition, Figure 1 This is a schematic diagram showing the structure of the mobile body control device 1 according to the main processing content in order to facilitate understanding of the present invention. The mobile body control device 1 may also be configured in other ways. In addition, the processing of each component may be performed by one hardware unit or by multiple hardware units. Figures 4 to 6 The processing of each component shown may be executed by one program or by a plurality of programs.

[0089] [5. Structure supported by the above-mentioned embodiments]

[0090] The above-mentioned embodiment is a specific example of the following structure.

[0091] (Structure 1) A mobile body control device, comprising: a first processor; a first memory, which stores first software used by the first processor; a second processor; and a second memory, which stores second software used by the second processor, wherein the mobile body control device comprises: a software update unit, which executes update processing of the first software and the second software; a software abnormality identification unit, which identifies whether there are abnormalities in the first software stored in the first memory and the second software stored in the second memory after executing the update processing; and a software abnormality response unit, which, when the software abnormality identification unit identifies an abnormality in the first software stored in the first memory or the second software stored in the second memory, executes abnormality response processing for causing the target mobile body, which is the control object of the mobile body control device, to operate in a specified abnormality response mode through the first processor or the second processor.

[0092] According to the moving body control device of Configuration 1, it is possible to suppress a situation in which the target moving body cannot operate when the update of the first software or the second software is not normally completed.

[0093] (Structure 2) A mobile body control device according to Structure 1, wherein, 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 booting of the valid first software stored in the first memory or the valid second software stored in the second memory is poor, the software abnormality identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal.

[0094] According to the mobile body control device of structure 2, when the update process of the first software or the second software is not completed normally, and therefore the versions of the effective first software and the second software are different, it can be recognized that the first software or the second software is abnormal. In addition, when the result of the safe startup of the effective first software or the second software is bad, it can be recognized that the first software or the second software is abnormal.

[0095] (Structure 3) A mobile body control device according to Structure 2, wherein 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 first memory, and 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 in the second memory. When the valid version of the first software stored in the first memory is different from the valid version of the second software stored in the second memory, and the software abnormality identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal because the version of the first software stored in the first memory is different from the version of the second software stored in the second memory, the software abnormality response unit performs the following processing as the abnormality response processing: the old version of the first software stored in the first memory is executed by the first processor, and the old version of the second software stored in the second memory is executed by the second processor.

[0096] According to the mobile body control device of structure 3, when the update of the first software or the second software to the new version is not completed normally and the effective versions of the first software and the second software are different, the first processor and the second processor can respectively execute the old versions of the first software and the second software to make the object mobile body work.

[0097] (Structure 4) A mobile body control device according to Structure 2 or 3, wherein, when the software exception identification unit identifies that the result of the secure boot of the first software stored in the first memory is poor and the result of the secure boot of the second software stored in the second memory is good, the software exception response unit performs the following processing as the exception response processing: prohibiting the first processor from executing the first software, and executing the second software through the second processor.

[0098] According to the moving body control device of the fourth configuration, when a defect in the first software is identified, the operation of the target moving body can be ensured by causing the second processor to execute the second software in which a defect is not identified.

[0099] (Configuration 5) The moving body control device according to Configuration 4, wherein the software abnormality handling unit notifies that the abnormality handling process is being executed through a notifying unit included in the target moving body.

[0100] According to the moving body 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 due to non-execution of the first software.

[0101] (Structure 6) A mobile body control device according to Structure 2 or 3, wherein an area for storing a new version of the first software updated by the update processing and an area for storing an old version of the first software before being updated by the update processing are set in the first memory, and an area for storing a new version of the second software updated by the update processing and an area for storing an old version of the second software before being updated by the update processing are set in the second memory, and when the software abnormality identification unit identifies that the result of secure booting 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 in a state where the new version of the first software is stored in the first memory as valid first software and the new version of the second software is stored in the second memory as valid second software, the software abnormality response unit performs the following processing as the abnormality response processing: executing the old version of the first software stored in the first memory by the first processor, and executing the old version of the second software stored in the second memory by the second processor.

[0102] According to the mobile body control device of structure 6, when the result of the secure startup of the first software or the second software that is valid after the first software or the second software is updated to a new version is poor, the first processor and the second processor can respectively execute the old versions of the first software and the second software to make the target mobile body work.

[0103] (Structure 7) A mobile body control method, executed by a mobile body control device, the mobile body control device having: a first processor; a first memory, which stores a first software used by the first processor; a second processor; and a second memory, which stores a second software used by the second processor, wherein the mobile body control method includes: a software update step, executing update processing of the first software and the second software; a software abnormality identification step, after executing the update processing, identifying whether the first software stored in the first memory and the second software stored in the second memory have abnormalities; and a software abnormality response step, in which, when an abnormality of the first software stored in the first memory or the second software stored in the second memory is identified by the software abnormality identification step, the first processor or the second processor executes an abnormality response processing for making the object mobile body that is the control object of the mobile body control device operate in a specified abnormality response mode.

[0104] By executing the moving body control method of Structure 7 by the moving body control device, the same operational structure as that of the moving body control device of Structure 1 can be obtained.

[0105] (Structure 8) A non-volatile recording medium having recorded thereon a program executed by a mobile body control device, the mobile body 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, wherein the program causes the mobile body control device to function as: a software update unit that executes update processing of the first software and the second software; a software abnormality identification unit that, after executing the update processing, identifies whether the first software stored in the first memory and the second software stored in the second memory have abnormalities; and a software abnormality response unit that, when the software abnormality identification unit identifies an abnormality in the first software stored in the first memory or the second software stored in the second memory, executes an abnormality response processing through the first processor or the second processor for causing the mobile body, which is the control object of the mobile body control device, to operate in a prescribed abnormality response mode.

[0106] By executing the program of Structure 8 in the mobile body control device, the structure of the mobile body control device of Structure 1 can be realized.

Claims

1. A mobile body 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, wherein: The mobile body control device comprises: a software updating unit configured to execute an update process of the first software and the second software; a software anomaly identification unit, which identifies whether the first software stored in the first memory and the second software stored in the second memory have anomalies after executing the update process; as well as A software exception response unit, which, when the software exception identification unit identifies an exception in the first software stored in the first memory or the second software stored in the second memory, executes an exception response process through the first processor or the second processor for making the object moving body that is the control object of the moving body control device operate in a specified exception response mode.

2. The mobile body control device according to claim 1, wherein: 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 booting of the valid first software stored in the first memory or the valid second software stored in the second memory is poor, the software abnormality identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal.

3. The mobile body control device according to claim 2, wherein: The first memory is provided with an area for storing a new version of the first software after the update process and an area for storing an old version of the first software before the update process. The second memory is provided with an area for storing a new version of the second software after the update process and an area for storing an old version of the second software before the update process. In the case where the software exception identification unit identifies that the first software stored in the first memory or the second software stored in the second memory is abnormal because the valid version of the first software stored in the first memory is different from the valid version of the second software stored in the second memory, the software exception response unit performs the following processing as the exception response processing: executing the old version of the first software stored in the first memory through the first processor, and executing the old version of the second software stored in the second memory through the second processor.

4. The mobile body control device according to claim 2, wherein: When the software exception identification unit identifies that the result of secure booting of the valid first software stored in the first memory is poor and the result of secure booting of the valid second software stored in the second memory is good, the software exception response unit performs the following processing as the exception response processing: prohibiting the first processor from executing the first software, and executing the second software through the second processor.

5. The mobile body control device according to claim 4, wherein: The software abnormality handling unit notifies, through a notifying unit included in the target moving object, that the abnormality handling process is being executed.

6. The mobile body control device according to claim 2, wherein: The first memory is provided with an area for storing a new version of the first software after the update process and an area for storing an old version of the first software before the update process. The second memory is provided with an area for storing a new version of the second software after the update process and an area for storing an old version of the second software before the update process. When the software exception identification unit identifies that the result of secure booting 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 while the new version of the first software is stored in the first memory as valid first software and the new version of the second software is stored in the second memory as valid second software, the software exception response unit performs the following processing as the exception response processing: executing the old version of the first software stored in the first memory through the first processor, and executing the old version of the second software stored in the second memory through the second processor.

7. A mobile body control method, executed by a mobile body control device, the mobile body 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, wherein, The mobile object control method comprises: A software updating step, executing an update process of the first software and the second software; a software anomaly identification step of identifying whether the first software stored in the first memory and the second software stored in the second memory have anomalies after the update process is performed; and A software exception response step, in which, when an exception of the first software stored in the first memory or the second software stored in the second memory is identified through the software exception identification step, the first processor or the second processor executes an exception response process for making the mobile body, which is the control object of the mobile body control device, operate in a specified exception response mode.

8. A recording medium, which is a non-volatile recording medium, recording a program executed by a mobile body control device, the mobile body 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, wherein: The program causes the mobile body control device to function as the following: a software updating unit configured to execute an update process of the first software and the second software; a software anomaly identification unit, which identifies whether the first software stored in the first memory and the second software stored in the second memory have anomalies after executing the update process; as well as A software exception response unit, which, when the software exception identification unit identifies an exception in the first software stored in the first memory or the second software stored in the second memory, executes an exception response process through the first processor or the second processor for making the mobile body, which is the control object of the mobile body control device, operate in a specified exception response mode.

Images