DE102004052197A1

DE102004052197A1 - Verfahren zum Testen der Funktion einer datenverarbeitenden Schaltung

Info

Publication number: DE102004052197A1
Application number: DE200410052197
Authority: DE
Inventors: Dmitry Polivaev
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2004-10-27
Filing date: 2004-10-27
Publication date: 2006-05-04

Abstract

Zur Simulation der Funktion einer datenverarbeitenden Schaltung (1) wird mittels einer besonderen Beschreibungssprache die logische Struktur des Datensystems (13) der Schaltung (1) in Form eines Datenbaums (27) nachgebildet. Die Nachbildung umfaßt Datenknoten, welche die Elemente des Datenbaums (27) modellieren, sowie Verweisknoten, welche zyklenfrei entweder auf einen Datenknoten oder auf einen anderen Verweisknoten verweisen. Bevorzugt basiert die Beschreibungssprache auf XML. Weiter wird ein Testsystem (2) mit einem Testinterpreter (24) bereitgestellt, der dazu eingerichtet ist, durch Ausführung einer Testprozedur (26) bedingte Änderungen in der Nachbildung (27) der Datenstruktur der datenverarbeitenden Schaltung (1) zu verwalten und darzustellen. Vorzugweise wird dieselbe Testprozedur (26) parallel zur Simulation auch an der Schaltung (1) selbst ausgeführt und werden Abweichungen zwischen beiden Ausführungen angezeigt.

Description

Die Erfindung betrifft das Testen der Funktion einer datenverarbeitenden Schaltung, insbesondere eines tragbaren Datenträgers in Gestalt einer Chipkarte, auf der Grundlage einer Simulation der Schaltung unter Verwendung einer besonders anschaulichen Beschreibung ihrer Datenstruktur.

Bei der Qualitätssicherung von integrierten Schaltungen mit spezifischen datenverarbeitenden Funktionalitäten müssen insbesondere Funktion und Zuverlässigkeit des Mikrocontrollers überprüft und sichergestellt werden. Neben dazu erforderlichen Hardware-Tests, die in der Regel physikalisch und mittels spezieller Testkommandosätze durchgeführt werden, ist die Evaluierung der Funktionalität und das Auffinden von Programmierfehlern in den von der Schaltung auszuführenden Software-Applikationen von besonderer Bedeutung.

Zum Test der Applikationen wird üblicherweise eine Vielzahl von Testszenarien, die das Verhalten der Applikation in bestimmten Anwendungssituationen simulieren, durchgespielt um anhand der Ergebnisse die Applikation von Fehlern bereinigen und optimieren zu können.

Die Vorbereitung eines solchen Tests umfaßt zwei grundsätzliche Arbeitsschritte: Einerseits, als Ausgangspunkt der Simulation, das Herbeiführen eines bestimmten datentechnischen Zustands der integrierten Schaltung und andererseits das Entwerfen einer Testprozedur, die die zu testenden Handlungen und Manipulationen der Schaltung beschreibt.

Zusätzlich zur Einrichtung eines bestimmten Zustands auf der Schaltung selbst kann es zu einer erhöhten Effizienz und Testkontrolle beitragen, eine datentechnische Nachbildung der Schaltung in Form eines Simulationsdatensatzes in einer spezialisierten Testumgebung zu schaffen, in der die Simulation unabhängig von der eigentlichen Schaltung mittels der Testprozedur vorgenommen wird.

Der Simulationsdatensatz umfaßt dann eine Nachbildung des gesamten oder eines Teils des auf der Schaltung befindlichen Datensystems, das die von der Testprozedur angesprochenen Applikationen trägt. Dabei ist es zweckmäßig, von proprietären Datenformaten der jeweiligen Schaltung zu abstrahieren und das Datensystem in einer leicht zugänglichen und maschinenunabhängigen Computersprache nachzubilden.

Allerdings ist die Möglichkeit der Nachbildung des Datensystems einer integrierten Schaltung durch die Mächtigkeit und die Kontrollstrukturen der Beschreibungssprache beschränkt. So werden die üblichen baum- oder graphenartigen Datensysteme der Schaltung von Simulationsumgebungen meist nicht äquivalent als Datenbäume sondern z. B. tabellarisch beschrieben.

Zur Beschreibung von Datensystemen eignen sich neben einigen stark spezialisierten Ansätzen insbesondere moderne Datenmodellierungssprachen wie XML (Extensible Markup Language) oder UML (Unified Modeling Language). Beide sind weitverbreitet und weitgehend standardisiert. Zudem steht zur Entwicklung von XML-Skripten oder UML-Diagrammen ein umfangrei ches Angebot an Entwicklungswerkzeugen wie etwa Editoren und Browser zur Verfügung.

Eine besondere Schwierigkeit bei der Modellierung von datenverarbeitenden Schaltungen besteht indes darin, daß nachzubildende Datensysteme häufig nicht als reine Baumstrukturen, sondern aufgrund der Verwendung von Verweisen oder Links als strukturell vielseitige aber verwaltungstechnisch aufwendige, gerichtete Graphenstrukturen zu beschreiben sind.

Solche Verweise lassen sich in XML zwar formal beschreiben, entfalten aber bei der Ausführung der Beschreibung keine entsprechende Wirkung. XML ist nicht zur Datensimulation vorgesehen, sondern vielmehr zur strukturierten Beschreibung. Für die Beschreibung von Datensystemen könnten XML-Derivate eingesetzt werden, wie die Meta-Sprache XML-Schemata oder XPath. Auch diese erlauben es aber nur bedingt, Datensysteme integrierter Schaltungen äquivalent nachzubilden.

UML auf der anderen Seite ist zwar eine sehr mächtige graphische Sprache mit sehr komplexem Datenmodell und vielen Sprachkonstrukten. Für eine Modellierung von Datensystemen ist sie prinzipiell geeignet. Allerdings besitzt UML keine standartisierte API. Zudem kann die Sprache aufgrund ihrer Komplexität nur mit viel Aufwand für die Implementierung der Simulation benutzt werden.

Es ist vor diesem Hintergrund Aufgabe der Erfindung, eine effiziente Simulation der Funktionalität einer datenverarbeitenden Schaltung durch eine äqui valente und komfortable Nachbildung des Datensystems der Schaltung zu ermöglichen.

Diese Aufgabe wird durch ein Verfahren und ein System zum Simulieren und Testen der Funktionalität einer datenverarbeitenden Schaltung mit den Merkmalen der unabhängigen Ansprüche sowie durch die Verwendung derartiger Verfahren und Systeme gelöst. Die abhängigen Ansprüche beschreiben vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung.

Zum Zwecke der Simulation einer datenverarbeitenden Schaltung und ihrem Zusammenwirken mit den auf ihr ausführbaren Applikationen wird zunächst auf einer Testumgebung aus Datenknoten und Verweisknoten eine Nachbildung des Datensystems der datenverarbeitenden Schaltung als Datenbaum angelegt. Dabei wird die logische Struktur des Datensystems der Schaltung auf der Testumgebung äquivalent abgebildet, indem mittels Datenknoten die übliche baumartige Struktur eines Datensystems modelliert und der entstehende Datenbaum durch Verweisknoten ergänzt wird. Der Datenbaum wird aus datentragenden Elementardateien und daten- und/oder dateitragenden Verzeichnisdateien als zyklenfreier, gerichteter Graph, bestehend aus einem Wurzel- sowie mehreren hierarchisch angeordneten Datenknoten aufgebaut. Jeder Datenknoten, mit Ausnahme der Wurzelknotens, hat genau einen unmittelbar übergeordneten Knoten, den sogenannten Vaterknoten, und eine beliebige Anzahl von unmittelbar untergeordneten Knoten, den sogenannten Sohnknoten. Datenknoten mit mindestens einem Sohnknoten repräsentieren Verzeichnisdateien, Datenknoten ohne untergeordnete Knoten repräsentieren datentragende Elementardateien.

Durch die Möglichkeit mittels Verweisknoten „Abkürzungen" in die Baumstruktur einzuflechten, können beliebige Unterdatenbäume auf dieselbe Weise wie im nachzubildenden Datensystem topologisch direkt miteinander verbunden werden. Das Datensystem einer datenverarbeitenden Schaltung kann so in der Testumgebung äquivalent nachgebildet und simuliert werden.

Dabei ermöglichen Verweisknoten vorteilhaft die gemeinsame Nutzung von Dateien durch mehrere Applikationen („shared ressources"), so daß einmaliges Ändern dieser Dateien sich auf alle sie nutzenden Applikationen auswirkt. Mittels Verweisknoten lassen sich weiter auf einfache Weise logische Relationen zwischen verschiedenen Unterdatenbäumen modellieren. Ferner ergeben sich aus der zusätzlichen Möglichkeit, von logischen Namen und Bezeichnungen des Datenbaums direkt die zugehörigen, auf der Schaltung befindlichen Applikationsdaten zu referenzieren implementierungstechnische Vorteile.

Der Datenbaum wird mittels einer Beschreibungssprache erstellt und repräsentiert, die Verweisknoten unterstützt. Bei einer besonders bevorzugten Ausführungsform wird aufgrund ihrer Fähigkeit zur Datenabstraktion und Datenstrukturierung eine angepaßte, um das Konzept der Verweisknoten erweiterte Auszeichnungssprache XML verwendet.

Aufgrund ihrer Nähe zu einer gängigen Datenbeschreibungssprache, vorzugsweise XML, ist die erfindungsgemäße Datenbaumbeschreibungssprache intuitiv gut handhabbar. Insbesondere entspricht die Beschreibung eines Simulations-Datenbaumes in ihrem Aufbau nahezu genau der logischen Anordnung der Elemente des Datensystems einer realen Chipkarte.

Das Datensystem einer datenverarbeitenden Schaltung läßt sich somit unter Verwendung von Verweisknoten als gerichteter Graph vollständig und äquivalent nachbilden. Da XML eine Skript- bzw. Interpretersprache ist, wird ein erstellter Datenbaum in einer oder mehreren einem Testingenieur unmittelbar zugänglichen Textdateien im Simulationssystem abgelegt.

Weil der Prozeß des exakten Nachbildens eines bestimmten Kartenzustands bzw. eines Testszenarios meist nur schwer zu automatisieren ist, wird der Datenbaum in der Beschreibungssprache manuell als Nachbildung des Datensystems der zu testenden Schaltung erstellt. Zu diesem Zweck umfaßt die Testumgebung neben der zentralen Komponente des Testinterpreters einen Entwurfseditor, auf dem der Datenbaum in der Beschreibungssprache „programmiert" werden kann. Vorzugsweise umfaßt der Entwurfseditor unterstützende Funktionalitäten, wie z. B. Syntax-Checking, Debugger, etc.

In einer besonders bevorzugten Ausführungsform der Erfindung erfolgt die Datenbaumerstellung, indem zunächst Schemata erstellt werden, auf deren Basis erst später von Anwendern Datenbäume zu konkreten Anwendungen erstellt werden. Die Stellung der Schemata zu den Datenbäumen ist vergleichbar mit der die Beziehung von UML-Klassendiagrammen zu UML-Objektdiagrammen. Die Schemata beinhalten die Grundstrukturen von Datenbäumen. Weiter können sie Standardwerte enthalten, die herangezogen werden, wenn ein Anwender bei der Erstellung eines konkreten Datenbaumes benötigte Knoten nicht definiert. Standardwerte können z. B. Vorgaben für bestimmte Dateiattribute wie Sicherheitseinstellungen und Zugriffsrechte oder konkrete Dateninhalte sein.

Zur Erstellung eines anwendbaren Datenbaums wählt der Testingenieur ein zu der zu simulierenden Applikation grundsätzlich passendes Datenbaum- schema aus und stimmt dieses mit Hilfe des Entwurfseditors auf das gewünschte konkrete Testszenario ab. Bei der Abstimmung nimmt die Testumgebung anhand des Schemas automatisch eine Überprüfung und, soweit erforderlich, eine Vervollständigung des erstellten Datenbaumes durch Knoten mit Standardwerten vor.

Durch die automatische Kontrolle der Datenrichtigkeit und etwaiger schemagemäßer Ergänzung eines Datenbaums werden der Entwurf und die Bereitstellung von Testszenarien und -daten für eine Simulation wesentlich vereinfacht und weniger fehleranfällig. Weiter lassen sich zumindest fallweise bestehende Datenbäume komfortabel und effizient durch einfaches Ändern von Standardwerten des zugrundeliegenden Schemas an neue Testszenarien anpassen.

Bei der Erstellung eines neuen Datenbaumes wird zweckmäßig ein geeignetes Schema zugrundgelegt, um die Vorgaben des Schemas auf den zu erstellenden Datenbaum anzuwenden. Ein fertiggestellter neuer Datenbaum wird weiter zweckmäßig maschinell gegen ein Schema geprüft. Eventuell von der Grundstruktur des Schemas abweichende Datenstrukturen in dem neuen Datenbaum werden gemeldet. Fehlende benötigte Knoten, etwa für Dateieigenschaften und -attribute, werden gemäß dem Schema eingerichtet. Um Datenbäume mit Hilfe von Schemata zu erstellen, muß die benutzte Beschreibungssprache die Definition von Standardknoten mit Standardwerten unterstützen.

Bei der Erstellung von Datenbäumen können auch mehrere Datenbäume als Unterdatenbäume zu einem Gesamtdatenbaum kombiniert werden. Dies ist von Vorteil, wenn ein Datenbaum in getrennten Komponenten entwickelt wurde, weil etwa mehrere Applikationen in das gleiche Testszenario einbezogen werden sollen. Bei Verwendung einer Skriptsprache, wie dem erfindungsgemäß eingesetzten XML, als Beschreibungssprache werden die Textdateien der einzelnen Unterdatenbäume vorzugsweise durch Einlesen in den Entwurfseditor syntaktisch korrekt kombiniert. Die Kombination von Unterdatenbäumen kann auch unmittelbar vor der Simulation durch den Testinterpreter durchgeführt werden.

Der Testinterpreter dient der Ausführung der eigentlichen Simulationsanweisungen der Testprozedur auf dem das gewünschte Testszenario repräsentierenden Datenbaum. Er lädt Testprozedur und Datenbaum und führt die einzelnen Testkommandos der Testprozedur aus. Der Testinterpreter verfügt über die Fähigkeit, sowohl die Sprache der Testprozedur als auch die Repräsentationssprache des Datenbaums interpretieren zu können.

Bei einer Ausführungsform wird die beschriebene Simulationsfunktionalität der Testumgebung in ein Testverfahren eingebettet, in dem ein Testinterpreter zum einen die Ausführung einer Testprozedur auf einer zu testenden Schaltung und zum anderen parallel dazu auf den Simulationsdaten des Datenbaums veranlaßt, wodurch sich Inhalt und/oder Topologie des Datenbaums verändern können. Die Resultate der Ausführung der Testprozedur auf der datenverarbeitenden Schaltung und auf dem Datenbaum werden verglichen, wobei Abweichungen eine zu überprüfende Inkonsistenz des Schaltungsverhaltens offenbaren.

Da bei Ausführung einer Testprozedur durch den Testinterpreter viele Testkommandos den Datenbaum verändern, ist es vorteilhaft, die Ausführung der Testprozedur schrittweise überwachen und gegebenenfalls in sie eingreifen zu können. Zu diesem Zweck werden die einzelnen Arbeitsschritte des Testinterpreters zweckmäßig auf einer Anzeigeeinrichtung visualisiert. Ein Testingenieur kann so gegebenenfalls den Datenbaum in einer bestimmten Testsituation verändern, beispielsweise um eine Variante des Datenbaums durchzuspielen oder einen kritischen Parameter zu überprüfen.

Vorteilhaft wird während eines Simulationsdurchgangs jede von dem Testinterpreter vorgenommene Änderung des Datenbaumes auf einer Anzeigeeinrichtung unmittelbar visualisiert. Auf diese Weise läßt sich dann das zeitliche Verhalten einer simulierten Schaltung visualisieren.

Ebenso kann ein unter Einfluß einer Testprozedur geänderter Datenbaum durch den Testinterpreter zur späteren Auswertung abgespeichert werden. In Rahmen dieser Auswertung können die Änderungen durch einen rechnerunterstützten Vergleich mit der ursprünglichen Version des Datenbaumes analysiert werden und als Differenz-Datenbaum abgespeichert werden. Der generierte Differenz-Datenbaum kann anschließend mit seinem eigenen Schema verifiziert werden, um sicherzustellen, daß alle Änderungen in zulässigen Bereichen liegen.

In einer bevorzugten Ausführungsform der Erfindung ist die zu testende Schaltung eine Chipkarte mit einem eigenem Prozessor, insbesondere eine SmartCard. Hier ergibt sich eine Reihe von Vorteilen. Zunächst sind Chipkar ten-Datensysteme im Hinblick auf ihre Dateistruktur und -attribute weitgehend standardisiert, so daß das Bereitstellen von Simulationsdaten durch Verwendung entsprechender Datenbaumschemata besonders vereinfacht wird. Weiter werden durch die Verwendung von Verweisknoten beim Erstellen des Datenbaums die für die speicherplatzbegrenzten Chipkarten besonders wichtigen geteilten Ressourcen auch von den Simulationsdaten direkt unterstützt.

Ein weiterer Vorteil der Verwendung von Datenbäumen bei Chipkarten ist, daß auch der umgekehrte Weg, also das Aufspielen eines bestimmten Datenbaums von der Testumgebung auf eine Chipkarte, unterstützt wird. Hierzu bedarf es zwar aufgrund der üblicherweise proprietären Chipkarten-Formate einer Daten- und Formatkonversion des Datenbaums und seiner Inhalte. Prinzipiell wird aber eine besonders einfache Initialisierung bzw. Personalisierung einer Chipkarte ermöglicht, da die entsprechenden Dateien, Personalisierungsdaten und Applikationen auf der Testumgebung mittels des Entwurfseditors komfortabel zusammengestellt, simuliert und mittels geeigneter Konversionsroutinen und Schnittstellen sodann auf die Chipkarte übertragen werden können.

In einer vorteilhaften Weiterbildung der Erfindung werden Datenbäume durch maschinelle Konvertierung automatisch aus einer vorhandenen maschinenlesbaren Beschreibung von Kartendaten erzeugt. Die Beschreibung kann dabei vom Testinterpreter interpretiert und mit speziellen Off-Card-Testfällen gegen Spezifikationsanforderungen automatisch verifiziert werden.

Unter Bezugnahme auf die Zeichnung wird die Erfindung nachfolgend anhand verschiedener erfindungsgemäßer Ausführungsbeispiele und Ausführungsalternativen im Zusammenhang näher erläutert. Es zeigen:
1 einen schematischen Aufbau einer Testumgebung zum Simulieren und Testen einer Chipkarte;
2a, 2b ein Codebeispiel der Nachbildung einer Chipkarte in einem Datenbaum;
3 den Ablauf eines Verfahrens zum Erstellen eines Datenbaums;
4a bis 4f die Überprüfung und Ergänzung eines Datenbaums gemäß einem Datenbaumschema;
5a bis 5f die automatische Kombination zweier Datenbäume;
6 die automatische Kombination zweier Unterdatenbäume aufgrund eines Verweises eines logischen Namens in einem Datenbaum auf entsprechende physikalische Daten;
7 den Ablauf eines Verfahrens zum Simulieren und Testen einer datenverarbeitenden Schaltung.
1 illustriert schematisch eine bevorzugte Ausführungsform der Erfindung in einer Simulations- und Testumgebung 4. Die nachfolgend einfach Testumgebung genannte Simulations- und Testumgebung 4 setzt sich zusammen aus einem Testsystem 2 sowie einer Entwurfseinrichtung 3, welche über ein Datennetz 5 miteinander in Verbindung stehen. Testsystem 2 und Entwurfseinrichtung 3 sind auf der Basis herkömmlicher Computer aufgebaut, die zur Realisierung der erfindungsgemäßen Verfahren eingerichtet sind. Die Trennung der Komponenten 2 und 3 erfolgt zur Erleichterung der Beschreibung; praktisch können Testsystem 2 und die nachfolgend Entwurfssuite genannte Entwurfseinrichtung 3 sowohl integriert in einem einzigen Gerät wie auch einem Computernetzwerknetzwerk mit mehreren Geräten realisiert sein. Das Datennetz 5 kann eine beliebige zur Datenkommunikation geeignete Verbindung sein, z. B. ein Ethernet oder eine serielle Verbindung zwischen den beiden Computern oder auch ein portables Medium, wie z. B. eine Diskette oder ein Memory-Stick.
Stellvertretend für eine zu testende datenverarbeitende Schaltung zeigt 1 einen tragbaren Datenträger in der Ausführung einer Chipkarte 1. Diese Ausführungsform wird auch nachfolgend stets zugrundgelegt, ohne daß damit eine Beschränkung auf das Testen und Simulieren von Chipkarten 1 erfolgen soll. Vielmehr kann die datenverarbeitende Schaltung auch andere Bauformen besitzen und z. B. die Gestalt eines Kugelschreibers aufweisen oder in andere Gebrauchsgegenstände, wie z. B. eine Armbanduhr integriert sein.
Die Chipkarte 1 besitzt einer zu der Schnittstelle 20 des Testsystems 2 korrespondierende Schnittstelle 12, über die das Testsystem 2 Kommandos und Daten schicken bzw. von ihr empfangen kann. Weiter besitzt sie einen Chipkarten-Microcontroller 11 und eine hierarchisch strukturierte Speicheranordnung 10, die einen persistenten ROM-Speicher, der das Chipkarten-Betriebssystem enthält, einen flüchtigen RAM-Speicher und einem nichtflüchtigen, wiederbe schreibbaren EEPROM- oder Flash-Speicher umfaßt, in dem das Datensystem 13 der Chipkarte 1 abgelegt ist.
Der Aufbau von Chipkarten-Datensystemen 13 ist weitgehend in der ISO/IEC 7816-4 festgelegt. Ein derartiges Datensystem ist logisch als hierarchische, baumartige Dateistruktur organisiert, die typischerweise eine Wurzeldatei (MF: master file), sich verzweigende Verzeichnisdateien (DF: dedicated file) sowie Elementardateien (EF: elementary file) enthält. Letztere enthalten die eigentlichen Nutzdaten. In 1 wird das Chipkarten-Datensystem 13 durch einen Graphen symbolisiert, der von dem MF in ein EF und ein DF verzweigt, das seinerseits ein EF enthält.
Das Chipkarten-Datensystem kann Verweise (Links) enthalten, die den direkten Zugriff auf eine im Datenbaum entfernt liegende Datei erlauben. Solche Linkdateien sind nützlich unter anderem für eine speicherplatzsparende gemeinsame Verwendung von Ressourcen wie Dateien oder Schlüsseln durch mehrere Applikationen.
Das diese logisch-hierarchische Struktur bildende, zugrundeliegende Datenformat ist in der Regel proprietär und auf das jeweilige Betriebsystem bzw. den Kommandosatz des Prozessors 11 der Chipkarte 1 abgestimmt. Insbesondere gibt es Chipkarten-Datensysteme, die von der ISO 7816 abweichen können, z. B. bei JavaCard^TM. Aufgrund der Bekanntheit des inneren Aufbaus von Chipkarten wird im folgenden, soweit nicht anders erwähnt, nicht mehr jeweils nach den einzelnen Komponenten unterschieden sondern nur zusammenfassend von der Chipkarte 1 gesprochen.
Über die Schnittstelle 12 kommuniziert die Chipkarte 1 mittels eines proprietären Befehls- und Datenformats, den sogenannten APDU-Kommandos (Application Protocol Data Unit), mit der Außenwelt, im Beispiel mit dem Test- system 2. Für weiterführende Informationen über den Aufbau von Chipkarten, ihrer Datensysteme und dem APDU-Format wird auf das „Handbuch der Chipkarten", Rankl, Effing, Hanser Verlag, 2000, verwiesen.
Das Testsystem 2 basiert auf einem üblichen Computer mit einem Prozessor 22, einem Speicher 21 und einer Anzeigevorrichtung 23 in Gestalt z. B. eines Computermonitors. Es dient zur Ausführung von Testläufen. Darin werden Testkommandos zum einen an einer realen Chipkarte 1 ausgeführt, zum anderen erfolgt eine Simulation an Daten, die die Chipkarte 1 und ihr Verhalten beschreiben. Das Testsystem 2 steuert bei der Durchführung eines Testlaufes den Datenaustausch mit der Chipkarte 1 sowie die Simulation des Verhaltens der Chipkarte 1 auf der Basis der die Chipkarte 1 beschreibenden Daten.
Für die Ausführung von Testläufen verfügt das Testsystem 2 über einen, zweckmäßig in Gestalt eines Computerprogramms realisierten Testinterpreter 24. Dem Testinterpreter 24 sind die die Chipkarte 1 beschreibende Daten in Gestalt von mindestens einem Datenbaum 27 sowie Vorschriften einer Testprozedur 26 zugeordnet.
Ein Datenbaum 27 ist eine baumförmige Nachbildung des Datensystems 13 einer Chipkarte 1 in einer geeigneten Beschreibungssprache. Er basiert auf einer Struktur von Elementen, nämlich den Datenknoten, die die logische Struktur des Datensystems der Chipkarte 1 nachbilden. Dabei entspricht die topographische Anordnung der Datenknoten in dem Datenbaum 27 zumin dest weitestgehend übereinstimmend der baumartigen logischen Struktur des Datensystems 13 der Chipkarte 1. Datenbäume 27 bilden die datentechnische Grundlage der Simulation des Verhaltens einer zu testenden Chipkarte 1. Ein Datenbaum 27 bildet zu jedem Zeitpunkt einen bestimmten Zustand der Chipkarte 1 ab, wobei er alle simulations- bzw. testrelevanten Informationen enthält. Er kann die Nachbildung eines kompletten Datensystems 13 einer zu testenden Chipkarte 1 enthalten. Alternativ kann ein komplettes oder teilvollständiges Abbild eines Datensystems 13 auch als Summe von mehreren, jeweils einen Teil beschreibenden, nachfolgend als Teilbäume bezeichneten Unterdatenbäumen 27 gespeichert werden, die z. B. jeweils verschiedene, unabhängige Kartenapplikationen beschreiben bzw. diesen zugeordnet sind. Datenbäume 27 können ferner an verschiedenen Orten erstellt und verwendet werden. Hierzu werden fertig entwickelte Datenbäume 27 z. B. auf einem portablen Datenträger gespeichert. Zweckmäßig sind die Datenbäume 27 in einer separaten Verwaltungseinheit angelegt.
Neben der Verwendung als Simulations- und Testumgebung kann ein erfindungsgemäßes System, wie es in 1 dargestellt ist, auch zur Unterstützung der Initialisierung, also dem erstmaligen Laden von Applikationen und strukturierten Daten in den nichtflüchtigen Speicher, etwa den EEPROM-Speicher der Chipkarte 1, sowie der Personalisierung, also der datentechnischen Personenzuordnung der Chipkarte 1, eingesetzt werden.
Dazu wird zunächst, wie nachfolgend noch genauer beschrieben, ein Datenbaum 27 mit der gewünschten Funktionalität der Chipkarte 1 erstellt. Diesem steht bei einer Initialisierung jedoch noch kein äquivalentes Chipkarten-Datensystem 13 im Speicher 10 der Chipkarte 1 gegenüber, sondern eine zu initialisierende Chipkarte 1, in deren EEPROM- bzw. nichtflüchtigem Speicher sich noch keine Applikationen und Datenstrukturen befinden. Durch Abbilden der Datenknoten des Datenbaums 27 wird diese Karte 1 dann auf ent- sprechende proprietäre Datenstrukturen initialisiert.
Chipkarten speichern Daten hierarchisch als TLV-Strukturen (Tag-Length-Value) ab, die gemäß den im ASN.1 (Abstract Syntax Notation One) definierten „Basic Encoding Rules" (BER) kodierte Datenobjekte sind. Um mit einer Chipkarte 1 zu kommunizieren bzw. einen Datenbaum 27 einzuspielen muß der Datenbaum 27 bzw. seine XML-Repräsentation mittels zu definierender Abbildungsvorschriften auf derartige Objekte abgebildet werden. Die Abbildung der XML-Strukturen auf TLV-Strukturen und die dementsprechende Anwendung der Abbildungsvorschriften werden zweckmäßig durch den Testinterpreter 24 erledigt. Die entstehenden TLV-Objekte bilden Strukturen, die weder Teil einer Testprozedur 26 noch eines Datenbaums 27 sind, und die zur Initialisierung oder Personalisierung auf eine Chipkarte 1 übertragen werden können.
Die Entwurfssuite 3 kann ebenfalls als handelsüblicher Computer mit Prozessor 31, Speicher 30 und Anzeigeeinrichtung 32 realisiert sein. Sie steht mit dem Testsystem 2 über ein Datennetz 5 in Verbindung oder ist mit dem Testsystem 2 als integrierte Vorrichtung ausgeführt. Die Entwurfssuite 3 erlaubt den Entwurf von Datenbäumen 27 sowie die Vornahme von Änderungen darin während eines von dem Testsystem 2 ausgeführten Testlaufes. Hierzu verfügt die Entwurfssuite 3 über einen Entwurfseditor 33, eine Prüfungseinrichtung 34 zur Verifikation neu erstellter Datenbäume 27 sowie eine Verwaltungseinrichtung 35 zur Ablage verfügbarer Datenbäume und Datenbaum- Schemata. Alle drei Komponenten sind vorzugsweise als Computerprogramme realisiert, die im Speicher 30 abgelegt und auf dem Prozessor 31 lauffähig sind. Der Entwurfseditor 33 ist vorzugsweise ein „Folding"-Editor, der eine Ebenenverwaltung unterstützt, oder ein graphischer Editor für XML-Dateien. Zweckmäßig ist der Entwurfseditor 33 weiter als Texteditor ausgeführt, der durch Syntax-Prüfung und -Highlighting die Erstellung von Datenbäumen unterstützt. Zweckmäßig bietet der Entwurfseditor 33 weiterhin eine graphische Unterstützung der Datenbaumerstellung, indem er etwa anhand einer graphischen Anordnung von Datenbaumelementen automatisch eine programmförmige Beschreibung eines Datenbaumes 27 generiert.
Eine Funktion der Testinterpreters 24 ist die konsistente Verwaltung der die Chipkarte 1 beschreibenden Simulationsdaten. Dem Testinterpreter 24 ist hierzu eine Testprozedur 26 bereitgestellt, die zu testende Chipkartenbefehle bzw. die Aufrufe von zu testenden Applikationen enthält. Die Testprozedur 26 wird in der Regel ebenfalls von einem Testingenieur manuell oder semimanuell erstellt. Vorzugsweise ist sie in einer Skriptsprache verfaßt, d.h. liegt in textueller Form vor, und besteht aus einzelnen, nacheinander abzuarbeitenden Testkommandos. Beispielsweise kann eine Testprozedur 26 das Testkommando „CREATE FILE" beinhalten, welches das Anlegen einer neuen Verzeichnis- oder Elementardatei auf der Chipkarte 1 und im Datenbaum 27 bewirkt. Zum Entwurf einer Testprozedur 26, die z. B. durch Ableiten einer gewünschten Prozedur aus bereits bestehenden Prozeduren oder Basisprozeduren erfolgen kann, kann der Testingenieur eine spezielle Testentwurfsvorrichtung einsetzen, die ebenfalls mit der Simulationsvorrichtung 2 über ein geeignetes Datennetz 5 in Verbindung steht.
Zur Ausführung eines Testlaufes bringt das Testsystem 2 unter Verwendung eines Datenbaumes 27 eine Testprozedur 26 zur Ausführung. Auf dem einen bestimmten Kartenzustand beschreibenden Datenbaum 27 erfolgt im Rahmen des Testlaufs eine Simulation des Kartenverhaltens. Infolge der Ausführung der Testprozedur 26 können sich Daten und/oder Topologie des Datenbaumes 27 ändern. Die Änderung wird von dem Testinterpreter 24 verwaltet. Parallel zur Simulation führt das Testsystem 2 gemäß den Kommandos der Testprozedur 26 einen Datenaustausch mit der zu testenden Chipkarte 1 durch. Entsprechend den Kommandos ändert sich darauf auch der Zustand des Datensystems 13 der Karte 1. Die beiden Zustände, den „realen" der Chipkarte 1 und den simulierten des Datenbaumes 27 hält das Testsystem 2 dabei stets konsistent. Weichen beide voneinander ab, erzeugt das Testsystem 2 eine Fehlermeldung und bringt diese auf der Anzeigevorrichtung 23 zur Anzeige.
Zur Beschreibung von Datenbäumen 27 wird eine besonders geeignete Beschreibungssprache gewählt, die intuitiv anwendbar ist und es erlaubt, eine vorgegebene Datenstruktur einer Chipkarte 1 einfach in die Beschreibung eines Datenbaumes umzusetzen. Die Eignung zur Beschreibung von Datenbäumen 27 bildet dabei die Hauptanforderung an eine geeignete Beschreibungssprache.
Ein Datenbaum 27 umfaßt eine Mehrzahl von logisch darunter auf virtuellen Ästen hierarchisch angeordneten Datenknoten. Jeder Datenknoten kann mindestens einen Datensatz und einen Satz von Verweisen auf ihm unmittelbar untergeordnete Datenknoten, den Sohnknoten, speichern. Die Sohnknoten sind von ihnen unmittelbar übergeordneten Datenknoten, den Vaterknoten, über einen eindeutigen Schlüssel erreichbar. Der Schlüssel kann zum Beispiel aus Angaben eines Typs – etwa EF für Elementardatei oder DF für Verzeichnisdatei – und des Namens eines zu verweisenden Sohnknotens bestehen. Ein Datenknoten hat, in XML-naher Darstellung, beispielsweise folgendes Format:
<d3:node type="{Type}" name="{Name}" value={Value}/>
oder erfindungsgemäß modifiziert:
({Typ} {Name}) = {Value}.
Jedem Datenbaum 27 ist außerdem ein besonderer Knoten, der Wurzelknoten, zugeordnet, der vom Testinterpreter 24 unmittelbar von jedem Baumknoten über einen speziellen Schlüssel erreichbar ist und als einziger Knoten keinen übergeordneten Datenknoten besitzt. Alle anderen Baumknoten sind mittelbar oder unmittelbar dem Wurzelknoten untergeordnet. Der Wurzelknoten muß nicht gespeichert werden, er kann sogar einem leeren Datenbaum zugeordnet werden.
Jeder Vaterknoten ist von jedem seiner Sohnknoten z. B. über speziellen Schlüssel direkt erreichbar. Somit ist in einem Datenbaum 27 jeder unter dem Wurzelknoten liegende Datenknoten über genau einen Weg, nämlich über Vaterknoten und, falls vorhanden, die diesem übergeordneten weiteren „Vorfahren"-knoten, mit dem Wurzelknoten verbunden.
Eine verfügbare Beschreibungssprache, die intuitiv ist und in Grenzen auch bereits eine Beschreibung von Datenbäumen erlaubt, ist die Beschreibungs- bzw. Auszeichnungssprache XML.
XML ist weit verbreitet, wird gut beherrscht und ist dabei eine universelle, hochstrukturierte und von üblichen proprietären Chipkartenformaten unabhängig Sprache. XML erlaubt auch bereits eine direkte Modellierung von verzweigten Datenbäumen mittels Datenknoten. Jeder Datenknoten eines Datenbaumes ist dabei ausgehend von dem Wurzelknoten über einem eindeutigen Pfad erreichbar und auffindbar. Allerdings bieten die Sprachelemente von XML und ebenso das darunterliegende Datenmodell XML DOM (XML Data Object Model) in ihrer bekannten Form nicht die Möglichkeit, Verweise, wie sie im proprietären Format von Chipkarten-Datensystemen 13 typischerweise häufig auftauchen, in einem Datenbaum 27 zu modellieren.
Erfindungsgemäß wird deshalb zur Schaffung einer zur Beschreibung von Datenbäumen 27 geeigneten Datenbaumbeschreibungssprache grundsätzlich eine verfügbare Beschreibungssprache herangezogen. Diese wird aber um einen neuen Datenknotentyp, nämlich das Konstrukt des Verweisknotens, der beliebige Verweise in einem Datenbaum ermöglicht, erweitert. In besonders einfacher Weise ergibt sich eine erfindungsgemäße Datenbaumbeschreibungssprache, indem ein solches Konstrukt in Standard-XML eingeführt wird. Die Verweisknoten können als Sohnknoten einem Datenknoten zugeordnet und wie erläutert über einen Schlüssel referenziert werden. Sie besitzen aber weder einen eigenen Datensatz noch eigene Sohnknoten. Stattdessen verweisen Sie auf die Daten und Sohnknoten eines ihnen zugewiesenen Datenknotens.
Verweisknoten ermöglichen es, einen Datenknoten in einem Datenbaum 27 von beliebigen Datenknoten aus über mehrere Pfade zu erreichen und aufzufinden. Sie sind daher für die Datenmodellierung und die Simulation von entscheidender Bedeutung. Durch die Verweisknoten wird es möglich, Dateien und ihre Inhalte in mehreren Applikationen gleichzeitig zu verwenden („shared ressources") und zwischen entfernten Teilbäumen Relationen herzustellen, die in einem logischen Zusammenhang stehen, wie z. B. Dateien, die Schlüssel enthalten, und Dateien, die zu verschlüsselnde Daten enthalten. Die Verweisknoten erlauben eine direkte Modellierung der Auswahl von Verzeichnis- oder Elementardateien sowie die Darstellung von Zusammenhängen zwischen solchen Dateien in einem Datenbaum. Ein Verweisknoten hat beispielsweise folgendes Format:
<d3:link type="{Type}" name="{Name}" ref="{Pfad}"/>
bzw. erfindungsgemäß modifiziert:
({Typ} {Name}) = {Pfad},
wobei {Pfad} eine Abfolge von Schlüsseln des Wurzelknotens oder der unmittelbar über- oder untergeordneten Baumknoten ist. Absolute d.h. auf den Wurzelknoten bezogene und zur Position des Verweisknoten relative Pfade werden erlaubt. Diese Bezeichnungen können im Kontext des jeweiligen Knoten eindeutig interpretiert werden. Durch Verweisknoten festgelegte Verweise können sich im Rahmen der Ausführung einer Testprozedur 26 ändern. Verweisknoten können auch ihrerseits auf andere Verweisknoten weisen. Die insgesamt entstehenden Verweisungen müssen aber stets zyklenfrei sein; Verweisungen oder Verweisungsfolgen, die auf den Ausgangsknoten zurückführen, sind nicht erlaubt.
Vorzugsweise wird in der verwendeten Datenbaumbeschreibungssprache weiterhin das Konstrukt von „Nullknoten" eingeführt. Das Konstrukt ermöglicht es definiert z. B. einen – in Chipkarten regelmäßig auftretenden – Zustand zu modellieren, in dem ausdrücklich keine Datei selektiert ist. Zur Modellierung des Zustandes wird ein Verweisknoten eingesetzt, der auf einen Null knoten verweist. Das Konstrukt des Nullknotens ermöglicht die Simulation der speziellen Selektions- und Zugriffsmechanismen im objektorientierten Dateiverwaltungssystem einer Chipkarte.
Neben den unmittelbar auf die Modellierung einer Kartenstruktur gerichteten Daten enthalten Datenbäume 27 zweckmäßig auch alle weiteren für die Ausführung eines Testlaufs benötigten Daten. Solche Testlaufdaten sind zum Beispiel Angaben zu nur vorübergehend zum Zwecke des Testlaufs anzulegende Dateien sein oder Regeln für die Überführung bestimmter Teilbäume eines Datenbaumes 27 in eine chipkartentypische TLV-Struktur.
2 veranschaulicht einen unter Verwendung der erfindungsgemäß vereinfachten und modifizierten Beschreibungssprache XML beschriebenen Datenbaum 27, der einen Verweisknoten aufweist. 2a zeigt dabei eine Darstelllung in erfindungsgemäß verändertem XML-Pseudocode neben einer Blockdarstellung der entsprechenden Dateihierarchie, 2b gibt die Darstellung in erfindungsgemäß eingesetztem gewöhnlichem XML wieder.
Der Aufbau des Datenbaums 27 spiegelt eine verschachtelte, kaskadierte Struktur wieder, wie sie aus der Blockdarstellung der Dateihierarchie in 2a ersichtlich ist. Der Wurzelknoten wird nicht gespeichert und hat einen einzigen Sohnknoten, nämlich MF chipcard. Er repräsentiert hier die Wurzeldatei MF einer Chipkarte 1. Unter der Wurzeldatei MF liegen zwei weitere Dateien, nämlich eine Elementardatei EF ef00 mit dem Dateninhalt „'text1'" und eine Verzeichnisdatei DF df01 mit der Binärzahl „0n 1101" als Dateninhalt. Das Verzeichnis DF beinhaltet seinerseits zwei Elementardateien ef01 und ef02, wobei ef02 den Dateninhalt „'text2'" trägt und ef01 über den vom Wurzel ausgehenden Pfad: (MF chipcard)(EF ef00) auf die Elementardatei ef00 verweist; der Doppelpunkt in dem Pfad bezeichnet dabei den Wurzelknoten. Die Elementardatei ef01 bildet hier einen Verweisknoten, der auf die Datei ef00 verweist. Aufgrund des Verweises wird bei einem Zugriff auf die Elementardatei ef01 tatsächlich auf die Elementardatei ef00 zugegriffen und damit der Dateninhalt „text1'" erreicht
3 veranschaulicht den Prozeß des Entwerfens eines Datenbaumes 27. Typischerweise wird der Entwurf von einem Testingenieur auf einer Entwurfssuite 3 vorgenommen.
Besonders zweckmäßig erfolgt die Erstellung eines Datenbaumes 27 für eine zu testende Chipkarte 1 in zwei Stufen, wobei in einer ersten Stufe zunächst ein universell gehaltenes Datenbaumschema erstellt und dieses in einer zweiten Stufe gemäß einem konkreten Testszenario vervollständigt und spezifiziert wird.
Grundlage für die datenmäßige Nachbildung einer Chipkarte 1 in einem Datenbaum 27 bildet eine bereitgestellte, Schritt 200, genaue Beschreibung der Kartenfunktionalität, üblicherweise in Form einer zugehörigen Betriebssystemspezifikation. Auf Basis dieser Beschreibung wird zunächst mit Hilfe des Entwurfseditors 33 manuell ein Schema entwickelt, Schritt 210. Typischerweise erfolgt die Entwicklung des Schemas beim Hersteller der Chipkarten 1. Das Schema ist ein vollständiger vorstrukturierter Datenbaum 27 in Datenbaumsyntax, der die Strukturen der nachzubildenden Chipkarte 1 sowie der Testdaten mit allen möglichen Datenelementen und Konstrukten prinzipiell aufweist, ohne jedoch bereits konkrete Datenwerte festzulegen – eine auf eine Verwaltung von Telefonnummern gerichteten Anwendung werden beispielsweise noch keine konkreten Namen oder Nummern zugewiesen. Für die zunächst noch fehlenden konkreten Werte werden Platzhalter gesetzt, die zum Beispiel zulässige Wertebereiche angeben können. Ergänzend können für die Platzhalter zudem bereits Standardwerte festgelegt werden, die gesondert gespeichert und bei Ausbleiben einer individuellen Vorgabe herangezogen werden. Der Entwurfseditor 33 unterstützt den Datenbaumentwicklungsprozeß durch seine Oberflächengestaltung und durch eine geeignete Benutzerführung. Soweit vorhanden kann zur Entwurfsunterstützung auf vorhandene Datenbaumschemata oder Teile davon zurückgegriffen werden, die für bestimmte Kartenfunktionalitäten, Applikationen und Testszenarien prototypische Datenbäume repräsentieren.
In einem Folgeschritt 220, der typischerweise ausgeführt wird, nachdem die Chipkarte 1 einem Anwender zugewiesen wurde – etwa einer Bank, die eine Zahlungsverkehrsapplikation anwenden möchte -, wird das Schema in einen konkreten, einer realen Chipkarte 1 zugeordneten Testlauf-Datenbaum 27 überführt, der alle für einen nachfolgenden Testlauf relevanten Informationen und Datenwerte enthält.
Der Anwender definiert hierzu anhand einer konkreten vorgesehenen Applikation ein Testszenario und beginnt mittels einer Entwurfssuite 3 unter Verwendung einer erfindungsgemäßen Datenbaumbeschreibungssprache mit der manuellen Erstellung eines auf das Testszenario abgestimmten Anwender-Datenbaumes 27. Sofern ihm ein geeignetes Schema unmittelbar bekannt ist, kann er dabei von Beginn an auf ein zu der vorgesehenen Applikation passendes Schema als Vorlage zurückgreifen, die er nachfolgend anpaßt und vervollständigt. In einer Variante kann die Auswahl eines passenden Schemas unterstützt durch die Entwurfssuite 3 in Reaktion auf Eingaben des Anwenders erfolgen, nachdem dieser mit der Erstellung eines Datenbaumes 27 be- gonnen hat.
Ist ein Schema ausgewählt, erzeugt der Anwender vor allem durch Anpassung und Vervollständigung des ausgewählten Schemas nun einen Datenbaum 27. Im Rahmen der Anpassung eines Schemas werden beispielsweise MFs, DFs, EFs und Verweisknoten im Datensystem 13 einer zu testenden Chipkarte 1 entsprechend einer vorgesehenen Applikation angeordnet. Weiter werden Platzhaltern konkrete Datenwerte zugewiesen.
Die Verfügbarkeit von Schemata ermöglicht es, daß die Beschreibung des Anwender-Datenbaumes 27 in einer vereinfachten, auf wesentliche Angaben reduzierten Form erfolgen kann. Die vom Anwender vorgenommene Datenbaumbeschreibung wird durch die Entwurfssuite 3 gegen das ausgewählte Schema automatisch verifiziert und mit dort vorgegebenen Daten- und Verweisknoten vervollständigt, Schritt 230. Dabei prüft die Entwurfssuite 3 den Datenbaum 27 anhand der Schemata auf Richtigkeit der Struktur, Vollständigkeit und Konsistenz, Schritt 230. Sodann erzeugt sie fehlende Datenknoten selbständig unter Zugriff auf die Standardwerte. Erkannte Fehler teilt sie dem Anwender unmittelbar mit. Schritt 230 kann erst während der Testausführung vom Testinterpreter 24 vorgenommen werden.
Soweit geeignete Schemata zur Verfügung stehen, kann die Erstellung von Datenbäumen 27 zu gegebenen, maschinenlesbaren Kartendaten auch ganz oder teilweise automatisch erfolgen. Die Kartendaten, die etwa eine Applika tion beschreiben, können dazu beispielsweise in Datenbaumsprache konvertiert, vom Testinterpreter 24 interpretiert und mit speziellen Off-Card-Testfällen gegen Spezifikationsanforderungen automatisch verifiziert werden.
Datenbäume 27 können ferner in Form mehrerer Teilbäume gespeichert sein, die dann von der Entwurfssuite 3 oder dem Testinterpreter 24 zusammengefaßt werden. Die Teilbäume können z. B. unabhängige Applikationen beschreiben, die während einer Simulation zusammengeführt werden.
4 veranschaulicht die Vervollständigung eines rudimentären Datenbaums (4a) zu einem verifizierten Datenbaum (4c) mit Hilfe eines Schemas (4b) in erfindungsgemäß verändertem XML-Pseudocode. 4d zeigt die zu dem rudimentären Datenbaum (4a) gehörende Darstellung in erfindungsgemäß eingesetztem gewöhnlichem XML, 4e die zu dem Schema (4b) gehörende Darstellung in erfindungsgemäß eingesetztem XML und 4f die zu dem Datenbaum (4c) Darstellung in erfindungsgemäß eingesetztem gewöhnlichem XML. Schemata wie das Schema gemäß 4b geben für einen Datenbaum 27 die Grundstruktur und Standardwerte vor; sie entsprechen in ihrer Funktion insoweit bekannten Schemata, etwa XML-Schemata. Im Unterschied zu diesen werden die Datenknoten nun jedoch nach gewöhnlichen Datenknoten zum einen und nach Verweisknoten zum anderen unterschieden und jeweils individuell behandelt. Erfindungsgemäße Schemata führen ferner regelmäßig zur automatischen Erzeugung neuer Knoten, wobei Standardwerte Verwendung finden, die das jeweilige Schema vorgibt. Für jeden Knoten wird weiter einzeln geprüft, ob sein Wert bzw. sein Dateninhalt das vorgegebene Format besitzt und im vorgegebenen Bereich liegt, ob im Datenbaum 27 untergeordnete Datenknoten vorkommen, die im Schema nicht definiert sind, ob alle vorgesehenen untergeordneten Datenknoten mit den im Schema angegebenen Namen vorhanden sind und ob die vom Schema vorgesehenen aber tatsächlich nicht vorhandenen untergeordneten Datenknoten automatisch angelegt werden sollen. Für Verweisknoten wird geprüft, ob der jeweilige Ziel-Datenknoten vorhanden ist und ob der Typ des Verweisknotens mit dem Typ des Ziel-Datenknotens übereinstimmt.
Der in 4a beschriebene Datenbaum 27 enthält ein Verzeichnis (DF df_test) mit zwei Knoten (ID) mit Inhalt „ef01" und (Size) mit Inhalt „0010". Das Schema gibt ein Verzeichnis DF mit beliebigem Namen <name> und der Anzahlvorgabe #0..n vor. Die Vorgabe #0..n gibt vor, daß ein derartiger Knoten an entsprechender Stelle in einem Datenbaum 27 beliebig oft vorkommen kann aber nicht vorkommen muß. Das Verzeichnis df_test des Datenbaums 27 erfüllt diese Anforderung.
Gemäß dem Schema 4b enthält das Verzeichnis df_test mehrere Datenknoten. Das Schlüsselwort #Auto des Datenknotens EXIST gibt an, daß ein derartiger Datenknoten im Datenbaum mit dem spezifizierten Wert anzulegen ist, falls er fehlen sollte. Der Wert kann ausgewählt werden aus den Werten „No" und „Yes". Da ein Knoten EXIST im Datenbaum 4a fehlt, wird er im verifizierten Datenbaum 4c mit dem Standardwert „No" angelegt. Der Datenknoten ID muß aufgrund der Vorgabe #1 als Sohnknoten des Datenknoten df_test einmalig und aufgrund der Vorgabe des Wertebereiches 'int' einem höchstens 4-Byte-langen Wert vorkommen, SFI kann – aber muß nicht – aufgrund der Vorgabe #0..1 vorkommen. Bereits vorhandene Datenknoten dürfen durch das Schema nicht korrigiert werden.
Anders verhält es sich mit dem Datenknoten (FCP), das im verifizierten Datenbaum 4c mit allen Datenknoten aufgrund des Schlüsselwortes #Auto automatisch angelegt werden muß. Schlüsselwort „'NFixedLink'" definiert einen Verweis auf den durch den nachfolgenden Pfad spezifizierten Datenknoten. Deshalb verweisen (FCP)(Size) und (FCP)(ID) auf die jeweils darüberliegenden Datenknoten (Size) und (ID). Der Wert „'XString'" des Datenknotens DescriptorByte erlaubt schließlich einen beliebigen Dateninhalt.
5 zeigt die Kombination der Programme zweier Teilbäume zu einem kombinierten Datenbaum 27. Dabei zeigen die 5a bis 5c Pseuodocodedarstellungen, 5c zudem eine Blockdarstellung der zugehörigen Dateihierarchie; die 5d bis 5f geben die zugehörigen Darstellungen in erfindungsgemäß eingesetztem XML. Ein Kombinieren von Datenbäumen bzw. Schemata kann an unterschiedlichen Stellen in der Testumgebung 4 stattfinden. Beispielsweise kann die Prüfungseinrichtung 34 ausgewählte Schemata kombinieren oder einen Teilbaum mit einem anderen Teilbaum vor Verifikation kombinieren. Ebenso kann die Kombination von Datenbäumen im Entwurfseditor 33 erfolgen und von ihm durch eine entsprechende Konsistenzprüfung unterstützt werden. Schließlich ist es auch möglich, daß Datenbäume bzw. die sie repräsentierenden Programme erst nach dem separaten Einlesen in den Testinterpreter 24 von diesem konsistent kombiniert werden.
Bei der Kombination der Teilbäume „File1" gemäß 5a und „File2" gemäß 5b zu „File1+File2" gemäß 5c wird File1 zunächst eingelesen und durch die Angaben von File2 ergänzt. File1 beschreibt einen Datenbaum mit einem Wurzelverzeichnis (MF card) mit Dateninhalt „card1" und darin ein Verzeichnis (DF df00) und eine Elementardatei (EF ef00) mit dem Dateninhalt „data0". File2 ergänzt für das Verzeichnis df00 den Dateninhalt „'text'" und eine darin enthaltene Elementardatei (EF ef01) mit Dateninhalt „'data1'" und schließlich einen Verweis auf die Elementardatei ef01.
Falls File1 beispielsweise die Dateistruktur einer Applikation beschreibt und File2 einer anderen Applikation über einen Verweis den Zugriff auf Daten der ersten Applikation ermöglicht, realisiert der kombinierte Datenbaum gemäß 5c den Zugriff auf geteilte Ressourcen durch zwei unabhängige Applikationen.
Chipkarten-Datensysteme lassen sich aus physikalischer oder aus logischer Sicht darstellen. Beide Sichtweisen sind dabei zueinander komplementär. 6 illustriert vor diesem Hintergrund eine Möglichkeit zur Verknüpfung der in 6a dargestellten physikalischen Sicht eines Chipkarten-Datensystems mit der entsprechenden, in 6b dargestellten logischen Sicht. Die Komplementarität der beiden Sichten erlaubt es, daß eine Testprozedur schon entwickelt werden kann, bevor eine zugehörige, zu testende Applikation vollständig implementiert ist.
Die physikalische Sicht nach 6b umfaßt die Menge der im Speicher der Chipkarte 1 physikalisch vorhandenen persistenten Daten, z. B. (EF 0030) in Zeile 3 von 6b, jedoch keine Information über logische Dateinamen, wie z. B. (EF ef_rule) in Zeile 3 von 6a.
Die logische Sicht auf das Chipkarten-Datensystem 13 nach 6b repräsentiert die im Pflichtenheft verwendeten logischen Bezeichnungen der Datenstrukturen, umfaßt aber keine Implementierungsdetails. Dementsprechend bildet der Datenbaum gemäß 6a die Dateistruktur der Chipkarten-Struktur gemäß 6b ab, wobei anstelle einer Elementardatei der Verweisknoten ef_rule auf die eigentlichen Daten unter EF 0300 verweist.
Die Entwicklung der logischen Sicht kann also unabhängig von der Fertigstellung der physikalischen Sicht durchgeführt werden. Durch Verwendung der logischen Sicht des Datenbaums können Spezifikation und Implementierung der Testprozeduren ohne vollständige Entwicklung der Kartenapplikationen erfolgen. Bei der Testdurchführung kann jedoch die logische Sicht des Datenbaums nur gemeinsam mit der entsprechenden physikalischen Sicht benutzt werden.
7 veranschaulicht einen typischen, durch das Testsystem 2 gesteuerten kombinierten Ablauf von Simulation und Test einer Chipkarte 1.
In einem Vorbereitungsschritt 100 wird dem Testsystem 2 ein den Zustand der Karte 1 abbildender Datenbaum 27 bereitgestellt, z. B. von der Entwurfsvorrichtung 3 über das Datennetz 5. Weiter wird dem Testsystem 2 eine Testprozedur 26 bereitgestellt, z. B. von einer Testentwurfsvorrichtung über das Datennetz 5, Schritt 110.
Schon zu diesem Zeitpunkt kann vorgesehen sein, den Datenbaum 27 in einem Schritt 120 auf der Anzeigevorrichtung 23 zu visualisieren, um z. B. einem Testingenieur eine Übersichtlich über den Ausgangszustand der Chipkarte 1 zu verschaffen.
Sodann wird der eigentliche Testlauf gestartet, Schritt 130. Das Testsystem 2 führt daraufhin die bereitgestellte Testprozedur 26 aus, indem der Testinterpreter 24 schrittweise einzeln die in der Testprozedur 26 enthaltenen Testkommandos nacheinander abarbeitet. Jedes Testkommando wird dabei sowohl an der zu testenden Chipkarte 1 als auch in dem die Chipkarte 1 beschreibenden Datenbaum 27 ausgeführt. Die Ausführung erfolgt so, daß der Zustand der Chipkarte 1 und der anhand des Datenbaumes 27 simulierte Zustand stets konsistent sind.
Die Ausführung jedes Testkommandos beginnt mit seiner Interpretation durch den Testinterpreter 24, Schritt 132. Ein Testkommando kann unmittelbar eine Abfrage des Datenbaumes 27 erfordern, um z. B. mit Daten aus dem Datenbaum 27 Kommandodaten zu berechnen. Die Abfrage des Datenbaumes 27 wird in diesem Fall entsprechend ausgeführt, Schritt 140. Ist das Testkommando, ggf. nach Abfrage des Datenbaumes 27, ausführbar, transformiert das Testsystem 2, Schritt 142, es in das Kommandoformat der zu testenden Chipkarte 1, also typischerweise in APDU-Format, und übermittelt es ihr, Schritt 144. Die Chipkarte 1 führt das Kommando aus und nimmt entsprechende Änderungen in ihrem Datensystem 13 vor, etwa durch Anlegen einer neuen Datei, Ändern beliebiger Dateiinhalte, Inkrementieren einer Laufvariablen, etc. Anschließend übermittelt die Chipkarte 1 dem Testsystem 2 eine Antwort, Schritt 148.
Parallel zur Ausführung durch die Chipkarte 1 wird das Testkommando vom Testinterpreter 24 in dem Datenbaum 27 ausgeführt und der Datenbaum 27 aktualisiert, Schritt 150. Der Datenbaum 27 wird dabei, Fehlerfreiheit vorausgesetzt, auf die gleiche Weise geändert wie die Chipkarte 1.
Die Simulation des Verhaltens der Chipkarte 1 im Datenbaum 27 und der Datenaustausch mit der realen Chipkarte 1 können grundsätzlich zeitlich unabhängig voneinander erfolgen. Praktisch wird allerdings die Simulation zumeist dem realen Datenaustausch hinterhereilen. Grund ist, daß Simulationen in Datenbäumen 27 vielfach auf Daten angewiesen sind, die vorher von der realen zu testenden Chipkarte 1 erzeugt werden müssen. Dies gilt beispielsweise für eine Zufallszahl im Rahmen einer Authentisierung, die zunächst aufgrund einer Anforderung („challenge") vom Testsystem 2 von einer Chipkarte 1 erzeugt werden muß, und auf der ein nachfolgendes Testkommando aufsetzt. Die Simulation kann in diesem Fall erst nach Erhalt der Zufallszahl fortgesetzt werden.
Regelmäßig, vorzugsweise nach jeder von der Chipkarte 1 in Schritt 148 gelieferten Antwort, nimmt das Testsystem 2 eine Konsistenzprüfung vor, Schritt 160. Darin prüft es anhand der Antwort, ob der Zustand der Chipkarte 1 und der Zustand des Datenbaumes 27 übereinstimmen. Ergibt die Prüfung in Schritt 160, daß der Zustand der Chipkarte 1 und der Zustand des Datenbaumes 27 nicht übereinstimmen, erzeugt das Testsystem 2 eine Fehlermeldung, die es auf der Anzeigevorrichtung 23 visualisiert. Vorgesehen sein kann, daß zudem der Testlauf angehalten wird. Die Visualisierung erfolgt so, daß ein Testingenieur einen möglichst guten Überblick über den aktuellen Zustand der Chipkarte 1 und über die Abarbeitung der Testprozedur 26 erhält. Zweckmäßig wird insbesondere der Inhalt des Datenbaumes 27 zum Zeitpunkt der Inkonsistenz dargestellt.
Eine Visualisierung des Datenbaumes 27 auf der Anzeigevorrichtung 23 ist daneben zu jedem beliebigen Zeitpunkt während eines Testlaufs möglich. Für eine Visualisierung wird die Ausführung der Testprozedur 26 jeweils an- gehalten. Sofern die Hardwareressourcen des Testsystems 2 es zulassen, kann auch eine kontinuierliche Visualisierung eines Datenbaumes 27 während der Ausführung einer Testprozedur 26 erfolgen, so daß die Zustandsänderungen im Datenbaum 27 nach Art eines Filmes auf der Anzeigevorrichtung 23 erscheinen. Ebenso kann der unter Einfluß einer Testprozedur 26 geänderter Datenbaum 27 durch den Testinterpreter 24 zur späteren Auswertung abgespeichert werden.
In Rahmen dieser Auswertung können durch den rechnergestützten Vergleich des aktuellen Inhaltes des Datenbaumes mit der ursprünglichen Version alle während der Testausführung entstandenen Änderungen analysiert werden. Sie können als Differenz-Datenbaum abgespeichert werden, der anschließend gegen ein spezielles Schema evaluiert werden kann, um zu prüfen, dass alle Änderungen in zulässigen Bereichen liegen.
Jeweils nach erfolgtem Anhalten einer Testprozedur 26 können mit Hilfe der Entwurfssuite 3 ohne weiteres auch Änderungen an einem Datenbaum 27 vorgenommen werden, um beispielsweise Attribute von Dateien oder Dateninhalte zu Testzwecken zu variieren.
Indem jede Kartenoperation und Datenmanipulation während des Testlaufs einzeln gesteuert, visualisiert, überprüft und gegebenenfalls korrigiert sowie nach dem Test ausgewertet werden kann, stellt das Zusammenwirken des Testsystems 2 mit der Entwurfssuite 3 und der Anzeigeeinrichtung 23 für ei nen Testingenieur eine „gläserne Chipkarte" zur Verfügung. So wird in der Simulationsumgebung beispielsweise sofort sichtbar, wenn eine Datei nicht die erwarteten Daten enthält. Derartige Fehler können anschließend korrigiert werden, vor allem durch Ändern der Testprozedur 26 aber auch, wenn ein Fehler auf der Chipkarte 1 vorliegt, durch einen Eingriff in die zu testende Chipkarte 1.
Obgleich vorstehend von der Verwendung einer modifizierten XML-Syntax ausgegangen wird, soll die Erfindung nicht auf den Einsatz im XML-Bereich beschränkt sein. Vielmehr kann mit dem gleichen Erfolg jede beliebige andere Auszeichnungssprache eingesetzt werden, die bequem handhabbar ist und die die entsprechenden Datenstrukturen und -konstrukte auf einer ausreichend abstrakten Programmierebene bereitstellt. Der besondere Vorteil von XML besteht allerdings in seiner internationalen Standardisierung, der weiten Verbreitung und dementsprechenden großen Auswahl von Hilfswerkzeugen, wie z. B. Browsern zum Visualisieren von Programmierumgebungen.

Claims

Verfahren zum Simulieren der Funktion einer datenverarbeitenden Schaltung (1) mit den Schritten: – Erstellen (200) einer Nachbildung der Schaltung in Gestalt eines Datenbaums (27), welcher in einer Baumstruktur ausgehend von einem Wurzelknoten mittels Datenknoten und Verweisknoten die logische Struktur zumindest eines Teiles des Datensystems (13) der datenverarbeitenden Schaltung (1) nachbildet, wobei die Datenknoten die Elemente des Datenbaums (27) modellieren und jeder Verweisknoten zyklenfrei jeweils entweder auf einen Datenknoten oder auf einen anderen Verweisknoten verweist, – Bereitstellen einer Testprozedur (26), – Bereitstellen eines Testsystems (2) mit einem Testinterpreter (24), der dazu eingerichtet ist, durch Ausführung der Testprozedur (26) bedingte Änderungen in einer Nachbildung (27) der Datenstruktur der datenverarbeitenden Schaltung (1) zu verwalten und darzustellen; und – Ausführen (130) der Testprozedur (26) mit dem Datenbaum (27).
Verfahren nach Anspruch 1, gekennzeichnet durch, daß mit Ausnahme des Wurzelknotens jedem Datenknoten ein übergeordneter Datenknoten zugeordnet wird.
Verfahren nach einem der Ansprüche 1, dadurch gekennzeichnet, daß der Datenbaum (27) in Textform oder graphisch dargestellt wird.
Verfahren nach Anspruch 1, gekennzeichnet durch, daß zur Erstellung des Datenbaums (27) eine übliche Beschreibungssprache genutzt wird, die zusätzlich um das Konstrukt der Verweisknoten erweitert wurde.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß für die Erstellung des Datenbaumes (27) ein Datenbaumschema bereitgestellt wird (220), das für eine datenverarbeitende Schaltung (1) eine noch nicht mit konkreten Werteangaben versehene Grundstruktur eines prototypischen Datenbaums vorgibt und die für die Werteangaben zulässigen Wertebereiche einschränkt.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß der Datenbaum (27) ausgehend von einem Datenbaumschema erstellt wird, wobei fehlende Datenknoten von einer Entwurfseinrichtung (3) automatisch erzeugt werden und/oder Standardwerte zugewiesen bekommen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Datenbaum (27) angepaßt an ein Testszenario erstellt wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß Datenbäume mehrerer Applikationen als Unterdatenbäume zu einem Datenbaum (27) kombiniert werden.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch die Schritte: – Anzeigen (120) des Datenbaums (27) auf einer Anzeigeeinrichtung (23); und – Aktualisieren (147) des angezeigten Datenbaums (27), falls sich der Datenbaum (27) infolge des Ausführens (130) der Testprozedur (27) verändert.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Ausführung (130) der Testprozedur (26) angehalten wird, um den Datenbaum (27) manuell zu ändern.
Verfahren nach einem der Ansprüche 1, dadurch gekennzeichnet, daß die Testprozedur (27) auch an der datenverarbeitenden Schaltung (1) ausgeführt wird.
Verfahren zum Testen der Funktion einer datenverarbeitenden Schaltung (1), umfassend die Schritte: – Ausführen (130) einer Testprozedur (26) auf der datenverarbeitenden Schaltung (1), – Simulieren der Funktionalität der datenverarbeitenden Schaltung (1) auf einem Datenbaum (27) durch ein Verfahren nach einem der Ansprüche 1 bis 10; und – Abgleichen der jeweiligen Ergebnisse des Ausführens der Testprozedur (26) auf der datenverarbeitenden Schaltung (1) und der Simulation auf dem Datenbaum (27), so daß beide stets konsistent sind.
Testumgebung (4) zum Testen einer datenverarbeitenden Schaltung (1), mit einer Entwurfseinrichtung (3) zum Entwerfen (200) eines Datenbaumes (27) und einem Testinterpreter (24) zum Ausführen (130) einer Testprozedur (26) auf dem Datenbaum (27), wobei die Entwurfseinrichtung (3) es ermöglicht einen Datenbaum (27) zu erstellen, indem in einer Beschreibungssprache durch analoges Übertragen die logische Struktur eines Datensystems (13) einer auf der datenverarbeitenden Schaltung (1) lauffähigen Applikation aus Datenknoten und Verweisknoten nachgebildet wird, wobei die Datenknoten die Werte beinhalten und die Verweisknoten jeweils auf einen Datenknoten, Verweisknoten oder Nullknoten verweisen.
Testumgebung (4) nach Anspruch 13, dadurch gekennzeichnet, daß die Entwurfseinrichtung (3) einen unvollständigen Datenbaum (27) anhand eines Datenbaumschemas, das eine Grundstruktur und Standardwerte eines prototypischen Datenbaums vorgibt, automatisch vervollständigt.
Testumgebung (4) nach Anspruch 13 oder 14, dadurch gekennzeichnet, daß die Entwurfseinrichtung (3) eingerichtet ist, den Datenbaum (27) in Form einer Datei zu erstellen.
Testumgebung (4) nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, daß für die Erstellung eines Datenbaumes (27) ein Beschreibungsprachen-Profil bereitgestellt wird, das grundsätzlich für die Beschreibungssprache XML definiert ist, zusätzlich aber das Konstrukt des Verweisknotens unterstützt, und der Testinterpreter (24) eingerichtet ist, eine in diesem XML-Profil erstellte Datei zu interpretieren.
Testumgebung (4) nach einem der Ansprüche 13 bis 16, umfassend eine Anzeigeeinrichtung (23) zum Anzeigen (120) des Datenbaums (27), wobei der Testinterpreter (24) eingerichtet ist, die Aktualisierung (146) der Anzeige des Datenbaums (27) auf der Anzeigeeinrichtung (23) zu veranlassen, falls sich der Datenbaum (27) infolge der Ausführung der Testprozedur (26) verändert.
Testumgebung (4) nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, daß die Entwurfseinrichtung (3) eine graphische Benutzerschnittstelle zum manuellen Entwerfen des Datenbaums (27) aufweist.
Testumgebung (4) nach einem der Ansprüche 13 bis 18, dadurch gekennzeichnet, daß sie jederzeit ein Anhalten der Ausführung einer Testprozedur (26) erlaubt, um einen Datenbaum (27) manuell zu verändern.
Verwendung eines Verfahrens nach einem der Ansprüche 1 bis 10, zum Simulieren der Funktionalität der datenverarbeitenden Schaltung (1) einer Chipkarte.
Verwendung eines Verfahrens nach Anspruch 11 zum Testen der Funktionalität der datenverarbeitenden Schaltung (1) einer Chipkarte.
Verwendung einer Testumgebung (4) nach einem der Ansprüche 13 bis 19, zum Testen der Funktionalität der datenverarbeitenden Schaltung (1) einer Chipkarte.