text: preferred embodiments of the present invention will be described below in more detail with reference to the accompanying drawings . the present invention may , however , be embodied in different forms and should not be constructed as limited to the embodiments set forth herein . rather , these embodiments are provided so that this disclosure will be thorough and complete , and will fully convey the scope of the present invention to those skilled in the art . embodiments of the invention disclosed herein relate to a method for automatically testing embedded software in an emulator environment . fig1 is a block diagram of a test system 100 according to an embodiment of the present invention . referring to fig1 , the test system 100 includes a host system 10 , an emulator 20 , an evaluation board 30 , and an os server 40 . the host system 10 generates test cases for testing an embedded software interface . the emulator 20 executes the test case generated from the host system 10 , and then outputs the result . the evaluation board 30 is provided to test the embedded software 41 in hardware . the os server 40 includes the embedded software 41 , and loads the embedded software 41 into the evaluation board 30 under the control of the emulator 20 . the host system 10 includes an embedded software analyzing engine 11 , a test case generating engine 12 , a test executing engine 13 , and a test result analyzing engine 14 . the embedded software analyzing engine 11 receives source code or object code of the embedded software 41 from the os server 40 . the embedded software analyzing engine 11 automatically identifies the specific location from an executable linker format ( elf ) file ; each of the locations represents where each interface symbol corresponding to each interface of the embedded software 41 is mapped in the source code or the object code . the test case generating engine 12 generates test cases for testing the embedded software 41 . the test case is written in a script language , which can be executed on the evaluation board . the test executing engine 13 provides the test case from the test case generating engine 12 to the emulator 20 , and controls the emulator 20 for execution . the test result analyzing engine 14 receives a test result from the emulator 20 , and analyzes the received test result . the test result analyzing engine 14 reports an analysis of the test result . the analysis may include , for instance , a summary of test coverage , fault information , and performance data . fig2 is a block diagram of an interface of an embedded system according to an embodiment of the present invention . referring to fig2 , the embedded system includes a hardware layer 31 , a hardware abstraction layer ( hal ) 32 , an operating system ( os ) layer 35 , and an application layer 36 . the os layer 35 includes embedded software 33 and kernel software 34 . as shown , device drivers are connected to the os layer 35 and the hal 32 , and are embodied in software units . the embedded software 33 includes software units ( su &# 39 ; s ) in multiple layers , which are organically connected to each other . the software units in each layer are divided into kernel - dependent software unit ( suk ), device - dependent software unit ( sud ), and processor - dependent software unit ( sup ) types . the suk depends on kernel software , and is an os service like an application program interface ( api ). the sud is software for supporting a physical device such as a lcd controller . the sup is hal software for hardware device initialization and configuration , and depends on a target processor . fig2 also illustrates hardware units hua 1 and hua 2 included in hardware layer 31 . hua 1 is associated with a register and random access memory ( ram ); hua 2 is associated with a timer , a bus , or a universal asynchronous receiver / transmitter ( uart ). fig3 is an illustration of interfaces between components in fig2 . referring to fig3 , an interface associated with a hardware unit ( hu ) that can be directly or indirectly accessed from embedded software is defined as a hardware part interface ( hpi ). an interface with respect to an os part is called an os part interface ( opi ). in total , fig3 illustrates five types of interfaces . first , a hardware part interface hpi 1 exists when a software unit such as sud or sup directly accesses a hardware unit hua 1 ( such as ram capable of reading / writing data ). second , a hardware part interface hpi 2 exists when a software unit such as sup indirectly controls a hardware unit hua 2 ( such as a timer ) through an address of a hua 1 register . third , an os part interface opi 1 exists when the sud and sup call functions of suk that are not related to the control of hardware unit . in this instance , the called functions of suk could include , for example , task management , inter - task communication , system calls related to an exceptional handling , and certain api functions . fourth , an os part interface opi 2 exists when the sud and sup call functions of suk that are directly related to a hardware unit hua 1 . in this case , the called functions of suk could include system calls for managing a virtual memory . fifth , an os part interface opi 3 exists when the sud and sup call functions of suk that is indirectly related to a hardware unit ( e . g ., where a hua 2 is indirectly controlled through a hua 1 ). the called functions of suk may relate , for example , to physical memory management , time management , interrupt handling , io management , networking . each of the five interface types above may be associated with a test interface symbol used to generate the test case , as described below with reference to fig4 a and 4b . an embodiment of the present invention relates to an automation device and method for testing an embedded software interface . such automation features are integrated into an emulator that includes basic debugging and performance monitoring functions necessary to test embedded software interfaces . an embedded software test automation method of the present invention automatically identifies an interface , generates test cases according to an interface test criteria , and performs a test on embedded software . moreover , debugging processes such as fault detection and fault cause search are integrated into the test process . fig4 a and 4b are flowcharts of a test operation order according to an embodiment of the present invention . referring to fig4 a and 4b , an embedded software test device 100 of the present invention includes an embedded sw analyzing engine 11 , a test case generating engine 12 , a test executing engine 13 , and a test result analyzing engine 14 , all coupled in series . fig4 a and 4b further illustrate processes that are performed by each of the foregoing functional blocks . the embedded software analyzing engine 11 receives the embedded software 41 from the os server 40 in an executable image such as an executable and linking format ( elf ). the embedded sw analyzing engine 11 automatically identifies interface locations and debugging information in the embedded software 41 in operation 111 . the embedded sw analyzing engine 11 extracts monitoring symbol information from the executable image in operation 112 . the monitoring symbol information is determined based on a function - call relationship that can be defined according to interface properties . the embedded sw analyzing engine 11 extracts caller and callee information associated with each function in the embedded software 40 in operation 113 . in operation 114 , the embedded sw analyzing engine 11 identifies functions in each embedded software layer . for example , the embedded software layer is automatically identified as a suk function in an os kernel layer in the case of os system calls and os api functions . a function that includes a device driver name is automatically identified as a sud of the device driver layer . moreover , a function that includes a processor name is automatically identified as a sup of the hal layer . the embedded sw analyzing engine 11 then extracts an interface type according to a function - call relationship between the embedded software layers in operation 115 . operation 115 may be based on the interface type definitions illustrated in fig3 . for example , a function - call relationship between a sud and a hua 1 that is related to ram , or a function - call relationship between sup and hua 1 that is related to ram is automatically extracted as an hpi 1 interface type . on the other hand , a function - call relationship between sup and hua 1 that is related to a special register is automatically extracted as an hpi 2 interface type . the embedded sw analyzing engine 11 identifies the interface in operation 116 , and finally determines an interface in operation 117 . referring to fig4 a , the test case generating engine 12 automatically generates a test case at each identified interface based on the extracted monitoring symbol information in operation 121 . then , in operation 122 , the test case generating engine 12 generates a test case that includes pass / fail criteria for the function associated with the monitoring symbol . each pass / fail criteria may include a set of input data and expected output data . for example , parameters and return values of a function corresponding to an embedded software interface may be limited to registers r 0 , r 1 , r 2 , and r 3 according to standard procedure call protocol that is disclosed in a hardware processor specificaion ( and thus may be automatically determined ). in operation 123 , the test case generating engine 12 converts the test case into a test script for automatically executing the test case in the emulator 20 . the test script includes a script command determining pass / fail of the test result and a script command storing the test result as a log for analyzing the test result . the test script may further include a script commands for stopping at predetermined interface locations in the embedded code , a script command for executing a test target automatically , and a script command monitoring actual output values for comparison to expected output values associated with a pass / fail standard . the test case generating engine 12 automatically generates test suite in operation 124 . a test suite is a set of test cases according to an interface coverage . each test case in the test suite is written in script language for automatically executing in an emulator such that the emulator 20 . equipped with debugging and monitoring functions . each test case includes a symbol that will be monitored in a corresponding interface , together with input data and expected output data . the process for testing embedded software is continued in fig4 b . the test executing engine 13 associates a test suite with a graphical user interface ( gui ) feature , such as a button on a test suite tool bar ; upon activation of the gui feature , the test executing engine 13 executes the selected test suite for a target embedded software by using the emulator 20 in operation 131 . other gui features could alternatively be used in operation 131 , according to design choice . in operation 132 , the test executing engine 13 stores the test results as a test log . in operation 141 , the test result analyzing engine 14 distinguishes a tested interface from an untested interface based on pass / fail information in the test log . the total interface test coverage can then be determined in operation 144 by comparing the number of tested interfaces to the total number of interfaces that were identified in the embedded software . embedded software interface tests may be continued until 100 % of the identified interfaces have been tested . the test result analyzing engine 14 analyzes fault locations and causes from the pass / fail information of the test log in operation 142 , and summarizes and / or stores such fault information in operation 145 . in operation 143 , the test result analyzing engine 14 calculates performance metrics such as maximum , minimum , and average values based on measured performance data in the test log . the test analyzing engine 14 compiles , stores , and / or reports the calculated performance metrics in operation 146 . the process illustrated in fig4 a and 4b , and described above , may be implemented in processor - executable code ( software ). the processor - executable code may be stored in a processor - readable storage medium , such a random access memory ( ram ), read - only memory ( rom ), a hard drive , or a compact disc ( cd ). the invention provides many benefits . the invention provides a method for testing embedded software in actual hardware , so that target hardware can be emulated before finishing a product . the invention also provides a software test automation device for the above automation method . advantageously , the invention automatically identifies and tests interfaces between different layers of the embedded software . moreover , the inventive method and system integrates debugging and monitoring functions of an emulator into a test automation tool so that when faults are detected , a fault cause can be suggested . the above - disclosed subject matter is to be considered illustrative , and not restrictive , and the appended claims are intended to cover all such modifications , enhancements , and other embodiments , which fall within the true spirit and scope of the present invention . thus , to the maximum extent allowed by law , the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents , and shall not be restricted or limited by the foregoing detailed description .