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 ide1itity 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 Anforde- rungen 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 Funk- tionen der Chipkartenhardware und der zu testenden Programme software- mäßig zu simulieren, in einer sogenannten"Emulation". Eine Entwurfsumgebung, die eine solche Software-Emulation für Chipkarten gemäß dem Java Card-Standard ermöglicht, wird unter dem Namen "SmGrt CafeOO Professional"von der Anmelderin vertrieben (siehe Broschüre "SmOrt Café@ ;) Professional-The Ultimate Java Card Developer's Suite", Giesecke & Devrient GmbH, Art. Nr. 2881921, Oktober 1998).

Eine softwaremäßige Emulation stimmt aber in ihrer Funktionsweise nie vollständig mit der Funktion einer hinreichend komplexen Chipkarte über- ein, 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- che 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 Pro- grammausführung auf der Chipkarte kodierte Fehlerinformationen bereit- stellen. 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 wei- tergeleitet werden. Dieses Verfahren ist umständlich und seinerseits fehler- anfällig.

Es ist daher eine Aufgabe der Erfindung, die Probleme des Stands der Tech- nik 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-Emula- tors verbundenen Aufwand zu verringern oder zu vermeiden.

Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch Ver- fahren 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 Da- ten 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- dungen 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 Entwurfs- umgebungen, 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 Übertra- gungstabelle mit einer Mehrzahl von Einträgen vorgesehen. Vorzugsweise ist jeder Eintrag einem Bereich des Programmzä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 Übertra- gungstabelle 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 Übertragungs- tabelle 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 Auftre- 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 Zugriffs- versuch 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 bevor- zugten Ausführungsformen führt das Auftreten einer Ausnahme also erst dann zum Ausführen des erfindungsgemäßen Verfahrens, wenn sicher- gestellt ist, daß die Ausnahme einen Fehler oder ein nicht vorgesehenes Problem anzeigt.

Erfindungsgemäß wird das Auftreten des vorbestimmten Ereignisses wäh- rend 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 Chip- kartensoftware gerade entwickelt werden, werden durch bevorzugte Aus- gestaltungen der Erfindung Fehlerereignisse abgefangen, die bei der Ausfüh- rung 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 automa- tisch 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 vorzugs- weise über einen oder mehrere Ausspringpunkte-sowie entsprechenden Rückspringpunkten-an mindestens eine Programmroutine 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 vorzugs- weise mit und ohne den eingespielten Patch bis auf die Fehlerbehandlung in gleicher Weise funktionsfähig.

In bevorzugten Ausgestaltungen der erfindungsgemäßen Chipkarte, des erfindungsgemäßen Verfahrens zum Bereitstellen der Fehlerbehandlungs- routine 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 verwen- deten 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 CardTM-Standards der Firma Sun Microsystems, Inc., ausgestaltet.

Eine Dokumentation über diesen Standard findet sich im Internet unter littp./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 Patc1g-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 Aus- gaberoutinen bereitstellt.

Bei dem hier beschriebenen Beispiel einer Chipkarte 10 gemäß dem Java CardTM-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 standardi- sierte 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 Specificatio7z", Revision 1.0 vom 18. Mai <BR> <BR> 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 virtuel- len Maschine 24 vorgesehen. Das Ausnahmen-Bearbeitungsmodul 28 enthält Programmroutinen, die beim Auftreten eines Ausnahme-Ereignisses (exception) aufgerufen werden. Die damit zusammenhängenden Verfahrens- schritte 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 Anwen- dungsprogramm 32 ist in einer Anwendungsprogramm-Schicht 34 angeord- net. Das Anwendungsprogramm 32 nutzt die von der API-Schicht 30 bereit- gestellten 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 Anwendungspro- gramm 32 ist ein im Bytecode vorliegendes JavaTM-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-Daten- sä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üh- rungsbeispiels 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 Programmroutinen, 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 gela- den. 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 be- schriebenen 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 Bezugs- zeichen 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 vorlie- genden Ausführungsbeispiel sind dazu in zwei Feldern 52A, 52B die Gren- zen 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 Bytecode-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 Konstanten- pool 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 Kon- stantenpool 50 enthält in einem Textfeld 54A den Namen eines Konstrukt 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 Text- feldern 54A des Konstantenpools 50 primär Namen von Methoden oder Funktionen oder Prozeduren oder Module aus dem Quellcode des Anwen- dungsprogramms 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 die- se Beschreibungen der Fehlerbehandlungsroutine 40 zuordnen, aber sie kön- nen 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 Übertra- gungstabelle 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 wer- den. In Ausführungsalternativen werden die Zuordnungsdaten 46 stets zu- sammen mit dem Anwendungsprogramm 32 geladen, während die Fehler- behandlungsroutine 40 zusammen mit der virtuellen Maschine 24 in die Chipkarte 10 eingespielt wird.

Wenn während der Programmausführung durch den Prozessor 14 der Chip- karte 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 Fehlerbehandlungs- routine 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 Programm- zä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 Programmzä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 aufge- treten 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 ermittel- ten Angaben, die sich auf den Quellcode des ausgeführten Programms beziehen, wird in Schritt 68 die zur Fehlersuche vorgesehene Nachricht 1 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 flrrayIndexOutOfBoundsException in Modul com. gd. java. gsm. compare, Zeile 123 In noch komplexeren Ausgestaltungen, bei denen weitere symbolische An- gaben in den Zuordnungsdaten 46 oder in anderen Bereichen des Speichers 16 enthalten sind, werden noch aussagekräftigere Nachrichten erzeugt, z. B. : Fehler ArrayIndexOutOfBoundsException 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

empfangen 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 Sicherheits- risiken auszuschließen. Vorzugsweise werden auch die Fehlerbehandlungs- routine 40 und die Zuordnungsdaten 46 entfernt-bzw. gar nicht erst in die Chipkarte 10 geladen-, damit das fertige Produkt möglichst viel freien Spei- cher 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.