DE102008028702A1 - Method for monitoring progress of application in virtual machine of integrated system for portable data carrier, involves carrying out transmission of state information at debug-unit - Google Patents

Abstract

The method involves carrying out a transmission of the state information (RTS) at the debug-unit (DS). The debug-unit stores the state information in a temporary storage (SP) and it reads from the temporary storage for further processing, if the state information is required for debugging of the debug-event. An independent claim is included for a device for monitoring the progress of an application in a virtual machine of an integrated system.

Description

The The invention relates to a method for monitoring the process an application in a virtual machine of an embedded Systems where the virtual machine with a debug monitor is provided, which controls the flow of the application and at a debug event at least a state information of the application to a, in particular arranged on a test computer, debug unit transmits. The invention further relates to a device for monitoring the flow of an application in a virtual machine of a Embedded system in which the virtual machine with a Debug monitoring unit is provided, which is designed to is to control the flow of the application and at least during a debug event a status information of the application to one, in particular on a debug unit arranged to be transmitted to a test computer. Furthermore, the invention relates to a portable data carrier.

Smart Cards are smart devices, which are typically a processor, have a memory and input and output means. On this is an operating system for controlling the operation of one or more Applications installed in the memory of the smart card can be loaded. In a similar way equipped many mobile devices. Such smartcards and mobile devices are also called embedded system designated.

at the development of new or the modification of existing applications is the possibility of carrying out a simple and quick tests necessary to detect and fix bugs to be able to.

For this can use so-called debug monitoring units or monitors be used. Finding and fixing an error, the so-called Debugging is in applications for embedded systems due to limited resources and limited Communication between the embedded system and a corresponding terminal usually difficult. The communication between the embedded System and a terminal application is usually about a serial interface, being based on a data exchange of binary data.

Usually a so-called master-slave communication is performed, where the terminal application is the master and the application of the embedded Systems represents the slave. If the application of the embedded Systems cooperates with a corresponding terminal application, becomes a command in a message-like form from the master application Format generated as Application Protocol Data Unit (APDU) referred to as. This message is transmitted to the slave application, wherein the master application to a response of the slave application waiting. This approach complicates the process of debugging and thus the efficient development of applications for embedded systems.

Usually Therefore, simulations are performed on a test computer, this approach has the disadvantage that debugging the Simulation does not show the real behavior of the embedded system. There is therefore a need to debug an application an embedded system, especially a Java card, directly on the embedded system.

For this it is from the US 2002/0099953 A1 It is known to install a debug monitor directly on a smart card and to use standard communication with APDUs, supplementing this standard communication with debug information and commands.

The WO 00/68797 A1 Proposes to provide two communication channels to a smartcard, of which one of the two communication channels is used for debugging.

The US 2005/0128585 A1 discloses a method and system for monitoring the operation of an application in a virtual machine. By means of a debug interface of the embedded system, the state of the application is monitored in a debug mode. Data generated during the execution of the application is recorded by the debug interface of the virtual machine. Based on the recorded data can then be made a diagnosis of the problems occurring during operation of the application.

adversely in the proposals described above, the circumstance that the performance of the debugger is proportionate is low. It is therefore an object of the present invention to provide a Specify a method and a device with which the finding and fixing bugs in an application in an embedded System, especially a Java card, on easier and faster Way is possible. It is a further object of the invention to specify a portable disk, which is a simple and efficient debugging of an application bypassing a Simulation allowed.

These objects are achieved by a method having the features of claim 1, a device having the features of claim 15 and a portable data carrier having the features of patent claim 17. advantage Adhesive embodiments emerge from the dependent claims.

The The invention provides a method for monitoring the process an application in a virtual machine of an embedded Systems where the virtual machine with a debug monitor is provided, which controls the flow of the application and at a debug event at least a state information of the application to a, in particular arranged on a test computer, debug unit transmits. The transmission of at least the state information to the Debug unit is done at the request of the debug unit. The debug unit stores the state information in a temporary memory and read them for further processing from the temporary Memory if the state information is used to debug the debug event is needed.

One Advantage of the procedure according to the invention exists in that by saving certain debugging information a much better performance can be achieved during debugging can. In particular, the communication between the debugging, embedded system with the running application and the arranged on a test computer debug unit can be reduced. In some embedded systems, the inventive allows First of all, debugging an application.

Conveniently transmits the debug monitor next to the state information at least static debug information to the debug unit, which is the at least one static debug information in the temporary Memory stores. The at least one static debug information includes one or more static variables and / or object references and / or methods or frame information and / or method component information. The additional storage of one or more of the static debug information allows a simpler and more reliable Detecting an error in the to be checked Application of the embedded system.

In another expedient embodiment provided that the debug unit updating the state information and / or the at least one static debug information by the Debug Monitor initiates when after recovery the application being monitored changes its runtime state, taking the updated data to the debug unit for storage be transmitted in the memory. If the application is stopped, the debug unit requests the state information and / or the at least one static debug information from the debug monitor at. This information is used by the debug unit to do the current program state (a software or a Software engineer). The state of the application changes not, as long as the application process continues interrupted remains. However, if the process of the application continues to change their runtime state and the cached data are obsolete. Because of this, the debug unit sets one Update the necessary data securely by getting these from the Request debug monitor.

It can be further provided that the memory different memory areas in which the state information and the at least one Static information is stored. It can, for example different memory for different purposes or be provided different types of data. The breakdown and storing the information in different memory sections can be made, for example, depending on which the data must be updated regularly and which for a longer period of time the evaluation can continue to be used.

In a concrete realization of the invention provides the embedded System is a java card.

In Another embodiment is the subsequent introduction at least one patch into the source code of an operating system of the Embedded system for debugging the application to be monitored intended. This allows debugging an application directly in the embedded system, even if the embedded system is already produced. This requires a debug monitor is not by default to be provided in the embedded system, thereby reducing security risks can be reduced.

It In this case, it is provided in particular that for the subsequent Introducing the at least one patch one or more defined patch points provided in the source code of the embedded system operating system at which or at which the debug components necessary for debugging, in particular the debug monitor, inserted become. It is thus intended to use the code of the operating system of the to change embedded system by passing through the patch introduced a corresponding debug monitoring unit becomes.

The patch adds one or more commands to the operating system source code for the following functions: Processing the debug component of the application; Setting and / or removing a breakpoint; Monitoring the breakpoint; Interruption of processing and return of a status word when the breakpoint is reached; Interruption of the processing and return of a status word when an exceptional situation is reached; and query variables of the application.

The Communication between the debug unit and the debug monitor can in a first variant via a common communication channel respectively. In an alternative variant, the communication takes place between the debug unit and the debug monitor over two communication channels, with one of the Both communication channels data concerning the debugging and another one of the two communication channels APDU commands are transmitted. In the second variant it is useful if on an external computer, which The debug unit includes software that has a so-called terminal interface and a so-called debug interface offers. The software has the task of querying the debug interface into the appropriate APDU commands for the embedded System to translate. Furthermore, the software provides for the passing of the terminal commands to the embedded system. After all Response data of the embedded system are evaluated and sent to the debug interface or the terminal with which the embedded System connected for communication, passed. An advantage This approach is that an application developer directly in the embedded system the application can test and thereby also assess the correct behavior of the embedded system can.

The Debug unit expediently packs one Debug request in an APDU command and transmits this to the debug monitor unit of the embedded Systems for further processing. In particular, the debug monitor is Part of the virtual machine.

From The invention further provides an apparatus for monitoring the flow of an application in a virtual machine of a embedded system in which the virtual machine with a debug monitoring unit is provided, which is designed to is to control the flow of the application and during a debug event at least one status information of the application to one, in particular on a test computer arranged to transmit debug unit. The debug monitor is further designed to the state information to the debug unit on request of the Debug unit to transfer. The debug unit is to trained, the state information in a temporary Store memory and store it for further processing to read out temporary memory when debugging the Debug event the state information is needed.

The Device according to the invention has the same Advantages such as these in connection with the one described above Procedures have been explained.

In a further embodiment comprises the inventive Device further means for carrying out the inventive Process.

It Furthermore, a portable data carrier is proposed, which having a virtual machine, wherein the subsequent Introduce at least one patch for debugging an application or multiple defined patch points in the source code of its operating system are provided on or at which the necessary for debugging Debug components, especially a debug monitor, are insertable.

The Invention will be described in more detail below with reference to an embodiment explained in the drawings. Show it:

1 a schematic representation of a device according to the invention for monitoring the flow of an application in a virtual machine of the embedded system, and

2 another schematic representation of an environment for debugging an application of the embedded system.

1 shows a schematic representation of an inventive device for monitoring the flow of an application in a virtual machine of an embedded system ES. Such an embedded system is also referred to as an "embedded system". The embedded system may be formed, for example, by a smart card or a mobile terminal. The embedded system ES in the exemplary embodiment has a virtual machine (not shown), which provides a virtual runtime environment for applications within the embedded system ES. As part of the virtual machine, a debug monitoring unit DM is provided, which is also called a debug monitor. Via an interface IF1, the embedded system can communicate via a communication channel CC with a second interface IF2 of a test computer PC. On the test computer PC, a debug unit DS is provided, which, inter alia, has a memory SP. The debug unit DS is thus not part of the inserted embedded system ES, but rather represents a "black box", which runs on the external test computer PC.

The Existence of the debug monitoring unit DM allowed it, a running in the embedded system ES application directly in the embedded system to investigate for errors, ie to debug. For this purpose, special debug commands are used the debug unit DS and the debug monitor DM exchanged over the communication channel CC. The debug monitor DM is part of the embedded system and controls the execution of the program to be examined for error (application) and provides Information about the running time status of the application to disposal. The debug commands are from the debug unit DS to the debug monitor DM transmit to the program execution z. B. stop or resume or certain information about z. The program stack, Request variable values, etc.

Of the Communication channel CC can either be contacted by a contact or a contactless compound, e.g. Using microwaves, be prepared. The communication channel CC can be a single Communication channel for both transmission of APDU commands and debug commands. Likewise, the communication channel over separate channels for separate transmission APDU commands or debug commands.

If the application is stopped during the debugger, The debug unit DS requests a debug-relevant one Information from the debug monitor DM. These Information includes the current runtime state of the application (State information RTS, also called run time state) and optional further static debug information SDI, which is called Static Debug Information be designated. This information can be obtained from the debug unit DS used to the current program state for further processing and evaluation.

Of the Runtime state SDI of the application does not change, as long as the application is stopped. Usually is used during debugging by the debug monitor DM the same state information multiple times through the debug unit DS requested. To avoid this and thus the performance of the Debuggers are incremented by the debug monitor DM transmitted to the debug unit DS in the memory SP cached (see SDI 'and RTS'). The memory SP can therefore also be used as a cache for the debug information be designated. This information SDI 'and RTS' will then be used by the debug unit DS for debugging, so that additional communication between the debug unit DS and the debug monitoring unit DM are avoided can.

If the application is resumed changes their running time state and those stored in the memory SP Information may not be correct. Out This is why an update is made for debugging necessary information initiated by the debug unit DS, so that the debug watchdog DM of the embedded Systems ES the appropriate information to the debug unit DM transfers, so they are cached again can be. The debug unit DS ensures that that the update at appropriate times or in appropriate Time intervals takes place.

In a modification of this fundamental thought can be provided, different memory areas or memory (not shown) in the debug unit DS provide. In the different For example, memory areas or memory may have debug information be stored separately, depending on whether this during of the debugger need to be updated or not.

In In some situations it is necessary to debug an application when the embedded system, e.g. A smart card, already produced. To debug the application in the Embedded system ES to make yourself are therefore in the source code of the operating system patches for the debugging of the application to be monitored can be introduced. You can do this with one or more defined patch points be provided in the source code of the operating system on or where the debugging components needed for debugging, in particular the debug monitor. That way, the developer gets the operating system or the developer of the application to be tested the possibility a patch for debugging in an already produced one to provide embedded system.

By providing the patch, for example, the virtual machine can be extended with commands for the following functions: the processing of the debug component of the application; the setting and / or removal of a breakpoint (brake point); the monitoring of the breakpoint; the interruption of the processing and return of a status word when the breakpoint is reached; the interruption of processing and return of a status word when an exceptional situation is reached becomes; the query of variables of the application.

• – Übersetzen der Anfragen an die Debug-Schnittstelle in die korrespondierenden APDU-Kommandos für das eingebettete System;
• – Weitergabe der Terminalkommandos an das eingebettete System;
• – Auswertung der Antwortdaten des eingebetteten Systems und Weitergabe an die Debug-Schnittstelle oder das Terminal. Das Terminal stellt dabei ein Gerät dar, mit welchem das eingebettete System zu Kommunikationszwecken verbunden ist. Die Debug-Einheit oder die dafür vorgesehene Software ist auf dem Testrechner installiert, welcher dann in Kommunikationsverbindung zu dem Terminal steht.

The debug unit can debug the application. Thus, the debug unit DS or other software designed for this purpose can offer a terminal interface and a debug interface for the developer. Via the terminal interface, the developer can send APDU commands to the embedded system to be examined. The debug interface allows the developer to debug the application on the embedded system. The debug unit or software mentioned above performs the following three tasks in the described scenario:

• - translating the requests to the debug interface into the corresponding APDU commands for the embedded system;
• - passing the terminal commands to the embedded system;
• - Evaluation of the response data of the embedded system and forwarding to the debug interface or the terminal. The terminal represents a device with which the embedded system is connected for communication purposes. The debug unit or the software provided for this purpose is installed on the test computer, which is then in communication with the terminal.

Based on 2 the invention will be described for a Java system embedded system. The rough structure is in 2 shown. The Java card is communicatively coupled to a terminal T. The terminal T is connected to a test system TS via a serial communication link C1. The test system TS includes, among other units, not shown, a Java map simulator JCS, which includes a management tool JCSM and a module OCM. The Java Map Simulator JCS is connected to a development tool DT via a communication link C2. The communication connection C2 can be designed, for example, as a TCP / IP connection. The test system TS corresponds to the test computer PC 1 ,

The Module OCM generates debug requests and packages them into generic C-APDU commands and sends them to the Java JC card. An Indian Figure unspecified further module of the Java card JC, which is part of this virtual machine, handles this received debug APDU command and adds the requested data in an R-APDU command to return this to the module OCM to send. This will debug APDU commands to the processing module Java card can be transferred Operating system changed so that this regular APDU commands from debug APDU commands.

The Module OCM is not a fully implemented debugger, but Rather, it is part of a chain of tools that together form one Train Debugger. The first part of this chain is the development tool DT, which serves as a development tool for Java map applications and as a graphical user interface for the Debugger serves. With this help, a developer will be able to a java card application like an ordinary java program to develop and debug.

The the second link in the chain is the Java Map Simulator JCS. So far, the development tool DT and the Java map simulator JCS used together to develop Java map applications and to debug. For this purpose, the development tool DT and the Java Map Simulator JCS via the communication link C2, and this as a so-called. "Java Debug Wire Protocol" (JDWP) can be trained.

Of the Java card simulator JCS itself is designed in two parts. The Management tool JCSM is for communicating with others Components responsible and manages beyond existing Java map simulations. The java card simulator puts an implementation of a real Java map on z. For example, a Windows 32 platform and has all the features of a real Java map on: a Java virtual machine, a transport layer, to receive and send APDU commands, a memory management etc. The Java Map Simulator JCS has direct access to a simulation and can process debug information to B. breakpoints too set or delete or frame or reference data pick up. All requested data will be sent to the development tool DT forwarded. The Java Map Simulator informs the development tool DT about debug events, z. B. a breakpoint event, which by the Java card simulation was triggered.

For The debugging of the application in the Java Card JC becomes the functionality Java card simulator JCS for communication with the development tool DT, for communication via APDU with the java card JC and for handling the debug components used. The OCM module is designed to be in the Java Card Simulator to be integrated and replaces the actual Java map simulation, which for the implementation of the invention Procedure is not needed.

The development tool DT acts as the actual debugger and allows a developer to run the application running on the Java Card JC by setting breakpoints, steps, etc. to control. All debug requests are therefore transmitted to the JCSM management tool of the Java Card Simulator JCS via the communication channel C2. The management tool JCSM processes these commands and uses an interface S1 to the OCM module to trigger debug requests that it itself can not handle. This concerns, for example, the creation of breakpoints, frame information, reference information, etc. The module OCM forwards the received requests to the Java Card JC or answers them directly if the requested information is stored in a memory accessible to the module OCM and is up-to-date , If the request has to be forwarded to the Java card, it is packed by the module OCM in a C-APDU command and transmitted to the Java card JC. The Java Map debug monitor detects the required data and returns it to the OCM module using an R-APDU command. The management tool JCSM uses the data from the module OCM to transfer them back to the development tool DT.

Around to trigger the execution of an application of the Java Card JC, An APDU command must be transferred to the Java card. An application transfers the APDU command to the management tool JCSM, which forwards them to the module OCM. This, in turn, transmits the APDU command the java card JC. On the java card JC becomes the APDU command processed and executed by the application. If before a breakpoint in the source code of the application through the Development tool DT has been set, the execution is the application is interrupted as soon as the breakpoint is reached. The programmer can now decide on the further progress. When the execution of the application comes to an end, returned an R-APDU command from the Java card to the OCM module, which forwards this to the management tool JCSM. This leads It eventually continues to the application, which is the original one C-APDU command has sent.

The Module OCM acts as already described in the previous description as a link to the java card, since this all Forwards debug requests and general commands to the Java Card. Similarly, the module OCM accepts responses from the Java card and does these answers, depending on whether it's an answer on a debug request or a general ISO command. In addition, the module OCM serves as a data memory. Dates, which are transferred from the Java card to the module OCM, are for subsequent data requests of the Java Map Simulator Cached JCS. This storing mechanism allows the data transmitted on the communication channel C1 reduce, as most through the management tool JCSM or the Development tool DT requested data taken from the memory can be.

Of the For example, memory can be divided into four different areas be and a frame memory (frame cache, a static memory (Static cache), a reference memory (reference cache) and a Method component cache include.

The Java Card JC debug monitor is for the processing of all incoming debug commands and returning the requested debug information responsible. In doing so, the following functionalities be exported. Setting a Breakpoint, Deleting a breakpoint, resume the virtual machine, fetch frame information, getting reference information, the Get static variables and get method component information.

The Debug monitor is part of the virtual machine, because it's the proprietary virtual machine debug interface implements, through which the module OCM internal runtime information can request. To receive the required information, the module OCM uses a public interface.

Around a distinction between regular APDU commands and Debug APDU commands sent back to the Java card need to be before the virtual machine through the debugger The debug monitor instructs you to distinguish a means for sending debug commands. This agent is part of the operating system and separates debug commands from others Commands. If a debug command has been detected, it will be replaced by the Debug Monitor Processed. The result of the Processing is then returned.

DM

Debug Monitoring Unit

IT

embedded system

RTS

state information (Runtime State)

SDI

static Debug Information (Static Debug Information)

IF1

interface the debug monitor

PC

test computer

DS

Debug unit

SP

Storage (Cache)

RTS '

saved Status information (Runtime State)

SDI '

saved static debug information (static debug information)

IF2

interface the debug unit

CC

communication channel

DT

development tool

JCS

Java card simulator

JCSM

management Great of the Java map simulator

T

terminal

JC

Java map

OCM

module

TS

test system

QUOTES INCLUDE IN THE DESCRIPTION

This list The documents listed by the applicant have been automated generated and is solely for better information recorded by the reader. The list is not part of the German Patent or utility model application. The DPMA takes over no liability for any errors or omissions.

Cited patent literature

• US 2002/0099953 A1 [0007]
• WO 00/68797 A1 [0008]
• US 2005/0128585 A1 [0009]

Claims (17)

Method for monitoring the process an application in a virtual machine of an embedded Systems (ES), in which the virtual machine with a debug monitoring unit (DM) is provided, which controls the flow of the application and at least one status information (RTS) during a debug event the application to a, in particular on a test computer arranged, Debug unit (DS) transmits, the transmission at least the state information (RTS) to the debug unit (DS) on request the debug unit (DS) and the debug unit (DS) the state information (RTS) in a temporary memory (SP) stores and this to read further processing from the temporary memory (SP), if the state information for debugging the debug event (RTS) is needed. The method of claim 1, wherein the debug monitor (DM) in addition to the state information (RTS) at least one static Transfer Debug Information (SDI) to the Debug Unit (DS), which contains the at least one static debug information (SDI) in the temporary memory (SP) stores. The method of claim 2, wherein the at least Static Debug Information (SDI) includes: - one or more static variables, and / or - object references, and or - methods or frame information, and / or - Method component information. Method according to claim 2 or 3, wherein the debug unit (DS) an update of the state information (RTS) and / or the at least one static debug information (SDI) through the Debug Monitor (DM) is triggered when after resuming the application to be monitored Running time state changes, with the updated data to the debug unit (DS) for storage in the memory (SP) become. Method according to one of claims 2 to 4, in which the memory (SP) comprises different memory areas, in which the state information (RTS) and the at least one static information (SDI) are stored. Method according to claim 4 or 5, wherein an update the data only some of the memory areas is done. Method according to one of the preceding claims, where the Embedded System (ES) uses a Java Card becomes. Method according to one of the preceding claims, in which the subsequent introduction of at least one patch in the source code of the operating system of the embedded system for the debugging of the application to be monitored in the embedded System (ES) is provided. A method according to claim 8, wherein the subsequent Introducing the at least one patch one or more defined Patch points in the source code of the embedded operating system Systems are provided on or at which necessary for debugging Debug components, especially the debug monitor (DM). A method according to claim 8 or 9, wherein the patch the source code of the operating system by one or more Commands for the following functions are extended: - To process the debug component of the application; - Put and / or Removing a breakpoint; - Monitoring the breakpoint; - interruption of processing and Return a status word when the breakpoint arrives becomes; - interruption of processing and return a status word when an exception situation is reached; - query of variables of the application. Method according to one of claims 1 to 10, characterized in that the communication between the debug unit (DS) and the debug monitoring unit (DM) via a common communication channel (CC) takes place. Method according to one of claims 1 to 10, in which the communication between the debug unit (DS) and the Debug Monitoring Unit (DM) via two communication channels (CC), using one of the two communication channels (CC) data on debugging and on another the two communication channels (CC) transmit APDU commands become. Method according to one of the preceding claims, where the debug unit (DS) has a debug request in an APDU command packaged and transmitted to the Debug Monitoring Unit (DM). Method according to one of the preceding claims, where the debug monitor (DM) part of the virtual Machine is. Device for monitoring the execution of an application in a virtual machine of an embedded system (ES), in which the virtual machine is equipped with a debug monitoring unit (DM) which is designed to control the execution of the application and, in the event of a debug event, to transmit at least one status information item (RTS) of the application to a debug unit (DS), in particular arranged on a test computer, the debug unit Monitoring unit (DM) is further adapted to transmit the state information (RTS) to the debug unit (DS) at the request of the debug unit (DS) and the debug unit (DS) is adapted to the state information (RTS) in a temporary memory (SP) store and read them from the temporary memory (SP) for further processing when the state information (RTS) is required for debugging the debug event. Apparatus according to claim 15, the further means for carrying out the method according to one of the claims 2 to 14. Portable data carrier, comprising a virtual Machine, wherein for subsequent introduction, at least a patch for debugging an application one or more defined ones Patch points are provided in the source code of his operating system, on or at which the debug components needed for debugging, in particular a debug monitoring unit, insertable are.