EP1436703A2 - Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger - Google Patents

Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger

Info

Publication number
EP1436703A2
EP1436703A2 EP02772281A EP02772281A EP1436703A2 EP 1436703 A2 EP1436703 A2 EP 1436703A2 EP 02772281 A EP02772281 A EP 02772281A EP 02772281 A EP02772281 A EP 02772281A EP 1436703 A2 EP1436703 A2 EP 1436703A2
Authority
EP
European Patent Office
Prior art keywords
program
portable data
data carrier
source code
troubleshooting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02772281A
Other languages
English (en)
French (fr)
Inventor
Georg Kramposthuber
Thomas Stocker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP1436703A2 publication Critical patent/EP1436703A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3648—Software debugging using additional hardware

Definitions

  • the invention relates generally to the field of software development for portable data carriers, in particular in the form of chip cards, and more particularly to the field of troubleshooting software that is intended for execution by a processor of a portable data carrier or a chip card.
  • Portable data carriers in the form of chip cards are well known in many configurations. For example, they become
  • Access control or used in payment transactions usually have a semiconductor chip with a processor and at least one memory.
  • chip cards are also available in other designs, e.g. as a keychain or rings.
  • the term “chip card” is used to refer to all of these configurations.
  • chip cards which provide coded error information on the chip card when an error occurs during program execution.
  • This error information must be evaluated by experts, assigned to the respective sections in the source code of the program being executed, and then passed on to the actual program developer. This process is cumbersome and in turn prone to errors.
  • the invention is intended to do this Contribute to increasing the reliability of troubleshooting in chip card programs and / or reducing the effort associated with troubleshooting and / or reducing or avoiding the effort associated with programming a software emulator.
  • the invention is based on the basic idea of storing, at least during the design process, the data required for convenient troubleshooting in the chip card itself and the processor of the chip card ⁇ for accessing this data, for generating a fault-finding message understandable for the programmer and for output use this message as the output data record of the chip card.
  • At least one transmission table with a plurality of entries is provided as part of the assignment data stored on the chip card. Each entry is preferably assigned to a range of the program counter count. In those program sections for which the troubleshooting is to be carried out, at least one entry in the transmission table is preferably provided for each program counter reading.
  • the entries in the transmission table preferably each contain at least one entry relating to the source code of the program being executed. For example, the number of a source code line and / or the name of a source code construct and / or a reference to a name of a source code construct can be contained in each entry of the transfer table. This information preferably relates to that area, in particular that line of the source code, which corresponds to the program counter reading for which the entry in the transfer table is intended.
  • a “source code construct” is to be understood in particular, but not exclusively, to mean the names of variables, constants, functions, procedures, methods and modules.
  • the term “reference” is to be understood here in particular, but not exclusively, as pointers, references, identifiers (tags) or index numbers.
  • APDU application protocol data unit
  • the event evaluated in the troubleshooting is preferably the occurrence of an error or an exception or an interruption. These events can be triggered at the hardware or software level. If a software exception, e.g. If an access attempt occurs outside the boundaries of a memory field, this is preferably first processed by a customary exception handler in order to trap exceptions that may be provided in the normal program flow. In preferred embodiments, the occurrence of an exception only leads to the execution of the method according to the invention if it is ensured that the exception indicates an error or an unintended problem.
  • the occurrence of the predetermined event is monitored on the chip card during program execution.
  • program is to be understood in the broadest sense as a sequence of commands for the chip card processor.
  • preferred embodiments of the invention intercept error events that occur during the execution of an application program and / or a runtime environment, in particular a virtual machine, and / or an operating system routine including hardware-related drivers of the chip card ,
  • the program counter evaluated according to the invention is the program counter register of the processor or a virtual program counter of a runtime environment, which can be implemented by a further processor register or as at least one word in the memory of the chip card.
  • a virtual program counter can in particular be part of a virtual machine, for example a Java TM virtual machine.
  • the functionality according to the invention is used only for the purpose of troubleshooting during the development phase. This functionality can preferably be removed after completion of the program development in order to avoid security gaps.
  • the error handling routine required for executing the method and / or the assignment data are included in a preparatory step as a so-called patch
  • a method and a computer program product that automatically generate such error handling routines and / or mapping data and preferably provide them in the form of a patch are also considered to be within the scope of the invention.
  • the error handling routine can preferably be connected to at least one program routine of the chip card via one or more exit points - and corresponding return points.
  • This program routine can in particular be a runtime environment in which exceptions are processed while a user program is running.
  • the chip card is preferably functional in the same way with and without the patch applied, except for error handling.
  • FIG. 1 is a schematic representation of the functional layers of a chip card and the data flow according to an embodiment of the invention
  • FIG. 2 shows the data structures used for storing the assignment data in the exemplary embodiment from FIG. 1, and
  • FIG. 3 shows a flow diagram of the method sequence in the exemplary embodiment from FIG. 1.
  • FIG. 1 shows a portable data carrier in the form of a chip card 10, which corresponds to the exemplary embodiment described here
  • the chip card 10 is designed in accordance with version 2.1.1 of the Java Cßrrf TM standard from Sun Microsystems, Inc. Documentation about this standard can be found on the Internet at http://java.sun.com/products/javacard.
  • other configurations of the chip card 10 are provided, which can generally be any smart card provided with a microprocessor or microcontroller.
  • a hardware layer 12 has a processor 14, a memory 16 and other modules, not shown, which are integrated in a single semiconductor chip.
  • the memory 16 is divided into several areas, for example a program memory, a P ⁇ fc / i memory, a working memory or the like, which are used in suitable technologies, for example as a mask-programmed ROM, EEPROM, RAM, etc. are implemented.
  • the processor 14 has several registers, including a program counter 18.
  • the elements of the hardware layer 12 are known per se, except for the programming of the memory 16, which will be described in detail below.
  • a hardware-related operating system 20 is based on the hardware layer 12 and in particular provides drivers for modules of the hardware layer 12 as well as basic routines for file system administration and input and output routines.
  • a VM layer 22 is set up on the hardware-related operating system 20, which provides a virtual machine 24 - here abbreviated to" VM ".
  • the virtual machine 24 is generally a Program which simulates a different, generally standardized environment on the given chip card hardware
  • the virtual machine 24 is a Java TM virtual machine, as described in the document “Java Card TM 2.1.1 Virtual Machine Specification”, Revision 1.0 dated May 18, 2000 (available at http://java.sun.com/products/javacard).
  • virtual machine 24 may have other features or may be absent.
  • the virtual machine 24 has a virtual program counter 26, which is implemented by a register of the processor 14 or by means of the memory 16.
  • An exception processing module 28 is also provided in the virtual machine 24.
  • the exception processing module 28 contains program routines that are called when an exception event occurs. The associated process steps are described in more detail below.
  • An application program 32 is arranged in an application program layer 34. The application program 32 uses the interfaces provided by the API layer 30 in order to implement the desired function for the user of the chip card 10.
  • the API layer 30 corresponds to the specification in the document "Java Card TM 2.2.1 Application Programming Interface", revision 1.0 of May 18, 2000 (available at the address given above), and the application program 32 is an im Byte TM present Java TM cardlet (CAP). Only one application program 32 is shown by way of example in FIG. 1, but if the chip card 10 is sufficiently powerful, several application programs 32 can also be loaded into the memory 16 and executed in parallel.
  • CAP Java TM cardlet
  • the components and program components of the chip card 10 described so far are known per se.
  • the present exemplary embodiment of the invention relates to the functionality described in detail below, which makes it possible to generate a message intended for troubleshooting as output data record 38 of the chip card 10.
  • an error handling routine 40 is provided in the VM layer 22.
  • the error handling routine 40 is an optional addition - in the form of a patch - to the virtual machine 24, more precisely to its exception processing module 28, tethered.
  • the exception processing module 28 has a exit point 42, which branches to the error handling routine 40.
  • a return point 44 of the exception processing module 28 After the end of processing in the error handling routine 40, there is a return to a return point 44 of the exception processing module 28. While only one exit and return point 42, 44 is shown in FIG. 1, further such points are in the exception processing module in alternative embodiments 28 or in other program routines stored on the chip card 10, for example those of the operating system 20 or the application program 32.
  • the error handling routine 40 has access to assignment data 46.
  • the method is used when searching for errors in the application program 32.
  • the assignment data 46 therefore contain information relating to the source code of the application program 32, and the assignment data 46 are loaded into the memory 16 of the chip card 10 together with the application program 32. For these reasons, the assignment data 46 is shown in the application program layer 34 in the conceptual view of FIG. 1. In alternative embodiments in which the troubleshooting in other program routines of the chip card 10 is to be supported, e.g. in the virtual
  • the assignment data 46 relate to the source code of these program routines.
  • the structures used for storing the assignment data 46 are roughly indicated in FIG. 1 and shown in more detail in FIG. 2.
  • a transmission table 48 and a constant pool 50 are provided.
  • the transfer table 48 contains a plurality of entries, which are shown as lines in FIG. 2.
  • An entry is provided with the reference number 52 as an example.
  • Each entry 52 defines that area of the virtual program counter 26 (VPC) or, in alternative embodiments, the program counter 18 (PC) for which the entry 52 is provided.
  • the limits of this area start and end are specified in two fields 52A, 52B.
  • each entry 52 has a field 52C which contains the line number of that source code line which corresponds to the area defined by the fields 52A, 52B. For example, if 32 byfecotiss instructions with addresses 456 to 466 were generated when line 123 of the source code of the application program was translated, fields 52A, 52B and 52C would contain the values 456, 466 and 123.
  • each entry 52 in the transfer table 48 contains a reference to an entry 54 in the constant pool 50.
  • the constant pool 50 has a plurality of entries; in FIG. 2 only the entry 54 is provided with a reference symbol as an example.
  • Each entry 54 in the constant pool 50 contains, in a text field 54A, the name of a construct in the source code of the program being debugged — here the application program 32.
  • Another field 54B denotes the end of the name.
  • an indication of the length of text field 54A arranged in front of text field 54A can also be used.
  • names of methods or functions or procedures or modules from the source code of the application program 32 are primarily given in the text fields 54A of the constant pool 50.
  • the reference in field 52D of the entry in the transfer table 48 designates that entry 54 in the constant pool 50 which contains the name of the method or function or procedure or the module from the source code of the application program 32 in which the program counter range defined in the entry 52 is located located.
  • This method or function procedure or module also contains the source code line specified in entry 52 in field 52C.
  • further textual information relating to the source code of the executed program is contained in the constant pool 50 or in other structures of the assignment data 46 or in other fields of the memory 16.
  • This can e.g. be symbolic names of variables or constants or parameters, or names of structure units of the program.
  • the memory 16 preferably also contains textual descriptions of the possible causes of error or exception events. Conceptually, these descriptions can be assigned to the error handling routine 40, but they can also be contained in the constant pool 50 or in other data structures.
  • the references stored in the fields 52D of the transmission table are pointers which point to the start of the corresponding entry 54 in the constant pool 50.
  • the references in the fields 52D of the transfer table 48 are then not pointers, but rather corresponding identifiers which correspond to the respective identifiers in the constant pool 50.
  • the data of the constant pool 50 are stored directly in the transmission table 48.
  • the source code of the application program 32 is first translated in the exemplary embodiment described here. Furthermore - through an additional program that is integrated into the translator or designed as an external program may be - the mapping data 46, the error handling routine 40 and the data required to install the exit point 42 are determined and provided in the form of a patch. This patch is then loaded into a conventional chip card 10.
  • the application program 32 can be loaded into the chip card 10 on this occasion or before or only later.
  • the assignment data 46 is always loaded together with the application program 32, while the error handling routine 40 is loaded into the chip card 10 together with the virtual machine 24.
  • step 60 in FIG. 3 If, during the execution of the program by the processor 14 of the chip card 10, an exception or, in alternative embodiments, an interrupt occurs (step 60 in FIG. 3), this leads to a call to the exception processing module 28 first of all checks whether the exception is due to a program error or should be caught in the running program (trapping). In the former case, a jump is made via the exit point 42 to the error handling routine 40.
  • the error handling routine 40 first accesses the virtual program counter 26, step 62 in FIG. 3, in order to determine its counter reading.
  • the program counter 18 is accessed instead, as is indicated in FIG. 1 by a dashed arrow.
  • Step 64 in FIG. 3 is then searched for that entry 52 in the transmission table 48 which is assigned to the current program counter reading.
  • the transfer table 48 can be run through in sequence, or a binary search method can be used if the entries in the transfer table 48 are sorted, for example, by increasing values in the fields 52A.
  • the found entry 52 in the transmission table 48 contains in field 52C the line in the source code during the execution of which the runtime error occurred.
  • step 68 the message provided for troubleshooting is generated from the two items of information determined in this way, which relate to the source code of the program being executed.
  • this message can be, for example:
  • a symbolic description of the cause of the error is preferably generated within the chip card 10, so that the message is then e.g. would read:
  • the message generated in step 68 is output in a final step 70 as an output data record 38, in particular in the form of a response APDU, from the chip card 10. It can be from a usual terminal received and provides the developer with valuable information for program development without the need for additional hardware.
  • the exit point 42 is removed again in order to rule out possible safety risks.
  • the error handling routine 40 and the assignment data 46 are preferably also removed - or not even loaded into the chip card 10 at all - so that the finished product has as much free memory 16 as possible.
  • the invention simplifies the test sequence, as a result of which considerable cost savings are possible or the quality of the finished product can be increased by expanding the tests.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Bei einem Verfahren zum Erzeugen einer zur Fehlersuche vorgesehenen Nachricht wahrend der Ausführung eines Programms auf einer Chipkarte (10) wird ein vorbestimmtes Ereignis erkannt, ein Programnmzähler (18, 26) wird ausgelesen, dem Programmzählerstand wird mindestens eine Angabe zugeordnet, die sich auf den Quellcode des ausgeführten Programms bezieht, es wird die für die Fehlersuche vorgesehene Nachricht unter Verwendung der mindestens einen Angabe generiert und in einem Ausgabe-Datensatz (38) der Chipkarte (10) ausgegeben. Eine Chipkarte, ein Verfahren zum Bereitstellen einer Fehlerbehandlungsroutine (40) und/ oder von Zuordnungsdaten (46) und ein Computerprogrammprodukt weisen verwandte Merkmale auf. Durch die Erfindung wird die Zuverlässigkeit der Fehlersuche bei Chipkarten-Programmen erhöht bzw. der damit verbundene Aufwand verringert.

Description

Erzeugen einer Nachricht zur Fehlersuche bei einem tragbaren Datenträger
Die Erfindung betrifft allgemein das Gebiet der Softwareentwicklung für tragbare Datenträger, insbesondere in Gestalt von Chipkarten, und spezieller das Gebiet der Fehlersuche bei Software, die zur Ausführung durch einen Prozessor einen tragbaren Datenträger, respektive eine Chipkarte vorgesehen ist.
Tragbare Datenträger in Gestalt von Chipkarten sind in vielerlei Ausgestaltungen gut bekannt. Sie werden beispielsweise zur
Zugangskontrolle oder im Zahlungsverkehr eingesetzt und weisen in der Regel einen Halbleiterchip mit einem Prozessor und mindestens einem Speicher auf. Neben den üblichen Bauformen in Scheckkartengröße oder als kleine Kartenmodule, z.B. SIMs - subscriber identity modules bei Mobiltelefonen, werden Chipkarten auch in anderen Bauformen, z.B. als Schlüsselanhänger oder Ringe, hergestellt. Unter dem Begriff "Chipkarte" sollen im vorliegenden Text alle diese Ausgestaltungen mit bezeichnet werden.
An die auf einer Chipkarte gespeicherte Software werden hohe Anforderungen im Hinblick auf Fehlerfreiheit oder weitgehende Fehlerfreiheit gestellt, weil - erstens - Chipkarten in der Regel für sicherheitskritische Anwendungen eingesetzt werden und weil - zweitens - das nachträgliche Rückrufen bereits ausgegebener Chipkarten mit hohen Kosten verbunden ist. Die zunehmende Leistungsfähigkeit von Chipkarten hinsichtlich ihrer Rechenleistung und des verfügbaren Speichers hat zur Folge, daß sowohl der Umfang als auch die Komplexität der durch den Chipkartenprozessor ausgeführten Software immer weiter zunehmen. Dementsprechend wird es immer schwieriger, die genannten Anforderungen an die Fehlerfreiheit zu erfüllen. Neben sorgfältiger Arbeit bei der Programmentwicklung sind hierzu umfangreiche Fehlersuch- und Testverfahren erforderlich. Es ist bekannt, zum Testen von Programmen auf einer Chipkarte die Funktionen der Chipkartenhardware und der zu testenden Programme softwaremäßig zu simulieren, in einer sogenannten "Emulation". Eine Entwurfsumgebung, die eine solche Software-Emulation für Chipkarten gemäß dem Java C rd™-Standard ermöglicht, wird unter dem Namen
"Sm@rt Cafe® Professional" von der Anmelderin vertrieben (siehe Broschüre "Sm@rt Cafe® Professional - The Ultimate java Card Developers Suite", Giesecke & Devrient GmbH, Art. Nr. 288 1921, Oktober 1998).
Eine softwaremäßige Emulation stimmt aber in ihrer Funktionsweise nie vollständig mit der Funktion einer hinreichend komplexen Chipkarte überein, da sich Abweichungen bei der Nachbildung, die etwa darauf beruhen können, daß Fehler oder Eigenheiten der Chipkartenhardware nicht in der Emulation berücksichtigt wurden, nie ganz vermeiden lassen. Eine erfolgrei- ehe Programmausführung im Rahmen der Chipkarten-Emulation garantiert daher noch nicht die fehlerfreie Lauffähigkeit des Programms auf einer realen Chipkarte. Überdies erfordern die Entwicklung eines Chipkarten- Emulators und die ständige Anpassung an Änderungen der Hard- und Softwarekonfiguration der Chipkarte einen hohen Aufwand. .
Nach einem zumindest firmeninternen Stand der Technik der Anmelderin sind Chipkarten bekannt, die beim Auftreten eines Fehlers während der Programmausführung auf der Chipkarte kodierte Fehlerinformationen bereitstellen. Diese Fehlerinformationen müssen von Experten ausgewertet wer- den, den jeweiligen Abschnitten im Quellcode des ausgeführten Programms zugeordnet werden und dann an die eigentlichen Programmentwickler weitergeleitet werden. Dieses Verfahren ist umständlich und seinerseits fehleranfällig.
Es ist daher eine Aufgabe der Erfindung, die Probleme des Stands der Technik ganz oder teilweise zu vermeiden. Insbesondere soll die Erfindung dazu beitragen, die Zuverlässigkeit der Fehlersuche bei Chipkarten-Programmen zu erhöhen und/ oder den mit der Fehlersuche verbundenen Aufwand zu verringern und/ oder den mit der Programmierung eines Software-Emulators verbundenen Aufwand zu verringern oder zu vermeiden.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch Verfahren mit den Merkmalen von Anspruch 1 bzw. Anspruch 13, durch eine Chipkarte gemäß Anspruch 12 sowie durch ein Computerprogrammprodukt mit den Merkmalen von Anspruch 14. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundüberlegung aus, zumindest während des Entwurfsprozesses die für eine komfortable Fehlersuche erforderlichen Daten in der Chipkarte selbst zu speichern und den Prozessor der Chipkarte ■ zum Zugriff auf diese Daten, zur Generierung einer für den Programmierer verständlichen Fehlersuch-Nachricht und zur Ausgabe dieser Nachricht als Ausgabe-Datensatz der Chipkarte einzusetzen.
Durch die erfindungsgemäße Lösung können mit geringem Aufwand Mel- düngen für die Fehlersuche erzeugt werden, die für den Software-Entwickler verständliche Verweise auf den Quelltext des gerade getesteten Programms enthalten. Dadurch wird es möglich, die Programmentwicklung direkt unter Verwendung der Chipkarten-Hardware durchzuführen. Spezielle Entwurfsumgebungen, die eine aufwendige Hardware oder eine softwaremäßige Emulation der Chipkarte verwenden, sind nicht mehr erforderlich. Es reicht vielmehr aus, die Chipkarte an ein zum Empfangen der Ausgabe-Nachricht eingerichtetes Terminal anzuschließen. Falls ein Fehler auftritt, kann die von der Chipkarte erzeugte Ausgabe-Nachricht vom Programmierer ohne die bisher erforderliche Zwischenschaltung eines Experten ausgewertet werden. Die Aufzählungsreihenfolge der Schritte in den Ansprüchen soll nicht einschränkend aufgefaßt werden. Es sind vielmehr Ausführungsformen der Erfindung vorgesehen, in denen diese Schritte in anderer Reihenfolge oder parallel oder semi-parallel oder ineinander verzahnt ausgeführt werden.
In bevorzugten Ausgestaltungen der Erfindung ist, als Bestandteil der auf der Chipkarte gespeicherten Zuordnungsdaten, mindestens eine Übertragungstabelle mit einer Mehrzahl von Einträgen vorgesehen. Vorzugsweise ist jeder Eintrag einem Bereich des Prograrnrnzählerstands zugeordnet. In denjenigen Programmabschnitten, für die die Fehlersuche vorgenommen werden soll, ist bevorzugt für jeden Programmzählerstand mindestens ein Eintrag in der Übertragungstabelle vorgesehen.
Die Einträge in der Übertragungstabelle enthalten vorzugsweise je minde- stens eine Angabe, die sich auf den Quellcode des ausgeführten Programms bezieht. So kann beispielsweise die Nummer einer Quellcode-Zeile und/ oder der Namen eines Quellcode-Konstrukts und/ oder eine Referenz auf einen Namen eines Quellcode-Konstrukts in jedem Eintrag der Übertragungstabelle enthalten sein. Diese Angabe bezieht sich vorzugsweise auf denjenigen Bereich, insbesondere diejenige Zeile des Quellcodes, der dem Programmzählerstand entspricht, für den der Eintrag in der Übertragungstabelle vorgesehen ist. Unter einem "Quellcode-Konstrukt" sind in diesem Zusammenhang insbesondere, aber nicht abschließend, die Namen von Variablen, Konstanten, Funktionen, Prozeduren, Methoden und Modulen zu verstehen. Unter dem Begriff "Referenz" sollen hier insbesondere, aber nicht abschließend, Zeiger, Verweise, Kennungen (tags) oder Indexnummern verstanden werden.
In bevorzugten Ausführungsformen ist der Ausgabe-Datensatz eine Antwort- APDU (APDU = application protocol data unit) der Chipkarte. Es sind dann vorzugsweise keine besonderen Hardware-Einrichtungen für den Empfang des Ausgabe-Datensatzes erforderlich, sondern das übliche Terminal, an das die Chipkarte angeschlossen ist, reicht aus.
Das bei der Fehlersuche ausgewertete Ereignis ist vorzugsweise das Auf tre- ten eines Fehlers oder einer Ausnahme (exception) oder einer Unterbrechung (interrupt). Diese Ereignisse können auf Hardware- oder auf Softwareebene ausgelöst werden. Wenn eine softwaremäßige Ausnahme, z.B. ein Zugriffsversuch außerhalb der Grenzen eines Speicherfeldes, auftritt, wird diese vorzugsweise zunächst von einem üblichen Ausnahmen-Bearbeitungsmodul (exception handler) bearbeitet, um Ausnahmen abzufangen (trapping), die möglicherweise im normalen Programmablauf vorgesehen sind. In bevorzugten Ausführungsformen führt das Auftreten einer Ausnahme also erst dann zum Ausführen des erfindungsgemäßen Verfahrens, wenn sichergestellt ist, daß die Ausnahme einen Fehler oder ein nicht vorgesehenes Problem anzeigt.
Erfindungsgemäß wird das Auftreten des vorbestimmten Ereignisses während der Programmausführung auf der Chipkarte überwacht. Der Begriff "Programm" ist hierbei im weitesten Sinne als Folge von Befehlen für den Chipkartenprozessor aufzufassen. Je nachdem, welche Schichten der Chipkartensoftware gerade entwickelt werden, werden durch bevorzugte Ausgestaltungen der Erfindung Fehlerereignisse abgefangen, die bei der Ausführung eines Anwendungsprogramms und/ oder einer Laufzeitumgebung, insbesondere einer virtuellen Maschine, und/ oder einer Betriebssystem- routine einschließlich hardwarenaher Treiber der Chipkarte auftreten.
Der erfindungsgemäß ausgewertete Programmzähler ist in bevorzugten Ausführungsformen das Programmzählerregister des Prozessors oder ein virtueller Programmzähler einer Laufzeitumgebung, der durch ein weiteres Prozessorregister oder als mindestens ein Wort im Speicher der Chipkarte implementiert sein kann. Ein derartiger virtueller Programmzähler kann insbesondere Bestandteil einer virtuellen Maschine, z.B. einer Java™ Virtual Machine, sein.
In bevorzugten Ausführungsformen der Erfindung ist vorgesehen, die erfin- dungsgemäße Funktionalität nur zum Zwecke der Fehlersuche während der Entwicklungsphase einzusetzen. Vorzugsweise läßt sich diese Funktionalität nach Abschluß der Programmentwicklung entfernen, um Sicherheitslücken zu vermeiden. Insbesondere kann vorgesehen sein, die zum Ausführen des Verfahrens erforderliche Fehlerbehandlungsroutine und/ oder die Zuord- nungsdaten in einem vorbereitenden Schritt als sogenannten Patch in die
Chipkarte zu laden. Ein Verfahren und ein Computerprogrammprodukt, die derartige Fehlerbehandlungsroutinen und/ oder Zuordnungsdaten automatisch erzeugen und vorzugsweise in Form eines Patch bereitstellen, werden ebenfalls als in den Bereich der Erfindung fallend erachtet.
Nach dem Einspielen des Patch ist die Fehlerbehandlungsroutine vorzugsweise über einen oder mehrere Ausspringpunkte - sowie entsprechenden Rückspringpunkten - an mindestens eine Prograrnmroutine der Chipkarte anbindbar. Diese Programmroutine kann insbesondere eine Lauf- zeitumgebung sein, in der Ausnahmen (exceptions) während des Ablaufs eines Anwenderprogramms bearbeitet werden. Die Chipkarte ist vorzugsweise mit und ohne den eingespielten Patch bis auf die Fehlerbehandlung in gleicher Weise funktionsfähig.
In bevorzugten Ausgestaltungen der erfindungsgemäßen Cliipkarte, des erfindungsgemäßen Verfahrens zum Bereitstellen der Fehlerbehandlungsroutine und/ oder der Zuordnungsdaten sowie des erfindungsgemäßen Computerprogrammprodukts weisen diese Merkmale auf, die den oben beschriebenen oder den in den abhängigen Verfahrensansprüchen definier- ten Merkmalen entsprechen. Weitere Merkmale, Eigenschaften und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen. In den schematischen Zeichnungen zeigen:
Fig. 1 eine schematische Darstellung der Funktionsschichten einer Chipkarte und des Datenflusses gemäß einem Ausführungsbeispiel der Erfindung,
Fig. 2 eine Darstellung der zur Speicherung der Zuordnungsdaten verwendeten Datenstrukturen in dem Ausführungsbeispiel von Fig. 1, und
Fig. 3 ein Flußdiagramm des Verfahrensablaufs in dem Ausführungsbeispiel von Fig. 1.
In Fig. 1 zeigt einen tragbaren Datenträger in der Gestalt einer Chipkarte 10, welche zu dem vorliegend beschriebenen Ausführungsbeispiel der
Erfindung korrespondiert. Die Darstellung zeigt die Chipkarte 10 mit ihren aufeinander aufbauenden funktionalen Schichten, soweit die für die Erfindung relevante Funktionalität der Chipkarte 10 betroffen ist. Im hier beschriebenen Ausführungsbeispiel ist die Chipkarte 10 gemäß Version 2.1.1 des Java Cßrrf™-Standards der Firma Sun Microsystems, Inc., ausgestaltet. Eine Dokumentation über diesen Standard findet sich im Internet unter http://java.sun.com/products/javacard. In anderen Ausführungsformen der Erfindung sind andere Ausgestaltungen der Chipkarte 10 vorgesehen, die allgemein jede mit einem Mikroprozessor oder Mikrocontroller versehene Smart Card sein kann.
Eine Hardware-Schicht 12 weist einen Prozessor 14, einen Speicher 16 sowie andere nicht gezeigte Baugruppen auf, die in einem einzigen Halbleiterchip integriert sind. Der Speicher 16 ist in mehrere Bereiche, z.B. einen Programmspeicher, einen Pαfc/i-Speicher, einen Arbeitsspeicher o. dgl., unterteilt, die in geeigneten Technologien, z.B. als maskenprogrammiertes ROM, EEPROM, RAM, u.s.w. implementiert sind. Der Prozessor 14 weist mehrere Register auf, darunter einen Programmzähler 18. Die Elemente der Hardware-Schicht 12 sind, bis auf die noch im Detail zu beschreibende Programmierung des Speichers 16, an sich bekannt.
Auf die Hardware-Schicht 12 setzt ein hardwarenahes Betriebssystem 20 auf, das insbesondere Treiber für Baugruppen der Hardware-Schicht 12 sowie grundlegende Routinen für die Dateisystemverwaltung und Ein- und Ausgaberoutinen bereitstellt.
Bei dem hier beschriebenen Beispiel einer Chipkarte 10 gemäß dem Java Cαrtt"rM-Standard setzt auf das hardwarenahe Betriebssystem 20 eine VM- Schicht 22 auf, die eine virtuelle Maschine 24 - hier mit "VM" abgekürzt bereitstellt. Die virtuelle Maschine 24 ist allgemein ein Programm, das auf der gegebenen Chipkartenhardware eine andere, in der Regel standardisierte Umgebung simuliert. Im vorliegenden Ausführungsbeispiel ist die virtuelle Maschine 24 eine Java™ Virtual Machine, wie sie in dem Dokument "Java Card™ 2.1.1 Virtual Machine Specification" , Revision 1.0 vom 18. Mai 2000 (verfügbar unter http://java.sun.com/products/javacard) beschrieben ist. In anderen Ausgestaltungen der Erfindung kann die virtuelle Maschine 24 andere Eigenschaften aufweisen oder ganz fehlen.
Die virtuelle Maschine 24 weist einen virtuellen Programmzähler 26 auf, der durch ein Register des Prozessors 14 oder mittels des Speichers 16 imple- mentiert ist. Ferner ist ein Ausnahmen-Bearbeitungsmodul 28 in der virtuellen Maschine 24 vorgesehen. Das Ausnahmen-Bearbeitungsmodul 28 enthält Programmroutinen, die beim Auftreten eines Ausnahme-Ereignisses (exception) auf erufen werden. Die damit zusammenhängenden Verfahrensschritte werden unten genauer beschrieben. In Fig. 1 ist ferner eine API-Schicht 30 (API = application program interface = Anwendungsprogrammschnittstelle) gezeigt, die teils auf das hardwarenahe Betriebssystem 20 und teils auf die VM-Schicht 22 abgestützt ist. Ein Anwendungsprogramm 32 ist in einer Anwendungsprogramm-Schicht 34 angeord- net. Das Anwendungsprogramm 32 nutzt die von der API-Schicht 30 bereitgestellten Schnittstellen, um gewünschte Funktion für den Benutzer der Chipkarte 10 zu implementieren. Im hier beschriebenen Ausführungsbeispiel entspricht die API-Schicht 30 der Spezifikation in dem Dokument "Java Card™ 2.2.1 Application Programming Interface", Revision 1.0 vom 18. Mai 2000 (verfügbar unter der oben angegebenen Adresse), und das Anwendungsprogramm 32 ist ein im Bytecode vorliegendes Java™-Cardlet (CAP). In Fig. 1 ist beispielhaft nur ein Anwendungsprogramm 32 dargestellt, es können aber, bei hinreichender Leistungsfähigkeit der Chipkarte 10, auch mehrere Anwendungsprogramme 32 in den Speicher 16 geladen sein und semi- parallel ausgeführt werden.
Die Ein- und Ausgabe von Daten erfolgt über Eingabe- und Ausgabe-Datensätze 36, 38, die im vorliegenden Ausführungsbeispiel in an sich bekannter Art als Kommando- und Antwort- APDUs ausgestaltet sind (APDU = application protocol data unit).
Die bisher beschriebenen Komponenten und Programmbestandteile der Chipkarte 10 sind an sich bekannt. Gegenstand des vorliegenden Ausführungsbeispiels der Erfindung ist die im folgenden eingehend beschriebene Funktionalität, die es erlaubt, eine zur Fehlersuche vorgesehene Nachricht als Ausgabe-Datensatz 38 der Chipkarte 10 zu generieren.
Um diese Funktionalität zu verwirklichen, ist in der VM-Schicht 22 eine Fehlerbehandlungsroutine 40 vorgesehen. Die Fehlerbehandlungsroutine 40 ist als optionale Ergänzung - in Form eines Patchwes - an die virtuelle Maschine 24, genauer an deren Ausnahmen-Bearbeitungsmodul 28, angebunden. Dazu weist das Ausnahmen-Bearbeitungsmodul 28 einen Ausspringpunkt 42 auf, der zur Fehlerbehandlungsroutine 40 verzweigt. Nach dem Ende der Verarbeitung in der Fehlerbehandlungsroutine 40 erfolgt ein Rücksprung zu einem Rückspringpunkt 44 des Ausnahmen- Bearbeitungsmoduls 28. Während in Fig. 1 nur je ein Aus- und Rückspringpunkt 42, 44 gezeigt ist, sind in Ausführungsalternativen weitere solche Punkte im Ausnahmen-Bearbeitungsmodul 28 oder in anderen auf der Chipkarte 10 gespeicherten Program routinen, z.B. solchen des Betriebssystems 20 oder des Anwendungsprogramms 32, vorgesehen.
Die Fehlerbehandlungsroutine 40 hat Zugriff auf Zuordnungsdaten 46. Im vorliegenden Ausführungsbeispiel wird das Verfahren bei der Suche von Fehlern im Anwendungsprogramm 32 eingesetzt. Die Zuordnungsdaten 46 enthalten daher Angaben, die sich auf den Quellcode des Anwendungspro- gramms 32 beziehen, und die Zuordnungsdaten 46 werden zusammen mit dem Anwendungsprogramm 32 in den Speicher 16 der Chipkarte 10 geladen. In der konzeptuellen Ansicht von Fig. 1 sind die Zuordnungsdaten 46 aus diesen Gründen in der Anwendungsprogramm-Schicht 34 gezeigt. In Ausführungsalternativen, bei denen die Fehlersuche in anderen Programm- routinen der Chipkarte 10 unterstützt werden soll, z.B. in der virtuellen
Maschine 24 oder im Betriebssystem 20, beziehen sich die Zuordnungsdaten 46 auf den Quellcode dieser Programmroutinen.
Die zur Speicherung der Zuordnungsdaten 46 verwendeten Strukturen sind in Fig. 1 grob angedeutet und in Fig. 2 genauer gezeigt. Bei dem hier beschriebenen Ausführungsbeispiel sind eine Übertragungstabelle 48 und ein Konstantenpool 50 vorgesehen.
Die Übertragungstabelle 48 enthält eine Mehrzahl von Einträgen, die in Fig. 2 als Zeilen dargestellt sind. Ein Eintrag ist beispielhaft mit dem Bezugszeichen 52 versehen. Jeder Eintrag 52 definiert denjenigen Bereich des virtuellen Programmzählers 26 (VPC) oder, in Ausführungsalternativen, des Programmzählers 18 (PC), für den der Eintrag 52 vorgesehen ist. Im vorliegenden Ausführungsbeispiel sind dazu in zwei Feldern 52A, 52B die Grenzen dieses Bereichs Start und Ende angegeben. Ferner weist jeder Eintrag 52 ein Feld 52C auf, das die Zeilennummer derjenigen Quellcode-Zeile enthält, die dem durch die Felder 52A, 52B definierten Bereich entspricht. Wenn also beispielsweise bei der Übersetzung von Zeile 123 des Quellcodes des Anwendungsprogramms 32 Byfecotiß-Befehle mit den Adressen 456 bis 466 erzeugt worden sind, würden die Felder 52A, 52B und 52C die Werte 456, 466 und 123 enthalten.
Ein weiteres Feld 52D jedes Eintrags 52 in der Übertragungstabelle 48 enthält einen Verweis auf einen Eintrag 54 im Konstantenpool 50. Der Konstantenpool 50 weist eine Mehrzahl von Einträgen auf; in Fig. 2 ist beispielhaft nur der Eintrag 54 mit einem Bezugszeichen versehen. Jeder Eintrag 54 im Konstantenpool 50 enthält in einem Textfeld 54A den Namen eines Konstrukts im Quellcode des der Fehlersuche unterzogenen Programms -hier des Anwendungsprogramms 32. Ein weiteres Feld 54B bezeichnet das Ende des Namens. In Ausführungsalternativen kann statt einer Endmarkierung in Feld 54B auch eine vor dem Textfeld 54A angeordnete Angabe der Länge des Textfeldes 54A verwendet werden.
In dem hier beschriebenen, einfachen Ausführungsbeispiel sind in den Textfeldern 54A des Konstantenpools 50 primär Namen von Methoden oder Funktionen oder Prozeduren oder Module aus dem Quellcode des Anwendungsprogramms 32 angegeben. Der Verweis in Feld 52D des Eintrags in der Übertragungstabelle 48 bezeichnet denjenigen Eintrag 54 im Konstantenpool 50, der den Namen der Methode oder Funktion oder Prozedur oder des Moduls aus dem Quellcode des Anwendungsprogramms 32 enthält, in der/ dem sich der im Eintrag 52 definierte Programmzählerbereich befindet. Diese Methode bzw. Funktion Prozedur oder Modul, enthält auch die im Eintrag 52 in Feld 52C angegebene Quellcodezeile.
In komplexeren Ausführungsformen der Erfindung sind im Konstantenpool 50 oder in anderen Strukturen der Zuordnungsdaten 46 oder in anderen Feldern des Speichers 16 weitere textuelle Angaben enthalten, die sich auf den Quellcode des ausgeführten Programms beziehen. Dies können z.B. symbolische Namen von Variablen oder Konstanten oder Parametern sein, oder auch Namen von Gliederungseinheiten des Programms. Ferner enthält der Speicher 16 vorzugsweise auch textuelle Beschreibungen der möglichen Ursachen für Fehler- oder Ausnahmeereignisse. Konzeptuell lassen sich diese Beschreibungen der Fehlerbehandlungsroutine 40 zuordnen, aber sie können auch im Konstantenpool 50 oder in anderen Datenstrukturen enthalten sein.
Die in den Feldern 52D der Übertragungstabelle gespeicherten Verweise sind im vorliegenden Ausführungsbeispiel Zeiger (pointer), die auf den Beginn des entsprechenden Eintrags 54 im Konstantenpool 50 verweisen. In anderen Ausführungsbeispielen ist als Datenstruktur für den Konstanten- pool 50 eine TLV-Struktur (TLV = tag, length, value) vorgesehen, die für jeden Eintrag 54 eine Kennung (tag), eine Längenangabe (length) und den textuel- len Inhalt (value) enthält. Die Verweise in den Feldern 52D der Übertragungstabelle 48 sind dann keine Zeiger, sondern entsprechende Kennungen, die mit den jeweiligen Kennungen im Konstantenpool 50 übereinstimmen. In weiteren Ausführungsalternativen sind die Daten des Konstantenpools 50 unmittelbar in der Übertragungstabelle 48 gespeichert.
Zur Vorbereitung des erfindungsgemäßen Fehlersuchverfahrens wird im hier beschriebenen Ausführungsbeispiel zunächst der Quellcode des Anwen- dungsprogramms 32 übersetzt. Ferner werden - durch ein Zusatzprogramm, das in den Übersetzer integriert oder als externes Programm ausgestaltet sein kann - die Zuordnungsdaten 46, die Fehlerbehandlungsroutine 40 und die zum Installieren des Ausspringpunkts 42 erforderlichen Daten ermittelt und in Form eines Patch bereitgestellt. Dieser Patch wird dann in eine übliche Chipkarte 10 eingespielt. Das Anwendungsprogramm 32 kann bei dieser Gelegenheit oder vorher oder erst später in die Chipkarte 10 geladen werden. In Ausführungsalternativen werden die Zuordnungsdaten 46 stets zusammen mit dem Anwendungsprogramm 32 geladen, während die Fehlerbehandlungsroutine 40 zusammen mit der virtuellen Maschine 24 in die Chipkarte 10 eingespielt wird.
Wenn während der Programmausfültrung durch den Prozessor 14 der Chipkarte 10 ein Ausnahmeereignis (exception) oder, in Ausführungsalternativen, eine Unterbrechung (interrupt) auftritt (Schritt 60 in Fig. 3), so führt dies zu einem Aufruf des Ausnahmen-Bearbeitungsmoduls 28. Dort wird zunächst überprüft, ob die Ausnahme auf einen Programmfehler zurückgeht oder im laufenden Programm aufgefangen werden soll (trapping). Im erstgenannten Fall erfolgt ein Sprung über den Ausspringpunkt 42 zur Fehlerbehandlungsroutine 40.
Die Fehlerbehandlungsroutine 40 greift zunächst, Schritt 62 in Fig. 3, auf den virtuellen Programmzähler 26 zu, um dessen Zählerstand zu ermitteln. In Ausführungsalternativen erfolgt stattdessen ein Zugriff auf den Programmzähler 18, wie dies in Fig. 1 durch einen gestrichelten Pfeil angedeutet ist. Es wird dann, Schritt 64 in Fig. 3, nach demjenigen Eintrag 52 in der Übertragungstabelle 48 gesucht, der dem aktuellen Prograrnmzählerstand zugeordnet ist. Dazu kann entweder die Übertragungstabelle 48 der Reihe nach durchlaufen werden, oder es kann ein binäres Suchverfahren angewendet werden, wenn die Einträge in der Übertragungstabelle 48 z.B. nach aufsteigenden Werten in den Feldern 52A sortiert sind. Der aufgefundene Eintrag 52 in der Übertragungstabelle 48 enthält in Feld 52C die Zeile im Quellcode, bei deren Ausführung der Laufzeitfehler aufgetreten ist. Ferner wird über den in Feld 52D enthaltenen Verweis auf den Methodennamen in Feld 54A des Konstantenpool 50 zugegriffen, Schritt 66 in Fig. 3. Wenn der Konstantenpool 50 als TLV-Struktur implementiert ist, sind hierzu weitere Suchvorgänge erforderlich. Aus den beiden so ermittelten Angaben, die sich auf den Quellcode des ausgeführten Programms beziehen, wird in Schritt 68 die zur Fehlersuche vorgesehene Nachricht generiert. Im hier beschriebenen, besonders einfachen Ausführungsbeispiel kann diese Nachricht z.B. lauten:
Fehler 789 in Modul com.gd.java.gsm.compare, Zeile 123
Wie bereits beschrieben, wird vorzugsweise noch eine symbolische Beschrei- bung der Fehlerursache innerhalb der Chipkarte 10 erzeugt, so daß die Nachricht dann z.B. lauten würde:
Fehler ArraylndexOutOfBoundsException in Modul com.gd.java.gsm.compare, Zeile 123
In noch komplexeren Ausgestaltungen, bei denen weitere symbolische Angaben in den Zuordnungsdaten 46 oder in anderen Bereichen des Speichers 16 enthalten sind, werden noch aussagekräftigere Nachrichten erzeugt, z.B.:
Fehler ArraylndexOutOfBoundsException in Modul com.gd.java.gsm.compare (B,S), Zeile 123, Index m_SearchFile außerhalb der zulässigen Grenzen
Die in Schritt 68 generierte Nachricht wird in einem abschließenden Schritt 70 als Ausgabe-Datensatz 38, insbesondere in Form einer Antwort- APDU, von der Chipkarte 10 ausgegeben. Sie kann von einem üblichen Terminal empf angen werden und liefert dem Entwickler wertvolle Hinweise für die Programmentwicklung, ohne daß zusätzliche Hardware erforderlich wäre.
Nach dem Abschluß der Programmentwicklung und des Testvorgangs wird zumindest der Ausspringpunkt 42 wieder entfernt, um mögliche Sicherheitsrisiken auszuschließen. Vorzugsweise werden auch die Fehlerbehandlungsroutine 40 und die Zuordnungsdaten 46 entfernt - bzw. gar nicht erst in die Chipkarte 10 geladen -, damit das fertige Produkt möglichst viel freien Speicher 16 aufweist.
Insgesamt vereinfacht die Erfindung den Testablauf, wodurch erhebliche Kosteneinsparungen möglich sind bzw. durch Ausweitung der Tests die Qualität des fertiggestellten Produkts erhöht werden kann. •

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Erzeugen einer zur Fehlersuche vorgesehenen Nachricht während der Ausführung eines Programms auf einem tragbaren Datenträger (10), wobei die Nachricht mindestens ein Element aufweist, das sich auf den Quellcode des ausgeführten Programms bezieht, und wobei das Verfahren die durch den Prozessor (14) des tragbaren Datenträgers (10) ausgeführten Schritte aufweist:
Erkennen (60) eines vorbestimmten, zur Fehlersuche relevanten Ereignisses,
Auslesen (62) eines Programmzählers (18, 26),
Zugreifen (64, 66) auf in einem Speicher (16) des tragbaren Datenträgers (10) enthaltene Zuordnungsdaten (46), um dem Programmzählerstand mindestens eine Angabe zuzuordnen, die sich auf den Quellcode des ausgeführten Programms bezieht,
Generieren (68) der zur Fehlersuche vorgesehenen Nachricht unter Verwendung der mindestens einen Angabe, und
Ausgeben (70) der zur Fehlersuche vorgesehenen Nachricht in einem Ausgabe-Datensatz (38) des tragbaren Datenträgers (10).
2. Verfahren nach Anspruch 1, bei dem die Zuordnungsdaten (46) mindestens eine Übertragungstabelle (48) mit einer Mehrzahl von Einträgen (52) enthalten, wobei jeder Eintrag (52) einem Bereich des Programmzählerstands zugeordnet ist.
3. Verfahren nach Anspruch 2, bei dem zumindest einige der Einträge (52) in der Übertragungstabelle (48) jeweils eine Angabe einer Zeilennummer im Quellcode des ausgeführten Programms enthalten, wobei die angegebene Quellcode-Zeile dem Bereich des Prograrnmzählerstands entspricht, der dem Eintrag (52) in der Übertragungstabelle (48) zugeordnet ist.
4. Verfahren nach Anspruch 2 oder Anspruch 3, bei dem zumindest einige der Einträge (52) in der Übertragungstabelle (48) einen Namen oder eine Referenz auf einen Namen eines Konstrukts im Quellcode des ausgeführten Programms enthalten, das mit dem Teil des Quellcodes in Beziehung steht, der dem dem Eintrag (52) zugeordneten • Bereich des Programmzählerstands entspricht.
5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem der Ausgabe-Datensatz (38) eine Antwort- APDU des tragbaren Datenträgers (10) ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem das vorbestimmte, zur Fehlersuche relevante Ereignis ein Fehler und/ oder eine Ausnahme und/ oder eine Unterbrechung bei der Programm- ausführung durch den Prozessor (14) des tragbaren Datenträgers (10) ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem das vorbestimmte, zur Fehlersuche relevante Ereignis bei der Ausführung eines Anwendungsprogramms (32) und/ oder einer Laufzeit- Umgebung und/ oder einer Betriebssystemroutine des tragbaren Datenträgers (10) auftritt.
8. Verfahren nach einem der Ansprüche 1 bis 7, bei dem der Programmzähler (18, 26) ein Register des Prozessors (14) und/ oder ein virtueller Programmzähler (26) einer Laufzeitumgebung, insbesondere einer virtuellen Maschine (24), ist.
9. Verfahren nach einem der Ansprüche 1 bis 8, bei dem eine zum Ausführen des Verfahrens erforderliche Fehlerbehand- lungsroutine (40) über mindestens einen Ausspringpunkt (42) an eine Programmroutine des tragbaren Datenträgers (10) anbindbar ist.
10. Verfahren nach Anspruch 9, bei dem die Programmroutine, an die die Fehlerbehandlungsroutine (40) anbindbar ist, Teil einer auch ohne die Fehlerbehandlungsroutine (40) funktionsfähigen Laufzeitumgebung, insbesondere einer virtuellen Maschine (24), ist.
11. Verfahren nach Anspruch 9 oder Anspruch 10, mit dem vorbereitenden Schritt, die Fehlerbehandlungsroutine (40) und die Zuordnungsdaten (46) in den Speicher (16) des tragbaren Datenträgers (10) zu laden.
12. Tragbarer Datenträger (10) mit einem Prozessor (14) und mindestens einem Speicher (16), die zum Ausführen eines Verfahrens gemäß einem der Ansprüche 1 bis 11 eingerichtet ist.
13. Verfahren zum Bereitstellen einer Fehlerbehandlungsroutine (40) und/ oder von Zuordnungsdaten (46), die in einen Speicher (16) eines tragbaren Datenträgers (10) ladbar sind, um dem tragbaren Datenträger (10) zu veranlassen, ein Verfahren nach einem der Ansprüche 9 bis 11 auszuführen.
14. Computerprogrammprodukt, das Befehle zur Steuerung eines Computers aufweist, um den Computer zur Ausführung eines Verfahrens nach Anspruch 13 zu veranlassen.
EP02772281A 2001-09-17 2002-09-09 Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger Withdrawn EP1436703A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE2001145783 DE10145783A1 (de) 2001-09-17 2001-09-17 Erzeugen einer Nachricht zur Fehlersuche bei einem tragbaren Datenträger
DE10145783 2001-09-17
PCT/EP2002/010085 WO2003025753A2 (de) 2001-09-17 2002-09-09 Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger

Publications (1)

Publication Number Publication Date
EP1436703A2 true EP1436703A2 (de) 2004-07-14

Family

ID=7699316

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02772281A Withdrawn EP1436703A2 (de) 2001-09-17 2002-09-09 Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger

Country Status (3)

Country Link
EP (1) EP1436703A2 (de)
DE (1) DE10145783A1 (de)
WO (1) WO2003025753A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10324384B3 (de) * 2003-05-28 2004-11-04 Giesecke & Devrient Gmbh Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
DE102004007614A1 (de) * 2004-02-17 2005-09-01 Giesecke & Devrient Gmbh Datenträger mit Ablaufdiagnosespeicher
DE102005028394A1 (de) 2005-06-20 2006-12-28 Giesecke & Devrient Gmbh Behandlung von Fehlerereignissen bei einem tragbaren Datenträger

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2667419A1 (fr) * 1990-10-02 1992-04-03 Gemplus Card Int Procede de debogage de programme d'application de carte a memoire et systeme de debogage.
US5371747A (en) * 1992-06-05 1994-12-06 Convex Computer Corporation Debugger program which includes correlation of computer program source code with optimized object code
US5446900A (en) * 1992-07-24 1995-08-29 Microtec Research, Inc. Method and apparatus for statement level debugging of a computer program
US5581696A (en) * 1995-05-09 1996-12-03 Parasoft Corporation Method using a computer for automatically instrumenting a computer program for dynamic debugging
DE19930120A1 (de) * 1999-06-30 2001-01-11 Siemens Ag Multiprozessor-Tracekonzept für System on Chip Anwendungen
DE19954810B4 (de) * 1999-11-13 2007-12-27 Tenovis Gmbh & Co. Kg Verfahren zur Erzeugung und zum Debuggen eines Maschinenprogramms

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03025753A3 *

Also Published As

Publication number Publication date
WO2003025753A3 (de) 2004-01-08
WO2003025753A2 (de) 2003-03-27
DE10145783A1 (de) 2003-04-24

Similar Documents

Publication Publication Date Title
DE69720821T2 (de) Fehlersuchsystem für Programme mit einer graphischen Benutzerschnittstelle
DE60031370T2 (de) Tokenbasierte verknüpfung
DE60010420T2 (de) Automatisches Regressionstesten von Arbeitsplatz-Software
DE69533005T2 (de) Bytecodeprogramminterpreter, Verfahren und Anordnung mit Vorprüfung von Datentyprestriktionen
DE69932371T2 (de) Verschiebbare Instrumentationskennzeichen für die Prüfung und die Fehlerbeseitigung eines Computerprogramms
DE60021066T2 (de) Prüfung eines Softwarepakets
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE19960050A1 (de) Grafische Benutzerschnittstelle zur Entwicklung von Anwendungsbeispielen unter Verwendung einer Testobjektbibliothek
DE10225664A1 (de) System und Verfahren zum Prüfen von Systemabrufereignissen mit Systemabrufumhüllungen
DE19536548A1 (de) Vorrichtung und Verfahren zur vereinfachten Erzeugung von Werkzeugen zur Initialisierung und Personalisierung von und zur Kommunikation mit einer Chipkarte
EP1611510B1 (de) Kontrollierte ausführung eines für eine virtuelle maschine vorgesehenen programms auf einem tragbaren datenträger
DE102005037855A1 (de) System und Verfahren zum Speichern von Benutzerdaten in einer Partitionsdatei oder zum Verwenden einer Partitionsdatei, die Benutzerdaten enthält
DE60002455T2 (de) Verfahren und vorrichtung zur automatischen softwareprüfung
DE102004057490B4 (de) Vorrichtung und Verfahren zum Verarbeiten eines Programmcodes
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
DE10038499A1 (de) Verfahren und System für die verbesserte Entwicklungsprüfung mittels angepasster Ablaufverfolgung
EP1436703A2 (de) Erzeugen einer nachricht zur fehlersuche bei einem tragbaren datenträger
DE10357257A1 (de) Java Smart Card Chip mit für globale Variablen reserviertem Speicherbereich
EP1709534B1 (de) Ausführung eines programms durch eine virtuelle maschine
DE102005060714B4 (de) Datenverarbeitungsvorrichtung, Speicherkarte, Verfahren zum Betreiben einer Datenverarbeitungsvorrichtung und Herstellungsverfahren für eine Datenverarbeitungsvorrichtung
DE10324384B3 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
DE19926467C1 (de) Verfahren zum Betreiben eines Computersystems, Bytecode-Verifier und Computersystem
DE60213786T2 (de) System und verfahren zur automatischen erfassung von aussagen in einer java-kompatibilitätsprüfumgebung
EP1732001B1 (de) Validierung eines zur nativen Ausführung durch einen Prozessor vorgesehenen Programms auf einem Datenträger
DE102018001565A1 (de) Sicherheitselement und Verfahren zur Zugriffskontrolle auf ein Sicherheitselement

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: STOCKER, THOMAS

Inventor name: KRAMPOSTHUBER, GEORG

17P Request for examination filed

Effective date: 20040708

17Q First examination report despatched

Effective date: 20071005

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150401