KR20080050117A - Method and system for enhancing the reliability of embedded software - Google Patents

Abstract

The present invention relates to a method and system for enhancing the reliability of embedded software.

The method for enhancing the reliability of embedded software according to the present invention detects an error of the source code according to an error detection syntax added to the source code of the software, receives the detected error information, and processes the error based on the error information. By doing so, the operating system, middleware, and application programs of the embedded computer system can recognize errors.

Description

Method and system of Reinforcing Reliability in Embedded Software

1 is a diagram schematically showing the overall configuration of a system for enhancing the reliability of embedded software according to an embodiment of the present invention.

2 is a view schematically showing the configuration of an error detector according to another embodiment of the present invention.

3 is a flowchart illustrating an error detection method according to another embodiment of the present invention.

4 is a flowchart illustrating an error handler operation algorithm according to another embodiment of the present invention.

5 is a flowchart illustrating an error handler operation algorithm according to another embodiment of the present invention.

6 is a diagram schematically showing the overall configuration of a system for enhancing reliability using a simulator according to another embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

110: error detector 120: error handler

130: event logger 140: queue

106: user handler 121: default handler

111: input inspection unit 112: all state inspection unit

113: processing unit 114: output inspection unit

115: post-state inspection unit

The present invention relates to error detection of software of the present invention, and more particularly, to a method and system for effectively detecting an error of embedded software to enhance reliability of embedded software.

An embedded system is a device that embeds a microprocessor or microcontroller to perform only the functions specified by the original manufacturer. Generally, an embedded system is a specific application that includes hardware and software to perform special tasks as part of a larger system. Say the system.

Such embedded systems are used in various application fields, such as factory automation, home automation, robot control, process control including process control, terminal device fields including mobile phones, PDAs, smartphones, LBSs, printers, Internet refrigerators, and game machines. , Information including HDTV, etc. are being applied to various fields such as electric appliance field, network device field including exchange, router, home server, home gateway and the like.

In recent years, hardware specifications of embedded computer systems have been increasing in performance, and various electronic products have been converged. Due to this trend, the complexity of embedded software is increasing. On the contrary, the market cycle of products is shortened due to various demands of users and rapid changes in demand.

As a result of these recent trends, the rapid development of complex software leads to an increase in software bugs and a decrease in software stability.

Conventional software verification and verification is a modeling checking technique, which extracts a software model and verifies a model in a finite state machine (FSM) format. However, these techniques not only have inaccuracies due to the difference between the actual software and the model, and complicated modeling processes, but also have difficulty coping with increasing software complexity.

In addition, the Abstract Interpretation technique is a technique for checking and verifying an error in a virtual machine at compile time or runtime time by substituting a syntax of interest with an arbitrary syntax for a virtual machine, but has the same limitation as described above.

In addition, the conventional run-time checker technique adds a routine to detect an error in the source code, and handles it properly when an error is detected. However, there are not many operating systems that support such error detection and error handling among a large number of operating systems, and even operating systems that support error detection and error handling have limitations in that they can detect errors only for their own applications.

On the other hand, the above-described techniques for detecting errors in software did not cope with all kinds of errors. In addition, it can cope with unpredictable errors that occur in a very short time, such as interrupts caused by an asynchronous event such as an interrupt of an application, and errors that cannot be checked through a test case. There was no.

The present invention has been made to overcome the above problems and limitations of the prior art, and an object thereof is to provide a method and system for enhancing the reliability of embedded software.

According to an aspect of the present invention, there is provided a method for enhancing reliability of embedded software, the method comprising: detecting an error of the source code according to an error detection syntax added to the source code of the software; And receiving the detected error information, and processing an error based on the error information.

A system for enhancing reliability of embedded software for achieving another technical problem of the present invention includes an error detector for detecting an error of the source code according to an error detection syntax added to the source code of the software; And an error handler receiving the detected error information from the error detector and processing an error based on the error information.

An error detection method for achieving another technical problem of the present invention includes the steps of passing debugging information and hardware information on the error of the software to the simulator; And detecting an error of the software based on the transmitted debugging information and hardware information.

Another aspect of the present invention includes a recording medium having recorded thereon a program for executing the above methods on a computer.

Details and improvements of the invention are disclosed in the dependent claims.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram schematically showing the overall configuration of a system for enhancing the reliability of embedded software according to an embodiment of the present invention.

Reliability as used throughout the specification of the present invention is used to mean a continuous time for the embedded system to operate stably. In addition, the component is used as a component of the system for enhancing the above-described reliability, may be used as a whole component, and may be optionally used. Such a system includes an error detector 110, an error handler 120, an event logger 130, and a queue 140.

The operation mode of such a system is divided into a development mode and a release mode. The development mode refers to a programming stage, and is here for the purpose of recognizing an error and identifying a cause. On the other hand, in the release mode, this means that the programmed software is embedded in an embedded system and then distributed to individual users.In this case, error recognition and recovery, isolation (i.e., error) are not related to the entire system, but functions related to the error. The purpose is to limit it.

Referring to FIG. 1, the source code 100 includes a software error 101, a hardware error 102, a software event 103, a hardware event 104, debugging information 105, a user handler 106, and the like. do.

It is assumed here that the hardware and development tools are stable. If you find a bug in the hardware, you can use the device driver to prevent the error from happening and replace the development tools with other reliable tools.

When the source code 100 is created, a syntax for detecting an error and recording an event is added. In addition, the custom handler 106 has been previously included in the source code by the user for error handling.

The error detector 110 recognizes a syntax for detecting an error added to the source code 100 to detect an error 101 and a hardware error 102 of the software. Then, the debugging information 105 included in the source code 100 is received.

The error detector 110 may be largely composed of the following four application programming interfaces (APIs).

RRM_DETECTOR # (ErrorCond, ErrorType, HandlerParam), RRM_DETECTOR_EXCEPTION (int iType, void * pContext), RRM_DETECTOR_CALLBACK (ErrorCond, ErrorType, HandlerParam, CallbackFunc, CallbackP aram), RRM_DETECTOR_RETURN (ReturnValue), where the reliability is Rm Reinforcement Module).

RRM_DETECTOR # (ErrorCond, ErrorType, HandlerParam) is a routine for recognizing a software error, that is, a software error 101 in the source code 101, where # is any natural number. When an error condition (ErrorCond) is true or false, an error corresponding to an error type (ErrorType) is recognized. Then, the handler parameter (HandlerParam) is transmitted to the error handler 120.

RRM_DETECTOR_EXCEPTION (int iType, void * pContext) is a routine for recognizing the hardware error 102, and is a routine for recognizing an exception when the hardware enters an error state, for example. When this syntax is executed, it always recognizes that an error corresponding to iType has occurred, and delivers the context at the time of hardware error indicated by the pContext variable to the error handler 120.

RRM_DETECTOR_CALLBACK (ErrorCond, ErrorType, HandlerParam, CallbackFunc, CallbackParam) has the same basic function as the above-mentioned Error_DETECTOR #, and receives callback function pointers and parameters that are callback functions (CallbackFunc) and callback parameters (CallbackParam), and an error occurs and recovers it. If not, the callback function is called to release the allocated resources and return the function. The function of releasing the resource of the callback function will be described later with reference to FIG. 5.

RRM_DETECTOR_RETURN (ReturnValue) checks the return value to check whether there is an error in the execution result of the function, and if there is an error, calls the error handler.

The error handler 120 receives error type and debugging information from the error detector 110, receives error log information and log information recorded from the event logger 130 from the queue 140 and the log interpreter 150, Based on this, error recovery is performed.

This error handler has the following API, and includes RRM_HANDLER_TRY (FaultType, FaultHandler, QueueSize) and RRM_HANDLER_CATCH (). The routine coded between the above two functions uses the FaultHandler as a user handler when an error corresponding to the FaultType occurs. Where QueueSize represents an additional data structure.

The error handler 120 adds a syntax for detecting an error and recording an event to the source code, and recovers the error by using the error detector 110 and the event logger 130 interlocked with the additional syntax. In addition, the error handler 120 may be performed by dividing the operation mode of the system into a development mode and a release mode. Detailed operation algorithm of the error handler 120 will be described later with reference to FIGS. 4 and 5.

The event logger 130 receives the software event 103 and the hardware event 104 from the source code 100 and records them. In other words, in order to know the cause of the error, the source code has been processed. These events include software events and asynchronous events, which point to hardware and software interrupts. Hardware interrupts here occur on devices other than the CPU. Examples include devices such as keyboards, disk drives, CD-ROMs, sound cards, and mice. Internal interrupts include operational errors from the CPU, and software interrupts are generated using the native APIs as needed by the program. Most operating systems, such as Unix and Windows, have a software interrupt interface.

The event logger 130 includes RRM_LOGGER_FUNC (), RRM_LOGGER_EVENT (ucName, pHandler, uiLR), int RrmLoggerPrintCallstack (Task * pTask), int RrmLoggerPrintSystemEvent (), int RrmLoggerGetHead (), int RrmLoggerGetTail (), int iRmIndexgerPrint, etc. Include an API.

RRM_LOGGER_FUNC () is located at the beginning of the function and records that the function is called. This is managed by the call stack of the function over time. RRM_LOGGER_EVENT (ucName, pHandler, uiLR) is a hardware event named ucName, for example, when an interrupt has occurred, the address of the handler on the operating system of this event is pHandler, and when this event occurs, the task pointed to by the gpCurrentTask variable This is the point when the instruction located at uiLR address is executed.

int RrmLoggerPrintCallstack (Task * pTask) is a function that prints the call stack collected through the above API. It prints only the call stack of the task indicated by pTask. int RrmLoggerPrintSystemEvent () prints out all the hardware events that occurred on the system, and int RrmLoggerPrint (int iIndex) prints a record of the errors that have occurred so far.

In addition, the event logger 130 automatically passes debugging information to the error handler similarly to the error detector 110. Here, the event is divided into a software event and an asynchronous event. Asynchronous events indicate hardware and software interrupts. Log information stored for each event type includes a software error log and a hardware error log.

The software error log includes a handler including a task ID, a file, a line, a function, a fault point, a fault type, a condition string, a handler, a function name, a system tick, It consists of System Calls including Function Callstack including SP, Event Type, Handler, Task ID, PC and so on.

The hardware error log refers to an exception log, which consists of a fault point including a task ID, a fault type, a register set, and a call without a call symbol.

The event logger 130 delivers debugging information including the error log to the error handler 120. Debugging information is passed as a parameter when the error handler 120 is called or passed through a compiler built-in macro __FILE__. Also, optionally, the error handler 120 may be implicitly delivered by utilizing the time at the time of the call only by the call itself.

The queue 140 includes a system queue 141, a task queue 142, a log queue 143, and an error log queue 144.

A queue is a place that receives events from the event logger 130 and stores them in a message form. Each event type is recorded in the system queue 141 and the task queue 142, and the error log information is transferred to the error log queue 144 and provided to the error handler 120. In addition, the log queue 143 recording the log information provides the log information to the log interpreter 150 and transmits the log information to the default handler 121 of the error handler 120.

The queue 140 has APIs such as QueueCreate (), QueueDestroy (), QueueIn (), QueueOut (), QueueGetHead (), and QueueGetTail ().

Hereinafter, a description will be given with reference to exemplary source code according to a preferred embodiment of the present invention.

<Example source code>

int function ()

{

RRM_LOGGER_FUNC ();

RRM_DETECTOR1 (RrmCheckStack (), RRM_FAULT_STACK, NULL);

RRM_DETECTOR2 (RrmIsConstant (Param, 1, 5), RRM_FAULT _...,;

RRM_HANDLER_TRY (RRM_FAULT_A, myHandler, 10);

/ * User Code * /

RRM_HANDLER_CATCH ();

}

First, RRM_LOGGER_FUNC () at the beginning of the function records that the function is called. In addition, the routine RRM_DETECTOR1, which recognizes a software error, is executed. When RrmCheckStack () is executed as an error condition, an error corresponding to FAULT_STACK is recognized as an error type when it is true or false. Then, NULL is passed as the handler parameter to the error handler.

User code coded between RRM_HANDLER_TRY () and RRM_HANDLER_CATCH (), two functions, uses myHandler as a user handler when an error corresponding to Fault_A occurs. At this time, QueueSize is delivered as "10".

In summary, the system described above adds syntax for event detection and event recording to the source code, utilizes error detectors and event loggers associated with these additional syntaxes, and error detectors and event loggers, in turn, are error-prone by error handlers. It is used in the process of recovering. Here, if the error detector recognizes an error and the error handler cannot recover it, it is considered an error. In addition, by selectively using the operation mode to be described later, each component can operate in a different form according to the development mode and the release mode, and can be applied to systems of various sizes by reconfiguring and selectively using the component.

The configuration of the entire system shown in FIG. 1 may be optionally configured. For example, Error Detector Level 1 may be set to Enable / Disable, Error Detector Level # may be Enable / Disable, and Hardware Error Detector may be set to Enable / Disable. . In addition, when the error detector is enabled, the maximum error type (Max Error Type) of the error handler may be selected as the development mode or the release mode.

Also, among the event loggers, the System Event Log can be set to Enable / Disable, the Function Callstack Log to Enable / Disable, and the Log Queue Size can be set to [1,100]. have.

2 is a view schematically showing the configuration of an error detector according to another embodiment of the present invention.

Referring to FIG. 2, a detailed configuration of the error detector 110 and an error handler 120 are illustrated. The error detector 110 may include an input checker 111, a pre-condition state checker 112, a processing unit 113, an output checker 114, and a post-condition state checker 115. Include.

Typical error detectors proceed in the order of input, processing, and result. In a preferred embodiment of the present invention, the input checker 111 checks the input parameters of the function and passes debugging information to the error handler 120. In addition, the pre-state checker 112 checks the state of software and hardware at the time of the function call and transmits debugging information to the error handler 120.

The processor 113 processes the input parameters of the function according to a specific function execution and provides them to the output inspector 114 and the post state inspector 115.

The output checker 114 checks the result value according to the execution of the function and transmits debugging information to the error handler 120. After the state checker 115 checks the state of software and hardware at the end of the function, the debugging information is errored. Transfer to handler 120.

The post state inspecting unit 115 is input to the pre state inspecting unit 112 again through internal states. Herein, internal states refer to comprehensive software and hardware states including not only values of variables in memory but also register values of hardware devices.

In an exemplary embodiment, the check syntax includes a constant, a string, a memory pointer, a control block, and a stack.

Constants are int RrmIsConstant (int iVar, int iFrom, int iTo), a syntax for checking the range of integer values, for example, greater than 5 and less than 10.

A string is an int RrmIsString (uint8 * pString, int iFrom, int iTo), a syntax for checking the length of a string, for example, if it is greater than 3 bytes and less than 10 bytes.

A memory pointer is a syntax that checks for int RrmIsMemory (void * pPointer), int RrmIsCodeMemory (void * pPointer), int RrmIsDataMemory (void * pPointer), that is, whether the memory pointer points to code memory, data memory, ROM, or RAM.

Control blocks and stacks are int RrmIsObject (void * pObject, int iType) and int RrmCheckStack (), that is, statements that check whether they are objects and the stack. Here, as a method of identifying a kernel object of a specific type, a mask or a relative distance may be used.

In each inspection unit, it is possible to identify whether a particular kind of kernel object is used by simply using an address of a memory.

For example, in the following syntax:

: struct Task {

int id;

...

};

struct Task t1;

When there is an object called Task, it uses only the memory address of this object to determine whether the memory address points to a Task object. Conventionally, an identification variable such as an id variable is stored as t1.id = & t1, and the start address of the object is stored there, but this can identify the objects but not different objects.

Thus, in a preferred embodiment of the present invention, a method of identifying different objects is described. In the syntax below,

t1.id = & t1 XOR mask;

In this case, a mask is uniquely assigned to each object, and then whether or not t1 is an object using mask1 can be checked by checking whether t1.id XOR mask1 == & t1, and, optionally, another XOR operation Can be verified by replacing with logical operation.

In addition, in the following syntax, the position in the structure of id, which is an identification variable, can be identified by using it differently between objects.

struct Task {

int id;

...

}

struct Task t1;

struct Mem {

int a;

int id;

...

}

struct Mem t2;

For example, if & (t2.id)-& t2 == sizeof (int) it is a memory object.

3 is a flowchart illustrating an error detection method according to another embodiment of the present invention.

Referring to FIG. 3, the error detector 110 receives a parameter that is an input value of a function from source code. In step 300, the function input parameter and the software and hardware state at the time of function call are checked. In step 302, the user-defined macro or compiler built-in macro is used to pass debugging information about the check result of the input parameter and the software and hardware state check result at the time of function call to the error handler.

Here, debugging information is passed as a parameter when calling an error handler or through a compiler built-in macro __FILE__. Also, optionally, the call may be implicitly delivered by utilizing the time at the time of invocation, etc., only by the call of the error handler itself.

In step 304, the function is processed according to the input parameter, and when the execution of the function is finished, the result value is checked, and the software and hardware states at the end point are checked. In step 306, as in step 302, debugging information about the test result is passed to the error handler using a user-defined macro or a compiler built-in macro.

4 is a flowchart illustrating an error handler operation algorithm according to another embodiment of the present invention.

Referring to FIG. 4, an algorithm for performing error processing in an error handler based on debugging information and an error type received from an error detector and an event logger is illustrated.

First, in step 400 it is determined whether there is a custom handler included in the source code. If it is determined in step 402 that the user handler exists, the flow proceeds to step 404 to call the user handler to perform error processing. If it is determined in step 402 that the user handler does not exist, in step 406 it is determined the operation mode (operation mode) of the software. Operation mode is divided into development mode and release mode. In steps 408, 410, and 416, in the development mode, the default handler for development mode is called to perform error handling, and in steps 412, 414, and 416, the release mode is called by the default handler for the release mode to perform error processing. . Here, the user handler refers to an error handling handler defined by the user in the source code, and the default handler is included in the error handler, that is, a handler in the original operating system, and the default handler is divided into development mode and release mode. .

The development mode refers to the programming phase, the default handler for development mode performs the processing of error recognition and cause identification, and the release mode refers to after the programmed software is deployed to the embedded system and distributed to individual users. The default handler for release mode handles the recognition, recovery, and isolation of an error, that is, to limit the error to the corresponding function where the error occurred, rather than to the system as a whole.

For example, if your interrupt handler handles a task-dependent function call error, you can set or unset values for specific variables at the beginning and end of the interrupt handler, and add error detection statements at the beginning of every task-dependent function. If an error is detected, error information is output in development mode. In release mode, the interrupt handler is processed in the same way as a signal in the context of the task that registered the interrupt handler.

In addition, a starvation error occurs when a large number of concurrent tasks are performed, an interrupt, a large memory, or a large IPC.

First, the case of a large number of concurrently executed tasks is determined based on the number of tasks in the waiting state and the time between two scheduling of a specific task, and warns that performance may be degraded in development mode. Blocks some tasks.

In case of an interrupt, turn off some interrupts of the interrupt. In this case, consider the number of interrupts generated by each interrupt channel, and also turn off interrupts having a low priority and interrupted but not processed at regular intervals.

In case of using large memory or large IPC, it warns that the performance may be degraded in the development mode. In the release mode, it is processed according to the policy. For example, lower priority tasks block, terminate tasks that require memory, and treat IPC as shared memory.

In the case of a deadlock error, the deadlock is recognized by drawing a resource allocation graph. For example, it includes APIs such as IntDisable (), IntEnable (), and MutexLock (). Here, deadlock refers to a state in which a competition occurs when programs acquire data for data processing and cannot wait for data to be released from each other. Assume no deadlock occurs. If an application uses BPI, it warns that a deadlock may occur in development mode. In release mode, it recognizes the deadlock and applies IIP to the task when the system is restarted.

5 is a flowchart illustrating an error handler operation algorithm according to another embodiment of the present invention.

Referring to FIG. 5, in step 500, it is determined whether the error has been recovered. In step 502, if the error is recovered, terminate. The determination of whether the error is recovered is performed by determining the return value after executing the function in the error handler. In step 502, if it is determined that the error has not been recovered, it is necessary to clean up the resource that performed the error processing, for example, a data structure for error recovery. Therefore, in step 504, it is determined whether a callback handler exists. Here, the callback function is a function that is called automatically and executed without the user's explicit call. That is, in the past, an error was detected and the resource release was coded directly, but the resource release can be automatically performed by calling a callback handler. In step 506, if it is determined that the callback handler does not exist, a result value is returned, that is, no resource release processing is performed. If there is a callback handler, then at steps 508, 510 and 512, the callback handler is invoked, the resource release is performed and the result value is returned.

6 is a view for explaining a method for checking an error using a simulator according to another embodiment of the present invention.

The simulator 600 shown in FIG. 6 may perform error recognition and event logging without adding explicit error detection and event logging routines to software. For example, in the case of stack checking, if the branch check of all branch instructions is in the symbol table, it is considered a function call, and the function's stack frame size and the task's stack pointer are used. The solution is to perform stack error checking.

The system simulator or platform simulator checks for hardware errors and debugging information to check for errors.

The invention can also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (for example, transmission over the Internet). Include.

Although described above based on the preferred embodiments of the present invention, those skilled in the art will understand that the present invention may be implemented in other specific forms without changing the technical spirit or essential features of the technical field to which the present invention belongs. Therefore, the embodiments described above are to be understood as illustrative in all respects and not as restrictive. The scope of the present invention is defined by the appended claims rather than the foregoing description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be construed as being included in the scope of the present invention. do.

In order to enhance the reliability of embedded software according to the present invention, an error of the source code is detected according to an error detection syntax added to the source code of the software, the detected error information is received, and the error is detected based on the error information. By doing so, it is possible to recognize errors in the operating system, middleware, and application programs of the embedded computer system.

In addition, the error can be recognized at more various points than in the conventional error detection method, and when the error occurs, the debugging information related to the error can be sufficiently provided by utilizing logging information including an event.

In addition, after the product is released, if an error occurs, the operation is limited to the occurrence of the error or recovery from the error. If the error is not recovered, the allocated resources can be released and the control flow of the program can be changed.

Claims (20)

As a way to increase the reliability of embedded software, (a) detecting an error of the source code according to an error detection syntax added to the source code of the software; And (b) receiving the detected error information and processing an error based on the error information. The method of claim 1, Logging log information for the event according to an event recording syntax added to the source code of the software, And receiving the logged log information to process an error based on the log information. The method of claim 2, And storing log information on the event for each event type. The method of claim 1, Further comprising dividing an operation mode of the software into a development mode or a release mode, Reliability enhancement system, characterized in that for handling the error in accordance with the divided operation mode. The method of claim 1, In step (a), (a1) checking an error of an input parameter of a specific function of the software, and passing debugging information according to the test result; (a2) checking the state of the software and hardware at the time of invoking the function, and passing debugging information according to the checked result; (a3) checking the result value according to the execution of the function when the execution of the function is finished, and delivering debugging information according to the checked result; And (a4) checking the state of the software and hardware at the end of the execution of the function, and passing debugging information according to the checked result; In step (b), And error processing based on the transmitted debugging information. The method of claim 5, wherein Delivery of the debugging information, A method for enhancing reliability characterized by using predefined user-defined macros or compiler built-in macros. The method of claim 5, wherein The inspection of the error is Reliability enhancement method characterized in that identifying the specific type of object using the memory address of the object. The method of claim 1, In step (b), Determining whether there is a predefined user handler, And in response to the user handler being present, calling the user handler to handle the error. The method of claim 8, And determining whether to recover the error based on a return result value of the user handler. The method of claim 8, As a result of the determination, if the user handler does not exist, Determining an operation mode, And handling the error by calling a default handler according to the operation mode. 12 according to claim 10, And determining whether to recover the error based on a return result value of the default handler. The method of claim 1, After step (b) above, (c) if the error is not recovered, further comprising calling a callback handler, And the callback handler releases resources according to the error processing. A recording medium having recorded thereon a program for executing a method according to any one of claims 1 to 12 on a computer. As a system for enhancing the reliability of embedded software, An error detector for detecting an error of the source code according to an error detection syntax added to the source code of the software; And And an error handler receiving the detected error information from the error detector and processing an error based on the error information. The method of claim 14, According to the event recording syntax added to the source code of the software, further comprising an event logger for logging the log information for the event, The error handler is And an error process based on the log information received from the event logger. The method of claim 15, And a queue for storing log information of the event for each event type. The method of claim 14, The system, The operation mode is divided into a development mode and a release mode, and the reliability reinforcement system, characterized in that to handle the error according to the divided operation mode. The method of claim 14, The error detector, An input checker for checking an error of an input parameter of a specific function of the software and transferring debugging information according to the check result to the error handler; A state checking unit which checks the state of the software and hardware when the function is called, and passes debugging information according to the checked result to the error handler; An output checker that checks a result value according to the function execution when the execution of the function is completed and delivers debugging information according to the checked result to the error handler; And And a status checker after checking the state of the software and hardware at the end of the execution of the function, and passing debugging information according to the checked result to the error handler. The method of claim 18, The error handler is And process the error based on the debugging information transmitted from the error detector. (a) delivering debugging information and hardware information about errors in the software to the simulator; And (b) detecting an error of the software based on the transmitted debugging information and hardware information.

Images