Movable body controller, movable body control method, and program

Abstract

To reduce an inoperable time of a movable body as much as possible, and prevent a malfunction and a change of a state after software update.SOLUTION: A movable body controller 1 has software update units 10, 20 that execute software update processing. When executing the software update processing, the software update units 10, 20 write new version software in memories 12, 22, and subsequently write function state information DK indicating the current state of the function of a movable body 100 in a predetermined storage area 40, before completing processing of activating the new version software.SELECTED DRAWING: Figure 2

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, technologies for supporting software updates in control devices mounted on mobile objects such as vehicles have been proposed. For example, Patent Document 1 discloses a configuration in which an area for storing a currently running program and an area for storing update programs are set in a storage unit that stores programs executed by an ECU (Electronic Control Unit) mounted on a vehicle. This configuration is said to enable the storage unit to store update programs even while a program is running, thereby reducing constraints on the timing of program updates. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-144669 Summary of the Invention [Problem to be solved by the invention]

[0004] However, if the functions and status of the vehicle are reset to their initial values ​​when the software is updated, there is a risk that functions that were operating while the vehicle was stopped will no longer work while the vehicle is stopped, or that the settings of the vehicle will change before and after the software update. For example, vehicle security is a function to prevent vehicle theft and operates when the power is off, the vehicle is parked, and the vehicle is locked. Security is set when the user locks the vehicle, so if a software update is performed with security set, there is a risk that the security will be unintentionally set after the software update. While there is also a method to maintain the state before the software update and carry over that state after the software update, there is a risk of a long downtime during which security will not function until the software starts up and the transfer process is completed. The present application aims to solve the above problems by minimizing the downtime of a vehicle and suppressing malfunctions and changes in status after software updates, thereby further improving traffic safety and contributing to the development of a sustainable transportation system. [Means for solving the problem]

[0005] One aspect of the present disclosure is a mobile body control device that includes a processor and a memory in which software used by the processor is stored, and that has a software update unit that executes an update process for the software, and when executing the software update process, the software update unit writes function status information indicating the current status of a specified function of the mobile body into a specified memory area after writing a new version of the software to the memory and before completing the activation process for the new version of the software.

[0006] Another aspect of the present disclosure is a mobile body control method executed by a mobile body control device having a processor and a memory in which software used by the processor is stored, in which, when performing an update process for the software, after writing a new version of the software to the memory, and before completing an activation process for the new version of the software, function status information indicating the current function status of the mobile body is written to a specified memory area.

[0007] Another aspect of the present disclosure is a program that causes at least a part of a mobile object control device, which has a processor and a memory in which software used by the processor is stored, to function as a software update unit that executes an update process for the software, wherein when executing the software update process, the software update unit is a program that, after writing a new version of the software to the memory, writes function status information indicating the current functional status of the mobile object to a specified memory area before completing the activation process for the new version of the software. [Effects of the Invention]

[0008] According to one aspect of the present invention, it is possible to minimize the inoperation time of a mobile object and to suppress malfunctions and state changes after a software update. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a configuration diagram of a mobile object control device. [Figure 2] FIG. 2 is a timing chart of the software update process in the mobile object control device. [Figure 3] FIG. 3 is a diagram showing an example of a state of a predetermined function of a moving object. [Figure 4] FIG. 4 is a diagram illustrating the operation of the second microcomputer when the central ECU issues a reset request. DETAILED DESCRIPTION OF THE INVENTION

[0010] [1. Configuration of mobile control device] The configuration of a mobile body control device 1 of this embodiment will be described with reference to Fig. 1. The mobile body control device 1 includes a central ECU 2 that performs overall control and information processing of a mobile body 100. In this embodiment, a case where the mobile body 100 is a vehicle is exemplified, but the mobile body 100 is not limited to a vehicle and may be an aircraft, a ship, or the like. The central ECU 2 is connected to communication lines including communication lines L1 to L3. The central ECU 2 is connected to multiple ECUs for controlling the operation of the mobile object 100 via the communication lines, and realizes the function of a gateway that manages the exchange of communication data. Of the multiple ECUs, Fig. 1 shows an area ECU that controls the operation of functions (door locks and security) that can be operated while the mobile object 100 is stopped, along with its peripheral configuration. The area ECU includes a first microcomputer 10 and a second microcomputer 20.

[0011] The communication line is a bus that performs communication conforming to standards such as CAN (Controller Area Network, registered trademark), CAN FD (CAN with Flexible Data Rate), LIN (Local Interconnect Network), Ethernet (registered trademark), FlexRay (registered trademark), etc. Note that any of the communication lines L1 to L3 may be a communication line that performs communication conforming to a different standard.

[0012] The central ECU 2 writes software (programs) to be executed by each ECU to multiple ECUs connected via communication lines and to other ECUs connected via these ECUs. Writing software includes updating software already written in an ECU and writing new software to an ECU. That is, the central ECU 2 also functions as an OTA (Over The Air) manager that performs OTA management. The OTA management includes, for example, a process of downloading updated software for each ECU included in the vehicle 100 from an external server and a control related to software update processing.

[0013] The mobile body 100 includes a communication unit 5 that performs wireless communication with the mobile body management server 310 and the like via the communication network 300, and a display 6 that functions as a notification unit that notifies various pieces of information to the user (occupant) of the mobile body 100. The communication unit 5 and the display 6 are connected to the mobile body control device 1, but may also be provided by the mobile body control device 1.

[0014] An in-vehicle device 200 mounted on the moving body 100 is also connected to the moving body control device 1 via a communication line L3. The in-vehicle device 200 includes configurations related to functions that operate while the moving body 100 is stopped, and in this embodiment includes a door lock module 201 and a security module 202. The door lock module 201 and the security module 202 are connected to at least one of the first microcomputer 10 and the second microcomputer 20 via the communication line L3.

[0015] The first microcomputer 10 and the second microcomputer 20 execute the control and processing assigned to the area ECU. The first microcomputer 10 has a first processor 11, a first memory 12, a first communication circuit 13, etc. The first processor 11 executes first software stored in the first memory 12, thereby locking / unlocking the door lock module 201 and activating / deactivating the headlights / wipers of the vehicle 100.

[0016] The second microcomputer 20 has a second processor 21, a second memory 22, a second communication circuit 23, etc., and the second processor 21 executes second software stored in the second memory 22 to control the power supply of the in-vehicle device 200 and configure the security module 202, etc. The control and processing assigned to each microcomputer 10, 20 may be changed as appropriate. Furthermore, the area ECU is not limited to having two microcomputers 10, 20, but may have one or three or more microcomputers.

[0017] The moving object 100 includes an SS (start / stop) switch 7 that can instruct switching of the IG (IGNITION) of the moving object 100 between on (power on state) and off (power off state). 1, an operation signal of the SS switch 7 (on / off state of the SS switch 7) is input to the second microcomputer 20 via an input circuit 30. The first microcomputer 10 is also connected to the IG relay 8 via an input circuit 31, and the IG relay 8 is turned on and off 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. The on / off detection signal of the IG relay 8 (on / off state of the IG relay 8) is input to the first microcomputer 10 via the input circuit 31 and also input to the second microcomputer 20 via the input circuit 32.

[0018] The mobile object control device 1 performs wireless communication with the mobile object management server 310 via the communication network 300 using the communication unit 5, thereby updating the first software and the second software through OTA management. That is, when the central ECU 2 downloads a new version of the first software 122 from the mobile object management server 310, the first microcomputer 10 updates the first software. Also, when the central ECU 2 downloads a new version of the second software 222 from the mobile object management server 310, the second microcomputer 20 updates the second software.

[0019] The first software update process and the second software update process correspond to an example of "update process of software that controls the operation of functions held by the moving object 100" in the present disclosure.

[0020] The first memory 12 and the second memory 22 in each of the microcomputers 10 and 20 are implemented as a rewritable dual bank ROM (two-sided ROM). If an old version of the first software 121 used by the first processor 11 is stored in one bank 12a of the first memory 12, the downloaded new version of the first software 122 is written by the first processor 11 to the other bank 12b, which is an empty bank of the first memory 12.

[0021] In addition, if an old version of the second software 221 used by the second processor 21 is stored in one bank 22a of the second memory 22, the downloaded new version of the second software 222 is written by the second processor 21 to the other bank 22b, which is an empty bank of the second memory 22.

[0022] The first software 121, 122 is software that can be used by the first processor 11, and includes a control program for the moving body 100 and a data set used to control the moving body 100. A program for a boot (bootstrap) process of the first microcomputer 10 is stored in an area 12c of the first memory 12.

[0023] The second software 221, 222 is software that can be used by the second processor 21, and includes a control program for the moving body 100, a data set used to control the moving body 100, etc. An area 22c of the second memory 22 stores a program for a boot (bootstrap) process of the second microcomputer 20.

[0024] [2. Software update timing] The timing of updating the first software and the second software will be described with reference to Figure 2. Because the first software and the second software are updated at the same time and through similar processing, 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 microcomputers, and the first memory 12 and the second memory 22 will be collectively referred to as memories. 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. Each of the microcomputers 10 and 20 functions as a "software update unit" of the present disclosure by executing the programs of the respective boot processes using the first processor 11 and the second processor 21.

[0025] [3. Operation of mobile control device during software update]

[0026] 2 shows the software update process sequence in chronological order, with time axis t representing the time. When the mobile control device 1 recognizes that the SS switch 7 has been turned on at time t1, it starts the OTA sequence and executes the following steps: configuration synchronization → download of repro data (data for the new version of software) from the mobile control server 310 → erasure of the software → installation (dual ROM microcomputer installation).

[0027] 2 shows an example in which the mobile object control device 1 performs a software update by OTA when it recognizes that the SS switch 7 has been turned on, but the software may be updated at other times. For example, when the mobile object control device 1 receives a software update instruction signal transmitted from another ECU via the communication line 41, the software may be updated by OTA, i.e., configuration synchronization → download of reproduction data (data on new version of software) from the mobile object management server 310 → erasure of software → installation (dual ROM microcomputer installation).

[0028] As shown by symbols C1 to C5 in Figure 2, 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. Symbol C1 shows the situation where side B, which stores the new version of the software, is erased, and the erased areas gradually become free space. Side A stores the active (active) old version of the software.

[0029] Next, the microcomputer starts writing the new version of the software to side B, and after writing is complete, it waits for the IG to be turned off. Symbol C2 shows the state where the new version of the software is written to side B. At time t2, when the microcomputer recognizes that the SS switch 7 has been turned IG off, it starts the activation process. The activation process includes confirming the user's permission to activate, turning off the IG, activating the software, and resetting the microcomputer.

[0030] The microcontroller confirms permission for activation (such as confirming the update to the new version of the software), and if permission is confirmed, turns off the IG (including a setting that prohibits powering on again), activates the new version of the software, and resets itself. Code C3 indicates the state where the writing of the new version of the software to side B is complete and the activation process is complete, and the new version of the software will become effective when the microcontroller is restarted (equivalent to restarting the processor).

[0031] At time t3, when the microcomputer recognizes that the SS switch 7 has been turned on, it confirms that the software update 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. Symbol C5 shows the state in which the software launched by the microcomputer when the IG is turned on has switched from the old version software stored on side A to the new version stored on side B.

[0032] Here, if the functions and status of the mobile body 100 are reset to their initial values ​​when the software is updated, there is a risk that functions that were operating while the vehicle was stopped will no longer work while the vehicle is stopped, or that the settings of the mobile body will change before and after the software update. Therefore, in this embodiment, as shown in Figure 2, after the microcomputer writes the new version of software into memory, it writes function status information DK indicating the current status of a specified function of the mobile body 100 into the non-volatile memory 40, which functions as a specified storage area, before completing the activation process of the new version of software.

[0033] More specifically, when updating the first software, the first microcontroller 10 writes function status information DK indicating the status of the function (door lock) controlled by the first software to a non-volatile memory 40 accessible by the first microcontroller 10. On the other hand, when updating the second software, the second microcomputer 20 writes function status information DK indicating the status of the functions (security) controlled by the second software to the nonvolatile memory 40 accessible by the second microcomputer 20. The nonvolatile memory 40 can be widely applied to writable nonvolatile memories other than the first memory 12 and the second memory 22.

[0034] FIG. 3 is a diagram showing an example of the state of a predetermined function of the moving object 100. As shown in FIG. Door locks and security are functions that may be activated while the vehicle is stopped, and are examples of "predetermined functions" in the present disclosure. As shown in FIG. 3, there are four types of door locks, for example, door lock operation, super lock control, keyless door lock, and trunk (T) and glove box (G) unlock control, and the status of each function includes, for example, locked, unlocked, and unused states.

[0035] The door locking operation is a function for locking or unlocking the doors of the vehicle 100, and locking the doors improves safety and security. The super lock control is an extended version of the general door locking function, and is a function that improves security compared to when the normal door lock is locked. The keyless door lock is a function that locks and unlocks the doors using a remote control or keyless entry system, and the trunk (T) and glove box (G) unlock control is a function that prohibits unlocking of the trunk and glove box, respectively.

[0036] As shown in FIG. 3, there are three types of security features, for example, valet mode control, security specifications, and ultrasonic security, and the state of each feature can be, for example, set / not set. Valet mode control is a type of security system for the mobile object 100. For example, when valet mode control is enabled, only authenticated users are allowed to use the vehicle's functions. Security specifications indicate specifications and standards related to the security functions of the mobile object 100, such as immobilizers and theft alarm systems. Ultrasonic security is a security system that uses ultrasonic waves.

[0037] The door lock and security are set to lock, unlock, not in use, set, not set, etc. according to preset specifications or according to user selection. In this embodiment, information indicating the latest function status at the time of writing to nonvolatile memory 40 is written as function status information DK to nonvolatile memory 40. In other words, after a new version of software is written to memory, the function status information DK at the time before the activation process of the new version of software is completed is written to nonvolatile memory 40. In this way, the function status information DK immediately before the software update is recorded.

[0038] With reference to FIG. 4, the operation of the microcomputer when the central ECU 2 issues a reset request to the microcomputer will be described. The microcomputer receives the reset request from the central ECU 2, and when responding to the request, writes the functional state information DK to the nonvolatile memory 40 (step Sa). Next, the microcomputer executes a process to synchronize the reset between the first microcomputer 10 and the second microcomputer 20 using the first communication circuit 13, the second communication circuit 23, etc. (step Sb), and then restarts the microcomputer (step Sc). The restart makes the new version of the software effective.

[0039] 2, when the microcomputer is restarted with the new version of the software, it sets the states of the functions that operate while the vehicle is stopped in the software, etc., based on the function state information DK written in the nonvolatile memory 40. This makes it possible to prevent the states of the functions that operate while the vehicle 100 is stopped from changing. 4, the period between steps Sa and Sc is an inoperative timing (a period during which the user cannot perform operations). In this embodiment, software can be updated immediately regardless of the current functional status of the mobile object 100, and when the software is updated, the functional status of the mobile object 100 is immediately set based on the functional status information DK, so that the inoperative timing can be shortened as much as possible.

[0040] As described above, when the mobile body control device 1 of this embodiment executes software update processing, after the microcomputer writes the new version of software into memory, before completing the activation processing of the new version of software, it writes function status information DK indicating the current status of specified functions (door lock and security) of the mobile body 100 into the non-volatile memory 40, which is a specified storage area. This allows the state of a specific function of the mobile object 100 to be set based on the function state information DK when software is updated. Also, software can be updated immediately regardless of the current function state of the mobile object 100. This minimizes downtime of the mobile object 100 and reduces malfunctions and state changes after a software update. Ultimately, this further improves traffic safety and contributes to the development of a sustainable transportation system.

[0041] Furthermore, the mobile object control device 1 has multiple ECUs (which can also be called processors) including ECUs having microcomputers 10 and 20, and after the activation process is started by the microcomputers 10 and 20, before the target ECU (processor) is restarted, the function state information DK is written to the nonvolatile memory 40. This makes it possible to prevent malfunctions and state changes after a software update.

[0042] Furthermore, since the nonvolatile memory 40 is a recording area of ​​a memory separate from the memory in which the software is saved, the software can be smoothly rewritten. Furthermore, after the microcomputer is restarted with the new version of software, it sets the state of a given function based on the function state information DK, thereby preventing malfunctions and state changes after a software update.

[0043] Furthermore, when the mobile body control device 1 executes an update process for software that controls the operation of the mobile body 100, including functions (e.g., at least one of door lock and security) that the mobile body 100 maintains while stopped, the mobile body control device 1 writes function status information DK to the non-volatile memory 40, thereby preventing the state of the mobile body 100 from changing even if the software is updated while the mobile body is stopped. The present invention is not limited to the process of updating software that controls the operation of the mobile object 100, including the functions maintained while the mobile object 100 is stopped. In other words, the present invention may be configured to write the function state information DK to the non-volatile memory 40 when performing the process of updating software that controls the operation of the functions maintained by the mobile object 100. This makes it possible to prevent the state of the mobile object 100 from changing even when the software is updated.

[0044] 4, if the microcomputer detects a user operation on the mobile object 100, it is preferable to postpone (cancel) the software update process. This can prevent the software update process from being performed while the user is changing the state of a predetermined function, and can prevent the state of the predetermined function from changing even if the software is updated.

[0045] 4. Other Embodiments The above embodiment is merely one embodiment of the present invention, and any modifications and applications are possible without departing from the spirit of the present invention.

[0046] The configuration of the mobile body control device 1 shown in Fig. 1 is an example, and the configuration may be changed as appropriate. Also, Fig. 1 is a schematic diagram showing the configuration of the mobile body control device 1 divided according to the main processing content in order to facilitate understanding of the present invention, and the mobile body control device 1 may be divided according to other divisions. Furthermore, the processing of each component may be executed by one hardware unit or by multiple hardware units. Furthermore, the processing of each component may be executed by one program or by multiple programs.

[0047] 5. Configurations supported by the above embodiments The above embodiment is a specific example of the following configuration.

[0048] (Configuration 1) A mobile body control device having a processor and a memory in which software used by the processor is stored, and a software update unit that executes the software update process, wherein when executing the software update process, the software update unit writes function status information indicating the current status of a specified function of the mobile body into a specified memory area after writing a new version of the software into the memory and before completing the activation process of the new version of the software. According to the mobile object control device of configuration 1, when software is updated, the state of a predetermined function of the mobile object can be set based on the function state information. Furthermore, software can be updated immediately regardless of the current state of the function of the mobile object. This makes it possible to minimize downtime of the mobile object and to prevent malfunctions and state changes after a software update.

[0049] (Configuration 2) A mobile control device as described in Configuration 1, having multiple processors including the processor, wherein the software update unit writes the functional status information to the memory area after starting the activation process and before the processor restarts. According to the mobile object control device of configuration 2, malfunctions and state changes after software updates can be suppressed.

[0050] (Configuration 3) The mobile object control device according to configuration 1 or 2, wherein the storage area is a recording area of ​​a memory separate from the memory. According to the mobile object control device of configuration 3, software can be smoothly rewritten.

[0051] (Configuration 4) A mobile control device according to any one of configurations 1 to 3, wherein the processor sets the state of the predetermined function based on the function state information after restarting with the new version of the software. According to the mobile object control device of configuration 4, malfunctions and state changes after software updates can be suppressed.

[0052] (Configuration 5) A mobile body control device described in any one of configurations 1 to 4, wherein the software update unit writes the function status information to the memory area when performing an update process for software that controls the operation of a function held by the mobile body. According to the mobile object control device of configuration 5, the state of the mobile object can be prevented from changing even if the software is updated.

[0053] (Configuration 6) A mobile body control device described in any one of configurations 1 to 5, wherein the software update unit postpones the software update process if it detects user operation on the mobile body when a reset request is received in connection with the software update process. According to the mobile control device of configuration 6, it is possible to avoid a situation where a software update process is performed while the user is changing the state of a specified function, and it is possible to prevent the state of the specified function from changing even when the software is updated.

[0054] (Configuration 7) A mobile body control method executed by a mobile body control device having a processor and a memory in which software used by the processor is stored, in which, when performing an update process for the software, after writing a new version of the software to the memory, function status information indicating the current status of a specified function of the mobile body is written to a specified memory area before completing the activation process for the new version of the software. By executing the mobile body control method of configuration 7 by a mobile body control device, it is possible to obtain the same effects as the mobile body control device of configuration 1.

[0055] (Configuration 8) A program that causes at least a part of a mobile object control device having a processor and a memory in which software used by the processor is stored to function as a software update unit that executes the software update process, wherein when executing the software update process, the software update unit writes function status information indicating the current status of a specified function of the mobile object to a specified memory area after writing a new version of the software to the memory and before completing the activation process of the new version of the software. By executing the program of the eighth aspect by the mobile body control device, the same effects as those of the mobile body control device of the first aspect can be obtained. [Explanation of symbols]

[0056] 1...mobile object control device, 2...central ECU, 5...communication unit, 6...display, 7...SS switch, 8...IG relay, 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, 40...non-volatile memory (predetermined storage area), 100...mobile object, 121...old version of first software, 122...new version of first software, 200...in-vehicle device, 201...door lock module, 202...security module, 221...old version of second software, 222...new version of second software, 300...communication network, 310...mobile object management server.

Claims

1. A mobile object control device including a processor and a memory in which software used by the processor is stored, a software update unit that executes the software update process; When executing the software update process, the software update unit writes function status information indicating the current status of a predetermined function of the mobile object into a predetermined storage area after writing the new version of the software into the memory and before completing the activation process of the new version of the software. Mobile control device.

2. a plurality of processors including the processor; The software update unit writes the function status information to the storage area after starting the activation process and before restarting the processor. The mobile object control device according to claim 1 .

3. The storage area is a recording area of ​​a memory separate from the memory. The mobile object control device according to claim 1 .

4. The processor sets the state of the predetermined function based on the function state information after rebooting with the new version of the software. The mobile object control device according to claim 1 .

5. The software update unit writes the function status information to the storage area when executing an update process for software that controls the operation of a function held by the mobile object. The mobile object control device according to claim 1 .

6. When a reset request is received in connection with the software update process, if a user operation on the mobile object is detected, the software update unit postpones the software update process. The mobile object control device according to claim 1 .

7. A mobile object control method executed by a mobile object control device including a processor and a memory in which software used by the processor is stored, When the software update process is executed, after writing the new version of the software to the memory, function status information indicating the current status of a predetermined function of the mobile object is written to a predetermined storage area before completing the activation process of the new version of the software. A mobile object control method.

8. A program that causes at least a part of a mobile object control device, which includes a processor and a memory in which software used by the processor is stored, to function as a software update unit that executes an update process for the software, When executing the software update process, the software update unit writes function status information indicating a current function status of the mobile object into a predetermined storage area after writing the new version of the software into the memory and before completing an activation process of the new version of the software. program.

Images