Control device, management method

Abstract

To provide a technique which, when failure on updated software is found out, in a control device of a vehicle, can suitably deal with the failure.SOLUTION: A control device of a vehicle includes: a first nonvolatile memory storing software which controls the vehicle; and one or more processors which execute the software. The one or more processors, if the updated software needs changing back to the old one before the update, determines whether or not the older one before the update is stored in a second nonvolatile memory mounted on the vehicle and then, if the older one is stored in the second nonvolatile memory, stores the older one from the second nonvolatile memory into the first nonvolatile memory.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present disclosure relates to a vehicle control device and a management method for managing the control device.

Background Art

[0002] Patent Document 1 discloses a control system and a program update method for safely recovering when an update of a program of a control device that performs control processing based on a computer program fails. In a system in which a plurality of control devices are connected, when updating the program of the target control device, the program information before the update is temporarily stored in another control device. When the update of the program in the control device to be updated fails, the program can be restored by rewriting it to the stored program.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] A vehicle control device performs control processing based on software such as a computer program. The software may be updated to new software for adding functions, improving convenience, etc. The update of the software may fail when communication interruption or the like occurs, and Patent Document 1 discloses a technique that enables recovery even when the update of the software fails. However, even after the update of the software is successfully completed, some problems may be found in the updated software itself, and corresponding measures may be required.

[0005] An object of the present disclosure is to provide a technique capable of appropriately dealing with a defect when a defect is detected in updated software in a vehicle control device.

Means for Solving the Problems

[0006] A first aspect relates to a vehicle control device. The vehicle control device includes a first non-volatile memory that stores software for controlling the vehicle, one or more processors that execute the software and is provided with. When it is necessary to return the software to the old software before the update, the one or more processors determine whether the old software before the update is stored in a second non-volatile memory mounted on the vehicle, and when the old software is stored in the second non-volatile memory, store the old software from the second non-volatile memory to the first non-volatile memory. When the old software is stored in the second non-volatile memory, store the old software from the second non-volatile memory to the first non-volatile memory.

[0007] A second aspect relates to a management method for managing a control device. The control device is mounted on a vehicle and includes a first non-volatile memory that stores software for controlling the vehicle. The management method includes when it is necessary to return the software to the old software before the update, determining whether the old software before the update is stored in a second non-volatile memory mounted on the vehicle, and when the old software is stored in the second non-volatile memory, storing the old software from the second non-volatile memory to the first non-volatile memory. and includes.

Advantages of the Invention

[0008] According to the present disclosure, in a vehicle control device, when a defect is detected in software, the defect can be appropriately dealt with.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

[0010] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0011] 1. Overview The control device according to the present embodiment is a control device for a vehicle. The control device includes a memory and a processor, and the processor executes software stored in the memory to control the vehicle. As a control device for a vehicle, an ECU (Electronic Control Unit) is typical. A vehicle including an ECU is configured as shown in FIG. 1, for example.

[0012] Figure 1 shows a vehicle 1000 and a management server 2000. The management server 2000 is a server that performs management such as software registration and distribution. Software distribution is performed by wireless communication or wired communication. When it is performed by wireless communication, the management server 2000 may also be called an OTA (Over the Air) server. The vehicle 1000 includes an ECU 100 and a communication device 200. The vehicle 1000 may also include other ECUs (not shown) in addition to the ECU 100. The communication device 200 is configured to be able to communicate with the outside of the vehicle 1000 and, for example, communicates with the management server 2000 during software updates. The ECU 100 includes a non-volatile memory 10, a RAM (Random Access Memory) 20, and a processor 30. The processor 30 may be one processor or may be composed of a plurality of processors.

[0013] The software for controlling the vehicle 1000 is stored in the non-volatile memory 10. The non-volatile memory 10 can store only one software or can store a plurality of softwares at the same time. When the ECU 100 is started, software (not shown) called boot software reads the software actually used for controlling the vehicle 1000 out of the software stored in the non-volatile memory 10 into the RAM 20. Then, the processor 30 executes the read software to control the vehicle 1000. Reading the software into the RAM 20 and causing the processor 30 to execute it is called starting the software. Hereinafter, unless otherwise specified, the term "software" refers to the software for controlling the vehicle 1000.

[0014] Software may be updated to new software for various reasons, such as adding functions, eliminating defects, or achieving more comfortable vehicle control. Software updates are performed, for example, when the management server 2000 distributes data via the communication device 200. Alternatively, it may be performed by writing from an external computer of the vehicle 1000. When data is distributed from the management server 2000, the data of the new software is registered in the management server 2000 by a software supplier or the like. The management server 2000 distributes the data of the new software or the differential data between the software before update and the new software to the vehicle 1000. The distributed data is restored to software in the RAM 20 and stored in the non-volatile memory 10.

[0015] When the storage in the non-volatile memory 10 is completed, the vehicle 1000 is controlled based on the new software. However, there may be cases where it is necessary to revert to the software before update after the update is completed. For example, this may occur when it is discovered that the software contains defects. The software containing defects includes cases where bugs are found in the software, cases where the software does not operate normally, and cases where, although no problems actually occur, there is a possibility that the software may stop operating normally.

[0016] For example, assume that the software of Ver5.0 stored in the non-volatile memory 10 is updated to the software of Ver.6.0, and it is then discovered that the software of Ver6.0 contains defects. Since it is rare for newer software that eliminates the defects in Ver6.0 to be immediately provided, it is necessary to revert to the software of Ver5.0 before update, which is known to operate normally.

[0017] As described above, returning the software used for vehicle control to the software before the update is called rollback. In the following description, the new software after the update is referred to as "Software PROG", and the software before the update that is the target of rollback is referred to as "Old Software PROG-OLD".

[0018] In situations where rollback is necessary, the Old Software PROG-OLD is not always registered in the management server 2000. If the Old Software PROG-OLD that can be rolled back is not in the management server 2000, it becomes necessary to wait for the update of the new software. Also, even if the Old Software PROG-OLD is registered in the management server 2000, depending on the communication status of the vehicle 1000, it may not be possible to perform a rollback from the management server 2000.

[0019] Therefore, in this embodiment, rollback is facilitated by mounting a non-volatile memory different from the non-volatile memory 10 in the vehicle 1000. In the following description, the non-volatile memory 10 is referred to as "First Non-volatile Memory 10", and the non-volatile memory different from the non-volatile memory 10 is referred to as "Second Non-volatile Memory 40". The Second Non-volatile Memory 40 may be a memory incorporated in the vehicle 1000 or may be configured to be removable from the vehicle 1000. Similar to the First Non-volatile Memory 10, software including the Old Software PROG-OLD can also be stored in the Second Non-volatile Memory 40.

[0020] When it becomes necessary to revert the software PROG stored in the first non-volatile memory 10 to the old software PROG-OLD in the ECU 100 according to this embodiment, the ECU 100 determines whether the old software PROG-OLD is stored in the second non-volatile memory 40. If the old software PROG-OLD is stored in the second non-volatile memory 40, the ECU 100 rolls back the old software PROG-OLD from the second non-volatile memory 40 to the first non-volatile memory 10. Thereby, a rollback can be performed quickly without relying on the management server 2000. For example, even when it is found that the software PROG contains a defect, an appropriate response can be made.

[0021] Figures 2 and 3 show an example of the configuration of the vehicle 1000 including the second non-volatile memory 40. In Figures 2 and 3, the RAM 20, the communication device 200, and the management server 2000 are omitted. In Figure 2, the second non-volatile memory 40 is mounted outside the ECU 100. In Figure 3, the second non-volatile memory 40 is included inside the ECU 100.

[0022] In this embodiment, the second non-volatile memory 40 may be mounted anywhere inside the vehicle 1000. However, when the second non-volatile memory 40 is included in another ECU other than the ECU 100, it may affect the other ECU due to the communication load. Therefore, it is more desirable that the second non-volatile memory 40 is included in the ECU 100 as shown in Figure 3 or mounted outside the ECU 100 and other ECUs. The second non-volatile memory 40 may be one or a plurality.

[0023] In the examples of FIGS. 2 and 3, the first non-volatile memory 10 stores the software PROG, and the second non-volatile memory 40 stores the old software PROG-OLD. When it is necessary to revert the software PROG to the old software PROG-OLD, the processor 30 rolls back the old software PROG-OLD from the second non-volatile memory 40 to the first non-volatile memory 10. By performing the rollback from the second non-volatile memory 40, the old software PROG-OLD can be quickly rolled back.

[0024] Hereinafter, various examples of the process related to the rollback will be described.

[0025] 2. First Example 2-1. Two-sided non-volatile memory In the first example, the first non-volatile memory 10 is a two-sided non-volatile memory. A two-sided non-volatile memory is a non-volatile memory having two areas in which software can be stored, and each area may be referred to as a side. In FIG. 4, the two areas are illustrated as the first area 10-A and the second area 10-B. For example, the storage area of the software that the first non-volatile memory 10 has is divided into two areas 10-A and 10-B. As another example, the first non-volatile memory 10 may include two non-volatile memories, and the two non-volatile memories may function as the first area 10-A and the second area 10-B.

[0026] When the first non-volatile memory 10 has two areas, at the time of starting the ECU 100, one of the first area 10-A and the second area 10-B is selected by the boot software. Then, among the software stored in the selected area, the software used for controlling the vehicle 1000 is started. The selected area is called the operating area or the operating side, and the unselected area is called the non-operating area or the non-operating side.

[0027] For example, in (1) of FIG. 4, the first region 10-A is the operating surface and the second region 10-B is the non-operating surface. In (2), the operating surface and the non-operating surface are swapped, with the first region 10-A being the non-operating surface and the second region 10-B being the operating surface. Swapping the operating surface and the non-operating surface is called switching the operating surface.

[0028] To explain with an example, assume that in FIG. 4, software PROG version 2.5 is stored in the first region 10-A and old software PROG-OLD version 2.0 is stored in the second region 10-B. The software executed by the processor 30 is software PROG version 2.5 in (1), and becomes old software PROG-OLD version 2.0 when the operating surface is switched to (2). The switching of the operating surface is performed while the ECU 100 is stopped or immediately after the ECU 100 is started.

[0029] Since the first non-volatile memory 10 has two regions, an operating surface and a non-operating surface, it is possible to write different software to the non-operating surface while executing the software stored on the operating surface. Since software can be written without stopping the control, a smoother rollback becomes possible.

[0030] 2-2. Example of processing FIG. 5 is a conceptual diagram showing an example of processing related to rollback in the case of the first example. In the example of FIG. 5, the software corresponding to software PROG is software version 4.0, and the software corresponding to old software PROG-OLD is software version 3.0. In the state of (1), the old software PROG-OLD version 3.0 stored in the second region 10-B of the operating surface is activated.

[0031] (1) From the management server 2000, software PROG of Ver4.0 is distributed and stored in the first non-volatile memory 10. At this time, the software PROG of Ver4.0 can be stored in either the first area 10-A or the second area 10-B. However, if the storage area is the first area 10-A which is the non-operating surface, the software PROG can be written without stopping the control, so that the update of the software PROG becomes smoother. In addition, the writing of the software PROG does not affect the old software PROG-OLD of Ver3.0 on the operating surface. When the writing of the software PROG of Ver4.0 to the non-operating surface first area 10-A is completed, the switching of the operating surface is performed. By switching the operating surface, the software started as in (2) becomes the software PROG of Ver4.0, and the update is completed.

[0032] After the update is completed, backup may be performed as in (2). Backup means evacuating the old software PROG-OLD to the second non-volatile memory 40. That is, in the example of FIG. 5, backup is performed by storing the old software PROG-OLD of Ver3.0 stored in the non-operating surface in the second non-volatile memory 40. By backup, a more reliable rollback can be realized.

[0033] After that, as in (3), newer software of Ver5.0 may be distributed from the management server 2000. At this time, the software of Ver5.0 is stored in the second area 10-B of the non-operating surface. When the writing of the software of Ver5.0 is completed, the operating surface is switched again, and the update of the software of Ver5.0 is completed. However, in (3) and (4), the state during the writing of the software is illustrated.

[0034] In (4), it is discovered that the software PROG of Ver4.0 contains defects and it is necessary to revert to the old software PROG-OLD. In the example of FIG. 5, since the old software PROG-OLD of Ver3.0 is stored in the second non-volatile memory 40, the processor 30 performs a rollback from the second non-volatile memory 40. That is, the processor 30 stores the old software PROG-OLD of Ver3.0 in the second area 10-B on the non-operating side as in (5). At this time, even if the software of Ver5.0 is being written to the non-operating side, the rollback takes precedence and the update of the software of Ver5.0 is stopped.

[0035] After storage, as in (6), the operating side is switched and the software to be started becomes the old software PROG-OLD of Ver3.0, and thus the rollback is completed. As shown in (5), since the old software PROG-OLD is stored on the non-operating side, it is possible to write the old software PROG-OLD while controlling the vehicle 1000. In this way, by having the first non-volatile memory 10 have two areas, the rollback can be performed more smoothly and appropriate responses can also be made to defects related to the software.

[0036] Here, as a comparative example, consider the case where the second non-volatile memory 40 is not provided. In this case, the old software PROG-OLD of Ver3.0 cannot be used. This is because at least a part of the old software PROG-OLD of Ver3.0 stored in the second area 10-B has been overwritten by the software of Ver5.0. On the other hand, according to the present embodiment, since the second non-volatile memory 40 is provided, it is possible to revert to the old software PROG-OLD of Ver3.0 by rollback. Furthermore, by performing a backup, the rollback can be made more reliable. In this way, the ECU 100 according to the present embodiment can make appropriate responses even when it is necessary to revert to the old software PROG-OLD due to defects related to the software PROG or the like.

[0037] 2-3. Rollback from the non-operating surface As a modification of the present embodiment, when the old software PROG-OLD is stored on the non-operating surface, rollback from the non-operating surface may be performed.

[0038] FIG. 6 shows an example of rollback from the non-operating surface. In the example of FIG. 6, the software corresponding to software PROG is software of Ver4.0, and the software corresponding to the old software PROG-OLD is software of Ver3.0. (1), similar to FIG. 5(1), software PROG of Ver4.0 is distributed from the management server 2000 and stored on the non-operating surface of the first non-volatile memory 10. After storage, the operating surface is switched. After the switch of the operating surface, in (2), a backup of the old software PROG-OLD of Ver3.0 is performed in the same manner as in the case of FIG. 5.

[0039] (3), it is found that the software PROG of Ver4.0 contains a defect and it is necessary to return to the old software PROG-OLD of Ver3.0. At this time, the old software PROG-OLD of Ver3.0 is stored in the second area 10-B of the non-operating surface. Therefore, instead of performing rollback from the second non-volatile memory 40, the operating surface is switched. By switching the operating surface, the software to be started becomes the old software PROG-OLD of Ver3.0 stored on the switched operating surface. That is, it is rolled back to the old software PROG-OLD.

[0040] Such rollback by switching the operating surface is called rollback from the non-operating surface. In the rollback from the non-operating surface, it is only necessary to switch the operating surface, and there is no need to re-store the software, so rollback can be performed more quickly.

[0041] 2-4. Processing flow FIG. 7 is a flowchart showing the processes related to rollback in the case of the first example. The flowchart illustrated in FIG. 7 is executed by the processor 30.

[0042] In step S101, an instruction for rollback is issued to the ECU 100. The rollback instruction is issued, for example, when the user of the management server 2000 or the vehicle 1000 needs to roll back the software to the old software PROG-OLD. When the ECU 100 receives the rollback instruction, the process proceeds to step S102.

[0043] In step S102, it is determined whether the software is being updated in the first non-volatile memory 10. If the software is being updated (step S102; Yes), the process proceeds to step S103. If it is not being updated (step S102; No), the process proceeds to step S104.

[0044] In step S103, in order to execute the rollback, the software update is stopped. Then, the process proceeds to step S104.

[0045] In step S104, it is determined whether the old software PROG-OLD is stored in the non-operating area of the first non-volatile memory 10. At this time, it may also be determined simultaneously whether the old software PROG-OLD is in a state where its integrity is maintained without being tampered with or rewritten. If the old software PROG-OLD is stored while maintaining its integrity (step S104; Yes), the process proceeds to step S105. If the old software PROG-OLD is not stored or the integrity of the old software PROG-OLD is not maintained (step S104; No), the process proceeds to step S106.

[0046] In step S105, the switching of the operating area is performed. Then, the process ends. The switching of the operating area performed in step S105 is a rollback from the non-operating area.

[0047] In step S106, it is determined whether the old software PROG-OLD is stored in the second non-volatile memory 40. At this time, it may be simultaneously determined whether the old software PROG-OLD is in a state where its integrity is maintained without being tampered with or rewritten. If the old software PROG-OLD is stored in a state where its integrity is maintained (step S106; Yes), the process proceeds to step S108. If the old software PROG-OLD is not stored, or if the integrity of the old software PROG-OLD is not maintained (step S106; No), the process proceeds to step S107.

[0048] In step S107, the processor 30 notifies the outside to download the necessary software. For example, the user of the vehicle 1000 is notified to perform a wired download using a dedicated tool or a download from an external computer. Then, the process returns to step S101.

[0049] In step S108, the old software PROG-OLD is stored from the second non-volatile memory 40 onto the non-operating surface of the first non-volatile memory 10. Then, the process proceeds to step S109.

[0050] In step S109, the operating surface is switched. By switching the operating surface, the old software PROG-OLD is started. Then, the process ends. The processes of step S108 and step S109 are a rollback from the second non-volatile memory 40.

[0051] The backup of the old software PROG-OLD is realized, for example, by the processor 30 executing the flowchart shown in FIG. 8.

[0052] In step S201, the software is updated. When the software is updated, the process proceeds to step S202.

[0053] In step S202, it is determined whether the software update has been completed. For example, when the software update is performed by storing new software in the non-operating area of the first non-volatile memory 10, it is determined that the software update has been completed when the storage of the software in the non-operating area and the switching of the operating area are completed. If the software update has been completed (step S202; Yes), the process proceeds to step S203. If the update has not been completed (step S202; No), the process returns to step S201.

[0054] In step S203, a software write notification is sent to the second non-volatile memory 40. Then, the process proceeds to step S204.

[0055] In step S204, it is determined whether a normal response has been received from the second non-volatile memory 40 in response to the software write notification. If a normal response has been received (step S204; Yes), the process proceeds to step S205. If there is no response or the response is abnormal (step S204; No), the process proceeds to step S207. An abnormal response is issued in the case of a failure or insufficient capacity of the second non-volatile memory 40.

[0056] In step S207, the user of the vehicle 1000 is notified of the backup failure. Then, the process ends. By the notification in step S207, when there is a failure or insufficient capacity of the second non-volatile memory 40, the user can be prompted to take action.

[0057] In step S205, the backup of the old software PROG-OLD, that is, the storage of the old software PROG-OLD in the second non-volatile memory 40, is started. Then, the process proceeds to step S206.

[0058] In step S206, it is determined whether the backup of the old software PROG-OLD has been completed. If the backup has not been completed (step S206; No), the process returns to step S205. If the backup has been completed (step S206; Yes), the backup process is stopped by the backup processing control software, and the process ends.

[0059] 3. Second example In the second example, when rolling back from the second non-volatile memory 40, a step of authentication by the management center is added. The second non-volatile memory 40 is more easily rewritable than the first non-volatile memory 10 and is vulnerable to attacks by malicious third parties. Also, when a plurality of versions of software are stored in the second non-volatile memory 40 as software of an older version than the software PROG, there is a risk of rolling back to the wrong version of the software. In the second example, by adding the authentication step, it is confirmed that the old software PROG-OLD stored in the second non-volatile memory 40 is the correct version of the regular software. In this way, it is possible to prevent rolling back to tampered software or the wrong version of the software. The authentication step is performed as follows.

[0060] The management center assigns an encryption key corresponding to each version to the software. The management center may be the same as the management server 2000. When performing a rollback from the second non-volatile memory 40, the ECU 100 transmits the encryption key of the old software PROG-OLD to the management center via the communication device 200. The management center decrypts the encryption key received from the ECU 100 and verifies that it is regular software. For example, by performing authentication using the Hash value assigned to the software, the uniqueness of the software is verified. Alternatively, authentication using a secret key, a public key, SHA-256, etc. may be performed. Only when the authentication by the management center is correctly performed, the rollback of the old software PROG-OLD from the second non-volatile memory 40 is performed.

[0061] Figure 9 is a flowchart showing an example of processing in the second example.

[0062] In steps S301 to S307, the same processing as steps S101 to S107 in FIG. 7 is performed. In step S306, when software is stored (step S306; Yes), the process proceeds to step S308.

[0063] In step S308, it is determined whether the old software PROG-OLD is correctly authenticated by the management center. As described above, an encryption key is used for authentication by the management center. When correctly authenticated (step S308; Yes), the process proceeds to step S310. When not correctly authenticated (step S308; No), the process proceeds to step S309.

[0064] In step S309, the same processing as step S107 in FIG. 7 is performed. Thereafter, the process returns to step S301.

[0065] In steps S310 and S311, rollback of the old software PROG-OLD from the second non-volatile memory 40 is performed in the same manner as steps S108 and S109 in FIG. 7. After the operation mode is switched in step S311, the process ends.

[0066] In this way, by adding the step of authenticating the old software PROG-OLD by the management center, it is possible to prevent the modified software or the wrong version of software from being rolled back to the first non-volatile memory 10. When the old software PROG-OLD that is correctly authenticated is not stored in the second non-volatile memory 40, by notifying the user, it is possible to prompt an update to the correct software.

[0067] 3. Third Example The first non-volatile memory 10 may be a single-sided non-volatile memory. Even when the first non-volatile memory 10 is a single-sided non-volatile memory, the control device according to the present embodiment can perform rollback and backup of the old software PROG-OLD in the same manner as described above. Hereinafter, an example of performing rollback and backup will be described.

[0068] In FIG. 10, the first non-volatile memory 10 has only one area 10-A as an area for storing software. Therefore, the area 10-A always becomes the operating surface. In the example of FIG. 10, the software corresponding to the software PROG is Ver4.0 software, and the software corresponding to the old software PROG-OLD is Ver3.0 software.

[0069] (1), the old software PROG-OLD of Ver3.0 is stored in the area 10-A. In (1), a backup of the old software PROG-OLD is performed, and the old software PROG-OLD of Ver3.0 is evacuated to the second non-volatile memory 40. In (2), the software PROG of Ver4.0 is distributed from the management server 2000, and the software of the first non-volatile memory 10 is updated to the software PROG of Ver4.0. In FIG. 10, the control system of the vehicle 1000 including the ECU 100 is in a stopped state during the update of the software PROG.

[0070] After the update is completed, it is found in (3) that the software PROG of Ver4.0 contains defects and it is necessary to return to the old software PROG-OLD. Therefore, in (4), a rollback of the old software PROG-OLD of Ver3.0 is performed from the second non-volatile memory 40. At this time, the control system of the vehicle 1000 is in a stopped state until the rollback is completed.

[0071] As shown in FIG. 10, the control device according to the present embodiment can perform rollback regardless of whether the first non-volatile memory 10 has one side or two sides, and can appropriately respond even if it is found that the software contains defects. In an ECU that does not require high performance such as a sensor ECU, the cost can be reduced by making the area of the first non-volatile memory 10 single.

[0072] 4. Other Examples The old software PROG-OLD may include software of two or more previous versions. For example, when it is found that the software contains a bug, if the same bug is also included in the software of the previous version and it is necessary to roll back to the software of two or more previous versions, in such a case, the control device according to the present embodiment may perform a rollback to the old software PROG-OLD of two or more previous versions. In the present embodiment, data of software of an arbitrary version may be downloaded in advance from an external terminal such as a computer to the second non-volatile memory 40 so that the software can be rolled back to an arbitrary version.

[0073] 5. Summary As described above, by mounting the second non-volatile memory 40 on the vehicle 1000, the control device according to the present embodiment can realize a quick rollback. By mounting the second non-volatile memory 40, it is possible to surely secure the free capacity of the memory and perform a backup of the old software PROG-OLD. In addition, since the second non-volatile memory 40 can be configured to be removable, it is possible to select and use existing memories of various capacities, and the vehicle system can be made robust.

Explanation of Reference Numerals

[0074] 10 First non-volatile memory 10-A First area 10-B Second area 30 Processor 40 Second non-volatile memory 200 Communication device 1000 Vehicle 2000 Management server PROG Software PROG-OLD Old software

Claims

1. A control device for a vehicle, comprising a first non-volatile memory for storing software for controlling the vehicle, and one or more processors for executing the software , wherein the one or more processors, when updating the software, move the old software before the update to a second non-volatile memory mounted on the vehicle, store the software in the first non-volatile memory, when it is necessary to revert the software to the old software, determine whether the old software before the update is stored in the second non-volatile memory, when the old software is stored in the second non-volatile memory, after confirming that the encryption key of the old software has been correctly authenticated by the management center, store the old software from the second non-volatile memory to the first non-volatile memory is configured as such, wherein the second non-volatile memory is a non-volatile memory different from the first non-volatile memory, mounted outside the control device and other control devices, and is configured to be removable from the vehicle control device.

2. The control device according to claim 1, wherein the first non-volatile memory has a first area for storing the software and a second area in an area different from the first area, storing the old software from the second non-volatile memory to the first non-volatile memory includes storing the old software from the second non-volatile memory to the non-operating second area, after storing the old software in the second area, switching the first area to a non-operating state and switching the second area to an operating state including control device.

3. The control device according to claim 2, wherein the one or more processors further, when it is necessary to revert the software to the old software before the update, determine whether the old software is stored in the second area of the first non-volatile memory, when the old software is stored in the second area, switch the first area to a non-operating state and switch the second area to an operating state, skip the determination of whether the old software before the update is stored in the second non-volatile memory mounted on the vehicle, control device.

4. The control device according to claim 2 or 3, wherein the one or more processors further, When updating from the old software to the software, store the software in the non-operating state of the first area of the first non-volatile memory. After storage, switch the first area to the operating state and switch the second area to the non-operating state. After the switch, move the old software to the second non-volatile memory. Control device.

Images