KR100503429B1 - Real-time debugging method - Google Patents

Abstract

The present invention is a method for debugging source code in real time in the development of smart card operating system designing a debugging class including at least one debugging method and adding a debugging function to call the debugging method to the class of the package to debug After that, it is connected to debugging method and native interface, and it consists of designing debugging function that actually performs the operation of debugging method. The present invention can debug source code in real time in a debugging method that can be conveniently used in both a simulator and an emulator development environment, and in particular, the inconvenience of debugging due to the difference of each module language of a smart card in a smart card operating system development environment. I can eliminate it.

Description

Real-time debugging method

The present invention relates to a real-time debugging method, and more particularly, to a method for debugging source code in real time in the operating system development environment of the smart card.

In general, a smart card having an open structure is divided into a card application, an API (Application Programming Interface), a virtual machine (VM), a card operating system (COS), and a hardware. For example, a Java card includes a Java Card Virtual Machine (JCVM) on which a Card Operating System (COS) is mounted on a hardware (silicon chip) and reflects the characteristics of the Java Card. Also, Java Card API is provided to run Java Card Applet, a Java Card application, and native-interface and other added functions to enable Java Card virtual machine or Java Card Applet to call functions provided by COS. An API for is also provided.

In the case of Java cards, API is designed in Java language, while Java card virtual machine and card operating system are designed and used in C language. You may find it inconvenient to debug variables and array values in real time in the development environment.

The technical problem to be solved by the present invention is to solve the inconvenience of debugging due to the difference of programming language such as API, virtual machine, card operating system, etc. in the operating system development environment of smart card, and source code in the operating system development environment of smart card in real time To provide a way to debug.

In order to achieve the above technical problem, an embodiment of a source code real-time debugging method according to the present invention, the step of designing a debugging class including at least one debugging method; Adding the debugging method to a class of a package to be debugged; And designing a debugging function connected to the debugging method through a native interface to actually perform an operation of the debugging method.

As a result, the source code can be debugged in real time, and in particular, the inconvenience of debugging due to the difference of each module language of the smart card in the operating system development environment of the smart card can be solved.

Hereinafter, with reference to the accompanying drawings will be described in detail a source code real-time debugging method according to the present invention.

1 is a diagram illustrating a general smart card operating system development environment.

Referring to FIG. 1, the smart card operating system development environment generates an object code generation module 100 and an object code 106 that generate the source code 102 using the compiler 104 and the object code 106. The object code processing module 110 converts the test code 130 suitable for the environment of the 140 and the emulator 150, the simulator 140 and the emulator 150 to load and test the test code 130. It consists of.

The source code referred to in the present invention means all the source code constituting the smart card operating system as well as the class located at the API level. The present invention is a technology that can debug source code in real time in the development of smart card operating system, including the debugging-related API class and debugging functions in the smart card operating system, while developers perform operating system development, variables, arrays and This is a convenient way to debug PC (Program Counter) and SP (Stack Pointer) values used as internal system parameters.

When the method proposed in the present invention is applied to a card operating system development environment, a developer selects a debugging level according to the purpose of debugging and selects a variable to be debugged and calls a debugging function. Debugging levels and debugging functions can be provided in various forms, and the called debugging function uses token values to inform the developer what variables in which classes in which package are currently being debugged on the API.

The method proposed in the present invention can improve the productivity of the smart card operating system and applications by providing a convenient source code debugging environment in real time during the design and development of the operating system in the smart card operating system development environment. In addition, convenient debugging tools can accelerate the development of card operating systems and various applications.

In other words, the present invention is a technology that can provide a method of debugging source code on the API level more conveniently as a way to debug the source code in real time when developing a smart card operating system.

2 shows the internal structure of a smart card used for testing in a simulator or emulator environment.

First, the communication between the terminal 220 and the smart card 200, the smart card 200 and the terminal 220 transmits and receives mutual messages through an APDU (Application Protocol Data Unit), which APDU in the ISO 7816 standard The specified communication protocol. The smart card 200 is a passive medium that operates only when a command APDU is transmitted from the terminal 220. When the command is received from the terminal 220, the smart card 200 processes the command and transmits a response APDU to the terminal. The command APDU uses the upper 5 bytes of the APDU as the header, and the response APDU transmits the status of the card to the terminal after processing the command APDU using SW1 and SW2 2 bytes as status values.

Referring to FIG. 2, the smart card 200 has at least one applet 202, an APDU routing module 204 for transmitting a command APDU to a selected applet and receiving a response APDU of the card, and a card class named as a card API. library 206, virtual machine 208 providing platform independence, input / output (I / O) 210 responsible for APDU communication, cryptographic algorithm related modules 214, and other memory and other modules 212 ) And hardware 216.

For example, the test procedure for an applet mounted on a smart card is as follows.

After selecting the applet 5 202 to be tested using an application identifier (AID), the APDU tool 220 transmits a command APDU to be processed to the selected applet. The command APDU received by the card is received by the I / O module 210 of the smart card and transmitted to the currently selected applet 5 202 through the APDU routing module 204. The command transmitted to the applet 5 202 calls the corresponding function implemented in the applet, and then transmits the processing result to the APDU tool 220 through the I / O module 210.

When receiving a specific command related to the encryption algorithm processing from the terminal application, the process proceeds in the same manner as described above. In this case, the specific command is related to a specific function on the class library 206, the virtual machine 208, or the encryption algorithm. A function implemented in module 214 or a cryptographic accelerator implemented in hardware 216 is called to process the function.

Hereinafter, a detailed method and procedure for implementing a function for debugging source code in real time when developing the smart card operating system described so far will be described in more detail with reference to FIG. 3.

3 is a diagram illustrating steps for implementing a source code real-time debugging function according to the present invention.

Referring to FIG. 3, in order to implement the source code real-time debugging function according to the present invention, three additional modules should be implemented based on the operating system development environment of FIG. 1. The three additional steps S300, S310, and S340 are largely a debugging API design step S300, a debugging level and a debugging method adding step S310, and a debugging function design step S340. Hereinafter, specific contents are as follows.

Debugging API design step (S300) generates a debugging class (S302) and implements a method for setting the debugging method (S304) and the debugging level of various functions to be included in the debugging class (S306). In addition, a token value for providing the package to the developer for debugging the source code later is assigned to the class of each package. In addition, using the native keyword to design an interface that allows the debugging method to be connected to the debugging function on the card operating system through the native interface (S308). In general, due to the differences in API and programming language on the card operating system, debugging methods and actual implementation functions are connected through native interfaces.

The debugging level and the adding debugging function step S310 are performed by setting the debugging level and adding the debugging method to the class to be debugged using the debugging class and the debugging method designed in the debugging API design step S300.

That is, add a function that calls a method that sets the debugging level designed in the debugging API design stage to the debugging class to set the debugging level of the class to be debugged, and add a debugging method that provides debugging of various functions. . The detailed steps for the developer in the step of adding a debugging level and debugging method (S310) for source code debugging are as follows.

First, a developer selects and sets a desired debugging level on a class to be debugged, and then adds a debugging method that takes a variable of a class to be debugged as a parameter (S312). In order to check whether a variable to be debugged is located in which class in which package, a token value representing the current class is set among token values allocated in the debugging API design step (S314).

Debugging function design step (S340) designs a debugging function connected through the debugging method and the native interface of the debugging class designed in the debugging API design step (S300). The debugging function designed in the debugging function design step (S340) is a function for actually implementing the function of the debugging method designed in the debugging API design step.

Specifically, the debugging function designing step (S340) designs a debugging function that actually implements the functions of the debugging method, token setting method, and debugging level setting method declared in the debugging class of the debugging API designing step (S300). That is, in this step, a function for checking debugging conditions based on the debugging level set by the developer (S342), a function for outputting the value of a variable to be debugged in real time (S344), and a class variable currently being debugged A function for outputting in real time with reference to a token value which class is included is designed (S346).

In addition, a function for outputting an error or warning message or a function for outputting a system internal parameter value may be additionally designed according to the debugging level (S348).

The object code processing module S330 comprehensively refers to a tool for converting in units of packages using object code and generating test code for operating in an emulator environment or a simulator environment. For example, if you want to test a Java Card applet, the test code will be a Converted Applet (CAP) file.

As a whole, the classes and methods designed by the debugging API design step (S300) and the debugging level and debugging method addition step (S310) are compiled by the compiler (S320) and then generated as object code. The object code is converted into a code suitable for a simulator and an emulator environment by the object code processing module (S330). In the debugging function designing step (S340) according to the present invention, a function for performing an actual debugging function is designed at the card operating system level. . Finally, after generating the test code (binary code) that can be actually executed in the emulator and the simulator from the code changed by the object code processing module (S330) and the debugging function design step (S340) (S350), Run it in the emulator or simulator. The test code actually means a test file to be performed together with the APDU tool 220.

4a is a flowchart illustrating a flow of a smart card operating system development environment.

Referring to FIG. 4A, first, an API (password, UICC, GP, etc.) and a test applet to be mounted on a smart card are created (S400). The compiler generates the object code by compiling the source code of the created applet (S402). The object code processing module converts the object code generated by the compiler into a code suitable for an emulator or a simulator environment (S404). In addition, the test code is generated with the APDU tool to be actually executed (S408). The simulator or emulator tests the test applet and the card operating system using the test code (S410).

4b is a flowchart illustrating a flow of a smart card operating system development environment to which a real-time source code debugging method according to the present invention is applied.

Referring to FIG. 4B, a debugging class and a debugging method included in the debugging class are designed and a token value is assigned to a class of each package to be debugged (S450). After writing the test applet and API for the smart card (S452), the debugging level and the debugging method are added to the class to which the variable to be debugged belongs and the token value of the current class is set (S454).

The class, method, applet, and API created in the above step are compiled by the compiler to generate object code (S456). The generated object code is changed to a code suitable for an emulator or a simulator environment by the object code processing module (S458).

Next, a function that is connected to the debugging method of the debugging class and the native interface, exists at the operating system level of the smart card, and has a function having an actual implementation function of the debugging method of the debugging class (S460). Using the code changed by the object code processing module and the implemented debugging function, test code that is actually operable in the emulator or the simulator is generated (S462).

By creating a debugging class that includes debugging functions of various functions, designing various methods related to debugging in the class of the package to be debugged, and making them available according to the preference of the developer, the developer can use variables and system of the class to be debugged. You can debug your package's classes, tracking internal parameter values and more in real time. The actual implementation of the debugging method is implemented by a debugging function designed at the card operating system level. For this purpose, the debugging method and the card operating system level debugging function are connected by a native interface.

The steps described below represent procedures for testing in the development environment of the card operating system.

First, an applet and a script file to be tested are selected (S464), and a break point and test parameters are set in the applet to be tested (S466). And after receiving the command to be processed in the applet from the APDU tool 220 and transmits to the applet (S468). The applet parses the command and performs an operation according to the corresponding command (S470 to S476). Then, after executing the command operation or while executing the command, the variable value to be debugged and the package and class name where the variable is located are displayed. In addition, the error and warning messages are output according to the debugging level, and the APDU command processing result and the card response are transmitted to the APDU Tool 220 (S478).

When the test for all scripts is completed, the process ends (S480).

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

According to the present invention, by implementing the real-time source code debugging method in the smart card operating system development environment, a convenient development from the developer's point of view to develop and test the operating system while the developer debugs the source code in real time from the conventional limited debugging method It can provide an environment. In particular, in the case of Java Card, it is possible to solve the inconvenience of debugging due to the difference between the API and the implementation programming language of the card operating system.

In addition, the card operating system development environment to which the real-time source code debugging method according to the present invention is applied provides a convenient source code debugging environment to developers in real time, thereby improving productivity in smart card operating system and application development as well as various card operating systems and applications. Program development can be activated.

1 is a diagram illustrating a general smart card operating system development environment,

2 shows the internal structure of a smart card used for testing in a simulator or emulator environment.

3 is a diagram showing the steps for implementing a source code real-time debugging function according to the present invention,

4a is a flowchart illustrating a flow of a smart card operating system development environment, and

4b is a flowchart illustrating a flow of a smart card operating system development environment to which a real-time source code debugging method according to the present invention is applied.

Claims (5)

Designing a debugging class that includes at least one debugging method; Adding a debugging function to call the debugging method to a class of a package to be debugged; And Real-time debugging method comprising a; designing a debugging function connected to the debugging method and a native interface to actually perform the operation of the debugging method. The method of claim 1, Compiling the debugging class and the package class to generate object code; And And generating the target code as test code capable of operating in an emulator environment or a simulator environment. The method of claim 1, wherein the debugging class design step, Generating a debugging class; Designing at least one debugging method to be included in the debugging class; Designing a method for setting a debugging level; Allocating a token value for distinguishing a package to which a class to be debugged belongs and a class of the package to the class; And And designing a native interface that connects the debugging method to a debugging function including actual implementation code of the debugging method. The method of claim 1, wherein the adding of the debugging function comprises: Adding a method for setting a debugging level to a class to be debugged; And And a token value for distinguishing a package to which the class to be debugged belongs and the class to be debugged. The method of claim 1, In the debugging function designing step, a class name of a package to be debugged is output using a token value, and an error or warning and an internal parameter value according to the variable value and the debugging level of the class to be debugged are actually implemented. Designing a debugging function to the; real-time debugging method comprising a.