KR102141287B1 - Fault injection test method and system for vehicle software based on autosar - Google Patents

Abstract

The defect test method of the AUTOSAR-based vehicle software includes monitoring whether a vehicle control unit (ECU) executes a task in a basic software (BSW) layer, and at least that is called before the vehicle control device executes the task in the BSW layer. Selecting a wrapper function for one function, a target function that is a defect injection target among the at least one function in which the vehicle control apparatus is executed in the BSW layer, runtime environment (RTE) layer, and software component (SWC) Checking, the vehicle control device passing the defect code for the target function to the wrapper function for the target function, and transmitting the result of the vehicle control device executing the specific defect to the host device. do.

Description

FAULT INJECTION TEST METHOD AND SYSTEM FOR VEHICLE SOFTWARE BASED ON AUTOSAR

The technique described below relates to a defect testing technique for vehicle software.

Recently produced vehicles use dozens to hundreds of ECUs. Accordingly, the size and complexity of the software that controls the electronic control unit (ECU) and the micro controller unit (MCU) has increased, and the need for standardization of software has emerged. The AUTOSAR (AUTomotive Open System ARchitecture) consortium was launched with the aim of reusing software, data formats, and development processes to reduce the burden of software development and secure the quality of software, mainly for vehicle OEMs and ECU manufacturers. AUTOSAR standardized the interface, data exchange method and development methodology.

ISO 26262 (International Standard for Automotive Functional Safety) is the adaptation of the functional safety standard IEC 61508 to automotive electrical/electronic systems. According to ISO 26262, in order to verify functional safety, a defect injection test must be performed in the vehicle software.

Methods for injecting defects into AUTOSAR-based vehicle software are largely divided into methods using external hardware devices and software-based methods. A method of using an external hardware device is a method of injecting defects using a debugger module. There are three main types of defect injection through software. The first is to use a function (trace hook) provided by AUTOSAR. The second way is to modify the code yourself. The third method is to create a wrapper function to inject defects.

Korean Patent Publication No. 10-2014-0008547

The method of using the hardware device has a disadvantage in that an interface for connecting the device is required, and since the entire execution is monitored through a debugger, overhead is large. The method of using the software also has the following problems. The method using the hooking function provided by AUTOSAR has a limitation that it cannot change the parameter or return value of the function. Since the method of directly modifying the code is that the software is changed, there is a risk that the operation before and after the injection of the defect is changed. The method using the wrapper function has a problem that various defect injections are possible and is difficult to implement. In addition, the defect injection method using software has a problem that it is difficult to monitor the defect injection result.

The technique described below is intended to provide a test technique capable of injecting defects into all AUTOSAR layers. The technique described below is intended to provide a test technique capable of monitoring the results after injection of a defect.

The defect test method of the AUTOSAR-based vehicle software includes monitoring whether a vehicle control unit (ECU) executes a task in a basic software (BSW) layer, and at least that is called before the vehicle control device executes the task in the BSW layer. Selecting a wrapper function for one function, a target function that is a defect injection target among the at least one function in which the vehicle control apparatus is executed in the BSW layer, runtime environment (RTE) layer, and software component (SWC) Checking, the vehicle control device passes a defect code for the target function to a wrapper function for the target function to execute a specific defect, and the vehicle control device executes the specific defect as a host device. It includes the step of transmitting.

The defect test system of AUTOSAR-based vehicle software monitors the task execution in the Basic Software (BSW) layer, and the BSW layer, the Runtime Environment (RTE) layer, and the SWC (SoftWare Component) function called before the task execution. A defect code is assigned to a wrapper function for a target function that is a defect injection target among the at least one function executed in a monitoring module, a BSW layer, a runtime environment (RTE) layer, and a software component (SWC) that selects a wrapper function for And a vehicle control device including a defect injection module to transmit and a result report module to generate test result information including whether the defect code is delivered, the defect code execution result, and call stack information after the defect code execution. The monitoring module, the defect injection module and the result reporting module are software modules and are located in the BSW layer.

The defect injection method using software enables defect injection in a real vehicle environment (or similar environment) without a separate hardware device. The technology described below can easily inject various defects without changing the code of AUTOSAR-based vehicle software using a wrapper function. The technique described below is easy to monitor and analyze the results after the injection of defects.

1 is an example of an AUTOSAR software hierarchy.
2 is an example of a vehicle control device for defect testing of AUTOSAR based software.
3 is an example of a defect test system of AUTOSAR based software.
4 is an example of a defect test process of AUTOSAR based software.

The technique described below may be applied to various changes and may have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the techniques described below to specific embodiments, and should be understood to include all changes, equivalents, or substitutes included in the spirit and scope of the techniques described below.

Terms such as first, second, A, B, etc. can be used to describe various components, but the components are not limited by the above terms, and only for distinguishing one component from other components Used only. For example, the first component may be referred to as a second component, and similarly, the second component may be referred to as a first component without departing from the scope of the technology described below. The term and/or includes a combination of a plurality of related described items or any one of a plurality of related described items.

In the terminology used herein, a singular expression should be understood to include a plurality of expressions unless clearly interpreted differently in the context, and terms such as “comprises” describe features, numbers, steps, operations, and components described. It is to be understood that it means that a part or a combination thereof is present, and does not exclude the presence or addition possibility of one or more other features or numbers, step operation components, parts or combinations thereof.

Prior to the detailed description of the drawings, it is intended to clarify that the division of components in this specification is only divided by the main functions of each component. That is, two or more components to be described below may be combined into one component, or one component may be divided into two or more for each subdivided function. In addition, each of the components to be described below may additionally perform some or all of the functions in charge of other components in addition to the main functions in charge thereof, and some of the main functions in charge of each of the components are different. Needless to say, it may also be carried out in a dedicated manner.

In addition, in performing the method or the method of operation, each process constituting the method may occur differently from the specified order unless a specific order is explicitly stated in the context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

The technique described below corresponds to a defect injection method for AUTOSAR-based vehicle software and a test technique using the defect injection. Hereinafter, related embodiments will be described with reference to the drawings.

1 is an example of an AUTOSAR software hierarchy. The vehicle includes multiple ECUs. Hereinafter, the ECU has the same meaning as the vehicle control device. 1 shows two ECUs (ECU1 and ECU2) connected by a bus as an example. The AUTOSAR software hierarchy will be described based on the ECU1 100.

The AUTOSAR software layer structure is largely divided into a basic software (BSW) layer 110, a runtime environment (RTE) layer 120, and an application layer (application software layer 130).

The BSW layer 110 is composed of standard software modules, and is grouped into lower layers according to the role of the module. The lower layers of the BSW layer include SRVL (SeRVice Layer), ECUAL, and MCAL (not shown).

MCAL is a layer required to control a microcontroller, and is simply a device driver. Therefore, it is independent of the ECU, but is dependent on the microcontroller, and consists of the memory, communication, and I/O standard drivers that can control the microcontroller. AUTOSAR MCAL uses the API (APplication Interface) name defined in AUTOSAR to control the device driver. Since AUTOSAR MCAL automatically generates source code using XML format, if you use separate parameters depending on the MCU vendor, you must be able to set separate parameters in XML format, and at the same time, API required for automatic extension of separate parameters Source code must be generated. MCAL is located above the Microcontroller in the AUTOSAR software layer.

ECUAL is an abstraction of the functions of the ECU. It is a layer composed of standard software that can access memory, communication, and I/O related to ECU control. It is independent of the microcontroller, but implemented independently of the ECU. Almost all standardized interfaces belonging to BSW are mapped to this layer.

The service layer is a layer that includes communication, service, and OS blocks. It abstracts the ECU and hardware to provide services for applications and BSW modules to their upper layers. Thus, it consists of standard software that provides services such as network services, memory management and bus communication services to the application layer.

The RTE layer 120 is located between the upper layer application layer 130 and the lower layer BSW layer 110 and has a middleware characteristic. The user software of the application layer 130 and the basic software of the BSW layer 110 are separated through this layer, and a connection between SWCs 131 and 132 belonging to the application layer 130, which is a higher layer, or a higher layer SWC ( 131, 132) to mediate the connection to the lower layer BSW (110). In fact, the RTE layer 120 controls the runtime behavior of the SWCs 131 and 132 belonging to the application layer 130 and code necessary for data exchange is implemented.

The RTE layer 120 is a layer implementing a concept called Virtual Functional Bus (VFB). Since all SWC-to-SWC communication or SWC-to-BSW communication is based on VFB, it means a separate state from ECU hardware. Because the RTE layer 120 serves as a VFB, AUTOSAR software is not hardware dependent and can be reused. The RTE layer 120 supports a Client/Server and Sender/Receiver communication model. The Client/Server model refers to a communication method in which the Client SWC requests a predefined service from the Server SWC and receives the result. In the Sender/Receiver model, Sender SWC distributes data, and Receiver SWC receives the distributed data. The RTE layer 120 is responsible for communication between all SWCs, and the SWCs may be in the same ECU or may exist in different ECUs.

The application layer 130 includes SWC (SoftWare Component). 1 shows two SWCs 131 and 132 as examples. Application software is developed in the form of SWC.

The software development process using AUTOSAR will be briefly described. AUTOSAR software development is divided into system setup and ECU setup. The system setting stage is SW-C specification (Component Description) describing the data type, interface and connection status of the SWC, ECU Resource Description describing the HW configuration of each ECU, and system constraints such as bus signal and topology. Write a description (Constraint Description). In each SW-C, task operation definition and trigger conditions for application SW implementation are defined. Next, SWC is mapped to each ECU and the network is designed to describe the system configuration description. The created file uses a template in XML format, and by using XML, data sharing and delivery can be standardized. The next step is to extract each ECU information from the system design specification, design the ECU, and design the task definition and assignment, RTE generation, BSW, etc., and describe the ECU design description. Generates AUTOSAR software module codes such as RTE, OS, and Communication along with application SW, and compiles and links to create executable files to implement ECU application services.

Hereinafter, a process of inserting and testing a defect for the generated AUTOSAR software will be described. 2 is an example of a vehicle control apparatus 200 for defect testing of AUTOSAR-based software. The vehicle control device 200 corresponds to the aforementioned ECU. The vehicle control device 200 includes an application layer, an RTE layer, and a BSW layer. Modules for injecting and monitoring defects using wrapper functions are located in the BSW layer.

The vehicle control device 200 includes a monitoring module 211, a defect injection module 212, and a result reporting module 213. The vehicle control device 200 includes a wrapper function pool. A wrapper function pool is a set of various wrapper functions. The wrapper function pool may include wrapper functions for various execution functions for task execution. Wrapper functions can be prepared in advance for individual execution functions. A wrapper function overwrites a specific function with its own function.

The monitoring module 211 is a module that is called before the task of the BSW layer is executed. At this time, the monitoring module 211 may select a wrapper function related to a specific defect from the wrapper function pool. The monitoring module 211 may select a wrapper function related to specific software from a wrapper function pool. The selected wrapper function is called before the corresponding function in the task is executed to monitor for defect injection. When a defect injection request is input, the monitoring module 211 checks whether a function executed in the current BSW layer 110, the RTE layer 120, and the application layer 130 is a defect injection target. Hereinafter, a function that is a target for injection of a defect is called a target function.

The defect injection module 212 performs a defect on the target function selected by the monitoring module 211. The defect injection module 212 selects a specific defect code and delivers it to the target function. In this process, the wrapper function overwrites the fault code for the target function. The type of the defect code may be at least one of a data error, a program flow error, an access error, a timing error, and an asymmetric error.

The result reporting module 213 generates information on whether a defect injection function is executed after a defect injection function is executed, a result of the defect injection execution, and an exception handling routine operation due to a defect injection, such as a call stack. The information generated by the result reporting module 213 is called test result information. The test result information provides information about the software operation after the defect injection, and through this, the defect injection result can be monitored. The test result information includes at least one of whether a defect code is delivered, a defect code execution result, and call stack information after executing the defect code. The result reporting module 213 may store log information corresponding to test result information. The test result information may be stored in a vehicle control device or a separate storage medium.

Furthermore, the result reporting module 213 may transmit test result information to a host device (host PC) as an external object. The result reporting module 213 may transmit test result information to a host device connected through vehicle communication using an agent having a communication function.

3 is an example of a defect test system 300 of AUTOSAR based software. The software defect test system 300 includes a vehicle control device 310 and a host device 320. The vehicle control device 310 is the same object as the vehicle control device 200 described with reference to FIG. 2. The vehicle control device 320 includes a monitoring module 311, a defect injection module 312, and a result reporting module 313. The operation of each module is as described in FIG. 2.

The monitoring module 311 selects a wrapper function for a function that is called before task execution in the BSW layer. The monitoring module 311 checks whether a function currently executed in all layers is a defect injection target. The monitoring module 311 transmits information on the target function, which is a target of the defect injection, to the defect injection module 312. The defect injection module 312 executes the defect code using a wrapper function for the target function. The defect injection module 312 transmits information on the timing of the defect injection to the result reporting module 313. The result reporting module 313 generates test result information by collecting whether the target function is executed, the execution result of the defective code, and call stack information after the execution of the defective code. The monitoring module 311, the defect injection module 312, and the result reporting module 313 may communicate with each other through independent channels in the BSW layer. Also, the monitoring module 311, the defect injection module 312, and the result reporting module 313 may communicate with modules or functions of other layers through the RTE layer.

The result reporting module 313 may transmit test result information to the host device 320 which is an external object connected through the agent. If connection with the host device 320 is not possible, the result reporting module 313 may store test result information as a log file.

The vehicle control device 310 and the host device 320 may exchange information through vehicle communication (CAN, etc.). The host device 320 may analyze test result information using the analysis program 321 installed therein. The analysis program 321 may analyze and analyze a defect location, defect data, a defect generation time, and a post-defect operation of the software to be verified to monitor and analyze the operation of the vehicle control device 310 after injection of the defect.

4 is an example of a defect test process 400 of AUTOSAR-based software. 4 illustrates the operation of the software defect test system 300 of FIG. 3 as an example.

The monitoring module 311 monitors the entire software execution in the BSW layer. The monitoring module 311 monitors the tasks of the BSW layer (401). The monitoring module 311 receives information on a function that is called before execution of the task (402).

The monitoring module 311 selects a wrapper function matching the function to be called (412). The monitoring module 311 may select a matching wrapper function from the wrapper function pool. The monitoring module 311 may select a specific wrapper function according to the type of task. The monitoring module 311 may select a specific wrapper function according to a function called for task execution or a type of function. The vehicle control device executes the selected wrapper function.

When the defect injection request is input, the monitoring module 311 checks whether a function executed in the current BSW layer, RTE layer, and application layer is a target function. The defect injection module 312 transfers information on the target function to the defect injection module 312 (421 ). The defect injection module 312 may select a defect code for the target function selected by the monitoring module 311. The defect injection module 312 may select different defect codes for each software unit or integration test step. In this case, a defect code for a specific function may also be selected from a previously prepared defect code pool. The type of the defect code may be at least one of a data error, a program flow error, an access error, a timing error, and an asymmetric error. The defect injection module 312 injects a defect code for the selected target function (423).

Thereafter, a target function is executed with a defect code in at least one of the BSW layer 110, the RTE layer 120, and the application layer 130 (431). The defect injection module 312 may transmit information on a defect injection time or a defect execution time to the result report module 313 (not shown).

The result reporting module 313 is a test result including at least one of information about whether a defect injection function is executed after a defect injection function is executed, a defect injection execution result, and an exception handling routine operation due to a defect injection, such as a call stack. Information is generated (442). The result reporting module 313 may store the test result information in the form of a log file (451). The result reporting module 313 may transmit the test result information to the host device 320 through vehicle communication using an agent for transmitting information (452).

The host device 320 may analyze test result information using an analysis program installed therein (461). The analysis program 321 may analyze and analyze a defect location, defect data, a defect generation time, and a post-defect operation of the software to be verified to monitor and analyze the operation of the vehicle control device 310 after injection of the defect.

In the laboratory environment, the defect test system of AUTOSAR-based software was implemented to monitor the experimental results. The experimental environment is as follows. Using the development evaluation board and PC to reproduce the ECU environment, the development evaluation board was used for defect injection, and the defect injection result was confirmed on the PC. In the defect injection test, the CPU clock corruption defect was injected among the types of Timing Error defects during the integration test between Runnable and Runnable in SWC.

The following is an example of the process of injecting a defect in the experiment process and confirming the result of the injected defect. The monitoring module 311 of FIG. 4 monitors the task execution and monitors the invocation of all tasks including Runnable A (ESCLPowerSupply()), which is a target for injection of defects (401). When the call function information (name and function type of the runnable to be injected with defects) is received to initiate the injection of a defect (411), select the wrapper function Runnable A'(Wrap_ESCLPowerSupply()) that matches the calling function from the library and select Runnable A )), so that Runnable A'(Wrap_ESCLPowerSupply()) is called (412). Afterwards, the defect injection module checks whether the target function is every time Runnable A'is called (421). If it is confirmed as the target function, the CPU clock register value, which is the fault to be injected, is received (422) and the CPU clock register value is changed before calling the original function Runnable A (ESCLPowerSupply()) from Runnable A'(Wrap_ESCLPowerSupply()). Whether the defect injection has been executed and the values necessary for confirming the result are generated (442) as test result information, and stored (451), and the test result information is transmitted to the PC (452). The PC analyzes the execution result received from the evaluation board for development (461).

In addition, the defect injection method for the AUTOSAR based vehicle software and the test method using the defect injection as described above may be implemented as a program (or application) including an executable algorithm that can be executed on a computer. The program may be stored and provided in a non-transitory computer readable medium.

The non-transitory readable medium means a medium that stores data semi-permanently and that can be read by a device, rather than a medium that stores data for a short time, such as registers, caches, and memory. Specifically, the various applications or programs described above may be stored and provided in a non-transitory readable medium such as a CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM, and the like.

The drawings attached to the present embodiment and the present specification merely show a part of the technical spirit included in the above-described technology, and are easily understood by those skilled in the art within the scope of the technical spirit included in the above-described technical specification and drawings. It will be apparent that all of the examples and specific examples that can be inferred are included in the scope of the above-described technology.

100: vehicle control device
110: BSW layer
120: RTE layer
130: application layer
200: vehicle control device
211: monitoring module
212: fault injection module
213: result reporting module
300: vehicle software defect test system
310: vehicle control device
311: monitoring module
312: fault injection module
313: result reporting module
320: host device
321: analysis program

Claims (12)

Monitoring whether a vehicle control unit (ECU) executes a task including a target function that is a target of defect injection in a basic software (BSW) layer;
In order for the vehicle control apparatus to execute the task in the BSW layer, selecting a wrapper function for at least one target function called before the task execution:
Monitoring whether the target function is executed by the vehicle control device in the BSW layer, the runtime environment (RTE) layer, and the software component (SWC), respectively;
Executing, by the vehicle control device, a defect code for the target function executed in any one of the BSW layer, the RTE layer, and the SWC to the wrapper function to execute a specific defect; And
And transmitting, by the vehicle control device, a result of executing the specific defect to a host device.
The vehicle control device selects the wrapper function for inducing a specific defect in the target function from a pool of previously provided wrapper functions,
The vehicle control device using the defect injection module located in the BSW layer defect test method of AUTOSAR-based vehicle software to deliver the defect code for the target function. delete According to claim 1,
The vehicle control device monitors whether the task is executed using a monitoring module located in the BSW layer, and selects the wrapper function. delete According to claim 1,
The type of the defect code is AUTOSAR-based vehicle software that is at least one of a data error, a program flow error, an access error, a timing error, and an asymmetric error. Defect testing method. According to claim 1,
The vehicle control apparatus further comprises generating test result information including whether the defect code is delivered, the defect code execution result, and the call stack information after executing the defect code. The method of claim 6,
The vehicle control device using the result reporting module located in the BSW layer, the defect test method of the AUTOSAR-based vehicle software to transmit the test result information to the host device via network communication. In the Basic Software (BSW) layer, a task execution including a target function targeted for defect injection is monitored, and for the task execution, a wrapper function is selected for at least one target function called before the task execution And, the BSW layer, RTE (Runtime Environment) layer and SWC (SoftWare Component) monitoring module for monitoring whether the target function is executed;
A defect injection module that delivers a defect code to the wrapper function for the target function executed in any one of the BSW layer, the RTE layer, and the SWC; And
And a vehicle control device including a result reporting module for generating test result information including whether the defect code is delivered, the defect code execution result, and the call stack information after the defect code execution,
The monitoring module, the defect injection module and the result reporting module are software modules, located in the BSW layer,
The monitoring module is a defect test system of AUTOSAR based vehicle software that selects the wrapper function for inducing a specific defect in the target function from a pool of previously provided wrapper functions. The method of claim 8,
The type of the defect code is AUTOSAR-based vehicle software that is at least one of a data error, a program flow error, an access error, a timing error, and an asymmetric error. Defect testing system. The method of claim 8,
The result reporting module is a defect test system of AUTOSAR based vehicle software that stores the test result information in the vehicle control device or a separate storage device. The method of claim 8,
The result reporting module is a defect test system of AUTOSAR-based vehicle software that transmits the test results to an external host device through vehicle communication through an agent. A computer-readable recording medium recording a program for executing a defect test method of the AUTOSAR-based vehicle software according to any one of claims 1, 3 and 5 to 7, in a computer.

Images