DE10145783A1 - Erzeugen einer Nachricht zur Fehlersuche bei einem tragbaren Datenträger - Google Patents

Abstract

Bei einem Verfahren zum Erzeugen einer zur Fehlersuche vorgesehenen Nachricht während der Ausführung eines Programms auf einer Chipkarte (10) wird ein vorbestimmtes Ereignis erkannt, ein Programmzä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

• 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 Card™-Standard ermöglicht, wird unter dem Namen "Sm@rt Café® Professional" von der Anmelderin vertrieben (siehe Broschüre "Sm@rt Café® Professional - The Ultimate Java Card Developer's 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 erfolgreiche 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 werden, 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 Meldungen 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 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 mindestens 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 Auftreten 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 Betriebssystemroutine 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 erfindungsgemäß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 Zuordnungsdaten 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 Programmroutine der Chipkarte anbindbar. Diese Programmroutine kann insbesondere eine Laufzeitumgebung 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 Chipkarte, 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 definierten 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 Card™-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 Patch-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 Card™-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 implementiert 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) aufgerufen 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 angeordnet. 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 semiparallel 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 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 Anwendungsprogramms 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 Programmroutinen 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 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 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 Konstantenpool 50 eine TLV-Struktur (TLV = tag, length, value) vorgesehen, die für jeden Eintrag 54 eine Kennung (tag), eine Längenangabe (length) und den textuellen 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 Anwendungsprogramms 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ührung 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 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 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 Beschreibung der Fehlerursache innerhalb der Chipkarte 10 erzeugt, so daß die Nachricht dann z. B. lauten würde:
  Fehler ArrayIndexOutOfBoundsException 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 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 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 (14)

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 Programmzä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 Programmausfü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 Laufzeitumgebung 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 Fehlerbehandlungsroutine (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.