Electronic control unit

Abstract

To provide an electronic control device capable of downgrading software.SOLUTION: An electronic control device 100 comprises: a microcomputer; a memory 20 in which software to be executed by the microcomputer is stored in a rewritable state; and a communication interface 70 for receiving distribution software 1 which can rewrite the software. The microcomputer also comprises a security verification part 115 for determining whether or not the distribution software satisfies security standards when the distribution software is not newer than software stored in a ROM. The microcomputer also comprises a rollback part 116 which can rewrite the software stored in the ROM to the distribution software when determining that the security standards are satisfied.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to electronic control devices. [Background technology]

[0002] An example of an electronic control device is an information processing device disclosed in Patent Document 1. The information processing device updates software using update software when it is determined that the version of the update software is newer than the current software version. On the other hand, the information processing device suspends software rewriting when it is not determined that the version of the update software is newer than the current software version. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6595822 Summary of the Invention [Problem to be solved by the invention]

[0004] As described above, in the information processing device, if the version of the update software is newer than the current version of the software, the software rewriting is suspended. This causes a problem in that the information processing device cannot downgrade the software version.

[0005] One disclosed object is to provide an electronic control device that allows software to be downgraded. [Means for solving the problem]

[0006] The electronic control device disclosed herein comprises: An electronic control device comprising a processing device (10), a storage device (21) in which software executed by the processing device is stored in a rewritable state, and a communication device (70) for receiving distributed software for rewriting the software, The processing device a version check unit (112) for checking the versions of the software and the distribution software; a security determination unit (115) that determines whether the distributed software satisfies security standards if the distributed software is not a newer version than the software; and a rewriting unit (116) that rewrites the software to distribution software when it is determined that the software satisfies the security standards. 、 The security determination unit a first acquisition unit (115a) that acquires current location information indicating the current location of the electronic control device; a second acquisition unit (115c) that acquires distribution software information indicating the type of distribution software; and a determination unit (115b, 115d) that determines that the distribution software satisfies the security standard when the combination of the acquired current location and the acquired type is valid, and that the distribution software does not satisfy the security standard when the combination is invalid. Electronic control device.

[0007] In this way, the electronic control unit can rewrite its software with the distributed software even if the distributed software is not a newer version, as long as it satisfies the security standards. Therefore, the electronic control unit can rewrite its software with the distributed software even if it is a downgraded version.

[0008] The various aspects disclosed in this specification employ different technical means to achieve their respective objectives. The reference numerals in parentheses in the claims and in this section are intended to exemplify correspondences with the following embodiments and are not intended to limit the technical scope. The objectives, features, and advantages disclosed in this specification will become more apparent by reference to the following detailed description and the accompanying drawings. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 2 is a block diagram showing a schematic configuration of an ECU. [Figure 2]FIG. 2 is a functional block diagram showing functions of the ECU. [Figure 3] FIG. 2 is a functional block diagram showing functions of a security verification unit. [Figure 4] 4 is a flowchart showing the operation of the ECU. [Figure 5] 10 is a flowchart showing the operation of a security verification unit. [Figure 6] 10 is a flowchart showing security levels. [Figure 7] 1 is a diagram showing the relationship between security level items; [Figure 8] FIG. 10 is a functional block diagram showing functions of a security verification unit in a modified example. [Figure 9] 10 is a flowchart showing the operation of a security verification unit in a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0010] (Embodiment) Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. In this embodiment, as an example, an electronic control unit (ECU) 100 that can be mounted on a vehicle is employed. The vehicle is equipped with multiple electronic control units that control different objects. The electronic control unit 100 is one of them. Of the multiple electronic control units, electronic control units other than the electronic control unit 100 are also referred to as other control units.

[0011] <Configuration> As shown in FIG. 1, the electronic control device 100 includes a microcomputer 10, a memory 20, an input interface 30, an output interface 40, a protection element 50, an internal power supply 60, a communication interface 70, and the like.

[0012] The microcomputer 10 (MIC) is powered by an internal power supply 60 and becomes operational. The microcomputer 10 is configured to be able to execute software stored in the ROM 21 of the memory 20. The microcomputer 10 executes the software to perform various arithmetic operations. When performing arithmetic operations, the microcomputer 10 uses data stored in the RAM 22 of the memory 20 and sensor signals input via the input interface 30. The microcomputer 10 outputs the results of the operations as control signals via the output interface 40. The microcomputer 10 can also be called a processor. The microcomputer 10 corresponds to a processing device.

[0013] The memory 20 (MEM) includes a ROM 21, a RAM 22, etc. The ROM 21 stores software and the like in a rewritable manner. The ROM 21 can be an EEPROM (registered trademark), a flash memory, etc. The RAM 22 temporarily stores data and the like used by the microcomputer 10 for arithmetic processing. The ROM 21 corresponds to a storage device.

[0014] 2, the ROM 21 includes a version information storage unit 20a, a software storage unit 20b, and a security level list storage unit 20c. In Fig. 2, the version information storage unit 20a is indicated as VIS, the software storage unit 20b as SWS, and the security level list storage unit 20c as SLS.

[0015] The version information storage unit 20a stores version information (numbers) of software stored in the ROM 21. The software storage unit 20b stores software. Hereinafter, the software stored in the software storage unit 20b will also be simply referred to as software. The security level list storage unit 20c stores a security level list (SLL). The security level list storage unit 20c corresponds to a list storage unit.

[0016] The electronic control unit 100 is configured so that its software can be rewritten with distributed software 1 distributed from a rewriting device provided outside the vehicle. It can also be said that the electronic control unit 100 is configured so that its software can be reprogrammed.

[0017] The distributed software 1 may be a newer version than the software, or an older version. In other words, the electronic control unit 100 can upgrade the software stored in the software storage unit 20b by rewriting it with a newer version of the distributed software 1. The electronic control unit 100 can also roll back the software stored in the software storage unit 20b by rewriting it with an older version of the distributed software 1. However, when rewriting with an older version of the distributed software 1, security standards described later must be met. The electronic control unit 100 may also rewrite the software with the same version of the distributed software 1. This case may also be considered a rollback.

[0018] The security level list will now be described with reference to Figures 6 and 7. The security level list defines the relationship between multiple GPS information 3, the security level (SL) of each GPS information 3, and the type of distribution software 1 corresponding to each security level. The type can be rephrased as the rewrite software level of the distribution software 1.

[0019] The security level list includes the following items: security level, GPS information 3, and distributed software information 2. The relationship between each item is as shown in Figure 7. The software version number is included in the distributed software information 2 and differs for each type of distributed software 1. Therefore, the type can be determined by the version number. Furthermore, the distributed software information 2 may include information indicating the type of distributed software 1 in addition to the version number.

[0020] GPS information corresponds to location information. In Fig. 2 etc., distributed software 1 is written as DSW, distributed software information 2 is written as DSI, and GPS information 3 is written as GSI.

[0021] An example of the security level list is shown in Fig. 6. In the security level list, the security level is set to three levels, level 1 to level 3.

[0022] Level 3 is the highest security level. Level 3 specifies information indicating the location of the vehicle manufacturer as GPS information 3 and information indicating all distributed software 1 as the type. In other words, if the current location of the electronic control device 100 is within the manufacturer, all distributed software 1 can be considered to meet the security standards. Level 3 corresponds to a high level.

[0023] Level 2 is a security level lower than the high level. Level 2 specifies GPS information indicating the location of the vehicle's dealer (authorized dealer) and information indicating either the type of distributed software 1 related to a function update or the type of distributed software 1 related to a defect fix. In other words, if the current location of the electronic control device 100 is the dealer and the type of distributed software 1 indicates a function update, it can be considered that the security standard is met. Level 2 corresponds to the medium level.

[0024] Level 1 is a security level lower than the medium level. Level 1 specifies GPS information indicating the location of the user's home and type information indicating the distribution software 1 related to option changes. The location information may also include information indicating the location of a pre-registered car specialty store. In other words, if the current location of the electronic control device 100 is the user's home and the type of the distribution software 1 indicates option changes, it can be considered that the security standard is met. Level 1 corresponds to a low level.

[0025] In addition, if the type of security level is lower than the security level of the location information, it is considered to meet the security standard. In other words, if the location information is from a legitimate dealer, even if the type of distribution software 1 is related to option changes, it is considered to meet the security standard.

[0026] Returning now to the explanation of Figure 1, the input interface 30 (IIF) is connected to a sensor 300 (SEN). The input interface 30 receives a sensor signal output from the sensor 300. The microcomputer 10 performs arithmetic processing using the sensor signal. The sensor 300 is an output device that outputs a signal used by the microcomputer 10 for arithmetic processing. The input interface 30 may be connected to an output device other than the sensor 300.

[0027] The output interface 40 (OIF) is connected to an actuator 400 (ACT). The electronic control device 100 outputs a control signal generated by the microcomputer 10 via the output interface 40. The actuator 400 is an object to be controlled by the electronic control device 100. Therefore, the actuator 400 can also be called a target device. The output interface 40 may be connected to a target device other than the actuator 400.

[0028] The protection element 50 (PRT) is connected to the battery 200 and the internal power supply 60 (PWS). The protection element 50 is an element for preventing an overvoltage from being applied from the battery 200.

[0029] The internal power supply 60 (PWS) generates power to be used inside the electronic control device 100 and supplies it to the microcomputer 10, etc. The internal power supply 60 is supplied with power from the battery 200 via the protection element 50. The internal power supply 60 generates power to be used inside the electronic control device 100 from the power from the battery 200.

[0030] The communication interface 70 (CIF) is connected to the communication line 500. The communication interface 70 is a communication device that communicates with other control devices, etc. via the communication line 500. The communication interface 70 receives distributed software 1, etc., that rewrites software stored in the ROM 21. The electronic control device 100 can receive the distributed software 1, etc., via the communication line 500 from a rewrite device at a vehicle manufacturer, dealer, etc. In other words, it can be said that the rewrite device is provided outside the vehicle, at a manufacturer, dealer, etc.

[0031] In addition to the distributed software 1, the electronic control unit 100 can receive distributed software information 2 indicating the type of the distributed software 1 and GPS information 3 indicating the current location of the electronic control unit 100. When the electronic control unit 100 is mounted on a vehicle, the GPS information 3 is information indicating the current location of the vehicle.

[0032] The communication here can be in accordance with the CAN (registered trademark) protocol. In this case, the communication interface 70 is a CAN interface. The communication interface 70 corresponds to a communication device.

[0033] The electronic control unit 100 may be provided with a wireless communication device as a communication device. In this case, the electronic control unit 100 can communicate with an external center provided outside the vehicle and equipped with a rewriting device via the wireless communication device. By providing the wireless communication device, the electronic control unit 100 can wirelessly receive distributed software 1, etc. In other words, the electronic control unit 100 can rewrite software using OTA (Over the Air).

[0034] <Function blocks, processing operations> Here, the functional blocks and processing operations of the electronic control device 100 will be described with reference to Figures 2 to 5. The electronic control device 100 provides various functions for the microcomputer 10 to execute arithmetic processing. Figures 2 and 3 show various functional blocks showing the relationships between the various functions. As shown in Figure 2, the microcomputer 10 has an updater 110 that rewrites software as a functional block.

[0035] When the microcomputer 10 receives a software update request from the rewriting device, it starts the process shown in the flowchart of FIG.

[0036] In step S11, the distribution software 1 is downloaded. The microcomputer 10 downloads the software via the communication interface 70. Hereinafter, the downloaded distribution software 1 will also be simply referred to as the distribution software 1.

[0037] In step S12, the validity of the version number is confirmed. The first verification unit 111 (1VDT) checks whether the version number of the distribution software 1 is valid. The version number is assigned to the distribution software 1. Therefore, the first verification unit 111 can check the validity by referring to the distribution software 1. If the microcomputer 10 determines that the version number is invalid, it may terminate the flowchart of FIG. 4.

[0038] In step S13, the version is confirmed. Here, it is confirmed whether the distributed software 1 is for a version upgrade or a version downgrade. The rollback detection unit 112 (RBD) confirms the version of the software and the version of the distributed software 1. At this time, the version management unit 113 (VCNT) reads the version number of the software from the version information storage unit 20a (VIS) and outputs it to the rollback detection unit 112. In other words, the rollback detection unit 112 refers to the version number stored in the version information storage unit 20a via the version management unit 113. The rollback detection unit 112 compares the version number of the software with the version number of the distributed software 1. The rollback detection unit 112 corresponds to a version confirmation unit.

[0039] In step S14, it is confirmed whether or not the version is newer. The rollback detection unit 112 compares the version number of the software with the version number of the distributed software 1. The rollback detection unit 112 then determines that the version is newer if the version number of the distributed software 1 is newer than the version number of the software. On the other hand, the rollback detection unit 112 does not determine that the version is newer if the version number of the distributed software 1 is not newer than the version number of the software. If the microcomputer 10 determines that the version is newer, it proceeds to step S15, and if it does not determine that the version is newer, it proceeds to step S16.

[0040] In step S16, security is checked. The security verification unit 115 (SVDT) checks whether security is met based on the relationship between the type of distributed software 1 and the current location, i.e., whether the security standard is met. In other words, the security verification unit 115 determines whether the distributed software 1 meets the security standard if the distributed software 1 is not a newer version than the software. The security verification unit 115 corresponds to a security determination unit.

[0041] The security verification process will now be described with reference to Figures 3 and 5. The security verification unit 115 includes the functional blocks shown in Figure 3.

[0042] In step S20, GPS information 3 is acquired. The GPS information acquisition unit 115a (GPA) acquires the GPS information 3 indicating the current position of the electronic control unit 100. The GPS information acquisition unit 115a acquires the GPS information 3 from a navigation control device, which is one of the other control devices, via the communication interface 70. The GPS information acquisition unit 115a corresponds to a first acquisition unit. The GPS information 3 corresponds to current position information.

[0043] In step S21, the GPS information 3 is checked against the security level list stored in the electronic control device 100. The security level verification unit 115b (SLD) checks the GPS information 3 against the security level list stored in the security level list storage unit 20c.

[0044] In step S22, the security level is determined. The security level verification unit 115b determines the security level of the GPS information 3, i.e., the security level of the current position of the electronic control device 100. In other words, the security level verification unit 115b determines the security level associated with the GPS information 3 in the security level list. The security level verification unit 115b corresponds to a determination unit and a first determination unit.

[0045] In step S23, distributed software information 2 is acquired. The distributed software information acquisition unit 115c (DSA) acquires the distributed software information 2. In other words, the distributed software information acquisition unit 115c acquires the type of distributed software 1 or a version number indicating the type of distributed software 1. The distributed software information 2 here is information on the distributed software 1 downloaded in step S11. The distributed software information acquisition unit 115c corresponds to a second acquisition unit.

[0046] In step S24, the distributed software information 2 and the security level are compared with the security level list stored in the electronic control device 100. The security clear verification unit 115d (SCD) compares the distributed software information 2 acquired in step S23 and the security level that is the judgment result of step S22 with the security level list stored in the security level list storage unit 20c. In other words, the security clear verification unit 115d compares the type of distributed software 1 and the security level of the GPS information 3 with the security level list. The security clear verification unit 115d corresponds to a judgment unit and a second judgment unit.

[0047] In step S25, it is determined whether the location (GPS information 3) and the distribution software 1 are a valid combination. If the combination of the acquired GPS information 3 and the acquired type is valid, the security clearance verification unit 115d determines that the distribution software 1 meets the security standard. Furthermore, if the combination of the acquired GPS information 3 and the acquired type is invalid, the microcomputer 10 determines that the distribution software 1 does not meet the security standard.

[0048] Therefore, the security clearance verification unit 115d uses the result of the comparison in step S24 to determine whether the relationship between the security level of the type and the security level of the GPS information 3 satisfies the relationship defined in the security level list.

[0049] The security clearance verification unit 115d determines that the combination of the GPS information 3 and the type is valid when the relationship between the security level of the type and the security level of the GPS information 3 satisfies the relationship defined in the security level list. Therefore, the security clearance verification unit 115d determines that the distribution software 1 satisfies the security standard.

[0050] On the other hand, if the relationship between the two security levels does not satisfy the relationship defined in the security level list, the security clearance verification unit 115d determines that the combination of the GPS information 3 and the type is invalid. Therefore, the security clearance verification unit 115d determines that the distribution software 1 does not satisfy the security standard.

[0051] For example, if the GPS information 3 indicates that the device is located in a manufacturer's office, all types of distributed software 1 will meet the security standards. If the GPS information 3 indicates that the device is located in an authorized dealer, distributed software 1 with a bug fix type will meet the security standards. However, if the GPS information 3 indicates that the device is located at home, distributed software 1 with a bug fix type will not meet the security standards.

[0052] In step S26, it is determined that the security has been cleared. The security clearance determination unit 115e (SCC) determines that the security has been cleared, that is, that the security standard is met, according to the verification result of the security clearance verification unit 115d. Here, if the security clearance determination unit 115e determines that the combination is valid, it stores information indicating that the security standard is met, for example, in the RAM 22.

[0053] The microcomputer 10 may proceed to step S15 if it determines YES in step S25, and may end the flowcharts of FIGS. 4 and 5 if it determines NO.

[0054] Returning now to the flowchart of FIG. 4, in step S17, it is confirmed whether or not security has been cleared. In step S16, the security verification unit 115 determines whether or not a verification result indicating that security has been cleared is obtained. The security verification unit 115 determines that security has been cleared if information indicating that security standards are met is stored in the RAM 22 or the like. On the other hand, the security verification unit 115 does not determine that security has been cleared if information indicating that security standards are met is not stored in the RAM 22 or the like. If the microcomputer 10 determines that security has been cleared, it proceeds to step S15, and if it does not determine that security has been cleared, it ends the flowchart of FIG. 4. In other words, the microcomputer 10 does not rewrite the software with distributed software 1 that has not cleared security. Note that if the capacity of the RAM 22 is small, the distributed software 1 may be written to the ROM 21 once, and use of the distributed software 1 may be permitted once security has been cleared.

[0055] In step S15, the software is rewritten. If the determination in step S14 is YES, the software is rewritten by the update unit 114 (UPD). The update unit 114 rewrites the software stored in the software storage unit 20b with the distributed software 1.

[0056] On the other hand, if the determination in step S14 is NO, the rollback unit 116 (RBP) rewrites the software. The rollback unit 116 rewrites the software stored in the software storage unit 20b with the distributed software 1. If the determination in step S14 is NO, there is a possibility of a rollback attack. Therefore, the rollback unit 116 rewrites the software only if it is determined in steps S16 and S17 that the security standards are met, as described above. The rollback unit 116 corresponds to a rewriting unit.

[0057] In step S18, it is determined whether the rewriting has been successful. The second verification unit 117 (2VDT) determines whether the rewriting of the software stored in the software storage unit 20b has been successful. If the microcomputer 10 determines that the rewriting has been successful, it proceeds to step S19, and if it determines that the rewriting has not been successful, it ends the flowchart of FIG. 4. Note that the method for determining whether the rewriting has been successful is not particularly limited.

[0058] In step S19, the version information is rewritten. Version management unit 113 rewrites the version number stored in version information storage unit 20a to the version number of the distributed software. As a result, the version number of the software stored in software storage unit 20b matches the version number stored in version information storage unit 20a.

[0059] <Effects> In this way, the electronic control unit 100 can rewrite the software to the distributed software 1 even if the distributed software 1 is not a new version, as long as it satisfies the security standards. Therefore, the electronic control unit 100 can rewrite the software to the distributed software 1 even if it is a downgraded version. In other words, the electronic control unit 100 can perform rollback on the condition that the security standards are satisfied. Therefore, the electronic control unit 100 can downgrade the software while preventing rollback attacks.

[0060] The electronic control unit 100 can perform rollback provided that security standards are met, allowing for flexible responses from users and developers. For example, even if the distributed software 1 for option changes corresponds to a version downgrade, the electronic control unit 100 allows software to be rewritten at the user's home. Furthermore, the electronic control unit 100 can prevent software rewriting from being rejected because the version downgrade is required. Furthermore, the electronic control unit 100 can increase the options for software customization.

[0061] The electronic control device 100 uses the security level list with the three security levels set as described above to determine whether the security standard is met. Therefore, the electronic control device 100 can achieve a safe rollback by combining an appropriate location and the distribution software 1.

[0062] Furthermore, the electronic control unit 100 stores a security level list in its own memory 20. Therefore, the electronic control unit 100 only needs to perform the work of incorporating the security level list and the security verification unit 115, and the work of verifying them, for one electronic control unit 100. In other words, the electronic control unit 100 can reduce the scale of the work of incorporating and verifying compared to the modified examples described later.

[0063] (Variation) Here, a modified example of the electronic control device 100 will be described with reference to Fig. 8 and Fig. 9. As shown in Fig. 8, a vehicle 100x (CAR) is provided with a memory 20x outside the electronic control device 100. The memory 20x is provided in another control device such as a master control device. The security level list storage unit 20c is provided in the memory 20x.

[0064] The vehicle control system can be considered to include a plurality of electronic control devices configured to be able to communicate with each other. The vehicle control system includes an electronic control device 100 and a master control device having a memory 20x.

[0065] The security level verification unit 115b and the security clearance verification unit 115d are configured to be able to access the memory 20x. In other words, the security level verification unit 115b and the security clearance verification unit 115d are configured to be able to refer to the security level list in the security level list storage unit 20c stored in the memory 20x.

[0066] 9, in step S21a, the security level verification unit 115b compares the GPS information 3 with the security level list stored in the vehicle 100x. In step S24a, the security clear verification unit 115d compares the distributed software information 2 and the security level with the security level list stored in the vehicle 100x.

[0067] Therefore, the electronic control unit 100 does not need to store the security level list in the memory 20. Therefore, the electronic control unit 100 does not need to reduce its functions for the security level list. Also, the electronic control unit 100 can incorporate the security level list without considering the size of the memory 20. Furthermore, the vehicle control system can share the security level list among multiple electronic control units. The electronic control unit 100 of the modified example can achieve the same effects as the above embodiment.

[0068] Although the preferred embodiments of the present disclosure have been described above, the present disclosure is not limited to the above embodiments and various modifications are possible without departing from the spirit and scope of the present disclosure.

[0069] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, although various combinations and forms are shown in the present disclosure, other combinations and forms including only one element, more, or less than one element are also within the scope and spirit of the present disclosure. [Explanation of symbols]

[0070] 1...Distribution software, 2...Distribution software information, 3...GPS information, 10...Microcomputer, 20, 20x...Memory, 20a...Version information storage unit, 20b...Software storage unit, 20c...Security level list storage unit, 21...ROM, 22...RAM, 30...Input interface, 40...Output interface, 50...Protection element, 60...Internal power supply, 70...Communication interface, 100...Electronic control unit, 100x...Vehicle, 110...Updater, 111... First verification unit, 112...rollback detection unit, 113...version management unit, 114...update unit, 115...security verification unit, 115a...GPS information acquisition unit, 115b...security level verification unit, 115c...distribution software information acquisition unit, 115d...security clearance verification unit, 115e...security clearance determination unit, 116...rollback unit, 117...second verification unit, 200...battery, 300...sensor, 400...actuator, 500...communication line

Claims

1. An electronic control device comprising: a processing device (10); a storage device (21) in which software executed by the processing device is stored in a rewritable state; and a communication device (70) for receiving distributed software for rewriting the software, The processing device includes: a version checking unit (112) for checking the versions of the software and the distributed software; a security determination unit (115) that determines whether the distributed software satisfies a security standard when the distributed software is not a newer version than the software; a rewriting unit (116) that rewrites the software to the distributed software when it is determined that the security standard is satisfied, The security determination unit a first acquisition unit (115a) that acquires current location information indicating the current location of the electronic control device; a second acquisition unit (115c) that acquires distribution software information indicating the type of the distribution software; An electronic control device comprising a judgment unit (115b, 115d) that judges that the distribution software satisfies the security standard if the combination of the acquired current location and the acquired type is valid, and judges that the distribution software does not satisfy the security standard if the combination is invalid.

2. The determination unit a list storage unit (20c) that stores a security level list that defines the relationship between a plurality of pieces of location information, a security level of each piece of location information, and the type of the distribution software corresponding to each security level; a first determination unit (115b) that compares the acquired current location with the security level list and determines the security level of the acquired current location; a second determination unit (115d) that compares the acquired type and the security level that is the determination result of the first determination unit with the security level list, and determines the relationship between the security level of the type and the security level that is the determination result, 2. The electronic control device according to claim 1, wherein the second judgment unit determines that the combination is valid when the relationship between the security level of the type and the security level that is the judgment result satisfies the relationship specified in the security level list, and determines that the combination is invalid when the relationship specified in the security level list is not satisfied.

3. The electronic control device according to claim 2 , wherein the list storage unit is provided in the storage device.

4. An electronic control device mounted on a vehicle, The electronic control unit according to claim 2 , wherein the list storage unit is provided in a control unit other than the electronic control unit mounted on the vehicle.

5. An electronic control device mounted on a vehicle, The security level list is set to three levels of security levels, The highest security level, i.e., a high level, is defined as the location information indicating the location of the manufacturer of the vehicle and the type of the distributed software, and At a medium level, which is a security level lower than the high level, information indicating a location of a dealer of the vehicle and information indicating either a function update or a defect fix are defined as the location information, An electronic control device according to any one of claims 2 to 4, wherein a low level, which is a security level lower than the medium level, is defined as information indicating the location of the user's home as the location information and information indicating an option change as the type.

Images