JP7204471B2 - VEHICLE ELECTRONIC CONTROL DEVICE, ABNORMAL SIGNAL GENERATING METHOD, ABNORMAL SIGNAL GENERATING PROGRAM - Google Patents

Description

The present invention relates to a vehicle electronic control unit, an abnormality signal generation method, and an abnormality signal generation program.

As integration of hardware and software progresses, it is important to verify compatibility between software and hardware. In particular, in automobiles equipped with hardware systems such as various sensors and software systems such as applications that control the logic of the sensors, it is necessary to meet the functional safety standards for vehicles and ensure safety. There is a need for a method to verify how the entire vehicle is affected when a hardware or software system fails, and to control the signals that occur in interactions between systems.

On the other hand, Japanese Patent Application Laid-Open No. 2013-161299 (Patent Document 1) describes "a program storage means 13 storing a plurality of programs, one or more computing means 11 for executing the programs, and an external An information processing apparatus 100 having a plurality of interfaces 20 capable of communicating with circuits, wherein an interface registration table 34 in which the interfaces accessible by the program are registered, and the program requesting access to the interface and access control means 33 for accessing said interface instead of said program if access to the interface is permitted."

JP 2013-161299 A

The above-mentioned Patent Literature 1 describes an information processing device that controls I/O between a control device such as an ECU mounted on an automobile and an application that operates on a hypervisor. According to the invention of Patent Document 1, when an application executes an instruction to access a specific I/O port (for example, an I/O port of an ECU) and an access violation is detected for the instruction, can prevent access violations by having the hypervisor execute the instructions on behalf of the application.

However, Patent Literature 1 does not discuss simulating and evaluating failures in hardware or software systems installed in automobiles. Therefore, in order to verify the operation of hardware or software, simulation methods such as HILS (Hardware In the Loop Simulation) and vHILS (Virtual Hardware in the Loop Simulation), or direct modification of the hardware are required. becomes. However, these simulation methods are expensive to introduce, and it is difficult to respond to the needs of automotive devices, which are evolving at a rapid pace, through direct hardware changes. In addition, there is a problem that the need for failure tolerance verification of hardware and software systems installed in automobiles cannot be sufficiently met.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide means for verifying the effects of a failure in a system mounted on an automobile without introducing expensive simulation means or changing the system to be verified.

In order to solve the above-mentioned problems, one typical vehicle train control device including an abnormal signal generating hypervisor of the present invention is a vehicle electronic control device including a hypervisor, the hypervisor comprising: An abnormal signal generator and a signal transfer unit, wherein the abnormal signal generator generates an abnormal signal based on a signal generation table that defines conditions for signal generation, and the signal transfer unit transmits the abnormal signal for testing. Transfer to the execution environment.

According to the present invention, it is possible to verify the effects of failure of a system mounted on an automobile without introducing expensive simulation means or changing hardware and software systems.
Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments.

1 is a block diagram showing an example of a vehicle electronic control device according to the present invention; FIG. 1 is a diagram showing an example of a distributed system according to the present invention; FIG. It is a figure which shows an example of the signal generation table based on this invention. FIG. 4 is a diagram showing an example of processing for generating an abnormal signal using a signal received from a hardware system or a software system in Embodiment 1 according to the present invention; FIG. 4 is a diagram showing an example of processing for generating an abnormal signal using state information of a hardware system or a software system in Embodiment 1 according to the present invention;

Hereinafter, embodiments of the present invention will be described with reference to the drawings. It should be noted that the present invention is not limited by this embodiment. Moreover, in the description of the drawings, the same parts are denoted by the same reference numerals.

[Outline of Example 1]
In the present invention, the hardware system installed in the automobile (Electric Control Unit, video shooting system, brake control system, etc.) and the software system (Supervisor such as Operating System and application installed thereon) A hypervisor is used to control interactions (communication of signals, etc.). In general, signals originating in hardware or software systems are transmitted directly from their source to their destination. However, in the present invention, a signal sent to a specific application or hardware is captured by the hypervisor before it reaches the destination, and an abnormal signal is generated based on a signal generation table prepared in advance. be. In this way, the abnormal signal is transferred to the destination (the system to be verified as the test execution environment) based on the signal generation table, thereby simulating a desired failure in the destination system. can be done. In addition, after transmitting the abnormal signal to the destination, the result of the operation in the destination system (how the system reacted) is recorded in a data log, etc. to evaluate and verify the impact of the abnormal signal on the system. be able to. This makes it possible to verify the compatibility of the hardware and software systems installed in the automobile without introducing expensive simulation means or changing the hardware and software systems.

First, the configuration of a vehicle electronic control unit 1300 according to the present invention will be described with reference to FIG. The vehicle electronic control unit 1300 comprehensively controls various functions in the vehicle, and manages hardware systems such as sensors installed in the vehicle and software systems such as applications that control the logic of the hardware systems. It is a system that As shown in FIG. 1, the vehicle electronic control unit 1300 includes a virtual environment 1200, a hypervisor 1100, and an ECU 1000. FIG.

ECU (Electronic Control Unit) 1000 refers to the engine, motor, meter, transmission, brake, airbag, lamp, power steering, power window, car air conditioner, electronic key receiver, car audio, car navigation system, and camera. , thermometer, and various sensors. As shown in FIG. 1, ECU 1000 includes a plurality of CPUs 1010 and 1015, a memory 1030, and a hardware signal transfer section 1020 that transmits hardware signals.
Although FIG. 1 shows the ECU 1000 having two CPUs and one memory and one hardware signal transfer unit, the present invention is not limited to this, and the number of parts may be changed as appropriate. good.

Next, the hypervisor 1100 will be explained.
In general, an electronic processing system installed in an automobile or the like consists of a hardware layer that provides hardware resources such as RAM and CPU, and a hypervisor layer that manages the operation of one or more virtual machines. It consists of a supervisor layer that implements the OS (Operating System) of the virtual machine and an application layer that runs application software. As a high-level control program that controls the virtual machine, the hypervisor distributes resources to supervisors and application software implemented in lower layers. The hypervisor in the present invention controls communication with external devices. In other words, the hypervisor 1100 in the present invention manages the operations of the ECU 1000 (that is, the hardware layer) and the virtual environment 1200 (that is, the supervisor layer and the application layer), which will be described later. It controls communication (exchange of signals, etc.) in

As shown in FIG. 1, the hypervisor 1100 includes a signal transfer unit 1110 that transmits and receives signals generated from the ECU 1000 and the virtual environment 1200, and an abnormal signal (a desired failure that is simulated in the system to be verified) by processing described later. signal), a signal generation table 1121 indicating conditions for generating the abnormal signal, and a data log 1130 for recording the operation and generation results of the signal in the hypervisor.
In addition, as shown in FIG. 1, the signal transfer unit 1110 can communicate with the abnormal signal generation unit 1120, and the abnormal signal generation unit 1120 can transmit signals received by the signal transfer unit 1110 and the signal generation table 1121. to generate an anomaly signal. The hypervisor configures a virtual environment 1200 using resources such as CPUs 1010 and 1015 and memory 1030 in ECU 1000 .
Although FIG. 1 shows the case where the ECU 1000 includes one hardware signal transfer unit 1020, a plurality of hardware signal transfer units 1020 may be provided. When a plurality of hardware signal transfer units 1020 are provided, the signal transfer units ga corresponding to the respective hardware signal transfer units may be provided in the signal transfer unit 1110 .

The virtualization environment 1200 is a logical space configured by the hypervisor 1100 and executing virtual machines and applications independently of each other. As shown in FIG. 1, one or more supervisors 1210 are implemented within the virtualized environment 1200 . The supervisor 1210 provides resources to an application described later and manages the operation of the application, and may be an OS (operating system) such as Windows or Linux, for example. The supervisor 1210 has a data log 1211 that records the resource usage and operation results of applications running on the supervisor. As described above, an application (hereinafter referred to as “app”) 1212 is implemented on the supervisor 1210 . The application 1212 is a program for controlling hardware such as an in-vehicle sensor. For example, the application 1212 may be an image processing program for processing an image captured by a sensor such as a camera.
Also, as described above, the application 1212 transmits signals to the ECU 1000 and receives signals from the ECU via the signal transfer unit 1110 of the hypervisor 1100 . Furthermore, the application 1212 has a data log 1213 that records resource usage and operation results within the application.

The data log analysis unit 1400 shown in FIG. 1 may be provided in the vehicle electronic control unit 1300, or may be provided in a remote device that communicates with the vehicle electronic control unit 1300 via a network. good. Here, the data log analysis unit 1400 acquires the data of the data log 1130 of the hypervisor, the data log 1211 of the supervisor 1210, and the data log 1213 of the application 1212, and operates the abnormal signal generated by the process described later. Analyze the results. Data log analysis unit 1400, for example, when an abnormal signal generated based on a signal transmitted from ECU 1000 is transmitted to application 1212 by signal transfer unit 1110, evaluates the influence on each of the hypervisor, supervisor, and application. For this purpose, the information in each data log may be obtained and analyzed.

Next, a specific example of the vehicle electronic control unit 1300 shown in FIG. 1 will be described. If the hardware signal transfer unit 1020 is configured as an Intel APIC (registered trademark), AMD AVID (registered trademark), ARM GIC (registered trademark), or ARM AMBA (registered trademark) specification device, , the signal transfer unit 1110 may be configured such that the hardware signal transferred from the hardware signal transfer unit 1020 is captured by the hypervisor. Various specific examples using the vehicle electronic control unit 1300 are possible other than the example described here.

Next, an example of the configuration of the distributed system 100 according to the present invention will be described with reference to FIG. In the above, the virtualization environment, the hypervisor, and the ECU according to the present invention have been described as an electronic control device for a vehicle. A configuration in which they are separated from each other and connected by a network such as the Internet is also possible.

As shown in FIG. 2 , the distributed system 100 consists of a central server 150 , vehicles 120 and 121 carrying ECUs 118 and 119 respectively, and a network 175 . Central server 150 is connected to vehicles 120 , 121 via network 175 .

The central server 150 includes a virtualization environment 110 , a verification unit 104 including a hypervisor 112 , a resource management unit 106 including a CPU 113 , a memory 114 , a storage unit 115 and a communication unit 116 .
The central server 150 is a test execution server that verifies the effects of abnormal signals that cause specific errors and failures in order to verify the fault tolerance of the verification target system (software such as applications or hardware systems such as ECUs). It is a server device that provides the environment 111 . The test execution environment 111 is a space for simulating an abnormal signal and verifying/analyzing the operation result and influence of the signal.
In this embodiment, as an example, the test execution environment 111 is described as a logical space created in a virtual environment, but the test execution environment 111 is not limited to this, and may be a specific hardware device. . For example, the test execution environment 111 may be hardware such as an ECU, a camera, an automatic driving system, a brake control unit, etc. that are set in advance to verify the operation and influence of an abnormal signal.

The hypervisor 112 of the central server 150 creates the virtual environment 110 including the test execution environment 111 using the physical resources of the CPU 113 , memory 114 and storage unit 115 . The hypervisor 112 also includes the anomaly signal generator 117 as described above. The anomaly signal generation unit 117 is a functional unit that generates an anomaly signal for verifying fault tolerance of the system to be verified. The abnormal signal generator 117 receives, for example, signals (original signals) from the ECUs 118 and 119 of the automobiles 120 and 121 via the network 175, processes the received signals based on an abnormal signal generation table described later, This may be transferred to the test execution environment 111 . Alternatively, a new abnormality signal may be generated based on the abnormality signal generation table and this abnormality signal may be transferred to the ECU 118 or 119 .

By using such a distributed system 100 and supporting a plurality of verification target systems (automobiles, etc.) under a common virtualization environment, there is no need to prepare a virtualization environment for each verification target system. As a result, system resources (CPU, memory, I/O, storage) can be greatly saved.

Next, the configuration of the signal generation table 1121 according to the present invention will be described with reference to FIG. The signal generation table 1121 is a table showing conditions for generating an abnormal signal (simulated failure signal) for verifying fault tolerance of a verification target system (software such as an application or hardware system such as an ECU). As shown in FIG. 3, the signal generation table 1121 defines an input/output signal ID that is an identifier for identifying a signal, a signal timing condition regarding signal timing, and a signal data condition regarding signal data. , the signal generation table 1121 may be manually created by the user, or may be created automatically by artificial intelligence based on analysis of past anomaly data, as described below.

As shown in FIG. 3, the signal generation table 1121 includes an input signal ID 1122 that identifies a signal to be processed among signals received by the signal transfer unit (for example, the signal transfer unit 1110 in FIG. 1), and an input signal ID 1122 that identifies a signal to be processed. An output signal ID 1123 indicating an identifier assigned when outputting a signal, a signal timing condition 1124 indicating a timing change (delay, etc.) to be applied to the target signal, and a data change to be applied to the target signal. and state information 1126 indicating the state of the system that transmitted the signal of interest or the system that received the signal of interest (abnormal, normal, period during which no signal is transmitted or received, etc.). This state information (also referred to as "system state") 1126 indicates, for example, the resource usage rate and I/O data traffic volume of an application or supervisor (or a hardware device such as a sensor) to which a signal is to be sent. It may be information indicating whether it is normal or not. In addition, if the software system or hardware system to be the destination is not normal, an error message indicating an abnormality in the system (no signal received within a predetermined period, insufficient memory, etc.) may be displayed. .
To simplify the explanation, FIG. 3 shows the case where the input identification ID 1122 is a single digit number, but the present invention is not limited to this. For example, the input identification ID 1122 may be a character string that uniquely identifies a specific signal, or may indicate the type of the specific signal. Processing using the signal generation table 1121 will be described later.

As noted above, the signal generation table 1121 may be automatically generated by artificial intelligence based on analysis of past anomaly data. Here, artificial intelligence is, for example, rule-based machine learning, deep learning, dimensionality reduction method, ensemble learning, instance-based algorithm, regression analysis, Bayesian network, neural network, cluster analysis, reinforcement learning, or these technologies A combination of other techniques and the like can be mentioned.
These artificial intelligences, for example, analyze accumulated past anomaly data, determine what kind of anomaly signals occur under various conditions, and determine when a software system or hardware system receives a specific anomaly signal. You may learn how it works and build a learning model. Then, by using the constructed learning model, optimal abnormal signal generation conditions for generating a specific abnormal state in the system to be verified are derived, and these generation conditions are defined as the signal generation table 1121. good. This allows automatic generation of conditions that can optimally trigger a particular abnormal condition.

Next, with reference to FIG. 4, the process of generating an anomaly signal using a signal received from a hardware system or software system will be described. As described above, in order to verify the fault tolerance of the target system (software such as applications, hardware such as ECU, etc.), this process receives a signal (original signal) from a hardware system or software system. , processing based on the generation conditions shown in the signal generation table 1121 (see FIG. 3) to generate an abnormal signal.
In the following description, an example in which a signal addressed to an application is transmitted from the ECU side will be described, but the present invention is not limited to this. For example, this processing may be applied when a signal addressed to a specific software system is sent from the hardware side, or applied when a signal addressed to a specific hardware system is sent from the software side. Good (that is, it does not matter whether the system to be verified is software or hardware).

In step 2000, a signal (original signal) directed to a particular app (eg, app 1212 shown in FIG. 1) or ECU (eg, ECU 1000 shown in FIG. 1) is generated in the ECU or app. As described above, this signal may be a signal generated in the ECU and directed to the application, or may be a signal generated in the application and directed to the ECU. Specifically, this signal corresponds to a request signal for processing image data acquired by a camera by an image processing application running in a virtual environment.

At step 2001 , a signal transfer unit (eg, signal transfer unit 1110 shown in FIG. 1) captures the signal generated at step 2000 . Here, "capturing" means capturing a signal and temporarily storing it in the signal transfer unit.

At step 2002, the signal transfer unit checks whether the abnormal signal generator (for example, the abnormal signal generator 1120 shown in FIG. 1) is activated (whether the abnormal signal generation function is turned on). If the abnormal signal generation unit is not activated, the process proceeds to step 2003, and the signal transfer unit transfers the signal (without processing) to the destination as it is. On the other hand, if the abnormal signal generator is activated, the process proceeds to step 2004 .

At step 2004, the signal transfer unit extracts a signal ID that identifies the signal from the signal received at step 2001 (for example, metadata associated with the signal).

At step 2005, the signal transfer unit checks whether or not the input signal ID corresponding to the signal ID of the received signal exists in the signal generation table 1121 (see FIG. 3). For example, the signal transfer unit compares the signal IDs extracted from the signals in step 2004 with the input signal IDs recorded in the signal generation table 1121 to determine whether there is a match. If the extracted signal ID does not match the input signal ID recorded in the signal generation table, the process proceeds to step 2003, and the signal transfer unit transfers the signal (without processing) to the destination as it is. . On the other hand, if the extracted signal ID matches the input signal ID recorded in the signal generation table, the process proceeds to step 2006 .

At step 2006, the signal transfer unit obtains status information of the system to which the signal is to be sent. As described above, this status information is information indicating the status (normal, abnormal, etc.) of the system that receives the target signal. For example, the signal transfer unit may transmit a status information acquisition request to the system that is the transmission destination of the signal received in step 2001, and receive notification of the status information from the transmission destination. The state information management table or the like stored in the destination may be accessed and the state information of the destination may be read, and the method of acquiring the state information is not particularly limited.

In step 2007, whether the state information obtained in step 2006 matches the state information described in the signal generation table (for example, the signal generation table 1121 shown in FIG. 2) (i.e., if the destination system is in an appropriate state to receive ). If the state information acquired in step 2006 and the state information described for the target signal in the signal generation table do not match, the process proceeds to step 2003, and the signal transfer unit transfers the signal (without processing ) is transferred to the destination system as is. On the other hand, if the state information acquired in step 2006 matches the state information described for the target signal in the signal generation table, the process proceeds to step 2008 .

At step 2008, the abnormal signal generator (for example, the abnormal signal generator 1120 shown in FIG. 1) generates an abnormal signal by processing the received signal based on the signal generation table. Here, the processing for generating the abnormal signal means that the abnormal signal generation unit performs processing corresponding to the signal described in the signal generation table for the signal received in step 2001, and generates the processed signal. It means to create as an anomaly signal. More specifically, the abnormal signal generation unit performs a process of applying the signal timing condition, signal data change, and/or signal ID change described in the signal generation table to the target signal. In this process, the abnormal signal generation unit generates the abnormal signal by, for example, replacing a predetermined portion of the data string of the received original signal with a predetermined value. To explain an example with reference to FIG. 3, when the signal transfer unit receives a signal with an input signal ID of “1”, the abnormal signal generation unit generates 2 Generate an anomaly signal by applying a nanosecond delay as a signal timing change (note that in the case of an input signal ID of "1", there is no change in the output signal ID and signal data, so the process for generating an anomaly signal is signal timing only).
Although an example of generating an abnormal signal by changing the timing of the received original signal has been described, the present invention is not limited to this, and the data of the original signal is changed, the output signal ID is changed, or the like. , processing other than timing change may be performed. When the abnormal signal generation process is completed (when all the changes described for the target signal in the signal generation table have been made), the process proceeds to step 2003, and the signal transfer unit transmits the abnormal signal to the destination (for example, transfer to the application, supervisor, or hardware device that will be the execution environment for testing.

In step 2009, the anomaly signal is forwarded to the destination system, while data logs that monitor the effects of the anomaly signal (e.g., app data log 1213, supervisor data log 1211, and hypervisor data log 1213 shown in FIG. 1). data log 1130) is activated. These data logs may be diagnostic programs that monitor and record activity at each layer of the abnormal signal. For example, these data logs can be used to identify changes in resource usage, I/O traffic, etc. in the app or supervisor, changes in signal timing, hardware device temperature, voltage, performance, etc., types of abnormal signals, and desired simulations. Depending on the fault, various parameters that quantify the effect of the anomalous signal may be recorded.

In step 2010, the data log analysis unit (for example, the data log analysis unit 1400 shown in FIG. 1) analyzes data log information (i.e., application data log 1213, supervisor data log 1211, and hypervisor data log 1130). information). As described above, the data log analysis unit is a functional unit that analyzes the effects of abnormal signals based on the information recorded in each data log. The data log analysis unit may, for example, continuously acquire information of each data log when the data log of each layer is activated, and periodically acquire the data log at predetermined intervals (for example, one minute). information may be obtained.

At step 2011 , the data log analysis unit analyzes the information of each data log acquired at step 2010 . Analyzing here means analyzing the information in each data log and It means to identify patterns or relationships. For example, the data log analysis unit compares parameters such as resource usage rate, signal timing, hardware device temperature, voltage, and performance obtained from the data log with predetermined thresholds to determine whether an abnormal signal has failed at the destination. It is possible to quantify and verify whether or not a failure has occurred and the magnitude of the failure.

The flow of generating an abnormal signal and verifying the influence of the abnormal signal has been described above for one abnormal signal, but this process does not need to end after generating and verifying one abnormal signal. In one aspect of the present invention, the hypervisor according to the present invention generates a new abnormal A signal (eg, a second anomaly signal) may be generated. For example, if you want to put the application or hardware device to be verified into a specific failure state, first generate and transfer the first abnormal signal, and after evaluating the operation result of the first abnormal signal (for example, if the verification target is After confirming whether or not a desired failure state has occurred, a second abnormality signal may be generated and transferred in accordance with this operation result. In this way, it is possible to cause simulated failures in a chain reaction, thereby simulating a situation in which failures occur consecutively.

[Outline of Example 2]
Next, with reference to FIG. 5, processing for generating an abnormal signal using state information of the hardware system or software system will be described. In order to verify the fault tolerance of a system to be verified (software such as an application or hardware such as an ECU), the processing described here is performed without using the original signal as described in the first embodiment. is the process of generating (from scratch) an anomaly signal that causes the desired fault using the state information of
As in the processing described in the first embodiment, in the following description, an example in which a signal addressed to an application is transmitted from the ECU side will be described, but the present invention is not limited to this. For example, this process may be applied when a signal destined for a specific software system originates from the hardware side, and is applied when a signal destined for a specific hardware system originates from the software side. may That is, it is arbitrary whether the system to be verified is software or hardware.

First, in step 3000, the signal transfer section checks whether or not the abnormal signal generator (for example, the abnormal signal generator 1120 shown in FIG. 1) is in operation. Here, "in operation" means that the abnormal signal generation function is turned on. If the abnormal signal generator is not activated, this process ends. On the other hand, if the abnormal signal generator is activated, the process proceeds to step 3001 .

Next, in step 3001, the signal transfer unit acquires state information of the system to which the signal is to be sent. As described above, this status information is information indicating the status (normal, abnormal, etc.) of the system that receives the target signal. For example, the signal transfer unit may transmit a state information acquisition request to a system to be step-verified, receive notification of state information from the verification target, and receive a state information stored in a predetermined memory address. The state information to be verified may be read by accessing an information management table or the like, and the acquisition method of the state information is not particularly limited. Here, the signal transfer unit may continuously monitor the status information of the system to be verified, or may periodically acquire the status information of the system at predetermined intervals (for example, one minute).

Next, in step 3002, the signal transfer unit checks whether the state information obtained in step 3001 matches the state information described in the signal generation table 1121 (see FIG. 3). That is, the signal transfer unit checks whether the system to be verified is in an appropriate state to receive the target signal. If the state information acquired in step 3001 and the state information described for the target signal in the signal generation table do not match, this process ends without generating an abnormal signal. On the other hand, if the state information acquired in step 3001 matches the state information described for the target signal in the signal generation table, the process proceeds to step 3003 .

Next, at step 3003, the abnormal signal generator (for example, the abnormal signal generator 1120 shown in FIG. 1) generates an abnormal signal based on the generation conditions described in the signal generation table. The abnormal signal generation according to the second embodiment generates a new abnormal signal according to the state of the verification target system without using the original signal from the software system or hardware system. The second embodiment differs from the abnormal signal generation process of the first embodiment in that the abnormal signal is generated according to the state of the system to be verified, regardless of the original signal. However, as in the abnormal signal generation process according to the first embodiment, in the abnormal signal generation process according to the second embodiment, the abnormal signal generation unit uses the signal timing conditions, the signal data conditions, and the conditions described in the signal generation table. / Or generate an anomaly signal according to the conditions of the signal ID. For example, to explain an example using the signal generation table of FIG. When the state is detected, the abnormal signal generator generates an abnormal signal including the contents of memory address 0x101 and having an output signal ID of "6" as described in the signal generation table.
Here, the case where there are a condition regarding the content of the abnormal signal and a condition regarding the output signal ID has been described as an example, but the present invention is not limited to this, and the abnormal signal is generated according to other conditions such as a condition regarding the timing of the abnormal signal. It is also possible to When the abnormal signal generation process ends, the process proceeds to step 3006, and the signal transfer unit transfers the abnormal signal to the verification target system.

At step 3004, the anomalous signal is forwarded to the system under verification while data logs monitoring the effects of the anomalous signal (e.g., app data log 1213, supervisor data log 1211, and The hypervisor's datalog 1130) is activated. These data logs may be diagnostic programs that monitor activity in each layer of the abnormal signal and record the results of the activity. For example, these data logs can be used to identify changes in resource usage, I/O traffic, etc. in the app or supervisor, changes in signal timing, hardware device temperature, voltage, performance, etc., types of abnormal signals, and desired simulations. Depending on the fault, various parameters may be recorded to quantify the effect of the anomalous signal.

In step 3005, the data log analysis unit (for example, the data log analysis unit 1400 shown in FIG. 1) analyzes the data log information, that is, the application data log 1213, the supervisor data log 1211, and the hypervisor data log 1130. Get information. As described above, the data log analysis unit is a functional unit that analyzes the effects of abnormal signals based on the information recorded in each data log. The data log analysis unit may, for example, continuously acquire information of each data log when the data log of each layer is activated, and periodically acquire the data log at predetermined intervals (for example, one minute). information may be obtained.

At step 3006 , the data log analysis unit analyzes the information of each data log acquired at step 3005 . Analyzing here means analyzing the information in each data log and It means to identify patterns or relationships. For example, the data log analysis unit compares parameters such as resource usage rate, signal timing, hardware device temperature, voltage, and performance obtained from the data log with predetermined thresholds to determine whether an abnormal signal has failed at the destination. It is possible to quantify and verify whether or not a failure has occurred and the magnitude of the failure.

In the abnormal signal generation means described in the first and second embodiments above, when the system installed in the automobile fails, without introducing expensive simulation means or changing the hardware system and software system. can be verified. As a result, the cost (monetary cost and computer resource usage) for verifying the fault tolerance of the system installed in the vehicle can be reduced, and verification can be performed using a general computer equipped with a hypervisor. becomes possible. As a result, the availability of the system for fault tolerance verification is improved, and the efficiency of verification is improved.

Modification

In the above, an example of generating an abnormal signal for verifying a software system using state information indicating the state of the software system (application, supervisor, etc.) has been mainly described, but the present invention is not limited to this. Instead, it is also possible to generate an anomaly signal that places the hardware system in a particular anomalous state.

One specific example of generating an abnormal signal that puts a hardware system in a specific abnormal state is a video capturing unit, an automatic driving unit, an engine throttle unit, a power steering unit, a telematics unit, a brake control unit, and an advanced driving assistance unit. A case of an automobile in which a part is mounted is conceivable. In such vehicles, there is a need to verify how other functional parts are affected when one functional part fails. Therefore, according to the abnormal signal generating means of the present invention, the abnormal signal generated by processing the signal from one functional unit based on the above-described signal generation table is transferred to the other functional unit. It is possible to verify the operation when the functional part of is in a specific abnormal state.

For example, in the case of the above-mentioned car, the video signal acquired by the video recording unit is processed to introduce noise into part of the video (processing that erases, blurs, or replaces a part of the video with an unclear image). by transferring the abnormal signal to other in-vehicle functional units, how other functional units will operate if the video recording unit fails (for example, at what timing the telematics unit will notify the driver or whether the automatic driving section switches to manual driving, whether the brake control section switches to manual driving, or whether the engine throttle section controls the acceleration of the vehicle).

In addition, by converting the brake signal sent from the brake control unit to the telematics unit into an abnormal signal (or generating a new abnormal brake signal), the response speed of the telematics unit time) can be verified.

Although the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and various modifications are possible without departing from the gist of the present invention.

1000 ECU
1100 Hypervisor 1110 Signal transfer unit 1120 Abnormal signal generation unit 1121 Signal generation table 1200 Virtual environment 1300 Vehicle electronic control unit 1400 Data log analysis unit

Claims (10)

A vehicle electronic control device including a hypervisor,
The hypervisor is
An abnormal signal generation unit and a signal transfer unit,
The abnormal signal generation unit is
Generate an abnormal signal based on a signal generation table that defines conditions for signal generation,
The signal transfer unit is
forwarding the abnormal signal to a testing execution environment;
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The abnormal signal generation unit is
generating the abnormal signal by processing the original signal received from the software system or hardware system linked to the hypervisor based on the signal generation table;
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 2,
The abnormal signal generation unit generates the abnormal signal by replacing a predetermined portion of the data string of the original signal with a predetermined value.
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The abnormal signal generation unit is
generating the abnormal signal based on state information indicating a system state obtained from a software system or hardware system linked to the hypervisor and the signal generation table;
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The signal generation table is a table in which an identifier for identifying a signal, a signal timing condition regarding signal timing, and a signal data condition regarding signal data are defined.
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The hypervisor includes a data log that records results of operation in the execution environment for testing the first anomaly signal;
The abnormal signal generation unit generates a second abnormal signal according to the operation result of the first abnormal signal recorded in the data log.
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The signal transfer unit is
receiving signals from software or hardware systems associated with the hypervisor;
if the signal identifier included in the signal matches a signal identifier pre-recorded in the signal generation table;
The abnormal signal generation unit is
generating the abnormal signal by converting the signal identifier based on the signal generation table;
A vehicle electronic control device characterized by: In the vehicle electronic control device according to claim 1,
The abnormal signal generation unit is
acquiring state information indicating the system state of the system from a software system or hardware system linked to the hypervisor;
if the system state indicated in the state information matches a system state pre-recorded in the signal generation table;
generating the abnormal signal based on the signal generation table;
A vehicle electronic control device characterized by: A method for generating an abnormal signal in a vehicle electronic control device including a hypervisor,
The hypervisor is
An abnormal signal generation unit and a signal transfer unit,
The abnormal signal generation method includes:
a step of generating an abnormal signal by the abnormal signal generator based on a signal generation table that defines conditions for signal generation;
transferring the abnormal signal to a test execution environment by the signal transfer unit;
Abnormal signal generation method including. An abnormality signal generating program in a vehicle electronic control device including a hypervisor,
The hypervisor is
An abnormal signal generation unit and a signal transfer unit,
The abnormal signal generation program is
a procedure for generating an abnormal signal by the abnormal signal generator based on a signal generation table that defines conditions for signal generation;
a procedure for transferring the abnormal signal to the test execution environment by the signal transfer unit;
Abnormal signal generation program for causing the vehicle electronic control unit to execute.

Images