WO2020129531A1 - 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム - Google Patents

車両用電子制御装置、異常信号生成方法、異常信号生成プログラム Download PDF

Info

Publication number
WO2020129531A1
WO2020129531A1 PCT/JP2019/045590 JP2019045590W WO2020129531A1 WO 2020129531 A1 WO2020129531 A1 WO 2020129531A1 JP 2019045590 W JP2019045590 W JP 2019045590W WO 2020129531 A1 WO2020129531 A1 WO 2020129531A1
Authority
WO
WIPO (PCT)
Prior art keywords
signal
signal generation
abnormal signal
abnormal
electronic control
Prior art date
Application number
PCT/JP2019/045590
Other languages
English (en)
French (fr)
Inventor
ハイロ ロペス
拓郎 森
亮輔 安岡
朋仁 蛯名
一 芹沢
亮輔 林
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Publication of WO2020129531A1 publication Critical patent/WO2020129531A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software

Definitions

  • the present invention relates to a vehicle electronic control device, an abnormal signal generation method, and an abnormal signal generation program.
  • Patent Document 1 discloses that "a program storage unit 13 that stores a plurality of programs, one or more calculation units 11 that execute the programs, and an external An information processing apparatus 100 having a plurality of interfaces 20 capable of communicating with a circuit, wherein an interface registration table 34 in which the interfaces accessible by the program are registered, and the program requesting access to the interface are: And access control means 33 for accessing the interface instead of the program when access to the interface is permitted.”
  • Patent Document 1 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 is described.
  • 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.
  • the access violation can be prevented by the hypervisor executing the instruction on behalf of the application.
  • Patent Document 1 does not consider simulating and evaluating a failure of a hardware system or a software system mounted on an automobile. Therefore, in order to verify the operation of the hardware or software, it is necessary to directly change the hardware such as HILS (Hardware In-the Loop Simulation) or vHILS (Virtual Hardware in the Loop Simulation). Becomes However, these simulation means are expensive to introduce, and it is difficult to directly meet the needs of in-vehicle devices that are evolving at a fast pace by directly changing the hardware. Further, there is a problem that the needs for verifying the fault tolerance of the hardware and the software system mounted on the automobile are not sufficiently met.
  • HILS Hardware In-the Loop Simulation
  • vHILS Virtual Hardware in the Loop Simulation
  • an object of the present invention is to provide a means for verifying the influence when a system mounted on an automobile fails without introducing a high-cost simulation means or changing the system to be verified.
  • one of the vehicle electric train control devices including a typical abnormal signal generation hypervisor of the present invention is a vehicle electronic control device including a hypervisor, the hypervisor, An abnormal signal generation unit and a signal transfer unit are provided, the abnormal signal generation unit generates an abnormal signal based on a signal generation table that defines conditions for signal generation, and the signal transfer unit tests the abnormal signal. Transfer to the execution environment.
  • FIG. 1 is a block diagram showing an example of a vehicle electronic control device according to the present invention.
  • FIG. 2 is a diagram showing an example of the distributed system according to the present invention.
  • FIG. 3 is a diagram showing an example of the signal generation table according to the present invention.
  • FIG. 4 is a diagram showing an example of a process of generating an abnormal signal using a signal received from a hardware system or a software system in the first embodiment according to the present invention.
  • FIG. 5 is a diagram showing an example of a process of generating an abnormal signal by using state information of a hardware system or a software system in the first embodiment according to the present invention.
  • Example 1 In the present invention, between a hardware system (Electric Control Unit, a video shooting system, a brake control system, etc.) mounted on an automobile and a software system (a supervisor such as an Operating System and an application mounted thereon) A hypervisor is used to control communication (signal communication, etc.).
  • a signal generated in a hardware system or a software system is directly transmitted from a signal source to a destination.
  • a signal transmitted to a specific application or hardware is temporarily captured by the hypervisor before reaching a destination, and an abnormal signal is generated based on a signal generation table prepared in advance.
  • the abnormal signal is transferred to the transmission destination (the verification target system that is the test execution environment) based on the signal generation table, so that a desired failure in the transmission destination system can be simulated.
  • the vehicular electronic control unit 1300 comprehensively controls various functions of a vehicle and manages a hardware system such as a sensor mounted on the vehicle and a software system such as an application that controls the logic of the hardware system. It is a system that does.
  • the vehicle electronic control unit 1300 includes a virtual environment 1200, a hypervisor 1100, and an ECU 1000.
  • the ECU (Electronic Control Unit) 1000 is an engine, a motor, a meter, a transmission, a brake, an airbag, a lamp, a power steering, a power window, a car air conditioner, a vehicle side receiving part of an electronic key, a car audio system, a car navigation system, a camera. It is an auxiliary device that controls the functions of a thermometer, various sensors, and the like.
  • ECU 1000 includes a plurality of CPUs 1010 and 1015, a memory 1030, and a hardware signal transfer unit 1020 that transmits a hardware signal.
  • 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 each component may be appropriately changed. Good.
  • an electronic processing system installed in an automobile or the like has a hardware layer that provides hardware resources such as RAM and CPU, a hypervisor layer that manages the operation of one or more virtual machines, and It consists of a supervisor layer that implements the operating system (OS) of the virtual machine, and an application layer that runs application software.
  • OS operating system
  • the hypervisor as an upper control program for controlling the virtual machine, distributes resources to the supervisor and application software installed in the lower layer.
  • the hypervisor controls communication with external devices.
  • the hypervisor 1100 manages the operation of the ECU 1000 (that is, the hardware layer) and the virtualization environment 1200 (that is, the supervisor layer and the application layer) that will be described later, and manages the operation between the ECU 1000 and the virtualization environment 1200. It controls communication (signal exchange, etc.) in.
  • 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 is simulated in a system to be verified by a process described later).
  • An abnormal signal generation unit 1120 that generates a signal that causes a signal
  • a signal generation table 1121 that indicates conditions for generating an abnormal signal
  • a data log 1130 that records the operation of the signal in the hypervisor and the generation result.
  • the signal transfer unit 1110 can communicate with the abnormal signal generation unit 1120, and the abnormal signal generation unit 1120 receives the signal received by the signal transfer unit 1110 and the signal generation table 1121.
  • An abnormal signal is generated based on The hypervisor configures the virtualized environment 1200 using resources such as the CPUs 1010 and 1015 and the memory 1030 in the ECU 1000.
  • FIG. 1 shows the case where ECU 1000 includes one hardware signal transfer unit 1020, a plurality of hardware signal transfer units 1020 may be included. When a plurality of hardware signal transfer units 1020 are provided, they may be provided in the signal transfer unit ga signal transfer unit 1110 corresponding to each hardware signal transfer unit.
  • the virtualized environment 1200 is a logical space that is configured by the hypervisor 1100 and that executes virtual machines and applications in mutually independent states.
  • one or more supervisors 1210 are implemented within virtualized environment 1200.
  • the supervisor 1210 gives resources to an application to be described later and manages the operation of the application, and may be an OS (operating system) such as Windows or Linux.
  • the supervisor 1210 is provided with a data log 1211 for recording the resource usage rate of the application running on the supervisor and the result of the operation.
  • the application hereinafter referred to as “app” 1212 is installed on the supervisor 1210.
  • the application 1212 is a program that controls hardware such as an in-vehicle sensor, and may be, for example, an image processing program that processes an image captured by a sensor such as a camera. Further, as described above, the application 1212 transmits a signal to the ECU 1000 or receives a signal from the ECU via the signal transfer unit 1110 of the hypervisor 1100. Further, the application 1212 includes a data log 1213 that records the resource usage rate and the operation result in the application.
  • the data log analysis unit 1400 shown in FIG. 1 may be included in the vehicle electronic control unit 1300, or may be included in a remote device that communicates with the vehicle electronic control unit 1300 via a network. Good.
  • 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 an abnormal signal generated by the process described below. The result is analyzed.
  • the data log analysis unit 1400 evaluates the influence on each of the hypervisor, the supervisor, and the application when, for example, the abnormal signal generated based on the signal transmitted from the ECU 1000 is transmitted to the application 1212 by the signal transfer unit 1110. Therefore, the information of each data log may be acquired and analyzed.
  • 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, etc.
  • the signal transfer unit 1110 may have a configuration in which 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.
  • the present invention is not limited thereto, and the constituent elements of the vehicle electronic control device described above are mutually different. It is also possible to have a configuration in which they are separated from each other and are connected by a network such as the Internet.
  • the distributed system 100 includes a central server 150, automobiles 120 and 121 equipped with ECUs 118 and 119, respectively, and a network 175.
  • the central server 150 is connected to the automobiles 120 and 121 via the network 175.
  • the central server 150 includes a virtual environment 110, a verification unit 104 including a hypervisor 112, a CPU 113, a memory 114, a storage unit 115, and a resource management unit 106 including a communication unit 116.
  • the central server 150 is a test execution for verifying the influence of a specific error or an abnormal signal that causes a failure in order to verify the fault tolerance of a system to be verified (software such as an application or a hardware system such as an ECU).
  • 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 the influence of the signal.
  • test execution environment 111 is not limited to this and may be a specific hardware device. ..
  • the test execution environment 111 may be hardware such as an ECU, a camera, an automatic driving system, and a brake control unit that are preset for verifying the operation/influence of an abnormal signal.
  • the hypervisor 112 of the central server 150 uses the physical resources of the CPU 113, the memory 114, and the storage unit 115 to create the virtualized environment 110 including the test execution environment 111. Further, the hypervisor 112 includes the abnormal signal generation unit 117, as described above.
  • the abnormal signal generation unit 117 is a functional unit that generates an abnormal signal for verifying the fault tolerance of the system to be verified. Then, the abnormal signal generation unit 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 abnormal signal may be generated based on the abnormal signal generation table, and this abnormal signal may be transferred to the ECU 118 or 119.
  • the signal generation table 1121 is a table showing the generation condition of an abnormal signal (simulated failure signal) for verifying the fault tolerance of the system to be verified (software such as application or hardware system such as ECU). As shown in FIG. 3, the signal generation table 1121 defines input/output signal IDs that are identifiers for identifying signals, signal timing conditions regarding signal timings, and signal data conditions regarding signal data.
  • the signal generation table 1121 may be manually created by a user, or may be automatically created by artificial intelligence based on an analysis of past abnormal data, as described later.
  • 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 a target signal ID 1122.
  • An output signal ID 1123 indicating an identifier assigned when outputting a signal
  • a signal timing condition 1124 indicating a change (delay or the like) in timing applied to a target signal, and a change in data applied to the target signal.
  • It includes the signal data condition 1125 shown and state information 1126 showing the state (abnormal, normal, no signal transmission/reception, etc.) of the system transmitting the target signal or the system receiving the target signal.
  • This status information (sometimes referred to as “system status”) 1126 is, for example, the resource usage rate or I/O data communication volume of an application or supervisor (or a hardware device such as a sensor) to which a signal is transmitted. It may be information indicating whether it is normal or not. If the destination software system or hardware system is not normal, an error message indicating that the system is abnormal (a signal has not arrived within a predetermined period, memory shortage, etc.) may be displayed. .. Note that, in order to simplify the description, the case where the input identification ID 1122 is a single digit number is shown in FIG. 3, 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 a specific signal. The process using the signal generation table 1121 will be described later.
  • the signal generation table 1121 may be automatically generated by artificial intelligence based on the analysis of past abnormal data.
  • artificial intelligence means, for example, rule-based machine learning, deep learning, dimension reduction method, ensemble learning, instance-based algorithm, regression analysis, Bayesian network, neural network, cluster analysis, reinforcement learning, or these techniques. Combinations of other technologies are possible.
  • These artificial intelligences analyze, for example, past abnormal data that has been accumulated, what kind of abnormal signal occurs under various conditions, and when a software system or a hardware system receives a specific abnormal signal.
  • a learning model may be constructed by learning how it works.
  • optimal abnormal signal generation conditions for generating a specific abnormal state in the system to be verified are derived, and these generation conditions may be set as the signal generation table 1121. Good. With this, it is possible to automatically generate a condition that can optimally cause a specific abnormal state.
  • this process processes the signal (original signal) received from the hardware system or software system in order to verify the fault tolerance of the target system (software such as applications or hardware such as ECU). , Processing for generating an abnormal signal by processing based on the generation conditions shown in the signal generation table 1121 (see FIG. 3).
  • the target system software such as applications or hardware such as ECU.
  • this processing may be applied when a signal addressed to a specific software system is transmitted from the hardware side, or may be applied when a signal addressed to a specific hardware system is transmitted from the software side.
  • Good ie, whether the system to be verified is software or hardware is arbitrary).
  • a signal (original signal) addressed to a specific application (for example, application 1212 shown in FIG. 1) or ECU (for example, ECU 1000 shown in FIG. 1) is generated in the ECU or application.
  • this signal may be a signal generated in the ECU for the application or a signal generated in the application for the ECU.
  • this signal corresponds to a request signal or the like that causes the image processing application operating in the virtual environment to process the image data acquired by the camera.
  • the signal transfer unit (for example, the signal transfer unit 1110 shown in FIG. 1) captures the signal generated in step 2000.
  • “capturing” means capturing a signal and temporarily storing it in the signal transfer unit.
  • step 2002 the signal transfer unit confirms whether or not the abnormal signal generation unit (for example, the abnormal signal generation unit 1120 shown in FIG. 1) is being activated (whether the abnormal signal generation function is turned on).
  • the process proceeds to step 2003, and the signal transfer unit transfers the signal as it is (without processing) to the destination.
  • the process proceeds to step 2004.
  • step 2004, the signal transfer unit extracts a signal ID for identifying the signal from the signal received in step 2001 (for example, metadata associated with the signal).
  • step 2005 the signal transfer unit confirms 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 ID extracted from the signal in step 2004 with the input signal ID 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 as it is (without processing) to the destination. .. 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.
  • the signal transfer unit acquires the status information of the system that is the transmission destination of the signal.
  • this state information is information indicating the state (normal, abnormal, etc.) of the system that receives the target signal.
  • 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 may receive a notification of the state information from the transmission destination.
  • the status information of the transmission destination may be read by accessing the management table of the status information stored in, and the acquisition method of the status information is not particularly limited.
  • step 2007, whether the state information acquired in step 2006 matches the state information described in the signal generation table (for example, the signal generation table 1121 shown in FIG. 2) (that is, the system that is the transmission destination is the target signal). Is in a proper condition to receive the). If the state information obtained in step 2006 does not match the state information described for the target signal in the signal generation table, the process proceeds to step 2003, and the signal transfer unit processes the signal (without processing it). ) Directly transfer to the destination system. 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.
  • the state information acquired in step 2006 matches the state information described for the target signal in the signal generation table
  • the abnormal signal generation unit processes the received signal based on the signal generation table to generate the abnormal signal.
  • the process of generating an abnormal signal means that the abnormal signal generation unit performs processing corresponding to the signal described in the signal generation table on the signal received in step 2001, and processes the processed signal. It means to create it as an abnormal signal.
  • the abnormal signal generation unit performs a process of applying the signal timing condition, the signal data change, and/or the signal ID change described in the signal generation table to the target signal.
  • the abnormal signal generation unit includes, for example, generating an abnormal signal by replacing a predetermined portion of the data string of the received original signal with a predetermined value.
  • the abnormal signal generation unit when the signal transfer unit receives the signal of the input signal ID “1”, the abnormal signal generation unit outputs 2 signals to the signal as described in the signal generation table.
  • An abnormal signal is generated by applying a nanosecond delay as a signal timing change (note that in the case of an input signal ID “1”, there is no change in the output signal ID and signal data, so the process for generating an abnormal signal is Only change the signal timing).
  • the generation of the abnormal signal by changing the timing of the received original signal has been described as an example, the present invention is not limited to this, and the data is changed with respect to the original signal, the output signal ID is changed, and the like. Processing other than the timing change may be performed.
  • the process proceeds to step 2003, and the signal transfer unit transmits the abnormal signal to the destination (for example, Transfer to the test execution environment such as application, supervisor, or hardware device.
  • the test execution environment such as application, supervisor, or hardware device.
  • a data log for monitoring the influence of the abnormal signal for example, the data log 1213 of the application shown in FIG. 1, the data log 1211 of the supervisor, and the hypervisor.
  • Data log 1130 is started.
  • These data logs may be a diagnostic program that monitors and records the operation of each layer of the abnormal signal. For example, these data logs show changes in the resource usage rate and I/O communication volume of applications or supervisors, signal timing, changes in hardware device temperature, voltage, performance, etc., types of abnormal signals, and desired simulations. Depending on the failure, various parameters may be recorded that quantify the effect of the abnormal signal.
  • the data log analysis unit determines whether the data log information (that is, the application data log 1213, the supervisor data log 1211, and the hypervisor data log 1130). Information).
  • the data log analysis unit is a functional unit that analyzes the influence of the abnormal signal based on the information recorded in each data log.
  • the data log analysis unit may, for example, continuously acquire the information of each data log when the data log of each layer is started, and the data log analysis unit may periodically acquire the information of the data log every predetermined period (for example, 1 minute). Information may be acquired.
  • the data log analysis unit analyzes the information of each data log acquired at step 2010.
  • analyze in order to evaluate the influence that the abnormal signal has given to each layer (application layer, supervisor layer, hypervisor layer, hardware layer, etc.), analyze the information of each data log and It means identifying patterns and relationships.
  • the data log analysis unit compares the parameters such as the resource usage rate, the signal timing, the temperature of the hardware device, the voltage, and the performance acquired from the data log with a predetermined threshold value, so that the abnormal signal fails at the destination. It is possible to quantify and verify whether or not the failure has occurred and the size of the failure.
  • the hypervisor provides a new anomaly in response to a previous anomalous signal (eg, the first anomaly signal and/or a previously transmitted past signal).
  • a signal for example, the second abnormal signal
  • the second abnormal signal may be generated.
  • the second abnormal signal may be generated and transferred according to the operation result.
  • this process may be applied when a signal destined for a specific software system is transmitted from the hardware side, and is applied when a signal destined for a specific hardware system is transmitted from the software side. May be. That is, whether the system to be verified is software or hardware is arbitrary.
  • step 3000 the signal transfer unit confirms whether or not the abnormal signal generation unit (for example, the abnormal signal generation unit 1120 shown in FIG. 1) is being activated.
  • the abnormal signal generation unit for example, the abnormal signal generation unit 1120 shown in FIG. 1
  • starting means that the abnormal signal generation function is turned on. If the abnormal signal generator has not been activated, this process ends. On the other hand, if the abnormal signal generation unit is being activated, the process proceeds to step 3001.
  • the signal transfer unit acquires status information of the system to which the signal is transmitted.
  • this state information is information indicating the state (normal, abnormal, etc.) of the system that receives the target signal.
  • the signal transfer unit may send a status information acquisition request to the system that is the step verification target and may receive a notification of the status information from the verification target, and the status stored in a predetermined memory address may be received.
  • the state information of the verification target may be read by accessing the information management table or the like, and the acquisition method of the state information is not particularly limited.
  • the signal transfer unit may continuously monitor the status information of the system to be verified, or may regularly acquire the status information of the system every predetermined period (for example, 1 minute).
  • step 3002 the signal transfer unit confirms whether the state information acquired in step 3001 matches the state information described in the signal generation table 1121 (see FIG. 3). That is, the signal transfer unit confirms whether or not the system to be verified is in an appropriate state for receiving 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 and the state information described for the target signal in the signal generation table match, the process proceeds to step 3003.
  • the abnormal signal generation unit (for example, the abnormal signal generation unit 1120 shown in FIG. 1) generates an abnormal signal based on the generation condition 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 system to be verified without using the original signal from the software system or the hardware system.
  • the second embodiment differs from the abnormal signal generation processing of the first embodiment in that the abnormal signal is generated according to the state of the system to be verified without depending on the original signal.
  • the abnormal signal generation unit causes the signal timing condition, the signal data condition, and the signal data condition described in the signal generation table, and / Or generate an abnormal signal according to the condition of the signal ID.
  • the signal transfer unit acquires the state information of the system to be verified, and as a result, the system to be verified indicates “no signal within 10 nanoseconds”.
  • the abnormal signal generation unit When detecting the state, the abnormal signal generation unit generates the abnormal signal having the output signal ID “6” including the content of the memory address 0x101 as described in the signal generation table.
  • the present invention is not limited to this, and the abnormal signal is generated according to another condition such as a condition regarding the timing of the abnormal signal. It is also possible to do so.
  • the process proceeds to step 3006, and the signal transfer unit transfers the abnormal signal to the system to be verified.
  • the abnormal signal is transferred to the system to be verified, and at the same time, a data log for monitoring the influence of the abnormal signal (for example, the data log 1213 of the application shown in FIG. 1, the data log 1211 of the supervisor, and The data log 1130 of the hypervisor is activated.
  • a data log for monitoring the influence of the abnormal signal for example, the data log 1213 of the application shown in FIG. 1, the data log 1211 of the supervisor, and The data log 1130 of the hypervisor is activated.
  • These data logs may be a diagnostic program that monitors the operation of each layer of the abnormal signal and records the operation result. For example, these data logs show changes in the resource usage rate and I/O communication volume of applications or supervisors, signal timing, changes in hardware device temperature, voltage, performance, etc., types of abnormal signals and desired simulations. Depending on the failure, various parameters may be recorded to quantify the effect of the abnormal signal.
  • the data log analysis unit uses the data log information, that is, the application data log 1213, the supervisor data log 1211, and the hypervisor data log 1130. Get information.
  • the data log analysis unit is a functional unit that analyzes the influence of the abnormal signal based on the information recorded in each data log.
  • the data log analysis unit may, for example, continuously acquire the information of each data log when the data log of each layer is started, and the data log analysis unit may periodically acquire the information of the data log every predetermined period (for example, 1 minute). Information may be acquired.
  • the data log analysis unit analyzes the information of each data log acquired at step 3005.
  • analyze in order to evaluate the influence that the abnormal signal has given to each layer (application layer, supervisor layer, hypervisor layer, hardware layer, etc.), analyze the information of each data log and It means identifying patterns and relationships.
  • the data log analysis unit compares the parameters such as the resource usage rate, the signal timing, the temperature of the hardware device, the voltage, and the performance acquired from the data log with a predetermined threshold value, so that the abnormal signal fails at the destination. It is possible to quantify and verify whether or not the failure has occurred and the size of the failure.
  • the present invention is not limited to this. Instead, a configuration is possible in which an abnormal signal that causes the hardware system to a specific abnormal state is generated.
  • One of specific examples of generating an abnormal signal that causes a hardware system to have a specific abnormal state is an image capturing unit, an automatic driving unit, an engine throttle unit, a power steering unit, a telematics unit, a brake control unit, and advanced driving support. It is conceivable that the car is equipped with a unit. In such an automobile, there is a need to verify how one functional unit is affected when another functional unit fails. Therefore, according to the abnormal signal generating means according to the present invention, the signal from one functional unit is processed based on the above-described signal generation table and the generated abnormal signal is transferred to another functional unit. It is possible to verify the operation when the functional part of is in a specific abnormal state.
  • the video signal acquired by the video shooting unit is processed to introduce noise into a part of the video (a process of deleting a part of the video, blurring it, or replacing it with a blurry image).
  • the other functional unit operates when the image capturing unit fails (for example, the telematics unit notifies the driver at what timing) Whether the automatic driving unit switches to manual driving, the brake control unit switches to manual driving, or whether the engine throttle unit controls acceleration of the vehicle).
  • the reaction speed of the telematics unit (up to the notification of the abnormality to the driver) Time) can be verified.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

自動車等に搭載されるハードウエアシステム及びソフトウエアシステムの耐故障性を検証するためには、コストの高いシミュレーションを導入するか、検証対象のハードウエアの直接的変更が必要となり、耐故障性の検証のための負担の軽減が求められている。本発明に係る車両用電車制御装置に含まれるハイパーバイザ１１００は、信号生成に関する条件を定める信号生成テーブル１１２１に基づき、模擬的に故障を引き起こす異常信号を生成し、当該異常信号をテスト用実行環境となる検証対象のシステムに転送することで、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を用いることなく、自動車に搭載されるシステムが故障した場合の影響を検証することができる。

Description

車両用電子制御装置、異常信号生成方法、異常信号生成プログラム
　本発明は、車両用電子制御装置、異常信号生成方法、異常信号生成プログラムに関する。
　ハードウエアとソフトウエアの統合化が進む中、ソフトウエアとハードウエアとの互換性を検証することが重要である。特に、多様なセンサ等のハードウエアシステム及び当該センサのロジックを制御するアプリ等のソフトウエアシステムが搭載される自動車では、車両に関する機能安全規格を満たし、安全性を確保するために、搭載されるハードウエアシステムまたはソフトウエアシステムが故障した場合に、自動車全体にどのような影響が与えられるかを検証し、システム間のやり取りに生じる信号を制御する手法が求められている。
　これに対して、特開２０１３－１６１２９９号公報（特許文献１）には、「複数のプログラムが記憶されたプログラム記憶手段１３と、前記プログラムを実行する１つ以上の演算手段１１と、外部の回路と通信可能な複数のインタフェース２０と、を有する情報処理装置１００であって、前記プログラムがアクセス可能な前記インタフェースが登録されたインタフェース登録テーブル３４と、前記インタフェースにアクセス要求した前記プログラムが、前記インタフェースにアクセスすることが許可されている場合、前記プログラムの代わりに前記インタフェースにアクセスするアクセス制御手段３３と、を有する」が記載されている。
特開２０１３－１６１２９９号公報
　上記の特許文献１においては、自動車に搭載されるＥＣＵ等の制御装置と、ハイパーバイザ上に動作するアプリケーションとのI/Oを制御する情報処理装置が記載されている。特許文献１に係る発明によれば、あるアプリケーションが特定のI/Oポート（例えば、ＥＣＵのI/Oポート）にアクセスする命令を実行し、当該命令に対してアクセス違反が検出された場合には、ハイパーバイザがアプリケーションの代わりに当該命令を実行することにより、アクセス違反を防止することができる。
　しかし、特許文献１では、自動車に搭載されるハードウエアシステムまたはソフトウエアシステムの故障をシミュレート及び評価することが検討されていない。このため、ハードウエアまたはソフトウエアの動作を検証するためには、ＨＩＬＳ（Hardware In the Loop Simulation）やｖＨＩＬＳ（Virtual Hardware in the Loop Simulation）等のシミュレーション手段、あるいはハードウエアの直接的な変更が必要となる。しかし、これらのシミュレーション手段は導入コストが高く、ハードウエアの直接的な変更では、速いペースで進化していく車載用デバイスのニーズに対応することが難しい。また、自動車に搭載されるハードウエア及びソフトウエアシステムの耐故障性検証のニーズに充分応えられてないといった課題がある。
　そこで、本発明は、コストの高いシミュレーション手段の導入や検証対象のシステムの変更を行うことなく、自動車に搭載されるシステムが故障した場合の影響を検証する手段を提供することを目的とする。
　上記の課題を解決するために、代表的な本発明の異常信号生成ハイパーバイザを含む車両用電車制御装置の一つは、ハイパーバイザを含む車両用電子制御装置であって、前記ハイパーバイザは、異常信号生成部と、信号転送部とを備え、前記異常信号生成部は、信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を生成し、前記信号転送部は、前記異常信号をテスト用実行環境に転送する。
　本発明によれば、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を行うことなく、自動車に搭載されるシステムが故障した場合の影響を検証することができる。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
図１は、本発明に係る車両用電子制御装置の一例を示すブロック図である。 図２は、本発明に係る分散型システムの一例を示す図である。 図３は、本発明に係る信号生成テーブルの一例を示す図である。 図４は、本発明に係る実施例１において、ハードウエアシステム又はソフトウエアシステムから受信した信号を用いて異常信号を生成する処理の一例を示す図である。 図５は、本発明に係る実施例１において、ハードウエアシステム又はソフトウエアシステムの状態情報を用いて異常信号を生成する処理の一例を示す図である。
　以下、図面を参照して、本発明の実施形態について説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。
　［実施例１の概要］
　本発明では、自動車に搭載されるハードウエアシステム（Electric Control Unit、映像撮影システム、ブレーキ制御システム等）と、ソフトウエアシステム（Operating System等のスーパーバイザ及びその上に実装されるアプリ）との間のやり取り（信号の通信など）を制御するハイパーバイザが用いられる。一般的には、ハードウエアシステムやソフトウエアシステムにおいて生じる信号は、信号の発生源から直接に送信先に送信される。しかし、本発明では、特定のアプリ又はハードウエア宛に送信される信号は、送信先に到達する前に、ハイパーバイザで一旦捕捉され、予め用意される信号生成テーブルに基づいて異常信号が生成される。このように、信号生成テーブルに基づいて異常信号が送信先（テスト用実行環境となる検証対象のシステム）に転送されることで、送信先のシステムにおいて所望の故障を模擬的にシミュレートすることができる。また、異常信号を送信先に転送した後、宛先のシステムにおける動作の結果（システムがどう反応したか）をデータログ等で記録することで、異常信号がシステムに与えた影響を評価・検証することができる。これにより、自動車に搭載されるハードウエアシステムとソフトウエアシステムの互換性を、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を用いることなく、検証することが可能となる。
　まず、図１を参照して、本発明に係る車両用電子制御装置１３００の構成について説明する。車両用電子制御装置１３００とは、自動車における様々な機能を総合的に制御し、車両に搭載されるセンサ等のハードウエアシステム及び当該ハードウエアシステムのロジックを制御するアプリ等のソフトウエアシステムを管理するシステムである。図１に示されるように、車両用電子制御装置１３００は、仮想化環境１２００と、ハイパーバイザ１１００と、ＥＣＵ１０００とを含む。
　ＥＣＵ（Electronic Control Unit）１０００とは、エンジン、モーター、メーター、トランスミッション、ブレーキ、エアバッグ、ランプ、パワーステアリング、パワーウィンドウ、カーエアコン、電子キーの車両側受信部、カーオーディオ、カーナビゲーションシステム、カメラ、温度計、各種センサ等の機能を制御する補助装置である。図１に示されるように、ＥＣＵ１０００は、複数のＣＰＵ１０１０、１０１５と、メモリ１０３０と、ハードウエア信号を発信するハードウエア信号転送部１０２０とを含む。
　なお、図１では、ＣＰＵを二つ有し、メモリとハードウエア信号転送部を１つずつ有するＥＣＵ１０００を示したが、本発明はそれに限定されず、各部品の数を適宜に変更してもよい。
　次に、ハイパーバイザ１１００について説明する。
　一般的に、自動車などに搭載される電子処理システムは、RAMやCPUなどのハードウエア資源を提供するハードウエア層と、一つまたは複数の仮想機械の稼働を管理するハイパーバイザ層と、それぞれの仮想機械のOS（Operating System）を実装するスーパーバイザ層と、アプリケーションソフトウェアが稼働するアプリケーション層からなる。そして、ハイパーバイザは、仮想機械を制御する上位の制御プログラムとして、下位の層で実装されるスーパーバイザやアプリケーションソフトウェアにリソースの分配などを行う。そして、本発明におけるハイパーバイザは、外部の装置とのコミュニケーションを統括する。つまり、本発明におけるハイパーバイザ１１００は、ＥＣＵ１０００（すなわち、ハードウエア層）と、後述する仮想化環境１２００（すなわち、スーパーバイザ層及びアプリケーション層）の稼働を管理し、ＥＣＵ１０００と仮想化環境１２００との間におけるコミュニケーション（信号のやり取りなど）を制御するものである。
　図１に示されるように、ハイパーバイザ１１００は、ＥＣＵ１０００及び仮想化環境１２００から生じる信号を送受信する信号転送部１１１０と、後述する処理によって異常信号（所望の故障を検証対象のシステムにおいて模擬的に引き起こす信号）を生成する異常信号生成部１１２０と、異常信号の生成条件を示す信号生成テーブル１１２１と、信号のハイパーバイザにおける動作や生成結果を記録するデータログ１１３０とを含む。
　また、図１に示されるように、信号転送部１１１０は、異常信号生成部１１２０と通信可能であり、異常信号生成部１１２０は、信号転送部１１１０で受信される信号と、信号生成テーブル１１２１とに基づいて、異常信号を生成する。ハイパーバイザは、ＥＣＵ１０００におけるＣＰＵ１０１０、１０１５やメモリ１０３０などのリソースを用いて、仮想化環境１２００を構成する。
　なお、図１では、ＥＣＵ１０００が１つのハードウエア信号転送部１０２０を備える場合を示しているが、ハードウエア信号転送部１０２０を複数備えられてもよい。そして、ハードウエア信号転送部１０２０が複数備えられている場合には、それぞれのハードウエア信号転送部に対応する信号転送部ｇａ信号転送部１１１０内に備えられていてもよい。
　仮想化環境１２００とは、ハイパーバイザ１１００によって構成され、仮想機械やアプリケーションを互いに独立した状態で実行させる論理空間である。図１に示されるように、仮想化環境１２００内には、１つまたは複数のスーパーバイザ１２１０が実装される。このスーパーバイザ１２１０は、後述するアプリケーションにリソースを与え、当該アプリケーションの動作を管理するものであり、例えば、WindowsやLinux等のＯＳ（オペレーティングシステム）であってもよい。スーパーバイザ１２１０には、スーパーバイザ上で稼働するアプリケーションのリソース使用率や動作の結果を記録するデータログ１２１１を備える。上述したように、スーパーバイザ１２１０の上では、アプリケーション（以下、「アプリ」という）１２１２が実装される。そして、アプリ１２１２は、車載のセンサ等のハードウエアの制御を行うプログラムであり、例えば、カメラ等のセンサによって撮像される画像を処理する画像処理プログラムであってもよい。
　また、上述したように、アプリ１２１２は、ハイパーバイザ１１００の信号転送部１１１０を介して、ＥＣＵ１０００に信号を送信したり、ＥＣＵから信号を受信したりする。さらに、アプリ１２１２は、アプリ内におけるリソース使用率や動作の結果を記録するデータログ１２１３を備える。
　図１に示されるデータログ分析部１４００は、車両用電子制御装置１３００内に備えられていてもよく、ネットワークを介して車両用電子制御装置１３００と通信を行う遠隔のデバイスに備えられていてもよい。ここで、データログ分析部１４００とは、ハイパーバイザのデータログ１１３０と、スーパーバイザ１２１０のデータログ１２１１と、アプリ１２１２のデータログ１２１３のデータを取得し、後述する処理によって生成される異常信号の動作結果を分析するものである。データログ分析部１４００は、例えば、ＥＣＵ１０００から発信された信号に基づいて生成した異常信号を信号転送部１１１０によってアプリ１２１２に送信した場合に、ハイパーバイザ、スーパーバイザ、及びアプリのそれぞれにおける影響を評価するために、それぞれのデータログの情報を取得して分析してもよい。
　次に、図１に示される車両用電子制御装置１３００の具体例を説明する。ハードウエア信号転送部１０２０がIntelのＡＰＩＣ（登録商標），AMDのAVID（登録商標）、ＡＲＭのGIC（登録商標）、又はＡＲＭのＡＭＢＡ（登録商標）仕様のデバイス等として構成された場合には、信号転送部１１１０は、ハードウエア信号転送部１０２０から転送されるハードウエア信号をハイパーバイザで捕捉する構成にしてもよい。ここで説明した例以外にも、車両用電子制御装置１３００を用いる様々な具体例は可能である。
　次に、図２を参照して、本発明に係る分散型システム１００の構成の一例について説明する。以上では、本発明に係る仮想化環境、ハイパーバイザ、及びＥＣＵが一体となる車両用電子制御装置について説明したが、本発明はそれに限定されず、上述した車両用電子制御装置の構成要素がお互いに離れており、インターネット等のネットワークにより接続される構成も可能である。
　図２に示されるように、分散型システム１００は、中央サーバ１５０と、ＥＣＵ１１８、１１９をそれぞれ搭載する自動車１２０、１２１と、ネットワーク１７５とからなる。中央サーバ１５０は、ネットワーク１７５を介して自動車１２０、１２１と接続される。
　中央サーバ１５０は、仮想化環境１１０と、ハイパーバイザ１１２とを含む検証部１０４と、ＣＰＵ１１３と、メモリ１１４と、記憶部１１５と、通信部１１６とを含むリソース管理部１０６とからなる。
　中央サーバ１５０とは、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエアシステム）の耐故障性を検証するために、特定のエラーや故障を引き起こす異常信号の影響を検証するテスト用実行環境１１１を提供するサーバ装置である。このテスト用実行環境１１１とは、異常信号を模擬的にシミュレートし、当該信号の動作結果や影響を検証・分析するための空間である。
　なお、本実施例では、一例として、テスト用実行環境１１１が仮想化環境において作成される論理空間を説明するが、テスト用実行環境１１１はこれに限定されず、特定のハードウエアデバイスとしてもよい。例えば、テスト用実行環境１１１は、異常信号の動作・影響を検証するために予め設定されたＥＣＵ、カメラ、自動運転システム、ブレーキ制御部等のハードウエアであってもよい。
　中央サーバ１５０のハイパーバイザ１１２は、ＣＰＵ１１３、メモリ１１４、及び記憶部１１５の物理リソースを用いて、テスト用実行環境１１１を含む仮想化環境１１０を作成する。また、ハイパーバイザ１１２は、上述したように、異常信号生成部１１７を含んでいる。この異常信号生成部１１７は、検証対象のシステムの耐故障性を検証するための異常信号を生成する機能部である。そして、異常信号生成部１１７は、例えば自動車１２０、１２１のＥＣＵ１１８、１１９からの信号（元信号）をネットワーク１７５を介して受信し、後述する異常信号生成テーブルに基づいて受信した信号を加工し、これをテスト用実行環境１１１に転送してもよい。あるいは、新たな異常信号を異常信号生成テーブルに基づいて生成して、この異常信号をＥＣＵ１１８又は１１９に転送してもよい。
　このような分散型システム１００を用いて、共通の仮想化環境下で、複数の検証対象のシステム（自動車等）に対応することにより、検証対象のシステムごとに仮想化環境を用意することが不要となり、システムのリソース（ＣＰＵ，メモリ、Ｉ/Ｏ、ストレージ）を大幅に節約することができる。
　次に、図３を参照して、本発明に係る信号生成テーブル１１２１の構成について説明する。信号生成テーブル１１２１は、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエアシステム）の耐故障性を検証するための異常信号（模擬故障信号）の生成条件を示すテーブルである。図３に示されるように、信号生成テーブル１１２１では、信号を識別する識別子である入力・出力信号ＩＤと、信号のタイミングに関する信号タイミング条件と、信号のデータに関する信号データ条件とが定められている、信号生成テーブル１１２１は手動でユーザによって作成されてもよく、後述するように、過去の異常データの分析に基づいて、人工知能によって自動的に作成されてもよい。
　図３に示されるように、信号生成テーブル１１２１は、信号転送部（例えば、図１における信号転送部１１１０）によって受信される信号のうち、加工対象の信号を識別する入力信号ＩＤ１１２２と、対象の信号を出力する際に割り当てる識別子を示す出力信号ＩＤ１１２３と、対象の信号に対して適用するタイミングの変更（遅延等）を示す信号タイミング条件１１２４と、対象の信号に対して適用するデータの変更を示す信号データ条件１１２５と、対象の信号を送信したシステムまたは対象の信号を受信するシステムの状態（異常、正常、信号を送受信してない期間等）を示す状態情報１１２６とを含む。この状態情報（「システム状態」ということもある）１１２６とは、例えば、信号の送信先となるアプリやスーパーバイザ（またはセンサ等のハードウエアデバイス）、のリソース使用率やI/Oデータ通信量が正常か否かを示す情報であってもよい。また、送信先となるソフトウエアシステム又はハードウエアシステムが正常でない場合には、当該システムの異常を示すエラーメッセージ（所定期間内には信号が届いていない、メモリ不足等）を示していてもよい。
　なお、説明を簡易にするため、入力識別ＩＤ１１２２が１桁の数字である場合を図３に示しているが、本発明はこれに限定されない。例えば、入力識別ＩＤ１１２２は、特定の信号を一意に識別する文字列であってもよく、特定の信号の種類を示すものであってもよい。信号生成テーブル１１２１が用いられる処理については後述する。
　上述したように、信号生成テーブル１１２１は、過去の異常データの分析に基づいて、人工知能によって自動的に生成されてもよい。ここで、人工知能とは、例えば、ルールベースの機械学習、ディープラーニング、次元削減方法、アンサンブル学習、インスタンスベースアルゴリズム、回帰分析、ベイジアンネットワーク、ニューラルネットワーク、クラスター分析、強化学習、又はこれらの技術と他の技術の組み合わせ等が上げられる。
　これらの人工知能は、例えば、蓄積された過去の異常データを分析し、様々な条件化でどのような異常信号が生じるか、ソフトウエアシステム又はハードウエアシステムが特定の異常信号を受信した場合にどのように作動するか等を学習し、学習モデルを構築してもよい。そして、構築した学習モデルを使用することで、検証対象となるシステムに特定の異常状態を発生させるための最適な異常信号生成条件を導出し、これらの生成条件を信号生成テーブル１１２１として定めてもよい。これにより、特定の異常状態を最適に引き起こせる条件を自動的に生成することができる。
　次に、図４を参照して、ハードウエアシステム又はソフトウエアシステムから受信した信号を用いて異常信号を生成する処理について説明する。上述したように、本処理は対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエア等）の耐故障性を検証するために、ハードウエアシステム又はソフトウエアシステムから受信した信号（元信号）を、信号生成テーブル１１２１（図３参照）に示される生成条件に基づいて加工し、異常信号を生成する処理である。
　なお、以下の説明では、アプリ宛の信号をＥＣＵ側から発信する例として説明するが、本発明はこれに限定されない。例えば、本処理は、特定のソフトウエアシステム宛の信号をハードウエア側から発信する場合に適用してもよく、特定のハードウエアシステム宛の信号をソフトウエア側から発信する場合に適用してもよい（すなわち、検証対象のシステムがソフトウエアかハードウエアかは任意である）。
　ステップ２０００では、特定のアプリ（例えば、図１に示されるアプリ１２１２）又はＥＣＵ（例えば、図１に示されるＥＣＵ１０００）宛の信号（元信号）がＥＣＵ又はアプリにおいて発生する。上述したように、この信号は、ＥＣＵにおいて発生したアプリ宛の信号であってもよいし、アプリにおいて発生したＥＣＵ向けの信号であってもよい。具体的には、この信号は、カメラによって取得された画像データを、仮想化環境で稼働する画像処理アプリに加工させる要求信号などが該当する。
　ステップ２００１では、信号転送部（例えば、図１に示される信号転送部１１１０）は、ステップ２０００で発生した信号を捕捉する。ここで、「捕捉」とは、信号を捉えて、信号転送部内に一時的に保存することを意味する。
　ステップ２００２では、信号転送部は、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）が起動中（異常信号生成機能がオンになっているか）か否かを確認する。異常信号生成部が起動中でない場合、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先に転送する。一方、異常信号生成部が起動中の場合、本処理はステップ２００４へと進む。
　ステップ２００４では、信号転送部は、ステップ２００１で受信した信号（例えば、信号に関連付けられているメタデータ）から、当該信号を識別する信号ＩＤを抽出する。
　ステップ２００５では、信号転送部は、受信した信号の信号ＩＤに該当する入力信号ＩＤが信号生成テーブル１１２１（図３参照）に存在するか否かを確認する。例えば、信号転送部は、ステップ２００４で信号から抽出した信号ＩＤを、信号生成テーブル１１２１に記録されている入力信号ＩＤと比較し、一致するものがあるかないかを判定する。抽出した信号ＩＤが信号生成テーブルに記録されている入力信号ＩＤに一致しない場合には、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先に転送する。一方、抽出した信号ＩＤが信号生成テーブルに記録されている入力信号ＩＤに一致する場合には、本処理はステップ２００６へと進む。
　ステップ２００６では、信号転送部は、信号の送信先となるシステムの状態情報を取得する。上述したように、この状態情報とは、対象の信号を受信するシステムの状態（正常、異常等）を示す情報である。例えば、信号転送部は、ステップ２００１で受信した信号の送信先となるシステムに対して状態情報の取得要求を送信し、当該送信先から状態情報の通知を受信してもよく、所定のメモリアドレスに保存されている状態情報の管理テーブル等をアクセスし、当該送信先の状態情報を読み込んでもよく、状態情報の取得方法は特に限定されない。
　ステップ２００７では、ステップ２００６で取得した状態情報が信号生成テーブル（例えば、図２示される信号生成テーブル１１２１）に記載されている状態情報に一致するか（すなわち、送信先となるシステムが対象の信号を受信するのに適切な状態となっているか）を確認する。ステップ２００６で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致しない場合には、本処理はステップ２００３に進み、信号転送部は当該信号を（加工せずに）そのまま送信先となるシステムに転送する。一方、ステップ２００６で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致する場合には、本処理はステップ２００８へと進む。
　ステップ２００８では、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）は、信号生成テーブルに基づいて、受信した信号を加工することにより、異常信号を生成する。ここで、異常信号を生成する処理とは、異常信号生成部が、ステップ２００１で受信した信号に対して、信号生成テーブルに記載されている、当該信号に対応する処理を施し、加工した信号を異常信号として作成することを意味する。より具体的には、異常信号生成部は、信号生成テーブルに記載されている信号タイミングの条件、信号データの変更、及び/又は信号ＩＤの変更を対象の信号に対して適用する処理を行う。この処理では、異常信号生成部は、例えば、受信した元信号のデータ列の所定箇所を所定の値に置換することで、異常信号を生成することを含む。図３を参照して一例を説明すると、信号転送部が入力信号ＩＤ「１」の信号を受信した場合、異常信号生成部は信号生成テーブルに記載されている通り、当該信号に対して、２ナノ秒の遅延を信号のタイミング変更として適用することで異常信号を生成する（なお、入力信号ＩＤ「１」の場合、出力信号ＩＤ及び信号データの変更がないため、異常信号を生成する処理は信号タイミングの変更のみとなる）。
　なお、受信した元信号のタイミングを変更することにより異常信号を生成することを一例として説明したが、本発明はこれに限定されず、元信号に対してデータの変更、出力信号ＩＤの変更など、タイミング変更以外の加工が行われていてもよい。異常信号の生成処理が終了すると（信号生成テーブルにおいて対象の信号について記載されている変更がすべて行われた時）、本処理はステップ２００３に進み、信号転送部は異常信号を送信先（例えば、テスト用実行環境となるアプリ、スーパーバイザ、又はハードウエアデバイス）へと転送する。
　ステップ２００９では、異常信号が送信先のシステムに転送されると同時に、異常信号の影響を監視するデータログ（例えば、図１に示されるアプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０）が起動する。これらのデータログは、異常信号の各層における動作を監視し、記録する診断プログラムであってもよい。例えば、これらのデータログは、アプリ又はスーパーバイザにおけるリソース使用率やI/O通信量等の変化、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等の変化、異常信号の種類や所望の模擬故障に応じて、異常信号の影響を定量化する様々なパラメータを記録してもよい。
　ステップ２０１０では、データログ分析部（例えば、図１に示されるデータログ分析部１４００）がデータログの情報（すなわち、アプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０の情報）を取得する。上述したように、データログ分析部とは、それぞれのデータログに記録されている情報に基づいて、異常信号の影響を分析する機能部である。データログ分析部は、例えば、各層のデータログが起動する際に、それぞれのデータログの情報を継続的に取得してもよく、所定の期間（例えば１分）ごとに定期的にデータログの情報を取得してもよい。
　ステップ２０１１では、データログ分析部は、ステップ２０１０で取得した各データログの情報を分析する。ここで、分析するとは、異常信号が各層（アプリ層、スーパーバイザ層、ハイパーバイザ層、ハードウエア層等）に与えた影響を評価するために、それぞれのデータログの情報を解析したり、データにおけるパターンや関係を特定したりすることを意味する。例えば、データログ分析部は、データログから取得したリソース使用率、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等のパラメータを所定の閾値に比較することで、異常信号が送信先において故障を引き起こしたか否か、故障の大きさなどを定量化し、検証することができる。
　以上、異常信号を生成し、当該異常信号の影響を検証する流れを一つの異常信号について説明したが、本処理は一つの異常信号の生成・検証後に終了する必要はない。本発明の態様の一つでは、本発明に係るハイパーバイザは、以前の異常信号（例えば、第１の異常信号及び/又はそれ以前に送信された過去の信号）の影響に応じて、新しい異常信号（例えば、第２の異常信号）を生成してもよい。例えば、検証対象となるアプリやハードウエアデバイスを特定の故障状態にしたい場合には、まずは第１異常信号を生成・転送し、第１異常信号の動作結果を評価した後（例えば、検証対象が所望の故障状態になったか否かの確認後）、この動作結果に応じた第２異常信号を生成・転送してもよい。このように、模擬故障を連鎖的に引き起こすことが可能となり、故障が連続する状況をシミュレートすることができる。
　［実施例２の概要］
　次に、図５を参照して、ハードウエアシステム又はソフトウエアシステムの状態情報を用いて異常信号を生成する処理について説明する。ここで説明する処理は、検証対象のシステム（アプリ等のソフトウエア又はＥＣＵ等のハードウエア）の耐故障性を検証するために、実施例１に説明したような元信号を用いずに、検証システムの状態情報を用いて所望の故障を引き起こす異常信号を（一から）生成する処理である。
　なお、実施例１に説明した処理と同じように、以下の説明では、アプリ宛の信号がＥＣＵ側で発信することを一例として説明するが、本発明はそれに限定されない。例えば、本処理は、特定のソフトウエアシステム宛の信号がハードウエア側から発信される場合に適用されてもよく、特定のハードウエアシステム宛の信号がソフトウエア側から発信される場合に適用されてもよい。すなわち、検証対象のシステムがソフトウエアかハードウエアかは任意である。
　まず、ステップ３０００では、信号転送部は、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）が起動中か否かを確認する。ここで、「起動中」とは、異常信号生成機能がオンになっていることを意味する。異常信号生成部が起動中でない場合、本処理は終了する。一方、異常信号生成部が起動中の場合、本処理はステップ３００１へと進む。
　次に、ステップ３００１では、信号転送部は、信号の送信先となるシステムの状態情報を取得する。上述したように、この状態情報とは、対象の信号を受信するシステムの状態（正常、異常等）を示す情報である。例えば、信号転送部は、ステップ検証対象となるシステムに対して状態情報の取得要求を送信し、当該検証対象から状態情報の通知を受信してもよく、所定のメモリアドレスに保存されている状態情報の管理テーブル等をアクセスし、当該検証対象の状態情報を読み込んでもよく、状態情報の取得方法は特に限定されない。ここでは、信号転送部は、検証対象となるシステムの状態情報を継続的に監視してもよく、所定の期間（例えば１分）ごとに定期的にシステムの状態情報を取得してもよい。
　次に、ステップ３００２では、信号転送部は、ステップ３００１で取得した状態情報が信号生成テーブル１１２１（図３参照）に記載されている状態情報に一致するかを確認する。すなわち、信号転送部は、検証対象となるシステムが対象の信号を受信するのに適切な状態となっているかを確認する。ステップ３００１で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致しない場合には、本処理は異常信号を生成せずに終了する。一方、ステップ３００１で取得した状態情報と、信号生成テーブルにおいて対象の信号について記載されている状態情報が一致する場合には、本処理はステップ３００３へと進む。
　次に、ステップ３００３では、異常信号生成部（例えば、図１に示される異常信号生成部１１２０）は、信号生成テーブルに記載されている生成条件に基づいて、異常信号を生成する。実施例２に係る異常信号生成は、ソフトウエアシステム又はハードウエアシステムからの元信号を用いずに、検証対象のシステムの状態に応じて新たな異常信号を生成する。実施例２は、元信号に依らずに、検証対象のシステムの状態に応じて異常信号を生成する点において実施例１の異常信号生成処理と異なる。ただし、実施例１に係る異常信号生成処理と同様に、実施例２に係る異常信号生成処理では、異常信号生成部は、信号生成テーブルにおいて記載される信号タイミングの条件、信号データの条件、及び/又は信号ＩＤの条件に従って異常信号を生成する。例えば、図３の信号生成テーブルを用いて一例を説明すると、信号転送部は、検証対象となるシステムの状態情報を取得した結果、検証対象となるシステムが「１０ナノ秒以内に信号なし」の状態であると検出した場合に、異常信号生成部は信号生成テーブルに記載されている通り、メモリアドレス０x１０１の内容を含み、出力信号IDが「６」の異常信号を生成する。
　ここでは、異常信号の内容に関する条件および出力信号ＩＤに関する条件がある場合を一例として説明したが、本発明はこれに限定されず、異常信号のタイミングに関する条件など、他の条件に従って異常信号を生成することも可能である。異常信号の生成処理が終了すると、本処理はステップ３００６に進み、信号転送部は異常信号を検証対象となるシステムへと転送する。
　ステップ３００４では、異常信号が検証対象となるシステムへと転送されると同時に、異常信号の影響を監視するデータログ（例えば、図１に示されるアプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０）が起動する。これらのデータログは、異常信号の各層における動作を監視し、動作結果を記録する診断プログラムであってもよい。例えば、これらのデータログは、アプリ又はスーパーバイザにおけるリソース使用率やI/O通信量等の変化、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等の変化、異常信号の種類や所望の模擬故障に応じて、異常信号の影響を定量化するために様々なパラメータを記録してもよい。
　ステップ３００５では、データログ分析部（例えば、図１に示されるデータログ分析部１４００）がデータログの情報、すなわち、アプリのデータログ１２１３、スーパーバイザのデータログ１２１１、及びハイパーバイザのデータログ１１３０の情報を取得する。上述したように、データログ分析部とは、それぞれのデータログに記録されている情報に基づいて、異常信号の影響を分析する機能部である。データログ分析部は、例えば、各層のデータログが起動する際に、それぞれのデータログの情報を継続的に取得してもよく、所定の期間（例えば１分）ごとに定期的にデータログの情報を取得してもよい。
　ステップ３００６では、データログ分析部は、ステップ３００５で取得した各データログの情報を分析する。ここで、分析するとは、異常信号が各層（アプリ層、スーパーバイザ層、ハイパーバイザ層、ハードウエア層等）に与えた影響を評価するために、それぞれのデータログの情報を解析したり、データにおけるパターンや関係を特定したりすることを意味する。例えば、データログ分析部は、データログから取得したリソース使用率、信号のタイミング、ハードウエアデバイスの温度、電圧、性能等のパラメータを所定の閾値に比較することで、異常信号が送信先において故障を引き起こしたか否か、故障の大きさなどを定量化し、検証することができる。
　以上の実施例１及び実施例２において説明した異常信号生成手段では、コストの高いシミュレーション手段の導入やハードウエアシステム及びソフトウエアシステムの変更を用いることなく、自動車に搭載されるシステムが故障した場合の影響を検証することができる。これにより、自動車に搭載されるシステムの耐故障性を検証するためのコスト（金銭的なコスト及びコンピュータリソースの使用率）を抑えることができ、また、ハイパーバイザを備える一般的なコンピュータで検証を行うことが可能となる。このため、耐故障性検証用のシステムの可用性が向上し、検証の効率が上がる効果が得られる。
変形例
　以上、ソフトウエアシステム（アプリ、スーパーバイザ等）の状態を示す状態情報を用いて、当該ソフトウエアシステムを検証するための異常信号を生成する例を主に説明したが、本発明はこれに限定されず、ハードウエアシステムを特定の異常状態にする異常信号を生成する構成も可能である。
　ハードウエアシステムを特定の異常状態にする異常信号を生成する具体例の一つとしては、映像撮影部、自動運転部、エンジンスロットル部、パワーステアリング部、テレマティクス部、ブレーキ制御部、及び先進運転支援部を搭載する自動車の場合が考えられる。このような自動車には、１つの機能部が故障した場合に、他の機能部がどのような影響を受けるかを検証するニーズがある。そこで、本発明に係る異常信号生成手段によれば、１つの機能部からの信号を、上述した信号生成テーブルに基づいて加工して生成した異常信号を他の機能部に転送することで、他の機能部が特定の異常状態になった場合の動作を検証することができる。
　例えば、上述した自動車の場合、映像撮影部が取得した映像信号を加工して、映像の一部にノイズを導入した（映像の一部を消したり、ぼやかしたり、不鮮明な画像で置き換えたりする処理を施した）異常信号を他の車載機能部に転送することで、映像撮影部が故障した場合に、他の機能部がどう作動するか（例えば、テレマティクス部がどのタイミングで運転者に通知するか、自動運転部がマニュアル運転に切り替えるか、ブレーキ制御部がマニュアル運転に切り替えるか、エンジンスロットル部が自動車の加速を制御するか）を検証することができる。
　また、ブレーキ制御部からテレマティクス部に送信されるブレーキ信号を異常信号に変換する（または異常のブレーキ信号を新たに生成する）ことで、テレマティクス部の反応速度（異常通知を運転者に知らせるまでの時間）を検証することができる。
　以上、本発明の実施の形態について説明したが、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
１０００　　ＥＣＵ
１１００　　ハイパーバイザ
１１１０　　信号転送部
１１２０　　異常信号生成部
１１２１　　信号生成テーブル
１２００　　仮想化環境
１３００　　車両用電子制御装置
１４００　　データログ分析部

Claims (11)

  1. 　ハイパーバイザを含む車両用電子制御装置であって、
    　前記ハイパーバイザは、
    　異常信号生成部と、信号転送部とを備え、
    　前記異常信号生成部は、
    　信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を生成し、
    　前記信号転送部は、
    　前記異常信号をテスト用実行環境に転送する、
    　ことを特徴とする車両用電子制御装置。
  2. 　請求項１に記載の車両用電子制御装置において、
    　前記異常信号生成部は、
    　前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから受信した元信号を、前記信号生成テーブルに基づいて加工することで、前記異常信号として生成する、
    　ことを特徴とする車両用電子制御装置。
  3. 　請求項２に記載の車両用電子制御装置において、
    　前記異常信号生成部は、前記元信号のデータ列の所定箇所を所定の値に置換することで、前記異常信号を生成する、
    　ことを特徴とする車両用電子制御装置。
  4. 　請求項１に記載の車両用電子制御装置において、
    　前記異常信号生成部は、
    　前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから取得するシステム状態を示す状態情報と、前記信号生成テーブルとに基づき、前記異常信号を生成する、
    　ことを特徴とする車両用電子制御装置。
  5. 　請求項１に記載の車両用電子制御装置において、
    　前記信号生成テーブルは、信号を識別する識別子と、信号のタイミングに関する信号タイミング条件と、信号のデータに関する信号データ条件と、が定められたテーブルである、
    　ことを特徴とする車両用電子制御装置。
  6. 　請求項１に記載の車両用電子制御装置において、
    　前記信号生成テーブルは、過去の異常データの分析に基づき、人工知能によって生成される、
    　ことを特徴とする車両用電子制御装置。
  7. 　請求項１に記載の車両用電子制御装置において、
    　前記ハイパーバイザは、第１の異常信号のテスト用実行環境における動作結果を記録するデータログを含み、
    　前記異常信号生成部は、前記データログに記録される前記第１の異常信号の前記動作結果に応じて、第２の異常信号を生成する、
    　ことを特徴とする車両用電子制御装置。
  8. 　請求項１に記載の車両用電子制御装置において、
    　前記信号転送部は、
    　前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムからの信号を受信し、
    　前記信号に含まれる信号識別子が、前記信号生成テーブルに予め記録された信号識別子に一致する場合、
    　前記異常信号生成部は、
    　前記信号識別子を前記信号生成テーブルに基づいて変換することで前記異常信号を生成する、
    　ことを特徴とする車両用電子制御装置。
  9. 　請求項１に記載の車両用電子制御装置において、
    　前記異常信号生成部は、
    　前記ハイパーバイザに連携しているソフトウエアシステムまたはハードウエアシステムから、当該システムのシステム状態を示す状態情報を取得し、
    　前記状態情報に示される前記システム状態が、前記信号生成テーブルに予め記録されたシステム状態に一致する場合、
    　前記信号生成テーブルに基づいて、前記異常信号を生成する、
    　ことを特徴とする車両用電子制御装置。
  10. 　ハイパーバイザを含む車両用電子制御装置における異常信号生成方法であって、
    　前記ハイパーバイザは、
    　異常信号生成部と、信号転送部とを備え、
    　前記異常信号生成方法は、
    　信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を前記異常信号生成部によって生成する工程と、
    　前記異常信号を前記信号転送部によってテスト用実行環境に転送する工程と、
    　を含む異常信号生成方法。
  11. 　ハイパーバイザを含む車両用電子制御装置における異常信号生成プログラムであって、
    　前記ハイパーバイザは、
    　異常信号生成部と、信号転送部とを備え、
    　前記異常信号生成プログラムは、
    　信号生成に関する条件を定める信号生成テーブルに基づき、異常信号を前記異常信号生成部によって生成する手順と、
    　前記異常信号を前記信号転送部によってテスト用実行環境に転送する手順と、
    　を前記車両用電子制御装置に実行させるための異常信号生成プログラム。
PCT/JP2019/045590 2018-12-20 2019-11-21 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム WO2020129531A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-237890 2018-12-20
JP2018237890A JP7204471B2 (ja) 2018-12-20 2018-12-20 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム

Publications (1)

Publication Number Publication Date
WO2020129531A1 true WO2020129531A1 (ja) 2020-06-25

Family

ID=71102110

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/045590 WO2020129531A1 (ja) 2018-12-20 2019-11-21 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム

Country Status (2)

Country Link
JP (1) JP7204471B2 (ja)
WO (1) WO2020129531A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010093431A (ja) * 2008-10-06 2010-04-22 Anritsu Engineering Kk 通信異常発生装置
JP2016213736A (ja) * 2015-05-12 2016-12-15 コハダ株式会社 試験プログラム及び試験装置
JP2018032392A (ja) * 2016-08-26 2018-03-01 株式会社日立製作所 複数のシミュレータを含むシミュレーション

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010093431A (ja) * 2008-10-06 2010-04-22 Anritsu Engineering Kk 通信異常発生装置
JP2016213736A (ja) * 2015-05-12 2016-12-15 コハダ株式会社 試験プログラム及び試験装置
JP2018032392A (ja) * 2016-08-26 2018-03-01 株式会社日立製作所 複数のシミュレータを含むシミュレーション

Also Published As

Publication number Publication date
JP2020101877A (ja) 2020-07-02
JP7204471B2 (ja) 2023-01-16

Similar Documents

Publication Publication Date Title
US11223525B2 (en) Gateway device, firmware update method, and recording medium
US10725762B2 (en) Gateway device, in-vehicle network system, and firmware update method
US11360762B2 (en) Information update apparatus and information update method
US10723361B2 (en) Monitoring apparatus, communication system, vehicle, monitoring method, and non-transitory storage medium
US10685124B2 (en) Evaluation apparatus, evaluation system, and evaluation method
JP5972303B2 (ja) 制御装置テストシステムのコンフィギュレーション設定の実行方法
US20180370459A1 (en) Apparatus and method for checking or monitoring in-vehicle control unit
DE102022122167A1 (de) Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung
JP7485106B2 (ja) 車両、車載制御装置、情報処理装置、車両用ネットワークシステム、アプリケーションプログラムの提供方法、及びプログラム
KR102154279B1 (ko) 차량용 디버깅 시스템의 동작 방법
Kenjić et al. Connectivity challenges in automotive solutions
WO2020129531A1 (ja) 車両用電子制御装置、異常信号生成方法、異常信号生成プログラム
DE102022122064A1 (de) System und verfahren für verbesserte ecu-ausfallerkennung in fahrzeugflotte
Devi et al. Bootloader design for advanced driver assistance system
Dhulipala Detection of injection attacks on in-vehicle network using data analytics
KR102595323B1 (ko) 차량용 임베디드 시스템을 위한 가상 ecu 검증 시스템및 방법
Werquin Automated reverse engineering and fuzzing of the can bus
Demmeler et al. Enabling rapid design exploration through virtual integration and simulation of fault tolerant automotive application
Bozic et al. A New Generation Automotive Tool Access Architecture for Remote in-Field Diagnosis
Han A new mapping algorithm for vehicle CAN BUS mapping based on correlation method
Devi et al. 3 Bootloader Design for
Pereira Testes Automáticos utilizando o Vector CANoe num Sensor Inercial
US20240134628A1 (en) Software Update Device, Software Update System, and Software Update Method
DE102022122162A1 (de) Eingebettete systemzeiterfassung bei automobilen
CN115761936A (zh) 改进的目标单元测试

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19899156

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19899156

Country of ref document: EP

Kind code of ref document: A1