KR101584717B1 - Method and Apparatus for testing software fail processing module mounted on embeded system for aerial Vehicle - Google Patents

Abstract

The present invention relates to an embedded system for an airplane. More specifically, the present invention relates to an inspection device for verifying the produce of a malfunction processing module for sensing and responding to malfunction and exceptional situation of a failure mode which can occur in various aircraft embedded systems and a method thereof.

Description

TECHNICAL FIELD [0001] The present invention relates to a software fault-handling module mounted on an aircraft,

Field of the Invention [0001] The present invention relates to an embedded system for aircraft, and more particularly, to a test method and apparatus for verifying the design of a failure processing module for detecting and responding to failures and exceptional conditions for possible failure modes in various aircraft embedded systems will be.

In order to allow a certain level of failure occurring in the system, the embedded system for aviation requiring a high reliability analyzes the failure mode of the system hardware and analyzes the failure mode of the embedded software The fault tolerant design is applied in such a way as to develop.

The embedded system needs to simulate the failure condition of the hardware during normal operation of the embedded software to verify the failure handling module before operation. For this purpose, a test software module for fault injection has been added to the software generally installed only temporarily during the test, and after the test has been performed, the reference value of the hardware failure judgment of the software has been arbitrarily modified only during the test.

However, in this method, the configuration of the system loading software operated during the flight is changed at the time of executing the test, and additional execution time is required accordingly, so that the function of the software failure handling module in the actual flight operating situation is fully verified There is a problem that it can not be done.

1. Korean Patent Publication No. 10-2013-0088506 2. Registration No. 10-1448013

1. Kwak, Jun-Hyuk, et al., "A Study on Verification Method of UAV Flight Control Software" 2. Yoon, Hyung-Sik, et al., "Development of Verification Environment for Flight Safety Required Software Using NEXUS" Journal of Korean Society for Aeronautical and Space Sciences 40 (6) (June 2012) pp.548-554

The present invention has been made in order to solve the problems according to the above background art, and it is an object of the present invention to provide an embedded system for a military aircraft for verifying the design of a failure processing module for detecting and coping with failures and exceptional conditions for possible failure modes in various aircraft embedded systems. And a method and an apparatus for testing a software fault-handling module equipped with the system.

It is another object of the present invention to provide a method and an apparatus for testing a software failure processing module for verifying a failure processing module through fault injection without affecting the shape and execution time of the software for loading an embedded system for an aircraft.

In order to accomplish the above-mentioned object, the present invention provides a software fault diagnosis system for embedded systems for military aircraft, which verifies the design of a fault processing module for detecting and responding to faults and / or exceptional conditions for possible fault modes in various aircraft embedded systems Provides a testing method for processing modules.

The software failure processing module testing method includes:

(a) transmitting a failure simulation request signal to a failure detection support module of the embedded system for a software testing apparatus to perform a test on the failure processing module of the embedded system;

(b) transmitting and receiving a first hardware status request signal and first hardware status information between the failure detection support module and the failure handling module at predetermined intervals;

(c) waiting for a certain period of time until the first hardware status request signal and the failure simulation request signal match each other;

(d) generating second hardware state information in which the failure detection support module simulates a failure value when a second hardware state request signal is received from the failure processing module after the lapse of the predetermined time; And

and (e) transmitting the failure occurrence information generated by the failure processing module to the software test equipment by determining the hardware failure using the second hardware status information.

In addition, the failure simulation request signal includes hardware identification information (ID), a failure occurrence time, and a failure hold time.

Also, the first and second hardware status request signals may include hardware identification information (ID) and current operation time.

In addition, the first and second hardware status information may include hardware identification information (ID) and a status value.

In the step (c), the controller may wait for a predetermined time until the current operation time of the first hardware status request signal and the failure occurrence time of the failure simulation request signal match each other.

In addition, the failure processing module may transmit the failure occurrence information to the software testing equipment using serial communication.

Further, the failure occurrence information may include hardware identification information (ID), a failure occurrence time, and a failure processing result.

The failure detection support module may perform a self-check of the specific hardware component according to a status check request signal of the specific hardware component from the failure processing module.

When the failure detection support module receives the hardware identification information (ID) of the specific hardware module, the failure occurrence time and the failure holding time from the software test equipment through the serial communication, the status of the specific hardware component And transmits the fault state through the serial communication to the fault handling module during the fault holding time from the fault occurrence time requested by using the request signal and the frame counter signal.

In addition, after step (e), the software test equipment compares the fault occurrence information with a predetermined test expected value to check whether a specific fault has occurred at a specific point in time, and then verify the fault to the fault handling module The method comprising the steps of:

In addition, the software testing equipment may transmit the failure simulation request signal to the failure detection support module using serial communication to inject a failure of a predefined hardware module.

On the other hand, another instant embodiment of the present invention is directed to an embedded system for aircraft having a fault handling module, an embedded system for a military aircraft having a fault detection support module, and software testing equipment in communication with the embedded system, A module testing apparatus, comprising: a software testing apparatus for transmitting a failure simulation request signal to a failure detection support module of the embedded system for performing a test on the failure processing module of the embedded system; Wherein the first hardware status request signal and the first hardware status information are transmitted and received at preset periods, and the failure detection support module waits for a predetermined time until the first hardware status request signal and the failure simulation request signal match each other, After the lapse of the predetermined time, When the second hardware status request signal is received from the module, the failure detection support module generates second hardware status information that simulates the failure value, and the failure processing module determines the failure of the hardware using the second hardware status information And transmits the generated fault occurrence information to the software test equipment. The software fault handling module testing apparatus may be provided with the embedded system for military aircraft.

According to the present invention, in order to verify the failure processing module of the operating software implemented for the fault tolerant design of the aircraft embedded system, The reliability of the system can be improved by properly inserting a fault according to the test step and verifying the result of the processing, confirming that the fault handling module performs the normal fault handling and executes the fault tolerant logic.

Another advantage of the present invention is that the entire software test including the failure mode test is automatically performed in comparison with the test method for the existing software failure processing module which confirms the failure processing result while passively applying the hardware failure one by one, , And the test can be effectively performed in terms of shortening the test time.

1 is an overall block diagram of an apparatus 100 for testing a software failure processing module with an embedded system for a military aircraft according to an embodiment of the present invention.
2 is a flowchart of a failure mode processing operation of a software failure processing module mounted on an avionics embedded system in a normal normal operation situation.
3 is an operational flowchart showing a process of testing a software failure processing module at the time of failure mode processing logic verification using the software failure processing module testing apparatus 100 mounted with an embedded system for aviation shown in FIG.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Like reference numerals are used for similar elements in describing each drawing.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. The term "and / or" includes any combination of a plurality of related listed items or any of a plurality of related listed items.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Should not.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a method and an apparatus for testing a software failure processing module equipped with an embedded system for a military aircraft according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is an overall block diagram of an apparatus 100 for testing a software failure processing module with an embedded system for a military aircraft according to an embodiment of the present invention. Referring to FIG. 1, a software failure processing module testing apparatus 100 mounted in an embedded system for a military aircraft mainly includes an embedded system 110, which is a test target, and an embedded system 110, And a software testing device 120, which is a device for testing the system.

The failure processing module 111-1 to be tested is included in the operating software 111 to detect a hardware failure occurring in the embedded system 110 and to record failure information according to each failure, Perform the content.

The failure processing module 111-1 transmits a hardware status request signal 15 composed of current operation time information based on the operating software 111 frame and hardware identification information ID required for state checking to a field programmable gate array 113 to the failure detection support module 113-1.

The failure detection support module 113-1 receives the failure occurrence time from the test case execution module 122 in the test case execution module 122 of the software test equipment 120, A failure simulation request signal 18 composed of failure simulation hardware identification information (ID) and a failure holding time.

At this time, the failure detection support module 113-1 determines whether the current operation time information included in the hardware state request signal 15 from the failure processing module 111-1 coincides with the failure occurrence time included in the failure simulation request signal 18 The failure processing module 111-1 determines that the failure has occurred by using the hardware state information 16 for each hardware identification information (ID) provided from the FPGA 113 to the operation software 111 during the failure holding time The result is simulated as failure. When the current operation time information of the hardware status request signal 15 is equal to or longer than the sum of the failure occurrence time and the failure hold time, the hardware failure status module 15-1 provides the hardware check result value of the hardware to the failure processing module 111-1 normally .

The software testing equipment 120 includes a test result determination module 121, a test case execution module 122, and a test case database 123. The test case database 123 stores a test case for verifying the software requirements of the embedded system 110. The test case execution module 122 adjusts the input and output provided to the embedded system 110 according to the test case 24 to be executed currently received from the test case database 123, And transmits the failure simulation request signal 18 to the failure detection support module 113-1.

In the test result judgment module 121, the test case information 25 consisting of the test case number and the expected test value that is currently performed and received from the test case execution module 122 and the failure information received from the failure processing module 111-1 The failure occurrence information 17 generated in the present embedded system 110 is received in accordance with the test case in response to the failure occurrence information 17 including the generated hardware identification information (ID), the failure occurrence time, And also whether or not the failure occurrence time and the detection time coincide with the design intended by the failure processing module 111-1.

2 is a flowchart of a failure mode processing operation of a software failure processing module mounted on an avionics embedded system in a normal normal operation situation. Referring to FIG. 2, in the operation software 111 mounted on a central processing unit (CPU), the failure processing module 111-1 controls the FPGA 113 at a point in time for monitoring to determine whether the hardware is faulty, And transmits a hardware status request signal to the failure detection support module 113-1 (S210).

The failure detection support module 113-1 implemented in the FPGA 113 determines the hardware status information 16 of the requested hardware identification information at step S220, (S230). Thereafter, when a failure occurs during operation, the failure processing module 111-1 records the failure occurrence information and performs predetermined planned actions accordingly (S240, S250). At this time, the hardware status information 16 performed in the failure detection support module 113-1 performs a built-in test (BIT), which is normally performed for each hardware component, and uses the result.

3 is an operational flowchart showing a process of testing a software failure processing module at the time of failure mode processing logic verification using the software failure processing module testing apparatus 100 mounted with an embedded system for aviation shown in FIG. Referring to FIG. 3, in case of a test case in which a failure simulation is required during execution of a test according to a test case in the test case execution module 122, a failure detection supported in the FPGA 113 of the embedded system 110 The module 113-1 transmits a fault simulation request signal 18 including a hardware ID to simulate a fault, a time at which the corresponding fault occurs, and a time at which the fault should be maintained (S310).

The hardware status request signal 15 and the hardware status information (hereinafter, referred to as " hardware status request signal ") are transmitted between the operation software 111-1 and the FPGA 113, more precisely between the failure handling module 111-1 and the failure detection support module 113-1 16 (S320, S330).

The failure detection support module 113-1 waits until the current operating time information of the hardware status request signal 15 reaches the failure occurrence time of the failure simulation request signal 18 at step S340.

If the hardware state request signal 15 is received from the failure processing module 111-1 after the elapse of the predetermined time period in step S350, the failure detection support module 113-1 of the FPGA 113 issues a corresponding identification A state value of the hardware state information 16 is generated by simulating the hardware of the information (ID) as a failure (S360, S370).

The failure processing module 111-1 determines the failure of the hardware based on the received hardware state information, records the failure state according to the failure, and performs the planned actions in advance (S380, S390). The failure occurrence information 17 including the hardware identification information (ID) at which the failure occurs, the time at which the failure occurred, and the result of processing the failure is transmitted to the test result determination module 121 of the software testing equipment 120 through the serial communication (S391). The test result determination module 121 verifies whether an intended failure has occurred at an intended time point through the test expected value and the received failure value, and verifies the failure of the failure processing module 111-1.

This verification is automatically performed by the test case execution module 122 for all the failure cases according to the embedded system hardware failure mode. When the tests for all the failure cases are completed, the verification for the failure processing module 111-1 is performed Is completed.

100: software failure processing module test device
110: Embedded system
111: Operation software 111-1: Failure processing module
113: Field Programmable Gate Array (FPGA)
121: Test result judgment module
122: Test case execution module
123: Test case database

Claims (10)

(a) transmitting a failure simulation request signal to a failure detection support module of the embedded system for a software testing apparatus to perform a test on the failure processing module of the embedded system;
(b) transmitting and receiving a first hardware status request signal and first hardware status information between the failure detection support module and the failure handling module at predetermined intervals;
(c) waiting for a certain period of time until the first hardware status request signal and the failure simulation request signal match each other;
(d) generating second hardware state information in which the failure detection support module simulates a failure value when a second hardware state request signal is received from the failure processing module after the lapse of the predetermined time; And
(e) transmitting, to the software test equipment, failure occurrence information generated by the failure processing module by using the second hardware status information to judge a failure of the hardware;
Wherein the software fault-handling module is installed in the embedded system for an aircraft.
The method according to claim 1,
Wherein the failure simulation request signal includes hardware identification information (ID), a failure occurrence time, and a failure hold time, the first and second hardware status request signals including hardware identification information (ID) Wherein the first and second hardware status information includes hardware identification information (ID) and a status value.
3. The method of claim 2,
Wherein in the step (c), the system waits for a certain period of time until the current operating time of the first hardware status request signal and the failure occurrence time of the failure simulation request signal match each other. Module test method.
The method according to claim 1,
Wherein the failure handling module transmits the failure occurrence information to the software test equipment using serial communication.
The method according to claim 1,
Wherein the failure occurrence information includes hardware identification information (ID), a failure occurrence time, and a failure processing result.
The method according to claim 1,
Wherein the failure detection support module performs a self-check of the specific hardware component according to a status check request signal of the specific hardware component from the failure handling module.
3. The method of claim 2,
When the failure detection support module receives the hardware identification information (ID) of the specific hardware module, the failure occurrence time and the failure holding time from the software test equipment through the serial communication, And transmitting the fault status to the fault handling module using the serial communication during the fault holding time from the fault occurrence time requested using the frame counter signal to the fault handling module. The method according to claim 1,
After the step (e), the software testing equipment compares the fault occurrence information with a predetermined test expected value to confirm whether a specific fault has occurred at a specific point in time, and then performs a verification of the fault to the fault handling module A software fault handling module test method with an embedded system for an aircraft.
3. The method of claim 2,
Wherein the software test equipment transmits the fault simulation request signal to the fault detection support module using a serial communication to inject a fault of a predefined hardware module to the fault detection support module .
1. An apparatus for testing a software fault processing module with an embedded system for avionics having a failure processing module, an embedded system for an aircraft having a failure detection support module, and software testing equipment communicating with the embedded system,
The software test equipment transmits a failure simulation request signal to the failure detection support module of the embedded system in order to perform a test on the failure processing module of the embedded system,
Transmitting and receiving the first hardware status request signal and the first hardware status information at predetermined intervals between the failure detection support module and the failure handling module,
The failure detection support module waits for a predetermined time until the first hardware status request signal and the failure simulation request signal match each other,
When the second hardware status request signal is received from the failure handling module after the lapse of the predetermined time, the failure detection support module generates second hardware status information simulating the failure value,
Wherein the failure handling module transmits failure occurrence information generated by determining failure of the hardware using the second hardware status information to the software testing equipment.

Images