1. Field
One or more embodiments relate to an apparatus and a method of detecting an error, and more particularly, to a method and apparatus for detecting an application error of an embedded system.
2. Description of the Related Art
An embedded system is an apparatus which has an embedded microprocessor or microcontroller and performs only functions that are specified by an original designer. Generally, the embedded system is a specific application system which, as part of a system larger than the embedded system, includes hardware and software in order to perform special tasks.
Embedded systems are applied to a variety of application fields, for example, a control field, including factory automation, home automation, robot control, and process control; a terminal device field, including mobile phones, personal digital assistants (PDAs), smart phones, and LBS (Location Based Services); an information appliance field, including printers, Internet refrigerators, video game consoles, and HDTVs; and a network device field, including exchanges, routers, home servers, and home gateways,
Meanwhile, as embedded systems are applied to an increasing variety application fields and the number of digital applications increases, the functions of embedded systems have become more complicated, and in line with the increase in the variety of hardware systems, embedded software has been developed with a variety of development languages on a variety of operating systems. Accordingly, the number of software bugs has also been increasing.
In this changing environment, when a plurality of programs are tested or debugged in an embedded terminal to find errors or bugs, it takes much time to find errors that are purely related to the application, because of errors caused by the application's dependency on a hardware system or an operating system occur. Also, in the case of a poor embedded development environment that does not support exception handling in an operating system, it is difficult to detect an exception of an application.
FIG. 1 is a block diagram illustrating comparison of technical constructions with respect to an error detection function when an application is developed with different development languages on a variety of embedded operating systems according to conventional technology. According to the conventional technology, in the case of an operating system 1510 supporting a memory protection unit (MPU), errors are detected by using functions or macros that have similar functions but different names, such as “_try”, and “_except( )” in development language 1 1101, “try”, and “catch( )” in development language 2 1102, and “Try”, and “Catch” in development language 3 1103. In a development language such as the C language, which does not have an error detection function, a critical error cannot be automatically detected, or only some exceptional errors can be identified through a variety of application program interfaces (APIs) supported by an operating system.
Also, in the case of most small-sized operating systems 1520 that do not support an MPU, even though the development languages 1 through 3 1101 through 1103 support exception handling functions, an operating system 1521 that does not support the functions cannot detect critical errors. However, in an operating system 1522 that does support the error detection functions through some hardware exception handling functions, the error detection function 1404 supported by the operating system can be used irrespective of the development language k 1104.
However, the conventional technology has many problems, which will be described below. Firstly, when an application is developed on an operating system, if a hardware problem occurs the hardware problem should be fixed and then the application can be verified, or if a complicated error occurs due to a combination of the application and the operating system, it takes much time to find a bug purely in the application and to stabilize the application. Secondly, in an environment of a poor operating system or a development language that does not support exception handling, it is impossible to automatically detect an error in an application, and thus it is difficult to debug the application. Thirdly, because an exception handling API is supported in different ways or not supported depending on the development environment, in the case of software meant to be reused in a variety of operating system such as middleware, it is difficult to reuse the software while performing exception handling. Fourthly, when coding is performed by using only an exception handling API provided by the conventional technology, the number of source lines increases in order to process debugging and logging with reducing intervals in which exceptions occur, and thus code readability is lowered and the source becomes complicated.