ECU, communication equipment, and access management systems
The ECU's public key system for role verification and permission management addresses access control issues, ensuring secure and compliant task execution in vehicle ECUs.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- SUBARU CORP
- Filing Date
- 2022-04-20
- Publication Date
- 2026-07-08
AI Technical Summary
Existing methods for controlling access to vehicle ECUs are inadequate, particularly in ensuring secure and controlled access for maintenance and diagnostic operations, especially in offline scenarios and in compliance with Right to Repair laws, which require access by non-dealer personnel.
The ECU implements a public key system to verify roles and permissions, allowing specific tasks based on a role list that has passed signature verification, with the management server managing role lists and permissions.
This system ensures secure and controlled access to ECUs, allowing authorized personnel to perform specific tasks within defined scopes, enhancing security and compliance with access control requirements.
Smart Images
Figure 0007886731000001 
Figure 0007886731000002 
Figure 0007886731000003
Abstract
Description
Technical Field
[0001] The present invention relates to an ECU, a communication device, and an access management system for preventing unauthorized access to information stored in an electronic control unit (hereinafter referred to as ECU) in a vehicle.
Background Art
[0002] In recent years, a plurality of ECUs are installed in vehicles, including an engine control ECU that controls an engine. There is also a technology for controlling a vehicle using an integrated ECU that integrates the functions of a plurality of ECUs. Some ECUs store control information such as sensor sensitivity and the delay operation time of a dome lamp in a rewritable non-volatile memory. Such control information can be rewritten even after being supplied to the market. In addition, various state data generated in the vehicle and diagnostic result data obtained by automatic diagnosis are output from the ECU and used. These data are used by manufacturers for development and improvement, and are also used for fault diagnosis and adjustment of control information by connecting an inspection and maintenance device such as a dedicated tablet when a dealer or the like performs vehicle maintenance.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] When diagnosing vehicle malfunctions, diagnostic communication (UDS) is commonly used. Dealers connect a dedicated tablet-type vehicle service device to the vehicle during maintenance to perform diagnostic communication. Traditionally, for diagnostic functions requiring high security and confidentiality, security access has been used to enable these functions. The key information used for this security access is stored in the vehicle service device's diagnostic software, and when the device is connected to the vehicle, the key information allows it to retrieve diagnostic information from the vehicle's ECU. Such vehicle service devices and diagnostic software can be analyzed to obtain the key information, potentially leading to the creation of unauthorized tools. Therefore, strict control is necessary regarding the vehicle service device's access to the ECU.
[0005] To prevent the leakage of key information as described above, one possible method is to store and manage the key information on a management server rather than on the vehicle maintenance device. However, this method requires the vehicle to be connected to the network during fault diagnosis work, and is affected by the availability of the communication environment.
[0006] Alternatively, instead of using key information, a method could be considered where permissions are set for each worker and stored in the ECU, as described in Patent Document 1. However, this method requires storing the permission information of all potential workers in the vehicle's ECU. This results in a large amount of information being stored in the ECU. Furthermore, although this method is intended for use even when the vehicle is offline, new workers cannot use it unless the worker permissions stored in the ECU have been updated.
[0007] On the other hand, R2R (Right to Repair) laws are being enacted in various US states and in Europe. R2R laws require that vehicle diagnostic information necessary for fault diagnosis be made available to persons other than dealers, such as the vehicle owner. This has created a problem in that it is difficult to strictly control access to the ECU. [Means for solving the problem]
[0008] An ECU according to one embodiment of the present invention is one or more ECUs installed in a vehicle, which store a public key, receive a role list that permits specific work from a communication device, perform signature verification using the public key, set an effective list indicating the specific work using the role list that has passed the signature verification, and when it receives the specific work set in the effective list, it executes the processing of the specific work. [Effects of the Invention]
[0009] Since specific tasks such as sending diagnostic information are permitted using a role list that has passed signature verification via a public key, each worker can perform specific tasks within an appropriate scope. [Brief explanation of the drawing]
[0010] [Figure 1] Access management system of Example 1. [Figure 2] Flowchart of the valid list setting in Example 1. [Figure 3] Application information for use in Examples 1-3. [Figure 4] A diagram showing the connection to the management server of the vehicle maintenance device in Examples 1 to 3. [Figure 5] Role list for Examples 1-3. [Figure 6] Correspondence table between roll codes and specific tasks in Examples 1-3. [Figure 7] A flowchart illustrating the process of performing a specific task in Example 1. [Figure 8] A diagram showing the connection of the vehicle maintenance device to the ECU in Example 1. [Figure 9] A diagram showing the connection of the vehicle maintenance device to the ECU in Example 2. [Figure 10] Flowchart of the valid list setting in Example 2. [Figure 11] A flowchart illustrating the process of performing a specific task in Example 2. [Figure 12] A diagram showing the connection of the vehicle maintenance device to the ECU in Example 3. [Modes for carrying out the invention] [Examples]
[0011] In this embodiment, access management is performed on the ECU mounted in the vehicle to determine whether or not to allow the ECU to execute a specific task based on a request message. The request message is information that causes the ECU to execute a specific task. Figure 1 shows the access management system of Embodiment 1. The ECU 11 mounted in the vehicle 1 has a control unit 111 and a memory 112, and the memory 112 stores the public key PK. The ECU 11 may be formed from a single ECU or from multiple ECUs. The ECU 11 can be connected to an external device such as a vehicle maintenance device 2 via a connector 12. The vehicle maintenance device 2 is used in a vehicle maintenance factory. The vehicle maintenance device 2 is a communication device with communication functions, a fault diagnosis device, and an adjustment device, etc. When fault diagnosis is performed, the vehicle maintenance device 2 is used for off-board diagnosis and for outputting results for on-board diagnosis. The vehicle maintenance device 2 can be connected to the ECU 11 of the vehicle 1 via the connector 12, and can also be connected to the management server 3 via a connection device 41 and a network 4 (Internet). The management server 3 has a control unit 31 and a memory 32, and the memory 32 stores the secret key SK.
[0012] In Embodiment 1, the vehicle maintenance device 2 is implemented as a dedicated tablet terminal equipped with dedicated software, and includes a control unit 21, memory 22, and a display 23 with touch panel functionality. The display 23 serves as both a display device and an input device. Vehicle maintenance workers connect the vehicle maintenance device 2 to the ECU 11 to diagnose and adjust the vehicle 1. The vehicle maintenance device 2 is also used to download update data from the management server 3 and update the ECU 11 via the vehicle maintenance device 2.
[0013] Access management is performed by setting, in the ECU 11 by the access management system, a valid list of specific operations permitted. And the specific operations set in the valid list can be executed by the ECU 11. Examples of the specific operations include a process in which the ECU 11 transmits engine data such as the engine speed to the vehicle maintenance device 2.
[0014] Next, the operation when performing access management in a vehicle maintenance factory by the access management system of the first embodiment will be described with reference to the flowchart in FIG. 2 and the like. In the vehicle maintenance factory, first, the vehicle maintenance device 2, which is a tablet terminal, is operated from the display 23 of the touch panel to create use application information. At this time, the target vehicle number set in the ECU 11 of the vehicle to be inspected and maintained is input from the display 23. This input of the target vehicle number can also be performed by connecting the vehicle maintenance device 2 to the connector 12 of the target vehicle and acquiring the target vehicle number from the ECU 11 by operating the touch panel of the display 23.
[0015] When the target vehicle number, which is the target vehicle information, is input, the usage application information generation unit of the vehicle maintenance device 2 generates usage application information that associates user information such as the user name stored in the memory 22 and the connection device number, which is the unique number of the vehicle maintenance device 2, with the input target vehicle information. The usage application information generation unit is composed of a control unit 21, which is a computer configuration of the vehicle maintenance device 2, and a memory 22 that stores a program for generating usage application information. An example of the usage application information generated at the vehicle maintenance factory is shown in FIG. 3. The example of the usage application information in FIG. 3 is the same in the subsequent Examples 2 and 3. The usage application information includes the user name, the connection device number, and the target vehicle number. In FIG. 3, the user name, the connection device number, and the target vehicle number are described with the meanings indicated by the item numbers. As data of the usage application information, with item numbers 1 to 3 as the headers of each content, it is described as "Item number 1: ○○ Co., Ltd., ○○ Business Office, Item number 2: Xxxxxxxx,...". The user name in item number 1 is the name of the business office that manages the vehicle maintenance device 2, and is set in the memory 22 when the vehicle maintenance device 2 is introduced into the vehicle maintenance factory, etc. Also, the connection device number is set in the memory 22 during the manufacture of the vehicle maintenance device 2.
[0016] After inputting the target vehicle information and generating the usage application information by the usage application information generation unit, as shown in FIG. 4, the vehicle maintenance device 2 is connected to the connection device 41, and then connected to the management server 3 via the network 4 (step S1). This connection can be wired or wireless such as wifi. Also, the network 4 is the Internet, but other networks such as those using a dedicated line may also be used. Note that the input of the target vehicle information and the generation of the usage application information can also be performed while the vehicle maintenance device 2 is connected to the management server 3. Then, the vehicle maintenance device 2 transmits the usage application information to the management server 3 via the connection device 41 and the network 4 (step S2).
[0017] The management server 3 verifies the validity of the usage application information and stores the valid usage application information in memory 32. If invalid usage application information is received, the management server 3 does not store the usage application information and sends a message to the vehicle maintenance device 2 indicating that it has not been accepted. The validity of the usage application information is verified by management information stored in memory 32 regarding the vehicle maintenance device 2, such as the correspondence information between the username and connected equipment number sent as the usage application information, and the password sent by the vehicle maintenance device 2 when it connected. Then, the control unit 31 creates a role list based on the valid usage application information stored in memory 32 and signs it with the private key SK (step S3). The role list is a list that authorizes the ECU 11 to perform specific tasks. An example of a role list is shown in Figure 5. Similar to the usage application information, the role list also describes the meaning indicated by the item number, such as the username and role code. The data in the role list is written with the item number as the header for each item, in the format "Item number 1: XX Co., Ltd. XX Sales Office, Item number 2: Market, ...".
[0018] A "role code" is a code that defines the specific tasks that can be performed. When creating the role list in step S3, the "role code" is determined by matching the transmitted connected device number with the correspondence list stored in memory 32 of the management server 3. In Example 1, the connected device number of the vehicle maintenance device 2 that sent the usage application information is registered in the correspondence list stored in memory 32 of the management server 3 as corresponding to "market". Then, the management server 3 creates the role list shown in Figure 5, setting the "role code" for item number 2 to "market" based on the connected device number in the usage application information.
[0019] In the role list in Figure 5, item number 1 is set to "User Name" as "○○ Co., Ltd. ○○ Sales Office". Item number 2, "Role Code," is "Market." Item number 3, "Connected Equipment Number," and item number 4, "Target Vehicle Number," are set to the information received by the management server 3 as application information. Item number 5, "Expiration Date," is the expiration date of the role list; after the expiration date, the ECU 11 will no longer accept work corresponding to the role code in the role list. Item number 6, "Mileage Limit," item number 7, "Vehicle Startup Limit," and item number 8, "Work Instruction Limit," are set after the role list is received and configured, and if the limit is exceeded, the ECU 11 will no longer accept work.
[0020] In the role list in Figure 5, the role code for item number 2 is set to "Market," which enables specific maintenance tasks. The role code sets the specific tasks that the ECU11 can perform. The connected device number for item number 3 is the number of the device connected to vehicle 1 when setting the specific tasks permitted for the ECU11, and also the number of the device connected to vehicle 1 when instructing the ECU11 to perform the specific tasks. In the case of Example 1, this is the number of vehicle maintenance device 2. It is not possible to set permitted specific tasks with other vehicle maintenance devices, etc., that have different connected device numbers. Nor is it possible to instruct them to perform the set specific tasks. The target vehicle number for item number 4 is the number of vehicle 1 on which the ECU11 that will perform the specific tasks is installed. The target vehicle number is stored in the memory 112 of the ECU11. It is not possible to set specific tasks with an ECU that has a different target vehicle number.
[0021] Items 5-8 indicate limit values that show the validity period. The specific operation can be performed if all limit values are not exceeded, but if any limit value is exceeded, the specific operation cannot be performed. Item number 5, the expiration date, is the deadline by which the specific operation can be performed. After the expiration date, the specific operation cannot be performed. Item number 6, the mileage limit, means that if vehicle 1 travels the limited distance after the specific operation is set in ECU11, the specific operation cannot be performed. Item number 7, the vehicle start count limit, means that if vehicle 1 is started more times than the limit after the specific operation is set in ECU11, the specific operation cannot be performed. Item number 8, the work instruction count limit, means that if the specific operation is instructed to ECU11 more times than the predetermined number after the specific operation is set in ECU11, the specific operation cannot be performed.
[0022] In Figure 2, the role list signed with the secret key SK in step S3 is transmitted from the management server 3 via the network 4 to the vehicle maintenance device 2 connected to the connection device 41 (step S4). If the connection device number stored in the memory 22 matches item number 3, the vehicle maintenance device 2 stores the role list transmitted from the management server 3 in the memory 22 (step S5). If they do not match, it does not store the list and displays it as an inappropriate reception on the display 23, and terminates the process.
[0023] After the connected device number matches item number 3 and the roll list is stored, the vehicle maintenance device 2 disconnects from the management server 3 (step S6) and is disconnected from the connection device 41. Then, before the inspection and maintenance work, the vehicle maintenance device 2 is connected to the ECU 11 of the vehicle 1 via the connector 12 (step S7). Once connected, the vehicle maintenance device 2 transmits the roll list to the ECU 11 (step S8). The vehicle maintenance device 2 functions as a communication device that transmits the roll list received from the management server 3 to the ECU 11.
[0024] In ECU11, if the target vehicle number stored in memory 112 does not match the content of item number 4, it displays a message indicating an improper reception to the vehicle maintenance device 2 and terminates processing. If they match, ECU11 uses the public key PK stored in memory 112 to verify the signature of the role list. If the role list passes the signature verification, ECU11 sets an active list indicating the permitted specific tasks (step S9). If the role list fails the signature verification, it displays a message indicating an improper reception to the vehicle maintenance device 2 and terminates processing. Permitted specific tasks can be executed by accepting request messages. Request messages for unauthorized specific tasks are not accepted, and no processing is performed.
[0025] Figure 6 shows examples of specific tasks configured for each role code. DID reading and DTC reading read the contents of memory 112 using a pre-configured function address. DTC reading is the reading of the onboard diagnostic results. These readings are considered one of the specific tasks. In Figure 6, they are labeled "DID reading / DTC reading". "Memory-specified reading" reads the contents of memory 112 by specifying a physical address. "Memory-specified writing" writes to memory 112 by specifying a physical address. "Active testing" tests the vehicle 1's components, such as the engine, by actually driving them. "Total manufacturing testing" is a test performed before shipment during the manufacturing of vehicle 1. "Programming" is a specific task that rewrites the program stored in memory 112 of the ECU 11. Specific tasks other than those listed above are omitted from the description.
[0026] When the role code is "Market," "DID Read / DTC Read" and "Active Test" are set as specific operations in memory 112. This allows the vehicle maintenance device 2 to have the ECU 11 perform DID Read, DTC Read, and Active Test as specific operations. In Figure 6, DID Read and DTC Read are written as "DID Read / DTC Read." However, "Memory-Specified Read" and "Memory-Specified Write," which are performed by specifying a physical address, are not set as specific operations. If "Memory-Specified Read" is executed as a specific operation when the role code is "Market," there is a possibility that important information such as encryption keys, passwords, and personal information may be extracted. Also, if "Memory-Specified Write" is executed as a specific operation when the role code is "Market," there is a possibility that the memory contents may be manipulated, leading to unintended operation. These specific operations are not set when the role code is "Market." In addition, "Total Test at Manufacture" and "Programming" are not necessary during maintenance, so they are not set when the role code is "Market."
[0027] On the other hand, if the role code is "Development," used by the manufacturer during development, all specific tasks are possible. Also, if the role code is "Manufacturing," used by the manufacturer during production, in addition to "Market" specific tasks, "Total Manufacturing Test" can be performed. In the "Analysis" role code, used by the manufacturer when a problem occurs in vehicle 1 and they analyze it, in addition to "Market" specific tasks, "Memory-Specific Read" and "Memory-Specific Write" can be performed. Since the "Analysis" role code is only set for manufacturers, there is no risk of extracting important information through "Memory-Specific Read" or unintended operation through "Memory-Specific Write." "Total Manufacturing Test" and "Programming" are not necessary during analysis, so they are not set in the "Analysis" role code. If the role code is "Disposal" or no role code is specified, only DID read and DTC read are set.
[0028] In this embodiment 1, as shown in Figure 5, the "Role Code" in the role list is "Market," so "DID Read / DTC Read" and "Active Test" are set as valid specific tasks in the valid list. "DID Read / DTC Read" and "Active Test" are stored in the valid list as authorized specific tasks. In this way, the specific tasks that can be performed are determined by the role code, and the ECU11 sets the specific tasks corresponding to the received role code as valid tasks in the valid list.
[0029] Items numbered 5 and beyond in Figure 5 are also stored in memory 112. The "Expiration Date" for item number 5 is set to "2022 / 03 / 05 12:00". After this time, specific operations cannot be accepted. The "Distance Limit" for item number 5 is set to "None", meaning there is no limit on distance traveled. If it were set to "10km", then specific operations corresponding to the roll code would be permitted until vehicle 1 traveled 10km after ECU 11 received the roll list. The "Work Instruction Limit" is a limit on the number of work instructions. For example, if engine data transmission is instructed as a specific operation, it counts as one work instruction. Similarly, if another specific operation is instructed, it also counts as one work instruction. "Expiration Date", "Distance Limit", "Vehicle Start-up Limit", and "Work Instruction Limit" are limit values indicating the validity period.
[0030] Next, the process of instructing the ECU 11 to execute a specific task from the vehicle maintenance device 2 will be explained using the flowchart in Figure 7. Here, we will show an example of executing engine data transmission as a specific task. As shown in Figure 8, the worker performing vehicle maintenance connects the vehicle maintenance device 2 to the ECU 11 of vehicle 1. Then, by inputting "engine data transmission" to the vehicle maintenance device 2, the specific task of engine data transmission is set (step S11). "Engine data transmission" is a specific task that reads the DID regarding engine data. Therefore, it corresponds to the specific task of "DID reading / DTC reading" in Figure 6. After setting the specific task, the vehicle maintenance device 2 sends a request message to the ECU 11 to execute multiple engine data transmission processes (step S12).
[0031] ECU11 checks whether the specific operation "Send Engine Data" instructed in the received request message is on the valid list corresponding to the connected device number of the vehicle maintenance device 2 (step S13). "Send Engine Data" is stored in memory 112 as part of the valid list and corresponds to the permitted "Read DID / Read DTC". Therefore, the specific operation "Send Engine Data" is on the valid list and is valid. It also checks whether it is within the valid period (step S14). If the request message was received before the limit value of "2022 / 03 / 05 12:00" in item number 5 of Figure 5, it is valid. It also checks whether it is within the valid period before the limit values of item numbers 6 and 7. In Figure 5, item number 6 is "none", so there is no mileage limit. Regarding item number 7, if vehicle 1 is started more than 5 times after the specific operation is set in the valid list of ECU11, the specific operation cannot be performed. Regarding item number 8, if more than 10 instructions for specific tasks are given to ECU11 after a specific task has been set in the valid list of ECU11, the specific task cannot be performed.
[0032] Steps S13 and S14 may be performed in reverse order. The validity period in step S14 is defined by the roll list shown in Figure 5. Depending on the contents of the roll list, the validity period check can be limited to checking only the expiration date or only the number of vehicle starts, or it can be a check that uses multiple of these restrictions.
[0033] If the valid list contains an entry for accepting the request message "Send Engine Data" and all limit values are within their validity period, the ECU 11 performs the specific task by sending engine data to the vehicle maintenance device 2 (step S15). In this way, the ECU 11 performs the processing of the corresponding specific task when it receives a request message for a specific task permitted in the valid list within its validity period. On the other hand, it does not perform the specific task when it receives a request message for a specific task not permitted in the valid list, or when it is outside the validity period. For example, it does not perform the processing of the specific task when it receives a request message for a memory read with a specific address specified. If the processing of the specific task for which a request message was received is not performed, the ECU 11 sends a response message indicating that it was not performed.
[0034] The ECU11 in Example 1 may be composed of multiple ECUs, or it may be composed of an integrated ECU that combines some or all of the multiple ECUs. When composed of multiple ECUs, the valid list may be set for each ECU. [Examples]
[0035] Examples 2 and 3 show cases where the ECU 11 of Example 1 is configured with multiple ECUs. In Example 2, as shown in Figure 9, the vehicle 5 is equipped with an access management ECU 51 and multiple vehicle equipment ECUs 52. The access management ECU 51 is interposed between the connector 53 and the vehicle equipment ECUs 52. The access management ECU 51 has a control unit 511 and a memory 512 that stores the public key PK. The access management ECU 51 functions as a gateway that forwards an acceptable request message to the vehicle equipment ECUs 52 via the communication line 54 when it receives an acceptable request message via the connector 53. When it receives an unacceptable request message, it does not forward the request message to the vehicle equipment ECUs 52. The vehicle equipment ECUs 52 have a control unit 521 and a memory 522. The configuration of the vehicle maintenance device 2, which is a communication device, is the same as in Example 1. Also, the connection of the vehicle maintenance device 2 to the management server 3 is the same as in Example 1, as shown in Figure 4.
[0036] In Example 2, the flow diagram in Figure 10 shows the process of setting an effective list of acceptable request messages that can be processed by the access management system at the vehicle maintenance factory. In Example 2, the destination of the role list in step S8 is the access management ECU 51, and the signature verification of the role list and the setting of the effective list in step S9 are performed by the access management ECU 51. The rest of the flow is the same as in Figure 2 of Example 1. The application information for use is also the same as in Example 1, as shown in Figure 3, and the role list is also the same as in Example 1, as shown in Figure 5. Furthermore, the connection of the vehicle maintenance device 2 to the management server 3 is as shown in Figure 4 and is the same as in Example 1, and the correspondence between each role code and a specific task is as shown in Figure 6 and is the same as in Example 1. In Example 2, when the vehicle maintenance device 2 sends the role list to the access management ECU 51 in step S8, it does not use the communication line 54 that connects the ECUs.
[0037] In Example 2, the process of instructing the vehicle equipment ECU 52 to perform a specific task from the vehicle maintenance device 2 will be explained using the flowchart in Figure 11. As shown in Figure 9, the worker performing vehicle maintenance connects the vehicle maintenance device 2 to the connector 53 of the vehicle 5. This connects the vehicle maintenance device 2 to the access management ECU 51. This connection does not use the communication line 54. Then, the vehicle maintenance device 2 sets a specific task called "engine data transmission" by inputting, for example, "engine data transmission" (step S21). The vehicle maintenance device 2 then sends a request message to the access management ECU 51 instructing the vehicle equipment ECU 52 to transmit multiple engine data (step S22).
[0038] The access management ECU 51 checks whether the specific task corresponding to the received request message is in the valid list corresponding to the connected equipment number of the vehicle maintenance device 2 (step S23), and also checks whether it is within the valid period (step S24). If the request message is accepted in the valid list and within the valid period, the access management ECU 51 accepts the request message and forwards it to the vehicle equipment ECU 52 via the communication line 54 (step S25). When the access management ECU 51 receives an accepted request message in the valid list within the valid period, it executes the processing of the corresponding specific task. On the other hand, if it receives an unacceptable request message or if the valid period has expired, it does not send a task command to the vehicle equipment ECU 52. Upon receiving the request message, the vehicle equipment ECU 52 sends engine data to the vehicle maintenance device 2 via the access management ECU 51 and executes the specific task (step S26). Thus, in this embodiment 2, when the access management ECU 51 receives a request message for a specific task permitted in the valid list, it accepts the request message and sends the request message to the vehicle equipment ECU 52. The access management ECU 51 functions as a gateway. [Examples]
[0039] In Embodiment 3, as shown in Figure 12, a connector 63 is connected to the communication line 64 of the serial communication protocol. The role list is sent from the vehicle maintenance device 2 to the access management ECU 61 via the connector 63 and the communication line 64 in the vehicle 6. The access management ECU 61 has a control unit 611 and a memory 612. Using the public key PK stored in the memory 612, it verifies the signature of the role list and sends the role list that passes the signature verification to all relevant vehicle equipment ECUs 62. Then, in all vehicle equipment ECUs 62 related to access management of a specific operation, the control unit 621 stores a valid list indicating the specific operation in the memory 622.
[0040] When performing a specific task, the vehicle maintenance device 2 sends a request message to the communication line 64 via the connector 63. The relevant vehicle equipment ECU 62 receives the request message from the communication line 64. Upon receiving the request message, the vehicle equipment ECU 62 checks whether it is within the validity period. If it is, the control unit 621 and memory 622 execute the specific task and send a response message to the communication line 64. The response message is received by the vehicle maintenance device 2 via the connector 63.
[0041] The flow for setting the valid list in Example 3 is the same as in Example 2, shown in Figure 10, and is performed in the vehicle equipment ECU 62, which is involved in setting the valid list in step S9. The flow for executing a specific task is the same as in Example 2, shown in Figure 11, and the destination of the request message in step S22 is the vehicle equipment ECU 62. The check in step S23 to see if the specific task is on the valid list and the check in step S24 to see if it is within the valid period are performed in the vehicle equipment ECU 62. The request message is not forwarded in step S25 of Example 2. The specific task in step S26 is performed in the vehicle equipment ECU 62. The application information for use is shown in Figure 3 and is the same as in Examples 1 and 2, and the role list is also shown in Figure 5 and is the same as in Examples 1 and 2. In addition, the connection of the vehicle maintenance device 2 to the management server 3 is shown in Figure 4 and is the same as in Examples 1 and 2, and the correspondence between each role code and the specific task is shown in Figure 6 and is the same as in Examples 1 and 2.
[0042] In Example 3, the vehicle equipment ECU performing the specific task checks whether the task is on the valid list and whether it is within its validity period. However, the ECU that checks whether the specific task is on the valid list and the vehicle equipment ECU that performs the specific task may be separate. Also, in Examples 2 and 3, the public key, role list, etc., do not have to be stored in the ECU that uses them, but may be stored in another ECU or storage device.
[0043] In Examples 1-3, a vehicle maintenance device used for vehicle maintenance was used as the communication device, but when used by a manufacturer, a device suitable for manufacturer use should be used. As a device, for example, a laptop or desktop computer with manufacturer software installed may be used. The vehicle maintenance device functions as a communication device that transfers the role list from the management server to the ECU. The vehicle maintenance device may use information devices other than tablet terminals, such as a laptop or desktop computer. Also, in Examples 1-3, the creation and submission of the usage application, the transfer of the role list, the setting of specific tasks, and the transmission of request messages were performed by one vehicle maintenance device, but these may be performed by different devices. The transmission of the role list may be performed directly to the vehicle via the network from the vehicle maintenance device or management server using a wireless communication device installed in the vehicle. Alternatively, the management server 3 may create and send the role list without submitting a usage application.
[0044] In Examples 1-3, the management server 3 set the role code based on the connected device number. However, the vehicle maintenance device 2 may input the role and send it to the management server via the usage application information, and the management server may set the role code based on the role. Also, in Examples 1-3, one or more specific tasks are set in the valid list. However, a role code that groups one or more specific tasks together may be stored in the valid list, and when an instruction for a specific task is received via a request message, etc., the system may determine whether it is a specific task permitted by the role code stored in the valid list and execute the process. In this case as well, the specific tasks that can be executed are determined by the role code, and the ECU, access management ECU, and vehicle equipment ECU determine whether it is a specific task permitted by the stored role code and execute the process.
[0045] Furthermore, the specific configuration is not limited to the embodiments, and any design changes, etc., that do not depart from the spirit of the present invention are also included. In addition, the above-described embodiments can be combined by utilizing each other's technologies, as long as there are no particular contradictions or problems in their purpose and configuration. [Explanation of Symbols]
[0046] 1 vehicle 11 ECU 111 Control Unit 112 memory 12 connectors 2. Vehicle maintenance equipment 21 Control Unit 22 memory 23 displays 3. Management Server 31 Control Unit 32 memory 4 Network 41 Connection device 5 vehicles 51 Access Management ECU 511 Control Unit 512 memory 52 Vehicle Equipment ECU 521 Control Unit 522 memory 53 Connectors 54 Communication lines 6 vehicles 61 Access Management ECU 611 Control Unit 612 memory 62 Vehicle Equipment ECU 621 Control Unit 622 memory 63 Connectors 64 communication lines PK public key SK private key
Claims
1. One or more ECUs installed in a vehicle, The system stores a public key, receives a role list authorized for specific tasks from a communication device, performs signature verification using the public key, and uses the role list that has passed the signature verification to set up an active list indicating the authorized specific tasks. The aforementioned role list includes a role code that groups together multiple of the aforementioned specific tasks. The valid list has multiple specific tasks set for the role code, An ECU characterized by executing the processing of a specific task when it receives any of the multiple specific tasks set in the valid list.
2. The ECU according to claim 1, characterized in that the role list includes a limit value indicating the validity period of the valid list.
3. Including the access management ECU and the vehicle equipment ECU, The aforementioned access management ECU is The public key is stored, the role list is received from the communication device, the signature verification is performed using the public key, and the valid list is set using the role list that has passed the signature verification. When the specified task set in the valid list is received, the specified task is transmitted to the vehicle equipment ECU. The vehicle equipment ECU is characterized in that it performs the processing of the specific task when it receives the specific task from the access management ECU, as described in claim 1 or 2.
4. Including the access management ECU and the vehicle equipment ECU, The aforementioned access management ECU is The public key is stored, the role list is received from the communication device, the signature verification is performed using the public key, and the valid list is set using the role list that has passed the signature verification. When the specified task set in the valid list is received, the specified task is transmitted to the vehicle equipment ECU. The vehicle equipment ECU is characterized in that it performs the processing of the specific task when it receives the specific task.
5. An access management system that manages access to an ECU installed in a vehicle, A management server that stores the private key, The ECU, which is installed in the vehicle and stores the public key, It includes the aforementioned management server and a communication device that can connect to the aforementioned ECU, The management server creates a role list that permits specific tasks and signs the role list with the private key. The communication device transmits the role list received from the management server to the ECU. The aforementioned ECU is The system receives the signed role list from the communication device, verifies the signature of the role list using the public key, and uses the role list that has passed the signature verification to set up an active list indicating the permitted specific tasks. The aforementioned role list includes a role code that groups together multiple of the aforementioned specific tasks. The valid list has multiple specific tasks set for the role code, An access management system characterized by executing the processing of a specific task when it receives any of the multiple specific tasks set in the valid list.
6. The aforementioned ECU consists of an access management ECU and a vehicle equipment ECU. When the access management ECU receives the specified task set in the valid list, it transmits the specified task to the vehicle equipment ECU. The access management system according to claim 5, characterized in that the vehicle equipment ECU executes a process corresponding to the specific task when it receives the specific task.