Function management system and function management method

Abstract

Provided are a function management system and a function management method which facilitate convenience to users while realizing authentication with high security. A function management system (1) according to the present invention comprises: a management unit (60) that generates, in response to a user input, a message for revising software installed on an electronic control device (40) constituting a network mounted on a vehicle; a processing unit (70) that identifies the address for the message by using metadata included in the message; and an execution unit (80) that receives the message and executes revision of the software on the basis of core data included in the message. The management unit (60) generates the message after unencrypting the metadata and encrypting the core data, and the processing unit (70) transmits the core data to the execution unit (80) of the electronic control device (40) with the identified address.

Description

[0001] [Document name] Statement

[0002] [Title of invention] Function management system and function management method

[0003] [Technical Field]

[0004]

[001] The present invention relates to a vehicle function management system and a function management method.

[0005] [Background technology]

[0006]

[002] Conventionally, there has been known a device in which a server device verifies the legitimacy of multiple electronic control devices mounted on a vehicle using a common key shared by each electronic control device (see Patent Document 1). The device described in Patent Document 1 is configured to allow electronic control devices authenticated by the server device to perform tasks such as updating firmware.

[0007] [Prior art documents]

[0008] [Patent documents]

[0009]

〇 0 0 3

[0010] [Patent Document 1] Japanese Patent Application Laid-Open No. 2017-017616

[0011] Summary of the Invention

[0012] [Problem to be solved by the invention]

[0013]

[0004] However, in the device described in Patent Document 1, after verifying the signature in the key management device, the re-signed updated firmware is re-signed with the common key of the ECU (Electronic Control Unit), and then returned to the gateway ECU, from which it is sent to the ECU. However, since multiple authentication procedures are required before the updated firmware is sent to the ECU, the processing load on the device increases. In addition, since data copies must be made at different nodes, synchronization must be performed frequently, which may result in data inconsistencies during the authentication procedure.

[0014]

[0005] Therefore, the present invention aims to provide a function management system and a function management method that realize highly secure authentication while being highly convenient for users.

[0015] [Means for solving the problem]

[0016]

[0006] In order to achieve the above object, according to one aspect of the present invention, there is provided a function management system comprising: a management unit that generates a message for revising software implemented in an electronic control unit that constitutes an in-vehicle network installed in a vehicle in accordance with user input; a processing unit that identifies the destination of the message using metadata included in the message; and an execution unit that receives the message and executes the revision of the software based on core data included in the message, wherein the management unit decrypts the metadata, encrypts the core data, and then generates the message, and the processing unit transmits the core data to the execution unit of the electronic control unit whose destination has been identified.

[0017] [Effects of the Invention]

[0018]

[0007] According to the present invention, it is possible to provide a function management system and method that can quickly update functions while achieving highly secure authentication.

[0019] [Brief explanation of the drawings]

[0020]

〇 0 0 8

[0021] [Figure 1] A diagram showing an example of the configuration of a function management system according to an embodiment of the present invention.

[0022] [Figure 2] A block diagram showing the main components of the management unit, processing unit, and execution unit of Figure 1.

[0023] [Figure 3] A sequence diagram showing a first embodiment of authentication processing in a server device, gateway, and electronic control device executed by the function management system of Figure 1.

[0024] [Figure 4] A sequence diagram showing a second embodiment of authentication processing in a server device, gateway, and electronic control device executed by the function management system of Figure 1.

[0025] [Figure 5] A sequence diagram showing a third embodiment of authentication processing in a server device, gateway, and electronic control device executed by the function management system of Figure 1.

[0026] DETAILED DESCRIPTION OF THE INVENTION

[0027]

[0009] Fig. 1 is a diagram showing a vehicle 10 and a function management system 1 according to one embodiment. In Fig. 1, a straddle-type vehicle (such as a motorcycle) is shown as an example of the vehicle 10. The present invention is suitable for use in motorcycles and the like where space for installing a high-performance ECU is limited. The vehicle 10 includes a gateway 20, a user interface 30, a drive control ECU_A (40a), a brake control ECU_B (40b), a steering control ECU_C (40c), and an in-vehicle network 50. In the following description, the drive control ECU_A (40a), the brake control ECU_B (40), and the steering control ECU_C (40c) may be collectively referred to as the electronic control unit 40. The gateway 20, the user interface 30, and the multiple electronic control units 40 are connected to an in-vehicle network 50. For example, a CAN is used as the in-vehicle network 50. CAN is known as a standard for communication networks installed in vehicles. The gateway 20, the user interface 30, and each electronic control unit 40 can exchange data via the in-vehicle network 50. The electronic control unit 40 exchanges data with other electronic control units 40 via the in-vehicle network 50.

[0028]

[0010] The electronic control unit 40 is an on-board computer provided in the vehicle 10. The electronic control unit 40 is composed of multiple ECUs with different functions, such as an ECU_A (40a) for drive control, an ECU_B (40b) for brake control, and an ECU_C (40c) for steering control. Depending on the type of vehicle control function to be executed, a single function may be realized by simultaneously controlling multiple electronic control units 40. For example, to realize an emergency vehicle stopping function that brings the vehicle to an emergency stop on the shoulder of the road, it is necessary to simultaneously control the ECU_B (40b) for brake control and the ECU_C (40c) for steering control. Furthermore, when performing traction control of a vehicle, the drive control ECU_A (40a) and the brake control ECU_B (40b) may be controlled simultaneously.

[0029]

[0011] The electronic control device 40 includes an execution unit 80, a CPU (Central Processing Unit) 41, and a non-volatile memory 42. In the following description, the individual execution units, CPUs, and non-volatile memories of the drive control ECU_A (40a), brake control ECU_B (40b), and steering control ECU_C (40c) will be referred to using the symbols a to c in Figure 1. The CPU 41 executes software installed in the electronic control device 40. The software is a computer program. The non-volatile memory 42 stores the software and data executed by the electronic control device 40. The nonvolatile memory 42 stores functional status information that enables or disables the execution of each piece of software by the CPU. The nonvolatile memory 42 is composed of ROM (read-only memory), RAM (random access memory), flash memory, etc.

[0030]

[0012] The gateway 20 communicates with the server device 1000 via a wireless communication network 2000, which includes public wireless communication networks such as the Internet and mobile phone networks. The gateway 200 can also exchange data with the diagnostic tester 300 via the diagnostic connector 310.

[0031]

[0013] The gateway 20 has a processing unit 70 as a functional configuration. The processing unit 70 identifies the electronic control device 40 that is the destination of the message from the metadata included in the message sent from the server device 100.

[0032]

[0014] The server device 100 has a functional configuration in which a management unit 60 is stored, which generates a message for updating the software of the electronic control device 40 in response to input from a user's mobile terminal (not shown) or the like. Note that updating software is a concept that includes updating, adding, deleting, and resetting parameters of the software.

[0033]

[0015] Note that user input can also be made through a user interface 30 or diagnostic tester 300 installed in the vehicle 10. In this case, it is desirable that the management unit 60 be stored in the user interface 30 or diagnostic tester 300.

[0034]

[0016] Server device 100 manages updated software and has the function of distributing updated software in response to user requests input from the mobile terminal. The updated software is installed from server device 100 to electronic control device 40 in response to a command from the mobile terminal.

[0035]

[0017] The diagnostic tester 300 is a diagnostic device that can read out software defects in the electronic control device 40, revise the software in non-volatile memory, and perform simulation tests, etc.

[0036]

[0018] Figure 2 is a block diagram showing the main components of the management unit 60, processing unit 70, and execution unit 80.

[0037]

[0019] The management unit 60 has, as its functional configuration, an interface 61, a message generation unit 62, an encryption unit 63, an acquisition unit 64, a determination unit 65, and a storage unit 66. The message generation unit 62 constitutes a data generation unit, and the encryption unit 63 constitutes a code generation unit.

[0038]

[0020] The message generation unit 62 generates a message that reflects a user request recognized by the interface 61. Specifically, it generates a message for revising part or all of the software of the electronic control device 40. The message includes metadata that identifies the electronic control device 40, which is the destination of the message, and core data for revising part or all of the software of the electronic control device 40. The message generated by the message generation unit 62 is stored in the storage unit 66 together with a preset validity period (for example, 10 minutes).

[0039]

[0021] Message generation may use standard diagnostic message specifications such as KWP (Keyword Protocol), UDS (Unified Diagnostic Protocol), BD2 (On-Board Diagnostics), WWH-OBD (Wide Integrated Wideband OBD), and J1939. This allows commands such as those for reading data, updating data, and rewriting function status to be generated according to the standard specifications.

[0040]

[0022] When a vehicle function is realized by software implemented in two or more different electronic control devices, the message generation unit may generate a message that can be executed by the execution unit 80 in one selected electronic control device 40 and send the message to the selected execution unit 80. For example, when revising software for realizing an emergency vehicle stopping function, the message generation unit 62 may send a message to the execution unit 80b of one selected brake control ECU_B (40b), and the execution unit 80b may revise the software in the nonvolatile memory 42b of the brake control ECU_B (40b) and the software in the nonvolatile memory 42c of the steering control ECU_C (40c).

[0041] [ 0 0 2 3 ] Unit 64 obtains information such as the current software version information and the lock / unlock status information of the target function.

[0042]

[0029] The determination unit 65 compares the user request recognized by the interface 61 with the functional status information acquired by the acquisition unit 64, and determines whether a message should be created in accordance with the user request.

[0043]

[0030] The processing unit 70 has the following functional configuration: an ECU information management unit 71, a destination management unit 72, and a transmission unit

[0044] 73 and memory unit 74.

[0045] [ 0 0 3 1 ]

[0046] The ECU information management unit 71 acquires the software version information of the corresponding electronic control unit 40 and the status of the function realized by the software from the memory unit 74 in response to a request from the acquisition unit 64 or at predetermined intervals. Since the processing unit 70 and the execution unit 80 are connected via an in-vehicle network, the updated software version information of the electronic control unit 40 stored in the memory unit 84 of the execution unit 80 and the status of the corresponding function are available in the memory unit 74. The status of the function refers to the status of the function, such as whether the software that realizes the function is functioning, whether the function is restricted, or whether software revision is prohibited.

[0047]

[0032] The destination management unit 72 identifies the destination of the electronic control device 40 from the metadata included in the message sent from the management unit 60. The metadata specifically includes an ID unique to the electronic control device 40 in which the execution unit 80 is stored, such as a CAN-ID or ECU-ID. The destination management unit 72 identifies the destination of the electronic control device 40 by reading unencrypted metadata, so there is no need for the processing unit 70 to decrypt the encrypted core data. The core data is decrypted by the execution unit 80, as described below. This makes it possible to quickly identify the destination and send the data to the destination.

[0048]

[0033] The sending unit 73 sends a message to the electronic control device 40 identified by the destination management unit 72. At this time, the sending unit 73 may send only the encrypted core data of the metadata and core data included in the message. In this way, the processing load on the execution unit can be reduced.

[0049]

[0034] Next, the execution unit 80 will be described. The execution unit 80 has the following functional configuration: a decryption unit 81, an authentication unit 82, an output unit 83, and a storage unit

[0050] 8 4 and has.

[0051]

[0035] The decryption unit 81 decrypts the encrypted message sent from the processing unit 70 using the private key stored in the memory unit 84. The decryption unit 81 decrypts the message using the private key stored in the memory unit 84, which corresponds to the public key used in the encryption unit 63 of the management unit 60.

[0052]

[0036] Alternatively, the decryption unit 81 may use the MAC key stored in the memory unit 84 to decrypt the message sent from the processing unit 70 and restore the MAC to the original data before encryption. That is, the decryption unit 81 decrypts the MAC and restores it to the original data message. The decryption unit 81 decrypts the MAC using the same MAC algorithm encryption method as the management unit 60. Therefore, the management unit 60 and the execution unit 80 have the same MAC algorithm method used for encryption and decryption set in advance. By decrypting the MAC, authentication can be performed in the authentication unit 82.

[0053]

[0037] If the authentication unit 82 determines that the transmitted message and the decrypted message match, it authenticates that the source of the message is legitimate. The processing unit 70 then sends a completion notification to the processing unit 70. Upon receiving the update completion notification from the execution unit 80, the processing unit 70 sends a completion notification of the update of the functional status of the electronic control device 40 to the management unit 60. This allows the user to confirm that the update of the functional status has been completed.

[0054]

[0053] The update completion notification in step S13 may or may not be executed. The update completion notification may also be sent from the processing unit 70 to the user interface 30.

[0055]

[0054] According to the first embodiment described above, the electronic control device to which the message should be sent is identified from the unencrypted metadata contained in the message, and the execution unit that receives the message decrypts and authenticates the message.

[0056]

[0055] This allows the frequency of decryption and authentication at each node on the vehicle to be significantly reduced, speeding up the process. In addition, the use of public keys for encryption of core data improves security.

[0057]

[0056] Next, the operation of a second embodiment in which a function is executed using at least two electronic control units will be described with reference to Fig. 4. Fig. 4 is a sequence chart of a function management method according to the second embodiment.

[0058] [ 0 0 5 7 ]

[0059] (Step S1) The user operates an input unit (not shown) of the mobile terminal, the user interface 30, or the diagnostic tester 300 to request a revision of the software implemented in the electronic control device 40 for realizing the vehicle's functions. As an example, in this case, the user requests a software update for the drive control ECU_A (40a) and the brake control ECU_B (40b) to update the traction control function.

[0060] [ 0 0 5 8 ]

[0061] (Step S2) The acquisition unit 64 acquires ECU status information stored in the memory unit 74 of the processing unit 70. Specifically, the acquisition unit 64 acquires software version information related to the traction control functions of the drive control ECU_A (40a) and the brake control ECU_B (40), as well as lock / unlock status information of the functions realized by the software.

[0062] [ 0 0 5 9 ]

[0063] (Step S3) The determination unit 65 compares the user request acquired in step S1 with the ECU status information acquired from the electronic control unit 40 in step S2, and determines whether a message should be created in accordance with the user request. When making this determination, at least the following points are taken into consideration:

[0064] • Is the software version required for the update the same as the software version currently running on the electronic control unit 4?

[0065] • If it is determined that the function being requested to be updated is not a function that is prohibited from being rewritten, and that the function status should not be changed according to the message (no), a message stating "Updated" or "Changes prohibited" is sent to the user's mobile device, etc., and the process is terminated.

[0066] [ 0 0 6 0 ]

[0067] (Step S4) In step S3, when the judgment unit judges that a message should be created in accordance with the user's request, the message generation unit 62 generates a message for revising the software based on the user's input in step S1. In the second embodiment, since the target function is realized by software implemented in two electronic control units, the message generation unit separately generates message A to be sent to the execution unit 80a of ECU_A (40a) and message B to be sent to the execution unit 80b of ECU_B (40b). The identification information establishes a correspondence between the ECU used for each function ID and the function in the ECU, so the message generation unit 62 can generate an individual message for each electronic control unit by referring to the identification information. Messages generated by the message generation unit 62 are temporarily stored in the memory unit 66 of the management unit 60 along with a preset validity period (for example, 10 minutes).

[0068] [ 0 0 6 1 ]

[0069] (Step S5) The encryption unit 63 encrypts the core data portions of the messages A and B generated by the message generation unit 62 using the MAC® (encryption key) stored in the storage unit 66, and generates a message authentication code whose original data is the core data included in the message. Note that the metadata included in the message is not encrypted here. However, since the metadata of message B contains the CAN-ID and ECU-ID for ECU_B (40b), it is possible to identify the electronic control unit 40 whose software needs to be revised.

[0070] [ 0 0 6 4 ]

[0071] (Step S8) In step S7, the transmitting unit 73 transmits messages to the electronic control devices 40 identified by the destination management unit 72. Message A is transmitted to the execution unit 80a of ECU_A (40a), and message B is transmitted to the execution unit 80b of ECU_B (40). Of the metadata and core data contained in the messages, the transmitting unit 73 transmits only the encrypted core data.

[0072] [ 0 0 6 5 ]

[0073] (Steps S9, S9') The decryption units of the execution unit 80a and execution unit 80b decrypt the MAC of the message received from the management unit 60 using the MAC key stored in the memory unit of each execution unit 80a, 80b. If the MAC cannot be decrypted using the specified algorithm (n 0), an error message is sent to the management unit 60 and the process ends.

[0074] [ 0 0 6 6 ]

[0075] (Steps S10, S10') If the authentication units of the execution units 80a and 80b determine that the sent message and the decrypted message match, they authenticate that the source of the message is legitimate. On the other hand, if the authentication units determine that the sent message and the decrypted message do not match, the authentication units do not authenticate the authenticity of the source and cut off the connection with the processing unit 70.

[0076] [ 0 0 6 7 ]

[0077] (Steps S11, S11') Once the message has been authenticated by the authentication unit in steps S10 and S10', the decrypted message is temporarily stored in the memory unit of each execution unit before the software of ECU_A (40a) and ECU_B (40b) is updated.

[0078] [ 0 0 6 8 ]

[0079] (Steps S12, S12') The execution units 80a and 80b revise the relevant software stored in the non-volatile memories 42a and 42b of the ECU_A (40a) and ECU_B (40b) based on the message stored in the storage unit at the next power cycle of the vehicle 10 (i.e., turning the vehicle power on or off, or turning the ignition on or off). When making the revision, the update may be performed only when the vehicle is stopped or parked. The stopped or parked state of the vehicle can be determined, for example, by evaluating a signal from a vehicle speed sensor, or, if the vehicle is a saddle-type vehicle, by evaluating a signal from a sensor that detects the state of the stand used to park the saddle-type vehicle.

[0080] [ 0 0 6 9 ]

[0081] (Step S13) When the execution of the revision process is completed, each execution unit 80a, 80b sends a revision completion notification to the processing unit 70. When the processing unit 70 receives the update completion notification from the execution unit 80, it sends a notification of completion of updating the functional status of the electronic control device 40 to the management unit 60. This allows the user to confirm that the update of the functional status has been completed. Note that the update completion notification in step S13 may or may not be executed. In addition, the update completion notification may be sent from the processing unit 70 to the user interface 30.

[0082]

[0070] According to the second embodiment described above, the command generation unit generates individual commands for each electronic control device.

[0083]

[0071] This allows command execution to be completed within each electronic control device when a function is performed by multiple electronic control devices, further improving security. If it is determined that the function status should not be changed (no) according to the message, the "Updated"

Claims

[Document name] Scope of claims

1. A function management system comprising: a management unit (60) that generates a message for revising software implemented in an electronic control device (4 ○) constituting an in-vehicle network mounted on a vehicle in response to a user input; a processing unit (70) that identifies a destination of the message by using metadata included in the message; and an execution unit (80) that receives the message and executes the revision of the software based on core data included in the message, wherein the management unit (60) decrypts the metadata, encrypts the core data, and generates the message, and the processing unit (70) transmits the core data to the execution unit (80) of the electronic control device (40) whose destination has been identified.

2. The function management system (1) according to claim 1, wherein the management unit has an encryption unit (63) that encrypts the core data using a public key.

3. The function management system (1) according to claim 1, wherein the management unit (60) has an acquisition unit (64) that acquires software version information of the electronic control device identified by the metadata before transmitting the message.

4. The function management system (1) according to claim 1, wherein the management unit (60) has an acquisition unit (64) that acquires a functional status of a function of the vehicle implemented by the software before transmitting the message.

5. The function management system (1) according to claim 1, wherein the execution unit (80) executes the software revision in a next output cycle of the vehicle after receiving the message.

6. The function management system (1) according to claim 1, wherein the execution unit (80) executes the revision of the software after detecting that the vehicle is stopped or parked. [Claim ?] The function management system (1) according to claim 1, wherein the core data includes a vehicle identification number that identifies the vehicle.

8. The function management system (1) according to claim 1, wherein the core data includes a serial number of the message.

9. The function management system (1) according to claim 1, wherein the software revision includes setting parameters according to the environment. [Claim 1 X] The function management system (1) according to claim 1, wherein when a function of the vehicle is realized by a plurality of pieces of the software implemented in two or more different electronic control devices, the management unit individually generates the message for revising the software executed in the execution unit of each of the electronic control devices.

11. The function management system (1) according to claim 1, wherein, when the function of the vehicle is realized by a plurality of pieces of the software implemented in two or more different electronic control devices, an execution unit of the electronic control device whose destination is specified by the processing unit executes the revision of the software. [Claim 1 2] The function management system (1) according to claim 1, wherein the vehicle is a saddle-type vehicle (10).

13. A function management method comprising: a message generating step of generating a message for revising software implemented in an electronic control device constituting an in-vehicle network mounted on a vehicle in response to a user's input; a destination specifying step of specifying a destination of the message using metadata included in the message; a transmission step of transmitting the message to the destination specified in the destination specifying step; and an execution step of executing the revision of the software in response to core data included in the message, wherein in the message generating step, the metadata specifying the destination of the message is decrypted and the core data is encrypted before the message is generated, and in the transmission step, the core data is transmitted to an execution unit of the electronic control device for which the destination is specified.

Images