KR20200007133A - Method and apparatus for dinamically injecting fault for vehicle ecu software test - Google Patents

Abstract

The present invention relates to a method for dynamically injecting a defect for vehicle ECU software verification, an apparatus thereof, and a software verification system for a vehicle. According to one embodiment of the present invention, a host computer for verifying a software built in an electronic control device for a vehicle includes: an experimental model generation module configured to generate an experimental model for a verification target software built in the electronic control device; a call relationship analysis module configured to determine a function call relationship of the verification target software; a defect selection module configured to receive defect information to be injected into the verification target software from a user and generate defect selection information; a defect injection code generation module configured to generate a defect injection code based on the defect selection information and the determined function call relationship; and a first communication modem configured to transmit the defect selection information and the defect injection code to the electronic control device.

Description

Dynamic defect injection method and apparatus for vehicle ECU software verification {METHOD AND APPARATUS FOR DINAMICALLY INJECTING FAULT FOR VEHICLE ECU SOFTWARE TEST}

The present invention relates to a software verification method, and more particularly, to a dynamic defect injection method and apparatus for vehicle ECU software verification and a vehicle software verification system.

As expectations for vehicle stability are raised, European OEMs have released ISO26262, a functional safety standard for the automotive sector, to improve safety.

This standard was developed by applying IEC61508, a functional safety standard in the general-purpose electric / electronic field, to automobiles, and it is a risk that may impair the safety of the vehicle due to the failure of the electronic device over the entire life cycle from the product concept stage to disposal. It states that systematic analyzes and measures to address the risks should be effective.

The ISO26262 Part6 Software Level requires defect injection verification on a per unit / integration level for controllers above Automotive Safety Integrity Level (ASIL) C, which requires a verification method to inject defects at the software level.

Fault Injection Test is a method of artificially injecting faults into the system to identify faults and verify the robustness of the functional safety of the system.

Conventionally, defect injection methods such as injecting a defect only for a limited specific defect or injecting a defect into a system by using an external device (debugger, etc.) have been disclosed. However, these methods can detect various errors required for effective verification of the system. It is difficult to generate or use of an external device has a problem that it is difficult to secure the real-time of error verification for the controller.

Korean Patent Laid-Open Publication No. 10-2009-0068259 ("Dynamic Defect Insertion Device, Dynamic Defect Insertion Method, and Dynamic Defect Insertion System") proposes a method of dynamically injecting a defect into a hardware device (circuit device). There was an unsuitable problem.

In addition, Korean Patent Publication No. 10-2014-0008547 ("Error-based software test method and error-based software test system") relates to the error-based software test method and error-based software test system, but a plurality of defect injection program for defect injection There was a problem that should be generated.

The present invention has been devised to solve the above-mentioned problems of the prior art, and an object of the present invention is to provide a method and apparatus for dynamic defect injection for vehicle electronic control unit (ECU) software verification.

It is another object of the present invention to provide an effective and efficient dynamic defect injection method and apparatus at the software level for vehicle software through one defect injection program.

Technical problems to be achieved in the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

The present invention provides a dynamic defect injection method and apparatus for vehicle ECU software verification, and a vehicle software verification system.

According to an embodiment of the present disclosure, a host computer for verifying software mounted on an electronic control apparatus for a vehicle may include an experiment model generation module for generating an experimental model for verification software mounted on the electronic control apparatus and a function of the verification target software. A defect selection module that receives defect information to be injected into the verification target software from a user and a call relationship analysis module which determines a call relationship, and generates defect selection information based on the defect selection information and the determined function call relationship It may include a defect injection code generation module for generating a code, and a first communication modem for transmitting the defect selection information and the defect injection code to the electronic control device.

Here, the experimental model generation module determines a means for extracting a defect injection position, a means for applying a defect type to the extracted defect injection position, a means for setting a defect injection test to be automated, and determining whether the defect type can be automated. Means and means for setting a defect injection scenario according to a result of the determination and excluding the defect type that cannot be automated.

In addition, the defect injection position may be extracted by applying a mutation operator for each unit and integration test step of the verification target software.

The error type may include a data error, a program flow error, an access error, a timing error, and an asymmetric error.

In addition, the defect selection information may include information for identifying a position at which a defect is to be injected, information for identifying a type of defect to be injected, information about a number of defect injections, information about a parameter to be changed, a value of a register, and / or a variable. It may include at least one of.

The defect injection code may include at least one of a defect injection code for unit testing and a defect injection code for integration testing according to the defect selection information.

The call relationship analysis module may include a first user interface providing unit constituting a user interface screen for generating a project and a structure analysis unit analyzing a hierarchical structure such as files, tasks, and functions constituting the verification target software. And a call relationship analysis unit that analyzes a relationship between a call function and a call function based on the analyzed hierarchical structure.

In addition, the defect selection module may perform the unit test with a second user interface providing unit constituting a predetermined defect injection user interface screen for receiving input of information necessary for generating a defect injection code for each software unit test step and software integration test step from a user. It may include a unit test information collection unit for collecting the first information required for generating the defect injection code for the integrated test information collection unit for collecting the second information required for generating the defect injection code for the integration test.

Further, the first information may include information about a unit function or a global variable to inject a defect, information about a defect type to be injected and information about the number of defect injections, information about a parameter to be changed, a register, and / or a variable value. It may include at least one of.

Further, the second information may include information about the series of unit tests included in the integration test and their execution order, information about a location to inject defects, information about a type of defect to be injected, and information about the number of defect injections. It may include at least one of information about a value of a parameter, a register, and / or a variable to be changed.

An on-vehicle electronic control apparatus for verifying internally mounted software in connection with a host computer according to another embodiment of the present invention is a diagnostic module that receives a defect selection information and a combined injection code generated based on the defect selection information from the host computer. And a second controller for identifying the verification target software based on the defect selection information, for identifying a task and a function to inject a defect in the identified verification target software, and the task call monitoring module for monitoring the identified task call. The function call monitoring module may be configured to monitor a call of the identified function when the identified task call is detected, and a defect injection code execution module to execute the combined injection code when the call of the identified function is detected.

Here, the software mounted on the vehicle electronic device may be software executed on an AUTOSAR (AUTomotive Open System Architecture) standard platform.

In addition, the AUTOSAR standard platform includes a basic software layer disposed between a real-time environment layer and a hardware layer, wherein the diagnostic module, the task call monitoring module, the function call monitoring module and the fault injection code execution module are the basic software layer. It can be mounted on.

In addition, the diagnostic module may receive the defect selection information and the defect injection code through CAN communication.

The defect injection code may include at least one of a defect injection code for unit testing and a defect injection code for integration testing according to the defect selection information.

The vehicle software verification system according to another exemplary embodiment of the present disclosure analyzes a function call relationship of the software to be verified and generates a defect injection code based on defect selection information received from a user and the analyzed function call relationship. And receiving the defect selection information and the defect injection code through CAN communication from the host computer, and executing the defect injection code by monitoring the identified tasks and functions based on the defect selection information when executing the verification target software. It may include a vehicle electronic control device.

Here, the on-vehicle electronic control device includes a diagnostic module for receiving the defect selection information and the combined injection code from the host computer and a monitoring module for monitoring the invocation of the identified task and function based on the defect selection information and the identified module. When a call of a task and a function is detected, the module may include a defect injection code execution module that executes the combined injection code.

In addition, the verification target software may be software running on an AUTOSAR (AUTomotive Open System Architecture) standard platform.

In addition, the AUTOSAR standard platform may include a basic software layer disposed between a real-time environment layer and a hardware layer, and the diagnostic module, the monitoring module and the defect injection code execution module may be mounted in the basic software layer.

The host computer may further include an experimental model generation module for generating an experimental model for the verification target software mounted on the vehicle electronic control device, a call relationship analysis module for determining a function call relationship between the verification target software, and the user. A defect selection module that receives defect information to be injected into a verification target software and generates the defect selection information and a defect injection code generation module that generates the defect injection code based on the defect selection information and the determined function call relationship; It may include a first communication modem for transmitting the defect selection information and the defect injection code to the vehicle electronic control device through the CAN communication.

The above aspects of the present invention are merely some of the preferred embodiments of the present invention, and various embodiments in which the technical features of the present invention are reflected will be described in detail below by those skilled in the art. Can be derived and understood.

The effects on the method and apparatus according to the present invention are described as follows.

The present invention has the advantage of providing a dynamic defect injection method and apparatus for AUTOSAR-based vehicle software verification.

In addition, the present invention has the advantage of providing an effective and efficient dynamic defect injection method and apparatus at the software level for vehicle software through one defect injection program.

In addition, the present invention has the advantage of providing a dynamic defect injection method and apparatus capable of ensuring a high reliability for vehicle electronics.

In addition, the present invention has the advantage of providing a dynamic defect injection method and apparatus.

Effects obtained in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

1 is a view for explaining a vehicle software verification system structure according to an embodiment of the present invention.
2 is a block diagram illustrating a structure of a host computer according to an exemplary embodiment.
3 is a view for explaining an experimental model definition procedure in an experimental model definition module according to an embodiment of the present invention.
4 is a diagram illustrating an internal structure of a call relationship analysis module according to an embodiment of the present invention.
5 is a view for explaining the internal structure of a defect selection module according to an embodiment of the present invention.
6 is a view for explaining the structure of a vehicle electronic control apparatus according to an embodiment of the present invention.
7 illustrates a hierarchical structure of an AUTOSAR standard platform implemented in an electronic control apparatus for a vehicle according to an embodiment of the present disclosure.
8 is a flowchart illustrating a dynamic defect injection method for verifying software mounted on an electronic control apparatus for a vehicle according to an embodiment of the present disclosure.

Hereinafter, an apparatus and various methods to which embodiments of the present invention are applied will be described in more detail with reference to the accompanying drawings. The suffixes "module" and "unit" for components used in the following description are given or mixed in consideration of ease of specification, and do not have distinct meanings or roles. In the above description, all the components constituting the embodiments of the present invention are described as defective or defective in one operation, but the present invention is not necessarily limited to these embodiments. That is, within the scope of the present invention, all of the components may be selectively defectively operated. In addition, although all of the components may be implemented in one independent hardware, each or all of the components are selectively combined to perform some or all of the functions combined in one or a plurality of hardware. It may be implemented as a computer program having a. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art. Such a computer program may be stored in a computer readable storage medium and read and executed by a computer, thereby implementing embodiments of the present invention. The storage medium of the computer program may include a magnetic recording medium, an optical recording medium, and the like.

In addition, the terms "comprise", "comprise", or "having" described above mean that the corresponding component may be included unless otherwise stated, and thus, other components are excluded. It should be construed that it may further include other components instead. All terms, including technical and scientific terms, have the same meanings as commonly understood by one of ordinary skill in the art unless otherwise defined. Terms commonly used, such as terms defined in a dictionary, should be interpreted to coincide with the contextual meaning of the related art, and shall not be interpreted in an ideal or excessively formal sense unless explicitly defined in the present invention.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are only for distinguishing the components from other components, and the nature, order or order of the components are not limited by the terms. If a component is described as being "connected", "defective" or "connected" to another component, that component may be directly connected to or connected to that other component, but there is another configuration between each component. It is to be understood that an element may be "connected", "faulted" or "connected".

1 is a view for explaining a vehicle software verification system structure according to an embodiment of the present invention.

In detail, FIG. 1 is a view for explaining a vehicle software verification system structure capable of verifying whether error processing logic of the corresponding software is normal by dynamically injecting a defect into software mounted in the vehicle electronic control apparatus.

Referring to FIG. 1, a vehicle software verification system may largely include a host computer 10 and a vehicle electronic control apparatus 20. For convenience of description below, the vehicle electronic control device 20 will be used in combination with an ECU (Electric Control Unit).

The host computer 10 and the vehicle electronic control apparatus 20 may exchange information with each other through controller area network (CAN) communication.

Here, the software mounted on the vehicle electronic control apparatus 20 may be software based on the AUTOSAR (AUTomotive Open System Architecture) standard.

The host computer 10 may provide an environment for developing software mounted on the vehicle electronic control apparatus 20, and may transmit defect selection information received from a user to the vehicle electronic control apparatus 20 through CAN communication. Here, the defect selection information includes information about the software to be verified, information about a position to be injected into a defect determined by a function call relationship, information about a type of a defect to be injected, information about a number of defect injections, a parameter to be changed, a register, and It may include at least one of information about a data value, but is not limited thereto.

In addition, the host computer 10 may collect real-time software execution status information from the electronic control device for a vehicle 20 through CAN communication and output the real-time software execution status on the screen.

In the above-described embodiment of FIG. 1, the host computer 10 is illustrated as being connected to one vehicle electronic control apparatus 20, but this is only one embodiment, and the host computer 10 according to another embodiment may be It may be connected to a plurality of vehicle electronic control device 20 via a CAN communication network.

The user—that is, TESTER—is verified by the host computer 10 for verification and evaluation of the implemented fail-safety logic, the defect location and defect data on the verified software, the time of defect injection, By selecting a defect injection method, a test model can be defined and maintained.

The host computer 10 is equipped with a fault injection test manager, and the user can use the fault injection test manager to provide software-related information of the ECU to be verified, for example, an executable and linkable format (ELF) file and a MAP. File, etc.).

Herein, the ELF defines a format of a binary or object file that can be executed and linked. The ELF file may include an ELF header at the front and a program header table and a section header table at the back. An object file is a relocatable file that allows code and data to be linked with other object files, an executable file that allows code and data to run on the target operating system, and static or reassignable data. It can include a shared object file that allows you to dynamically share with other shared objects.

In addition, the host computer 10 may analyze the function call relationship of the verification target software using an Executable and Linkable Format (ELF) file, a MAP file, and the like. Here, the analysis result may be maintained in the internal memory of the host computer 10.

In addition, the host computer 10 may generate a defect injection code based on defect selection information received from a user.

The host computer 10 may transmit at least one of the analysis result of the function call relationship, the defect selection information, and the generated defect injection code to the vehicle electronic control apparatus 20 through CAN communication.

In addition, the vehicle electronic control apparatus 20 may monitor running software to track the call relationship of functions, and dynamically execute the defect injection code according to the tracking result.

In this case, the vehicle electronic control apparatus 20 may transfer the tracking result of the call relation of the function and the information on the execution result of the defect injection code to the host computer 10 through CAN communication.

In the above description, the host computer 10 generates the defect injection code based on the defect selection information. However, this is only an example, and the vehicle electronic control apparatus 20 may verify the host computer 10 from the host computer 10. The joint injection code may be generated based on the result of the function call relationship analysis of the target software and the defect selection information. In this case, the combined injection code may include at least one of a defect injection code for a unit test and a defect injection code for an integrated test.

2 is a block diagram illustrating a structure of a host computer according to an exemplary embodiment.

Referring to FIG. 2, the host computer 10 may include an experimental model generation module 210, a call relationship analysis module 220, a defect selection module 230, a defect injection code generation module 240, and a first memory 250. It may be configured to include an input device 260, an output device 270, a first communication modem 280, and a first controller 290.

The experiment model generation module 210 may provide a project generation user interface for defining an experiment model.

The experimental model generation module 210 determines the verification target software in the verification target ECU and analyzes a layered structure of a task / file of the determined verification target software to generate a location and a defect in which a defect may be tentatively generated. The number of parameters and / or variables and / or registers can be selected, and an experimental model for the ECU can be defined and generated based on the selection result. Here, the information about the generated experimental model may be stored in the first memory 250.

The call relationship analysis module 220 analyzes information related to the software mounted in the ECU to be verified, including, for example, an ELF file, a MAP file, a header file, and the like, to determine a function call relationship on the software to be verified. Can be.

The defect selection module 230 may select defects to be injected from a user based on a task and generate defect selection information. Here, the defect selection information includes task identification information, information for identifying a location where a defect is to be injected, information for identifying a type of a defect to be injected, information about a parameter to be changed, a value of a register and / or a variable, and the like. May be transferred to the first controller 280.

A user may execute a defect injection test manager mounted in the host computer 10 and select a defect to be injected through a predetermined user interface screen. Here, the selectable defect location and type can be determined based on the experimental model defined above.

The first controller 290 may transmit the defect selection information received from the defect selection module 230 to the vehicle electronic control apparatus 20 through the first communication modem 270.

The first memory 250 may store software necessary for driving the host computer 10, information about a defined experimental model, information about an analysis of a function call relationship, and the like.

The first controller 290 may read information about the experimental model defined according to the user's selection and information about the analyzed function call relation from the first memory 250 and transmit the information to the ECU.

The defect injection code generation module 240 may generate a defect injection code based on the defect selection information. Here, the generated defect injection code may include a unit test defect injection code and an integrated test defect injection code.

The generated defect injection code may be stored in the first memory 250.

When the ECU is driven, the first controller 290 may read a defect injection code corresponding to the ECU from the first memory 250 and transmit the defective injection code to the ECU through the first communication modem 280.

The input device 260 may include user input means such as a keyboard, a touch screen, a mouse, and the like.

The output device 270 may include a display screen, a speaker, and the like, but is not limited thereto.

The first communication modem 280 may perform CAN communication with the ECU provided in the vehicle.

3 is a view for explaining an experimental model definition procedure in an experimental model definition module according to an embodiment of the present invention.

Referring to FIG. 3, the experimental model generation module 210 is a software unit and integrated muting technique, which is a technique for changing and testing a source code in a layer that can be called by an AUTOSAR-based vehicle software application in a unit / integration test step of vehicle software. The defect injection position may be extracted by applying a (Mutation) operator (S310).

The experimental model generation module 210 may derive a defect type based on an error type that may occur in an AUTOSAR application, and apply the derived defect type for each extracted defect injection position (S320).

For example, the types of errors that can occur in AUTOSAR applications include data errors, program flow errors, access errors, timing errors, and asymmetric errors. It may include.

The detailed error type of data error is 1 “Invalid Value”, the detailed error type of program flow error is 3 “Uncalled Function”, “Bypass Function Call” and “Illegal Instruction”, and the detailed error type of access error is “Invalid Address”. ”And“ Invalid Register ”, detailed error types of timing error are“ Data Delay ”,“ Data Loss ”,“ No Response ”and“ CPU Clock Corruption ”, and detailed defect types of asymmetric error are“ Asymmetric Valure ” It can be divided into one.

Upon completion of steps 310 to 320, a defect type for a defect injection test is defined.

The experimental model generation module 210 may set the defect injection test to be automated (S330).

For example, a method of injecting a fault into an AUTOSAR-based vehicle ECU software includes a monitoring module that monitors the invocation of tasks and functions in a basic software layer (BSW (Basic SoftWare) Layer) of the AUTOSAR layer of the ECU, and After the application is executed, if the call of the function to be injected is detected by the monitoring module, a function that executes a function with a defect code inserted instead of the original function called-for the convenience of explanation below, a business card called a defect code injection function. Injection test automation methods can be used.

That is, an embodiment of the present invention can automate a defect injection test by mounting a wrapper function and a module that can hook a wrapper function in a basic software layer. Here, a wrapper means overwriting a specific function with its own function.

The experimental model generation module 210 may determine whether the automation setting for each defect type is possible (S340).

That is, the experiment model generation module 210 may determine whether the automation method of step 330 can be applied to the defect type derived as a result of step 320. As a result of determination, if it is not applicable, the experimental model generation module 210 may exclude the corresponding defect type from the test target.

The experimental model generation module 210 may set a scenario in which a defect occurs and a defect injection method by analyzing the derived defect type and the AUTOSAR platform (S350).

4 is a diagram illustrating an internal structure of a call relationship analysis module according to an embodiment of the present invention.

Referring to FIG. 4, the call relationship analysis module 220 may include a first user interface provider 410, a structure analyzer 420, and a call relationship analyzer 430.

The first user interface providing unit 410 may configure a user interface screen for creating a project-a project generation UI, a business card, for convenience of description.

The user can select the ECU to be verified through the project creation UI. In addition, the user may select a verification target software component among software components mounted in the selected ECU through the project generation UI.

The structure analyzer 420 may analyze a hierarchical structure of a file / task (or module) / function of the software to be verified based on the ELF file and the MAP file of the software component to be verified.

The call relationship analyzer 430 may analyze a call relationship for each function, that is, a caller-caller relationship based on the hierarchical structure analyzed by the structure analyzer 420.

5 is a view for explaining the internal structure of a defect selection module according to an embodiment of the present invention.

Referring to FIG. 5, the defect selection module 230 may include a second user interface providing unit 510, a unit test information collecting unit 520, and an integrated test information collecting unit 530.

The second user interface providing unit 510 may configure a predetermined defect injection user interface screen for receiving input from the user of information necessary for generating a defect injection code for each software unit test step and software integration test step.

The unit test information collection unit 520 may collect information necessary for generating a defect injection code for unit testing. For example, the unit test information collection unit 520 may include information about a unit function or a global variable to inject a defect, information about a defect type to be injected, information about the number of defect injections, parameters to be changed, a register, and / or a variable. Information about the value of can be collected.

The integrated test information collecting unit 530 may collect information necessary for generating a defect injection code for the integrated test. For example, the integrated test information collecting unit 530 may include information about a series of unit tests included in the integrated test and their execution order, information about a location to inject defects, for example, a caller-callee call relationship. Information about the type of defects to be injected, information about the number of defect injections, parameters to be changed, information about the values of registers and / or variables, and the like.

The defect injection code generation module 240 performs the defect injection code and the integration test for the unit test based on the defect selection information collected by the unit test information collecting unit 520 and / or the integrated test information collecting unit 530. At least one of the defect injection codes may be generated and stored in the first memory 250.

6 is a view for explaining the structure of a vehicle electronic control apparatus according to an embodiment of the present invention.

Referring to FIG. 6, the vehicle electronic control apparatus 20 may include a task call monitoring module 610, a function call monitoring module 620, a defect injection code execution module 630, a second memory 640, and a diagnostic module 650. ), A second CAN communication module 660, and a second controller 670.

The task call monitoring module 610 may monitor whether a specific task is called while driving the vehicle electronic control apparatus 20. That is, the task call monitoring module 610 may monitor whether the task to be verified is called in real time and provide the monitoring result to the second controller 670.

Here, the task may be divided into software component units, but this is only one embodiment, and the task according to another embodiment may be divided into specific function modules within the software component. For example, when the vehicle electronic control apparatus is an air conditioner, the task may be the entire air conditioning software. As another example, when the vehicle electronic control apparatus is an air conditioner, the task may include a heating function module, a cooling function module, a ventilation function module, and the like among the air conditioning software.

The second controller 670 may control the function call monitoring module 620 to monitor the call of a specific function based on the monitoring result of the task call monitoring module 610.

The function call monitoring module 610 may monitor whether a specific function in a corresponding task is called according to a control signal of the second controller 670 and provide a monitoring result to the second controller 670. Here, the specific function may be a function to which a defect injection code is to be injected, that is, a function to be injected with a defect injection code.

When the defect injection code execution module 630 detects that a defect injection code injection target function is called according to a control signal of the second controller 670, the defect injection code execution module 630 may read and execute the corresponding defect injection code stored in the second memory 640. . That is, the defect injection code execution module 630 may be executed by the second function injected with the defect injection code instead of the execution of the first function composed of the original code without the defect. Here, it should be noted that the first function and the second function are functions having the same variable type with the same name.

The diagnostic module 650 may receive the defect selection information received from the user through the second CAN communication modem 660 from the host computer 10 and provide it to the second controller 670.

When the defect selection information is received from the host computer 10, the second controller 670 may identify the verification target software / task / function based on the defect selection information.

The second controller 670 may control operations of the task call monitoring module 610 and the function call monitoring module 620 according to the identification result.

In addition, the second controller 670 may receive a defect injection code, that is, a function code into which the defect injection code has been injected, from the host computer 10 via the second communication modem 660 and the diagnostic module 650. . The second controller 670 may store the received defect injection code in the second memory 640.

The second communication modem 660 may perform CAN communication with the host computer 10.

The second controller 670 may control internal operations and input / output of the vehicle electronic control apparatus 20.

If the vehicle electronic control apparatus 20 according to an embodiment supports the AUTOSAR standard platform, the task call monitoring module 610, the function call monitoring module 620, the defect injection code execution module 630, and the diagnostic module 650 may be used. ) May be mounted on the base software layer. Details will be apparent from the following description of the drawings.

7 illustrates a hierarchical structure of an AUTOSAR standard platform implemented in an electronic control apparatus for a vehicle according to an embodiment of the present disclosure.

As shown in FIG. 7, the AUTOSAR standard platform 700 includes a basic software on which an application layer (710), a hardware layer (740), and basic programs related to hardware, on which an AUTOSAR software component is mounted. And a Real Time Environment (RTE) 720 connecting the application layer 710 to the application software 710 and the basic software layer 730.

AUTOSAR software components consist of an atomic component consisting of a single component and a composition component consisting of two or more atomic components.

Here, the atomic component includes a plurality of software components such as application software components, actuator software components, sensor software components, and the like.

The application software component handles the control logic of the system, the sensor component acts as the hardware-dependent interface of the inputs, and the actuator component manages the hardware-dependent outputs. Accordingly, each software component exchanges data through a port and an interface as a basic unit that is mapped to an electronic control device that implements a corresponding application software function.

The real-time environment layer 720 serves for information exchange between each application software component and between the application layer 710 and the basic software layer 730.

The real-time environment layer 720 serves to separate hardware and software. The real-time environment layer 720 is a layer for controlling hardware independence from application software components, and serves as a communication bridge between the software component layer and the underlying software component module and the requirements of the software component. It is responsible for the communication between software components and other components through various mapping processes from the corresponding electronic control device.

Under the real-time environment layer 720, there is a basic software layer 730, and the basic software layer 730 again includes a service area, an ECU abstraction layer (EAL), a microcontroller abstraction layer (MCAL), and a complex device driver (CDD) area. And the like.

In order to design a defect injection test automation system for verifying error handling of an application software component in the hierarchical structure of the AUTOSAR standard platform described above, it is necessary to understand the correlation between software components, tasks, and functions.

The software component is a minimum program unit allocated to the corresponding electronic control apparatus, the software component is divided into task units, and the task may be composed of a plurality of functions that are minimum functional units. Accordingly, the actual execution of the software component is made in units of functions, and much of the defect injection related configuration can be made in units of functions.

Execution of the function may be determined by various events occurring in the real-time environment layer (RTE). For example, an event occurring in the real-time environment layer may include a timing event periodically generated based on a set timer, a data reception event generated when a specific signal is received, and an operation call event used in a client-server method. It is not limited to this.

As illustrated in FIG. 7, the basic software layer 730 according to an embodiment of the present invention may include a monitoring module 731 for monitoring a call of tasks and functions of a software component under test, input by a user through CAN communication. The diagnostic module 732 for receiving the defect selection information and the defect injection code and the defect injection code execution module 733 for executing the code in which the actual defect is injected may be mounted.

Here, the defect selection information may include defect injection target software component information, defect injection task information, defect injection function information, defect injection target parameter position information, defect injection target parameter or variable size information, defect type information, defect injection information, and the like. It may include at least one of the change value information, the information on the number of defect injection.

The monitoring module 731 may identify the defect injection target task and the function call based on the defect selection information during the execution of the verification target software in the electronic control apparatus.

The monitoring module 731 may monitor whether the defect injection target task and the function are called and determine whether to execute the pre-generated defect injection code corresponding to the defect injection target function based on the monitoring result.

The monitoring module 731 may perform monitoring on a task basis. Since one task is a group of several function calls grouped by time, the monitoring module 731 may check whether the user has selected a defect injection for the task before executing the task.

If a defect injection for the task is selected, the monitoring module 731 may identify a user input defect injection position by monitoring a call relation of a function in the task. That is, the monitoring module 731 may monitor the execution flow of the function in the task. Here, the function to be monitored is a callee function. The monitoring module 731 may check the caller function calling the called function by tracing the stack of the called function. The monitoring module 731 may determine whether the relationship between the call function and the called function corresponds to a defect injection position input from the user.

The defect injection code execution module 733 may identify the defect injection target task and the function based on the defect selection information. When the call of the defect injection target function is detected by the monitoring module 731, the corresponding position of the detected function is detected. You can generate and execute defect injection code with changed parameter or variable in.

As another example, when the call of the defect injection target task and the function is confirmed by the monitoring module 731, the defect injection code execution module 733 may execute the previously generated defect injection code. Here, the defect injection code can be received in advance from the host computer 10 and held in a predetermined recording area.

That is, the defect injection code execution module 733 may execute the code in which the actual defect is injected after it is determined by the monitoring module 731 that the function currently called is the target of defect injection.

A specific data structure for storing defect selection information for receiving input of defect selection information from a user may be defined in the diagnostic module 731.

When the basic software layer 730 is activated, the CAN diagnostic module setting process of defining a data structure for storing defect selection information and adding a read function and a write function for the data structure may be performed.

8 is a flowchart illustrating a dynamic defect injection method for verifying software mounted on an electronic control apparatus for a vehicle according to an embodiment of the present disclosure.

Referring to FIG. 8, the electronic control apparatus may execute the verification target software of the electronic control apparatus (S810). Here, the verification target software may be automatically executed when the electronic control apparatus is driven. However, this is only one embodiment. In another embodiment, the verification target software may be executed according to a control signal of an external host computer or an external diagnostic apparatus. It may be.

The electronic control apparatus may check whether defect selection information is input from the user (S820). Here, the defect selection information input from the user may be transmitted to the electronic control apparatus through CAN communication.

As a result of the check, when the defect selection information is input, the electronic control apparatus may monitor the defect injection target by tracking a task and a function call relationship (S830).

The electronic control device may detect a defect injection target through the monitoring (S840).

As a result of detection, when a defect injection target is detected, the electronic control apparatus may execute a defect injection code (S850). Here, the defect injection code may be generated in advance in the electronic control apparatus according to the input of the defect injection information and stored in a predetermined recording area.

The electronic control apparatus may determine whether the defect injection is repetitive based on the defect selection information (S860).

As a result of the determination, if it is repetitive, the electronic control apparatus may return to step 850 to repeatedly execute the defect injection code.

As a result of the determination of step 840, when the defect injection target is not detected, the electronic control apparatus may perform step 830.

In addition, if the defect selection information is not input as a result of the determination in step 820, or the defect injection is not set repeatedly as a result of the determination in step 860, the original is returned to the step 810, the defect is not injected. You can run your code.

As described above, the present invention has the advantage of supporting defect injection tests in the unit test step and the integrated test step of the vehicle software corresponding to ISO 26263 Part 6.

In addition, the present invention, when the user wants to verify the functional safety in the vehicle software unit / integration test step, by allowing the user to dynamically select the defect injection target function and function call relationship, the type of defect injection and the number of defect injection iterations, Verification can be performed efficiently for various functional safety scenarios.

In addition, the present invention can dynamically inject various defect data selected by the user through external communication, for example, CAN communication, without fixing the data for the defect type, thereby testing various defect control functions. There is an advantage to this.

In addition, the present invention not only does not need to change the code of the original software for vehicle software verification, but also generates a plurality of defect-injected software images according to the injecting defect, and injects different kinds of defects in one software image This is an advantage that can increase test efficiency.

The dynamic defect injection method described above can be embodied as computer readable code on a computer readable recording medium. Computer-readable recording media include all kinds of recording media having data stored thereon that can be decrypted by a computer system. For example, there may be a read only memory (ROM), a random access memory (RAM), a magnetic tape, a magnetic disk, a flash memory, an optical data storage device, or the like. The computer-readable recording medium can also be distributed over computer systems connected over a computer network, stored as readable code in a distributed fashion, and downloaded and executed on the device.

In addition, while the above has been described with reference to a preferred embodiment of the present invention, those skilled in the art to which the present invention pertains without departing from the spirit and scope of the present invention as set forth in the claims below. It will be appreciated that various modifications and changes can be made.

Claims (20)

A host computer for verifying software mounted on a vehicle electronic control device,
An experimental model generation module for generating an experimental model for the verification target software mounted on the electronic control device;
A call relationship analysis module that determines a function call relationship of the verification target software;
A defect selection module receiving defect information to be injected into the verification target software from a user and generating defect selection information;
A defect injection code generation module generating a defect injection code based on the defect selection information and the determined function call relationship; And
A first communication modem for transmitting the defect selection information and the defect injection code to the electronic control apparatus
Host computer comprising a. The method of claim 1,
The experimental model generation module
Means for extracting a defect injection position;
Means for applying a defect type to the extracted defect injection position;
Means for setting the defect injection test to be automated;
Means for determining whether to automate the defect types; And
Means for setting a defect injection scenario according to the determination result, excluding the defect type that cannot be automated
Host computer comprising a. The method of claim 2,
The defect injection position is extracted by applying a mutation operator for each unit and integration test step of the verification target software. The method of claim 2,
The error type includes a data error, a program flow error, an access error, a timing error, and an asymmetric error. The method of claim 1,
The defect selection information includes at least one of information for identifying a location to be injected, information for identifying a type of defect to be injected, information about a number of defect injections, information about a parameter to be changed, a value of a register, and / or a variable. Host computer containing one. The method of claim 1,
Wherein the defect injection code comprises at least one of a defect injection code for unit testing and a defect injection code for integration testing according to the defect selection information. The method of claim 1,
The call relationship analysis module
A first user interface providing unit constituting a user interface screen for generating a project;
A structure analyzer configured to analyze a hierarchical structure of a file, a task, and a function of the software to be verified; And
Call relationship analysis unit for analyzing the relationship between the call function (Caller) and the call function (Callee) based on the analyzed hierarchical structure
Host computer comprising a. The method of claim 1,
The fault selection module
A second user interface providing unit constituting a predetermined defect injection user interface screen for receiving input from a user of information necessary for generating a defect injection code for each software unit test step and a software integration test step;
A unit test information collection unit collecting first information necessary for generating a defect injection code for the unit test; And
Integration test information collection unit for collecting the second information necessary for generating the defect injection code for the integration test
Host computer comprising a. The method of claim 8,
The first information includes at least one of information on a unit function or a global variable to inject a defect, information on a defect type to be injected and information on the number of defect injections, and information on a parameter to be changed, a value of a register and / or a variable. Host computer containing one. The method of claim 8,
The second information includes a series of the unit tests included in the integration test and information about their execution order, information about a location to inject defects, information about a type of defect to be injected and information about the number of defect injections, and a change. A host computer comprising at least one of information about a parameter, a register, and / or a value of a variable to be. In the vehicle electronic control device for verifying the software mounted on-board in conjunction with a host computer,
A diagnostic module for receiving defect selection information and a combined injection code generated based on the defect selection information from the host computer;
A second controller identifying a software to be verified based on the defect selection information and identifying a task and a function to inject a defect in the identified software to be verified;
A task call monitoring module for monitoring the identified task call;
A function call monitoring module for monitoring a call of the identified function when the identified task call is detected; And
A fault injection code execution module that executes the joint injection code when a call of the identified function is detected
Vehicle electronic control device comprising a. The method of claim 11,
The software mounted on the vehicle electronic device is software running on an AUTOSAR (AUTomotive Open System Architecture) standard platform. The method of claim 12,
The AUTOSAR standard platform includes a basic software layer disposed between the real-time environment layer and the hardware layer,
And the diagnostic module, the task call monitoring module, the function call monitoring module, and the fault injection code execution module are mounted in the basic software layer. The method of claim 12,
And the diagnostic module receives the defect selection information and the defect injection code through CAN communication. The method of claim 12,
And the defect injection code comprises at least one of a defect injection code for unit testing and a defect injection code for integration testing according to the defect selection information. A host computer analyzing a function call relationship of the verification target software and generating a defect injection code based on the defect selection information received from a user and the analyzed function call relationship; And
Receiving the defect selection information and the defect injection code through the CAN communication from the host computer, and executing the defect injection code by monitoring the identified tasks and functions based on the defect selection information when executing the verification target software Electronic controller
Vehicle software verification system comprising a. The method of claim 16,
The vehicle electronic control device
A diagnostic module for receiving the defect selection information and the combined injection code from the host computer;
A monitoring module for monitoring invocation of identified tasks and functions based on the defect selection information; And
A fault injection code execution module that executes the joint injection code when a call of the identified task and function is detected
In-vehicle software verification system comprising a. The method of claim 17,
The verification software is a vehicle software verification system is software running on an AUTOSAR (AUTomotive Open System Architecture) standard platform. The method of claim 18,
The AUTOSAR standard platform includes a basic software layer disposed between the real-time environment layer and the hardware layer,
And the diagnostic module, the monitoring module and the defect injection code execution module are mounted in the basic software layer. The method of claim 16,
The host computer
An experimental model generation module for generating an experimental model for the verification target software mounted on the vehicle electronic control apparatus;
A call relationship analysis module that determines a function call relationship of the verification target software;
A defect selection module receiving defect information to be injected into the verification target software from the user and generating the defect selection information;
A defect injection code generation module generating the defect injection code based on the defect selection information and the determined function call relationship; And
A first communication modem for transmitting the defect selection information and the defect injection code to the vehicle electronic control apparatus through the CAN communication
In-vehicle software verification system comprising a.

Images