Vehicle verification system

Abstract

The purpose of the present invention is to provide a vehicle verification system capable of constructing a virtual model of a vehicle while reducing any risk that configuration information pertaining to the entire vehicle will be read by a security attack. For this purpose, a vehicle verification system 1 for evaluating the performance of a vehicle 2 comprises: a back-end server 3 disposed outside the vehicle 2; a plurality of first electronic control devices 4 mounted on the vehicle 2, the plurality of first electronic control devices 4 distributedly storing configuration information of the vehicle 2; and a second electronic control device 5 disposed in the vehicle 2, the second electronic control device 5 receiving partial configuration information, which is a portion of the configuration information pertaining to the vehicle 2, from the plurality of first electronic control devices 4 and transmitting the partial configuration information to the back-end server 3. The back-end server 3, stores the configuration information pertaining to the vehicle 2, updates the stored configuration information pertaining to the vehicle 2 by using the partial configuration information received from the second electronic control device 5, constructs a virtual model of the vehicle 2 using the updated configuration information pertaining to the vehicle 2, and evaluates the performance of the vehicle 2 by using the virtual model.

Description

Vehicle Verification System

[0001] The present invention relates to data retention for an electronic control unit mounted on a vehicle, a system comprising an electronic control unit, and a system located inside or outside the vehicle that simulates and verifies the vehicle.

[0002] For example, Patent Document 1 is a prior art document that discloses a technique for efficiently and accurately verifying the effects of changing or adding parts to a vehicle or updating software.

[0003] JP 2023-13183 A

[0004] Patent Literature 1 discloses a technology for acquiring data related to the state of a vehicle, constructing a virtual model using the data, and performing a virtual simulation using the virtual model to accurately verify the effects of adding or changing parts. However, the data related to the state of the vehicle used to construct the virtual model is collected in one location (a central ECU or a gateway ECU) and transmitted to an analysis server, and if the information transmitted to the analysis server for constructing the virtual model or the information stored in the central ECU or the gateway ECU is read by some kind of security attack, there is a risk that the entire state of the vehicle will be read.

[0005] The present invention has been made in consideration of the above-mentioned problems, and its purpose is to provide a vehicle verification system that can construct a virtual model of a vehicle while reducing the risk that the configuration information of the entire vehicle will be read by a security attack.

[0006] In order to achieve the above-mentioned object, the present invention provides a vehicle verification system for evaluating the performance of a vehicle, comprising: a back-end server located outside the vehicle; a plurality of first electronic control units mounted on the vehicle and storing configuration information of the vehicle in a distributed manner; and a second electronic control unit mounted on the vehicle and receiving partial configuration information that is part of the configuration information of the vehicle from the plurality of first electronic control units and transmitting the partial configuration information to the back-end server, wherein the back-end server stores the configuration information of the vehicle, updates the stored configuration information of the vehicle using the partial configuration information received from the second electronic control unit, constructs a virtual model of the vehicle using the updated configuration information of the vehicle, and evaluates the performance of the vehicle using the virtual model.

[0007] According to the present invention, it is possible to build a virtual model of a vehicle while reducing the risk that the configuration information of the entire vehicle will be read by a security attack. Problems, configurations, and effects other than those described above will become clear from the description of the following embodiments.

[0008] FIG. 1 is a diagram showing a vehicle verification system according to a first embodiment of the present invention. FIG. 2 is a diagram showing an example of configuration information of each component of a vehicle in the first embodiment of the present invention. FIG. 3 is a flowchart showing processing of the vehicle verification system according to the first embodiment of the present invention. FIG. 4 is a flowchart showing a first modified example of the processing of the vehicle verification system according to the first embodiment of the present invention. FIG. 5 is a flowchart showing a second modified example of the processing of the vehicle verification system according to the first embodiment of the present invention. FIG. 6 is a diagram showing a vehicle verification system according to a second embodiment of the present invention. FIG. 7 is a diagram showing an example of history and performance information of each component of a vehicle in the second embodiment of the present invention. FIG. 8 is a flowchart showing processing of the vehicle verification system according to the second embodiment of the present invention. FIG. 9 is a diagram showing a vehicle verification system according to a third embodiment of the present invention. FIG. 10 is a flowchart showing processing of the vehicle verification system according to the third embodiment of the present invention.

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In each drawing, the same reference numerals are used to designate the same components, and redundant description will be omitted.

[0010] 1 is a diagram showing a vehicle verification system according to a first embodiment of the present invention. In FIG. 1, the vehicle verification system 1 includes a vehicle 2 and a back-end server 3 (e.g., an analysis server, a verification server, a cloud, etc.).

[0011] The vehicle 2 is equipped with a plurality of electronic control units 4 (e.g., domain ECUs or zone ECUs, hereinafter referred to as local ECUs) distributed, for example, by zone (physical location) or domain (function), and an electronic control unit 5 (e.g., a central gateway, communication control unit, etc., hereinafter referred to as central ECU) that communicates between the local ECUs 4 and the outside of the vehicle.

[0012] The local ECU 4 includes a terminal change extraction unit 4a, a configuration information storage unit 4b, and a configuration information transmission unit 4c. When a component connected to the local ECU 4 (such as another electronic control unit, actuator, or sensor, hereinafter referred to as a connected component) is changed, the terminal change extraction unit 4a extracts the change information. The configuration information storage unit 4b stores the configuration information of the local ECU 4 and updates the stored configuration information of the local ECU 4 using the change information extracted by the terminal change extraction unit 4a. The configuration information transmission unit 4c transmits the updated configuration information of the local ECU 4 to the backend server 3 via the central ECU 5.

[0013] The central ECU 5 has a configuration information receiving unit 5a and an external configuration information transmitting unit 5b. The configuration information receiving unit 5a receives the configuration information of the local ECU 4 from the configuration information transmitting unit 4c of the local ECU 4. The external configuration information transmitting unit 5b transmits the configuration information of the local ECU 4 received by the configuration information receiving unit 5a to the backend server 3. However, the central ECU 5 does not aggregate, record, or combine the configuration information of the local ECU 4. This makes it possible to prevent the configuration information of the entire vehicle from being stored in a specific ECU.

[0014] The backend server 3 has a configuration information receiving unit 3a, a configuration information storage unit 3b, a virtual model building unit 3c, and an impact verification unit 3d. The configuration information receiving unit 3a receives configuration information of the local ECU 4 from the configuration information exterior transmission unit 5b. The configuration information storage unit 3b stores configuration information of the vehicle 2 and updates the stored configuration information of the vehicle 2 using the configuration information of the local ECU 4 received by the configuration information receiving unit 3a. The virtual model building unit 3c builds a virtual model (digital twin) of the vehicle 2 using the configuration information of the vehicle 2 stored in the configuration information storage unit 3b. The impact verification unit 3d verifies the impact of changes to the configuration information of the vehicle 2 by evaluating the performance of the vehicle 2 using the virtual model.

[0015] FIG. 2 is a diagram showing an example of configuration information for each component of a vehicle 2. The vehicle body configuration information includes an ID. The ECU configuration information includes an ID, design (SoC, storage, communication line type, etc.), SW (App, BSW / MW, OS), and connection relationships (connected component ID, communication line ID). The communication line configuration information includes an ID, type (Ethernet, CAN, etc.), bandwidth, and connection relationships (connected component ID). The sensor configuration information includes an ID, sensor type, control period, output data volume, and connection relationships (connected component ID). The actuator configuration information includes an ID, actuator type, control period, input data volume, and connection relationships (connected component ID). The application software (App) configuration information includes an ID, implementation type, required processing performance, control period, ASIL, security level, and version information. The basic software (BSW) / middleware (MW) configuration information includes an ID, required processing performance, and version information. The OS configuration information includes an ID, required processing performance, and version information.

[0016] 3 is a flowchart showing the processing of the vehicle verification system 1 according to this embodiment. In this flow, if the change of the connected components is not valid, the user is suggested to return the connected components to the state before the change.

[0017] First, in the vehicle 2, the connection components of the local ECU 4 are changed (step S100).

[0018] Following step S100, the terminal change extraction unit 4a of the local ECU 4 extracts change information of the connected component (step S101).

[0019] Following step S101, the configuration information storage unit 4b of the local ECU 4 updates the stored configuration information of the local ECU 4 using the change information of the connected component (step S102).

[0020] Following step S102, the configuration information transmitter 4c of the local ECU 4 transmits the updated configuration information of the local ECU 4 to the central ECU 5 (step S103).

[0021] Following step S103, the external configuration information transmitter 5b of the central ECU 5 transmits the updated configuration information of the local ECU 4 to the back-end server 3 (step S104).

[0022] Following step S104, the configuration information storage unit 4b of the backend server 3 updates the stored configuration information of the vehicle 2 using the updated configuration information of the local ECU 4 (step S105).

[0023] Following step S105, the virtual model construction unit 3c of the back-end server 3 constructs a virtual model using the updated configuration information of the vehicle 2 (step S106).

[0024] Following step S106, the effect verification unit 3d of the backend server 3 uses the virtual model to verify the effect of the change in the connected component (step S107).

[0025] Following step S107, the effect verification unit 3d of the backend server 3 determines whether the change in the connected components is effective based on the result of the verification in step S107 (step S108). The effective change in the connected components here means, for example, that the change in the connected components does not impair the performance of the vehicle 2.

[0026] If the determination result in step S108 is No, the system proposes to the user to return the connected components changed in step S100 to the state before the change (step S109), and the system returns to step S100.

[0027] If the determination result in step S108 is Yes, the flow ends.

[0028] 4 is a flowchart showing a first modified example of the processing of the vehicle verification system 1 according to this embodiment. In this flow, if a change to a connected component is invalid, the user is suggested to change a connected component other than the changed connected component. In FIG. 4, steps S100 to S108 are the same as those in FIG. 3, and therefore will not be described again.

[0029] If the judgment result of step S108 is No, the virtual model construction unit 3c of the backend server 3 reconstructs the virtual model assuming that a connection component other than the connection component changed in step S100 (another connection component) has been changed (step S110).

[0030] Following step S110, the effect verification unit 3d of the back-end server 3 uses the reconstructed virtual model to re-verify the effect of the change in the connected component (step S111).

[0031] Following step S111, the effect verification unit 3d of the backend server 3 determines whether the change in the connected component is valid or not based on the result of the re-verification in step S111 (step S112).

[0032] If the determination result in step S112 is No, the process returns to step S110.

[0033] If the determination result in step S112 is Yes, a suggestion is made to the user to change the other connected components assumed to have been changed in step S110 (step S113), and the flow ends.

[0034] 5 is a flowchart showing a second modification of the process of the vehicle verification system 1 according to this embodiment. In this flow, if a change to a connected component is invalid, software related to the changed connected component is changed. In FIG. 5, steps S100 to S108 are the same as those in FIG. 3, and therefore will not be described further.

[0035] If the determination result in step S108 is No, the virtual model construction unit 3c of the back-end server 3 changes the software related to the connection components changed in step S100, and reconstructs the virtual model (step S114).

[0036] Following step S114, the effect verification unit 3d of the backend server 3 uses the reconstructed virtual model to re-verify the effect of the change in the connected component (step S115).

[0037] Following step S115, the effect verification unit 3d of the backend server 3 determines whether the change in the connected components made in step S100 is valid or not, based on the result of the re-verification made in step S115 (step S116).

[0038] If the determination result in step S116 is No, the process returns to step S114.

[0039] If the determination result in step S116 is Yes, the backend server 3 transmits the related software changed in step S114 to the vehicle 2 to update the related software of the vehicle 2 (step S117), and ends the flow.

[0040] (Summary) In the first embodiment, a vehicle verification system 1 for evaluating the performance of a vehicle 2 includes a back-end server 3 arranged outside the vehicle 2, a plurality of first electronic control units 4 mounted on the vehicle 2 and storing configuration information of the vehicle 2 in a distributed manner, and a second electronic control unit 5 arranged on the vehicle 2 and receiving partial configuration information (configuration information of the local ECU 4) that is part of the configuration information of the vehicle 2 from the plurality of first electronic control units 4 and transmitting the partial configuration information to the back-end server 3, the back-end server 3 storing the configuration information of the vehicle 2, updating the stored configuration information of the vehicle 2 using the partial configuration information received from the second electronic control unit 5, constructing a virtual model of the vehicle 2 using the updated configuration information of the vehicle 2, and evaluating the performance of the vehicle 2 using the virtual model.

[0041] According to the first embodiment configured as described above, the configuration information of the entire vehicle is not stored in a specific electronic control unit, and the information transmitted from the vehicle 2 to the backend server 3 is limited to a portion (partial configuration information) of the configuration information of the vehicle 2. This makes it possible to build a virtual model of the vehicle 2 while reducing the risk that the configuration information of the entire vehicle will be read by a security attack. As a result, it is possible to prevent additional security attacks and misuse of information.

[0042] In this embodiment, the plurality of first electronic control units 4 transmit, as the partial configuration information, information on changed parts of the configuration information of the vehicle 2 to the second electronic control unit 5. This limits the information transmitted from the second electronic control unit 5 to the backend server 3 to changed parts of the configuration information of the entire vehicle, further reducing the risk of the configuration information of the entire vehicle being read.

[0043] The second embodiment of the present invention will be described, focusing on the differences from the first embodiment.

[0044] FIG. 6 is a diagram illustrating a vehicle verification system 1 according to this embodiment. In FIG. 6, the local ECU 4 includes a terminal status extraction unit 4d instead of the terminal change extraction unit 4a (shown in FIG. 1). The terminal status extraction unit 4d extracts history and performance information of each component. The history and performance information of each component corresponds to degradation information of each component.

[0045] FIG. 7 is a diagram showing an example of history and performance information for each component of the vehicle 2. The history and performance information for the vehicle body includes mileage, IGN ON / OFF time, and maintenance information. The history and performance information for the ECU includes startup / shutdown time, average CPU usage, maximum CPU usage, average memory usage, maximum memory usage, average power consumption, maximum power consumption, average temperature, maximum temperature, performance degradation information, and error logs. The history and performance information for communication lines includes bandwidth used, average delay, maximum delay, packet loss rate, bit error rate, and performance degradation information. The history and performance information for sensors includes output data, access frequency, and wear / wear status. The history and performance information for actuators includes input data, input frequency, sudden changes in input, and wear / wear status. The history and performance information for application software (App) includes data corresponding to the application software to be verified, update information, and error logs. The history and performance information of the basic software (BSW) / middleware (MW) and the operating system (OS) includes update information.

[0046] 8 is a flowchart showing the processing of the vehicle verification system 1 according to this embodiment. In this flow, a recommendation to replace the connected component is made to the user depending on the deterioration state of the connected component.

[0047] First, the terminal state extraction unit 4d of the local ECU 4 extracts history and performance information of the connected component (step S200).

[0048] Following step S200, the configuration information storage unit 4b of the local ECU 4 stores history and performance information of the connected component (step S201).

[0049] Following step S201, the configuration information transmission unit 4c of the local ECU 4 transmits the configuration information and history / performance information of the connected components of the local ECU 4 to the central ECU 5 (step S202).

[0050] Following step S202, the configuration information external transmitter 5b of the central ECU 5 transmits the configuration information and history / performance information of the connected components of the local ECU 4 to the backend server 3 (step S203).

[0051] Following step S203, the configuration information storage unit 4b of the backend server 3 updates the stored configuration information of the vehicle 2 using the configuration information and history / performance information of the connected components of the local ECU 4 (step S204).

[0052] Following step S204, the virtual model construction unit 3c of the back-end server 3 generates a virtual model using the updated configuration information of the vehicle 2 (step S205).

[0053] Following step S205, the effect verification unit 3d of the backend server 3 uses the virtual model to verify the effect of the degradation of the connected component (step S206).

[0054] Following step S206, the effect verification unit 3d of the backend server 3 determines whether or not the connection component needs to be replaced based on the result of the verification in step S206 (step S207).

[0055] If the determination result in step S207 is No, the flow ends.

[0056] If the determination result in step S207 is Yes, a component replacement is suggested to the user (step S208), and the flow ends.

[0057] (Summary) In the second embodiment, the second electronic control unit 5 acquires deterioration information (history and performance information) of components connected to multiple first electronic control units 4 from multiple first electronic control units 4, and transmits the deterioration information together with the partial configuration information to the backend server 3, and the backend server 3 updates the configuration information of the vehicle 2 stored therein using the deterioration information received from the second electronic control unit 5.

[0058] In the second embodiment configured as described above, as in the first embodiment, it is possible to construct a virtual model of the vehicle 2 while reducing the risk that the configuration information of the entire vehicle will be read by a security attack. Furthermore, by using the configuration information and history / performance information (deterioration information) of the connected components of the local ECU 4 to update the configuration information of the vehicle 2 stored in the backend server 3 and constructing a virtual model of the vehicle 2 using the updated configuration information of the vehicle 2, it is possible to verify the impact of deterioration of the connected components.

[0059] The third embodiment of the present invention will be described, focusing on the differences from the first embodiment.

[0060] 9 is a diagram illustrating the vehicle verification system 1 according to this embodiment. In FIG. 9, each local ECU 4 includes a configuration information storage unit 4b and a software update request unit 4e. The central ECU 5 includes an update request receiving unit 5c and an external update request transmitting unit 5d. The back-end server 3 includes a software update request receiving unit 3e instead of the configuration information receiving unit 3a (shown in FIG. 1).

[0061] 10 is a flowchart showing the processing of the vehicle verification system 1 according to this embodiment. In this flow, update software that has been verified using a virtual model is sent from the backend server 3 to the vehicle 2, and the software of the vehicle 2 is updated.

[0062] First, the software update request unit 4e of the local ECU 4 transmits the configuration information of the local ECU 4 and a software update request to the central ECU 5 (step S300). The software update request here refers to a request to update the software included in the configuration information of the local ECU 4.

[0063] Following step S300, the external update request transmitter 5d of the central ECU 5 transmits the configuration information of the local ECU 4 and a software update request to the backend server 3 (step S301).

[0064] Following step S301, the software update request receiving unit 3e of the backend server 3 checks the software update information included in the configuration information of the local ECU 4 (step S302).

[0065] Following step S302, it is determined whether or not there is software update (step S303). If the determination result in step S303 is No, the flow ends.

[0066] If the determination result in step S303 is Yes, it is determined whether or not the updated software has been verified using a virtual model (step S304).

[0067] If the determination result in step S304 is Yes, the backend server 3 transmits the update software to the vehicle 2 to update the software of the vehicle 2 (step S305), and ends the flow.

[0068] If the determination result in step S304 is No, the virtual model construction unit 3c of the back-end server 3 generates a virtual model using the configuration information of the vehicle 2 stored in the configuration information storage unit 4b (step S306).

[0069] Following step S306, the effect verification unit 3d of the backend server 3 uses the virtual model to verify the effect of the updated software (step S307).

[0070] Following step S307, it is determined whether the software update is effective or not based on the verification result of the effect of the updated software (step S308).

[0071] If the determination result in step S308 is Yes, the process proceeds to step S305.

[0072] If the determination result in step S308 is No, the update software is corrected (step S308), and the process returns to step S306.

[0073] (Summary) In the third embodiment, the multiple first electronic control units 4 send software update requests to the second electronic control unit 5 requesting an update of the software included in the partial configuration information, and when the second electronic control unit 5 receives the software update requests from the multiple first electronic control units 4, it sends the software update requests together with the partial configuration information to the backend server 3, and the backend server 3 receives the software update requests together with the partial configuration information, and if update software that is an updated version of the software included in the partial configuration information exists, it sends the update software that has been verified using the virtual model to the vehicle 2.

[0074] In the third embodiment configured as described above, as in the first embodiment, it is possible to build a virtual model of the vehicle 2 while reducing the risk that the configuration information of the entire vehicle will be read by a security attack. Furthermore, it is possible to update the software of the first electronic control unit 4 with update software that has been verified using the virtual model of the vehicle 2.

[0075] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. Furthermore, part of the configuration of one embodiment can be replaced with the configuration of another embodiment, or the configuration of another embodiment can be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment can be added, deleted, or replaced with other configurations. Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be implemented in hardware, in part or in whole, by designing, for example, an integrated circuit. Furthermore, the above-described configurations, functions, etc. may be implemented in software, with a processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0076] 1...vehicle verification system, 2...vehicle, 3...backend server, 3a...configuration information receiving unit, 3b...configuration information storage unit, 3c...virtual model construction unit, 3d...impact verification unit, 3e...software update request receiving unit, 4...local ECU (first electronic control unit), 4a...terminal change extraction unit, 4b...configuration information storage unit, 4c...configuration information transmission unit, 4d...terminal state extraction unit, 4e...software update request unit, 5...central ECU (second electronic control unit), 5a...configuration information receiving unit, 5b...configuration information external transmission unit, 5c...update request receiving unit, 5d...update request external transmission unit.

Claims

1. A vehicle verification system for evaluating the performance of a vehicle, comprising: a back-end server located outside the vehicle; a plurality of first electronic control devices mounted on the vehicle and storing configuration information of the vehicle in a distributed manner; and a second electronic control device mounted on the vehicle and receiving partial configuration information that is a part of the configuration information of the vehicle from the plurality of first electronic control devices and transmitting the partial configuration information to the back-end server, wherein the back-end server stores the configuration information of the vehicle, updates the stored configuration information of the vehicle using the partial configuration information received from the second electronic control device, constructs a virtual model of the vehicle using the updated configuration information of the vehicle, and evaluates the performance of the vehicle using the virtual model.

2. A vehicle verification system as described in claim 1, characterized in that the plurality of first electronic control units transmit information on changed parts of the vehicle's configuration information to the second electronic control unit as the partial configuration information.

3. A vehicle verification system as described in claim 1, characterized in that the second electronic control unit receives deterioration information of components connected to the plurality of first electronic control units from the plurality of first electronic control units, and transmits the deterioration information together with the partial configuration information to the back-end server, and the back-end server updates the configuration information of the vehicle that it stores using the deterioration information received from the second electronic control unit.

4. A vehicle verification system as described in claim 1, characterized in that: the multiple first electronic control units send a software update request to the second electronic control unit, requesting an update of the software included in the partial configuration information; when the second electronic control unit receives the software update request from the multiple first electronic control units, it sends the software update request together with the partial configuration information to the back-end server; and when the back-end server receives the software update request together with the partial configuration information and there is update software that is an updated version of the software included in the partial configuration information, it sends the update software that has been verified using the virtual model to the vehicle.

Images