DE102004039884A1

DE102004039884A1 - Verfahren und System zur Beschreibung und Ausführung automatischer Tests

Info

Publication number: DE102004039884A1
Application number: DE102004039884A
Authority: DE
Inventors: Erkan Bostanci; Klaus Dr. Lamberg; Rainer Rasche; Jobst Richert
Original assignee: Dspace GmbH
Current assignee: Dspace Digital Signal Processing and Control Engineering GmbH
Priority date: 2003-08-20
Filing date: 2004-08-17
Publication date: 2005-06-02
Also published as: US7092835B2; US20050090997A1

Abstract

Die Erfindung betrifft ein Verfahren und ein System zum Testen eines technischen Systems, insbesondere eines elektronischen Steuergerätes, umfassend wenigstens eine Datenverarbeitungsanlage zur Ausführung einer in einem Speicher als Programm abgelegten Testsequenz und eine Anzeigevorrichtung, wobei die Datenverarbeitungsanlage über wenigstens eine Schnittstelle mit dem technischen System verbunden ist und mittels der ausgeführten Testsequenz Daten an das technische System übertragen und/oder von diesem gelesen werden und wobei die Testsequenz zur Durchführung eines Tests auf der Anzeigevorrichtung grafisch dargestellt wird, wobei die Testsequenz durch ausführbare Programmblöcke zusammengesetzt wird und wobei mittels einer grafischen hierarchischen Anordnung von Programmblöcken ein gleichzeitiges Ausführen von Programmblöcken gleicher Hierarchiestufe durch ein grafisches Nebeneinander-Anordnen der Programmblöcke und ein zeitlich aufeinander folgendes Ausführen von Programmblöcken unterschiedlicher Hierarchiestufe durch ein grafisches Untereinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmbar ist.

Description

Die Erfindung betrifft ein Verfahren und ein System zum Testen wenigstens eines technischen Systems, insbesondere eines elektronischen Steuergerätes, umfassend wenigstens eine Datenverarbeitungsanlage zur Ausführung einer in einem Speicher als Programm abgelegten Testsequenz und einer Anzeigevorrichtung, wobei die Datenverarbeitungsanlage über wenigstens eine Schnittstelle mit dem technischen System verbunden ist und mittels der ausgeführten Testsequenz Daten an das technische System übertragen und/oder von diesem gelesen werden und wobei die Testsequenz zur Durchführung eines Tests auf der Anzeigevorrichtung grafisch dargestellt wird.

Technische Systeme, wie sie beispielsweise in Kraftfahrzeugen eingesetzt werden, umfassen heute oft elektronische Komponenten zur Steuerung und/oder Regelung des technischen Systems. Diese elektronischen Komponenten werden als Steuergeräte oder ECUs (Electronic Control Unit) bezeichnet.

Bevor ein solches Steuergerät in Serie geht, wird es umfangreichen Tests unterzogen. Hierbei wird dem Steuergerät insbesondere die technische Umgebung simuliert, in der es später zum Einsatz kommt. Beispielsweise zum Test eines elektronischen Steuergeräts zur Steuerung/Regelung einer Motorelektronik können verschiedenen Fahrbedingungen simuliert werden, die den späteren realen Begebenheiten entsprechen.

Je komplexer das technische System, desto mehr Anwendungsfälle und Szenarien können entstehen und müssen simuliert werden, um die Zuverlässigkeit des Systems in der Realität zu prüfen. Dabei entsteht eine beachtliche Menge an Daten. Diese Daten entstehen einerseits aus der Beschreibung der eigentlichen Testabläufe und andererseits auch aus den Testergebnissen selbst.

Bei der Erstellung, Durchführung und Auswertung von Testszenarien werden daher hohe Anforderungen an Flexibilität, Übersichtlichkeit und einfache Handhabbarkeit eines Testsystems und der durchgeführten Testverfahren gestellt.

Im Stand der Technik ist es bekannt, dass ein Testsystem für z.B. Steuergeräte mindestens einen Computer umfasst der über eine Schnittstelle mit einem Testobjekt, z.B. einem Steuergerät, verbunden ist. Zudem unterstützen Rechenprogramme den Anwender bei der Beschreibung seiner Testszenarien und Testprojekte.

Neben der vollständig textbasierten Programmierung von Testszenarien in Form von Testskripten ist es bekannt auch Testsysteme mit interaktiven, z.B. grafischen Benutzeroberflächen bzw. Programmierumgebungen einzusetzen. Diese Testsysteme ermöglichen es dem Anwender sein Testszenario als sogenannte Testsequenz zu beschreiben, welche wiederum aus einzelnen Testschritten bestehen kann. Testschritte laufen dabei nach einem bestimmten Kontrollfluss ab.

Oft müssen zuvor bestimmte Bedingungen erfüllt sein, damit ein Testschritt ausgeführt wird. Je komplexer ein Testszenario ist, desto mehr Bedingungen, Schleifen, sequenzielle Abläufe, parallele Abläufe oder ähnliches müssen bei der Erstellung des Testprojektes verwaltet werden. Gleichermaßen steigt auch auf der Testergebnisseite die Komplexität für die Verwaltung unterschiedlichster Testergebnisse.

Mit zunehmender Anzahl technischer Systeme, z.B. Steuergeräte, in einem Gesamtsystem, wie zum Beispiel in einem Kraftfahrzeug sind herkömmliche Testsysteme für die Erstellung der Testsequenzen für ein Testszenario oft nicht geeignet. Den bekannten Systemen fehlt eine übersichtliche und intuitive Erstellung, Ausführung und Darstellung von Testergebnissen und des Testprogrammes bzw. der Testsequenzen selbst.

Aufgabe der Erfindung ist es, die hohe Komplexität bei der Erstellung von Testszenarien z.B. in einem Steuergeräteverbund beherrschbar zu machen.

Die Aufgabe wird durch ein Verfahren und ein System gelöst bei dem eine Testsequenz durch ausführbare Programmblöcke zusammengesetzt wird, wobei die Ausführungsabfolge einzelner Programmblöcke durch die Datenverarbeitungsanlage durch eine hierarchische grafische Anordnung der Programmblöcke in der Anzeigevorrichtung bestimmt wird. Hierbei wird ein gleichzeitiges Ausführen von Programmblöcken gleicher Hierarchiestufe durch ein grafisches Nebeneinander-Anordnen und ein zeitlich aufeinander folgendes Ausführen von Programmblöcken unterschiedlicher Hierarchiestufe durch ein grafisches Untereinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmt.

Eine derartige erfindungsgemäße Lösung bietet eine ganzheitliche und hierarchische Sicht auf alle Testschritte, deren Reihenfolge und der zugehörigen Daten eines Testszenarios.

Gleiche Hierarchiestufen haben z.B. Bedingungen, die zu einer bedingten Verzweigung im Ablauf des Testprogrammes bzw. der Testsequenz führen können.

Vorteilhaft ist es, wenn ein Ausführen eines Programmblockes innerhalb eines Programmblocks durch ein grafisches Ineinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmt wird.

Um insbesondere die zugehörigen Daten eines Testszenarios übersichtlich zu organisieren und als Parameter z.B. einem Programmblock zuzuweisen, kann es vorgesehen sein, dass einem Programmblock wenigstens ein Datenobjekt zugeordnet wird, insbesondere durch grafische Anordnung. Eine Parametrierung kann somit ebenfalls grafisch erfolgen. Somit kann es in der programmierten Testumgebung Programmblöcke geben, denen ein Datenobjekt zugewiesen ist und Probgrammblöcke, denen kein Datenobjekt zugewiesen ist. Ein Programmblock ohne zugewiesenes Datenobjekt kann z.B. eine einfache Print-Anweisung zur Ausgabe eines festen Textes auf dem Bildschirm sein. Eine derartige Anweisung benötigt keine Parametrierung.

Ein Datenobjekt kann bevorzugt die für einen Test benötigten und/oder die in einem Test enthaltenen Daten umfassen und/oder auf ein anderes Datenobjekt verweisen. So muss z.B. bei gleichen Daten in unterschiedlichen Programmblöcken nicht jeweils erneut ein vollständiges Datenobjekt zugeordnet werden, sondern es reicht ein referenzierender Verweis aus.

Es können so Projekthierarchien aus Programmblöcken gebildet werden, die die Aufnahme und Administration von Testsequenzen, von Datenobjekten und von Ergebnissen erlauben, wobei sich die Datenobjekte an den Blöcken der Projekthierarchie orientieren und damit auch eine hierarchische Parametrierung ermöglicht wird.

Durch die Parametrierung eines Programmblocks z.B. durch einen oder mehrere Datenobjekte können komplette Bausteine gebildet werden, die neben einem ausführbaren Programmblock auch die für die Ausführung benötigten Daten bzw. Parameter umfassen. Gemäß der Erfindung können ein Programmblock und/oder ein Datenobjekt jeweils als ein Programmelement aufgefasst werden, welches zumindest einen Teil eines durchzuführenden Tests bzw. einer Testsequenz bildet. Hierbei können in einem Programmelement abstrakt die jeweiligen Eigenschaften und Fähigkeiten z.B. eines Programmblocks oder eines Datenobjektes festgehalten sein.

Ein erfindungsgemäßes Testsystem kann so aus verschiedenen Programm-Elementen, d.h. Programmblöcken und/oder Datenobjekten bestehen, die z.B. selber Möglichkeiten der Darstellung in einer Anzeigevorrichtung, Parametrierung, Ausführung, Ergebnisaufzeichnung, Hierarchisierung, Typ-/Instanzbildung umfassen, und damit den genannten ganzheitlichen sowie auch hierarchischen Blick auf komplexe Testszenarien ermöglichen.

Hierdurch ergeben sich Vorteile durch schnelleres Aufbauen komplexer Testprojekte mit darin enthaltenen Testsequenzen, durch einfacheres Parametrieren und übersichtliche hierarchische Gesamtdarstellung der Testprojekte und des Kontrollflusses innerhalb der Testsequenzen.

Die gewünschten Tests lassen sich durch die Definition von ausführbaren (Test-)Blöcken und den benötigten (Test-)Daten (Datenobjekte) vollständig beschreiben. Die Datenobjekte dienen dabei z.B. der Bereitstellung von Ausgangsdatenmaterial wie administrative Daten zur Angabe von Datum, Uhrzeit, Autor, Bemerkungen, Anregungsdaten, Daten zur Steuerung des Testablaufs etc.

Die Programmblöcke besitzen jeweils spezifische Ausprägungen und dienen einerseits zur Beschreibung administrativer bzw. strukturierender Einheiten (z. B. Test-Projekt, Test-Folder als gruppierendes Element innerhalb von Test-Projekten) und sie dienen andererseits zur Beschreibung von Programmblöcken innerhalb der Test-Sequenzen (z.B. zur Beschreibung des Kontrollflusses in den spezifischen Ausprägungen für Parallelitäten, sequenzieller Abläufe, Bedingungen, Schleifen oder ähnliches). Darüber hinaus werden sie in spezifischen Blöcken als Test-Schritte eingesetzt und besitzen eine Algorithmik und somit ein mathematisches Verhalten zur Verarbeitung, wie (z.B. Lesen, Verändern, Schreiben etc.) der Daten.

Die durchzuführenden Tests, bestehend aus den Programmblöcken und Datenobjekten, sollen bevorzugt die Möglichkeit der Anzeige, Parametrierung, Ausführung, Ergebnisaufzeichnung, Hierarchisierung, Typisierung besitzen.

Dies wird besonders durch die Zusammenfassung der Eigenschaften und Fähigkeiten von Datenobjekten und Programmblöcken in einem abstrakten Programmelement erreicht, von dem die Programmblöcke und Datenobjekte erben und weitere spezialisierte Eigenschaften und Fähigkeiten besitzen. Beispielsweise kann ein Programmelement, d.h. ein Programmblock oder ein Datenobjekt z.B. die Möglichkeit der Darstellung/Repräsentation in einer Baumdarstellung und somit z.B. die Bereitstellung eines spezifischen Icons, die Darstellung des Namens und von Kontextmenüs für den Zugang bestimmter Aktionen des Elements (z.B. Ausführung, Öffnen eines element-spezifischen Dialoges) besitzen.

Ebenso kann bevorzugt die Fähigkeit eines Programmelementes, insbesondere eines Programmblocks zur Ergebnisaufzeichnung („Clone"-Bildung) in einem bestimmten Kontext vorgesehen sein. Hierfür kann während der Ausführung des Programms ein Ergebnisbaum erzeugt werden, der die hierarchische und zeitliche Abfolge des Programmlaufes gemäß des Kontrollflusses repräsentiert. Insbesondere kann ein Programmelement eine Kopie und/oder einen Repräsentanten seiner selbst erzeugen und in den Ergebnisbaum einfügen. Ein solcher Ergebnisbaum kann eine Art elementbasiertes Log-File darstellen, mit dem der Anwender eine Kontrollmöglichkeit über den Ablauf einer Testsequenz erhält, da dieser die Blockhierarchie der Test-Sequenzen abbildet und den abgewickelten Kontrollfluss zusammen mit den jeweils verwendeten Datenobjekten darstellt. Die Ergebnisaufzeichnung erfolgt während der Ausführung einer Testsequenz und kann während der Ausführung auf der Festplatte gespeichert werden. In einer weiteren Ausbildung kann eine Fähigkeit zur Typ- u. Instanzbildung eines Programmelementes vorgesehen sein. Dies bedeutet, dass ein Programmelement entweder als Typ, z.B. im Sinne einer Vorlage, Schablone, Bauvorschrift oder als Instanz, z.B. im Sinne einer konkreten Testverwendung existieren kann.

Ein Programmelement kann die Möglichkeit aufweisen, im Falle eines Typs eine entsprechende Instanz zu erzeugen. Umgekehrt kann die Instanz die Möglichkeit besitzen, einen entsprechenden Typ zur Einstellung in eine Bibliothek, z.B. zwecks Wiederverwendung zu erzeugen. Bevorzugt kann somit ein Programmelement in eine Bibliothek einspeicherbar und/oder aus einer Bibliothek abrufbar sein.

Hierfür umfasst das Testsystem bevorzugt eine grafische Programmierumgebung, mit der zum einen die Testsequenzen) durch ausführbare Programmblöcke zusammensetzbar ist/sind, wobei die Ausführungsabfolge einzelner Programmblöcke durch die Datenverarbeitungsanlage durch eine hierarchische grafische Anordnung der Programmblöcke in der Anzeigevorrichtung bestimmbar ist und bei der zum anderen wenigstens zwei unterschiedlichen Bereiche, nämlich ein Bibliotheks- und ein Instanzbereich vorgesehen sind, wobei letzterer z.B. das komplette Test-Projekt inklusive der darin enthaltenen ausführbaren Tests bzw. Testschritte umfasst.

Darüber hinaus kann jede Instanz die Möglichkeit der Synchronisation mit einem zugehörigen Bibliothekselement aufweisen. Diese Zugehörigkeit wird durch einen Verweis der Instanz (d.h. des Datenobjekts oder Programmblocks) auf das zugehörige Bibliothekselement definiert. Durch die Synchronisation wird die Instanz gemäß des entsprechenden Bibliothekselements (Bauvorschrift) aktualisiert bzw. neu aufgebaut. Diese Synchronisierung kann auch rekursiv erfolgen, d.h. eine Instanz, die ein Verweis auf ein Bibliothekselement besitzt, kann wiederum Programmblöcke und Datenelemente enthalten, die jeweils Verweise auf Bibliothekselemente besitzen usw.

Dieser Mechanismus der Instanzbildung (Verwendung von Bibliothekselementen zum Zwecke der Testbeschreibung) und der Typbildung (Einstellen von Programmblöcken und Datenobjekten als Teile der Testbeschreibung) kann als Typisierung bezeichnet werden. Eine Besonderheit dieser Typisierung ist, dass durch den Austausch der Bibliotheken mit anschließender Synchronisation ein bestehendes Test-Projekt auf ein vollständig anderes Testsystem umgewandelt werden kann.

Beispielsweise können der Projektaufbau und der überwiegende Teil der Testbeschreibungen für zwei Fahrzeuge A und B gleich sein. Es kann Unterschiede innerhalb einzelner Testblöcke für die Fahrzeugvarianten A und B geben, die als Bibliothekselemente in unterschiedlichen Bibliotheken (jeweils für Fahrzeug A und Fahrzeug B) hinterlegt sind. Das Test-Projekt muss nur einmal aufgebaut werden (z.B. für Fahrzeug A). Durch Austausch der Bibliotheken und anschießender Synchronisation kann das Test-Projekt auf das entsprechende Fahrzeug, d.h. z.B. auf einen anderen Fahrzeugtyp umgeschaltet werden (z.B. Umschaltung des Testprojekts auf Fahrzeug B).

Die Lage der Bibliothek kann entweder global, d.h. projektübergreifend sein oder lokal, d.h. Bibliotheken können innerhalb der administrativen Programmblöcke liegen, die das Projekt unterteilen (z.B. innerhalb des Test- Projekts oder innerhalb von Test-Foldern) um somit jeweils nur lokale Gültigkeits- und Sichtbarkeitsbereiche für die Bibliothekselemente zu definieren.

Es gibt zwischen Datenobjekten und den ausführbaren Programmblöcken einige Unterschiede, die nachfolgend weiter beschrieben werden.

Ein Datenobjekt kann die Fähigkeit zur Aufnahmen von Daten (Werte, Konfigurationen), die Fähigkeit zur Aufnahme von Referenzen und die Fähigkeit zur Auflösung von Referenzen aufweisen.

Ein Datenobjekt kann einerseits konkrete Werte (z.B. Zahlenwerte, Listen und Felder für Signalverläufe als Störanregung, Informationen über das Aufschalten von Kurzschlüssen, Konfigurationen von Schnittstellen zur Kommunikation) lokal aufnehmen.

Andererseits kann das Datenobjekt wenigstens ein geeignetes Referenz-Datenobjekt benennen. Bei der Existenz einer derartigen Referenzierung kann der Bezug der Daten aus dem Referenz-Datenobjekt dem Bezug der lokalen Daten vorgezogen werden.

Das Datenobjekt besitzt hierfür die Möglichkeit, diese Referenz aufzulösen und somit an die Daten des Referenz-Datenobjektes zu gelangen.

Darüber hinaus erbt ein Datenobjekt alle Möglichkeiten und Eigenschaften eines Programmelements. Das Besondere dieses Ansatzes ist, dass auch die Datenobjekte (als Testdaten) vollständig dem obenbeschriebenen Typsierungsansatz des Programmblocks unterliegen können. Somit können Datenobjekte, die z.B. Testdaten wie Anregungen, Signalverläufe etc. als wiederverwendbare Bibliothekselemente verwendet werden.

Ein Datenobjekt kann durch weitere Spezialisierung über die generischen Eigenschaften und Fähigkeiten des Datenobjektes und darüber hinaus über benutzerspezifische Eigenschaften und Fähigkeiten verfügen (z.B. benutzerspezifische Dateninhalte und Datenformate, benutzerspezifische Dialoge zur Darstellung dieser Dateninhalte und Formate, benutzerspezifische Kontext-Menüs als Zugangsmöglicheit zu den benutzerspezifischen Dialogen, benutzerspezifische Icons).

Ein Programmblock kann eine Aggregation von Daten aufweisen, ausgeführt werden, mit den Daten arbeiten, weitere Blöcke aufnehmen (Aggregation), was zur Hierarchisierung führt und spezifische Kontrollflussbeschreibungen geben, z.B. durch die Block-Darstellung für sequenzielle oder parallele Ausführung von Programmblöcken.

Der Programmblock bietet die Möglichkeit der Aufnahme (Aggregation) von Daten. Seine Aufgabe besteht im weitesten Sinne darin, während der Ausführung mit diesen Daten zu arbeiten, d.h. sie zu lesen, zu verändern und ggf. wieder zu beschreiben.

Darüber hinaus bietet der Block die Möglichkeit, weitere Blöcke aufzunehmen (zu aggregieren). Somit ist der Aufbau hierarchischer, auch rekursiver Blockstrukturen bzw. Teststrukturen möglich. Aus der spezifischen Ausprägung der Aggregation ergibt sich auch die Ablaufbeschreibung (Kontrollfluss), z.B. sequenzielle, parallele, wiederholte oder bedingte Abarbeitung.

Ein Programmblock kann über die generischen Eigenschaften und Fähigkeiten des Programmblocks durch benutzerspezifische Eigenschaften und Fähigkeiten erweitert werden. (z.B. benutzerspezifische Algorithmen zur Ausführung, benutzerspezifische Visualisierung (Icon), benutzerspezifische Dialoge).

Durch diese Möglichkeit, benutzerspezifische Programmblöcke zu definieren, lassen sich auch benutzerspezifische Test-Projekte formulieren, die eine eigene Semantik im Sinne der erweiterten benutzerspezifischen Eigenschaften und Fähigkeiten besitzen. Somit können benutzerspezifische Test-Projekt-Typen formuliert werden, die z.B. festdefinierte Datenobjekte mitbringen, eigene benutzerspezifische Dialoge und benutzerspezifische Konsistenz-Prüfmethoden und benutzerspezifische Methoden der Testausführung besitzen.

Die mittels der erfindungsgemäßen Verfahren und/oder mit einem erfindungsgemäßen System programmierten Tests sollen automatisch ablaufen und während der Ausführung die angeschlossene Hardware beeinflussen, insbesondere die Einsatzbedingungen simulieren. Hierfür können z.B. Störsignale und Fehler aufgeschaltet werden bzw. über Sensorik physikalische Fehler eingelesen werden. Die Programmierung von Kurzschlüssen, Unterbrechungen, Überspannungen etc. sind möglich.

Das erfindungsgemäße Testsystem gibt die Möglichkeit einer Test-Projekterstellung, mit einer Projekt-Substrukturierung, die definiert, was getestet werden soll und wo gemeinsam genutzte Daten verwendet werden. Es können Test-Sequenzen angelegt werden und durch hierarchische Darstellung des Kontrollflusses definiert werden.

Vorteilhaft ist es, dass der Testingenieur seine Kognition und Intuition bei der Testentwicklung ganz gezielt zur Lösung der Testaufgabe einsetzen kann, wobei das Testsystem eine Entlastung bei Routinearbeiten wie der Ablage und Organisation von Daten, Tests und Test-Ergebnissen auf der Festplatte oder im Speicher gibt. Die Daten werden gemäß der in dem Testsystem vorgeschlagenen und angelegten Strukturen automatisch physikalisch auf der Festplatte oder im Speicher der Datenverarbeitungsanlage organisiert.

Bei der Erstellung von Tests kann der Benutzer einzelne Schritte ausführen und somit einzelne Störsignale und Fehler auf den Prüfling aufschalten.

Ausführungsbeispiele der Erfindung sind in den nachfolgenden Figuren dargestellt. Es zeigen:
1: Die Bildschirmdarstellung einer Programmierumgebung zur Durchführung des erfindungsgemäßen Verfahrens mit einem sequentiellen Kontrollfluss;
2: Die Bildschirmdarstellung einer Programmierumgebung zur Durchführung des erfindungsgemäßen Verfahrens mit einem parallelen Kontrollfluss;
3: die spezifischen Ausprägungen eines Programmblocks;
4: die spezifischen Ausprägungen eines Datenobjektes;
5: die Darstellung von verschiedenen und gemeinsamen Eigenschaften der Programmblöcke und Datenobjekte.
Die 1 zeigt beispielhaft die Darstellung einer Programmierumgebung auf der Anzeigeeinheit einer Datenverarbeitungsanlage zur Durchführung des erfindungsgemäßen Verfahrens. Es ist dargestellt, dass der Bildschirm in mehrere Bereiche unterteilt ist. Wesentlich ist zum Verständnis der Erfindung der Instanzbereich 1 und der Bibliotheksbereich 2. Der Bibliotheksbereich ist hier global, kann aber (wie zuvor beschrieben) auch lokal, d.h. innerhalb einer Hierarchieebene des Projekts angesiedelt sein.
Im Bibliotheksbereich 2 ist z.B. eine Hauptbibliothek „Main Library" dargestellt, die weiterhin unterteilt ist in einen Ordner „Control Flows", in dem Programmblöcke unterschiedlicher Typen, z.B. zur Definition verschiedener Kontrollflüsse abgelegt sind. Beispielsweise sind Programmblöcke zur Ausbildung eines seriellen, parallelen oder bedingten Kontrollflusses vorhanden.
Der Instanzbereich 1 zeigt die grafische hierarchische Darstellung eines Kontrollflusses, wobei durch die grafische Darstellung im Instanzbereich 1 der Ablauf des programmierten Test bzw. der Testsequenz bestimmt ist. Hierzu kann die im Instanzbereich 1 grafisch dargestellte Testsequenz ausgeführt werden.
Als Beispiel ist im Instanzbereich 1 eine im wesentlichen sequentielle Testroutine zur Prüfung auf einen Fehler abgebildet. Die programmierte Testroutine setzt sich zusammen aus einem hierarchisch übergeordneten Programmblock 3 „Check_Error", der seinerseits mehrere weitere Programmblöcke 4 bis 10 umfasst. Somit zeigt sich hier, dass in einem Programmblock mehrere weitere andere Programmblöcke aggregiert werden können.
Die Programmblöcke 4 bis 10 werden aufgrund ihrer grafischen Anordnung innerhalb des Programmblocks 3 nacheinander sequentiell abgearbeitet, wobei innerhalb des Programmblocks 6, der eine Bedingung enthält, zwei weitere Programmblöcke 6a und 6b enthalten sind, die je nach Erfüllung der Bedingung ausgeführt werden. Beide Programmblöcke 6a und 6b sind hierarchisch gleichwertig und daher in der Darstellung nebeneinander angeordnet.
Eine Programmierung kann für einen Benutzer derart einfach erfolgen, dass objektorientiert per Drag-and-Drop mit dem Mauszeiger aus der Bibliothek im Bibliotheksbereich 2 fertig vorkonfigurierte Programmblöcke entnommen und in dem Instanzbereich 1 gesetzt werden. Hierbei wird die Abfolge, in der die Programmblöcke ausgeführt werden durch die grafische Anordnung im Instanzbereich 1 bestimmt. Dabei können die Datenobjekte der so neu gebildeten Instanz neu besetzt werden (d.h. neue Werte oder Referenzen annehmen). Hiermit sind die Datenobjekte der obersten Hierarchieebene dieser neu gebildeten Instanz gemeint. Die Datenobjekte innerhalb der neu gebildeten Instanz, also innerhalb tieferer Hierarchie-Ebenen können im Instanzbereich nicht verändert werden, da sie durch das zugehörige Bibliothekselement definiert wurden. Umgekehrt kann eine Typ-Bildung für den Benutzer derart einfach erfolgen, dass objektorientiert per Drag-and-Drop mit dem Mauszeiger aus dem Instanzbereich 1 Programmblöcke in den Bibliotheksbereich 2 gesetzt werden.
Die 2 zeigt eine im wesentlichen gleiche Darstellung von Instanzbereich 1 und Bibliotheksbereich 2, wobei hier im Instanzbereich 1 eine Routine mit sequentieller und paralleler Abfolge durch grafische hierarchische Anordnung programmiert wurde.
Mit allgemeiner Gültigkeit für alle möglichen Ausführungsformen kann es vorgesehen sein, so wie in 2 dargestellt, dass im Instanzbereich ein Programmblock eines bestimmten Typs eröffnet wird, der die Ausführung darin enthaltener weiterer Programmblöcke definiert, ohne dass dies der Benutzer für jeden weitere Programmblock festlegen muss.
So kann ein Programmblock z.B. vom Typ „Parallell ", wie in 2 mit Bezugszeichen 13 eröffnet werden, so dass alle weiteren innerhalb dieses Programmblocks eingefügten Programmblöcke, hier z.B. 14 und 15, automatisch grafisch nebeneinander für eine Parallelausführung angeordnet werden.
Ebenso gilt allgemein, dass ein Programmblock z.B. vom Typ „Serial", wie in 2 mit Bezugszeichen 15, eröffnet werden kann, so dass alle weiteren in diesen Block 15 eingefügten Programmblöcke, hier z.B. 16 bis 19 zu einer seriellen Abarbeitung automatisch untereinander angeordnet werden.
Durch die Typangabe eines Programmblocks kann somit definiert werden, wie hierarchisch darunterliegende Programmblöcke ausgeführt werden sollen.
Hierdurch ergibt sich, dass mit Bezug auf 2 beginnend in einem Programmblock 11 „InitSimulinkAccess" anschließend Programmblock 12 „Range" ausgeführt wird, innerhalb dessen der Programmblock 13 „Parallell" ausgeführt wird.
Innerhalb des Programmblockes 13 erfolgt eine parallele Ausführung der Programmblöcke 14 und 15, wobei der Programmblock 15 selbst wiederum eine Sequenz aus den Programmblöcken 16 bis 19 aufweist, von denen der Programmblock 19 eine Bedingung und somit zwei hierarchisch gleichwertige grafisch nebeneinander angeordnete Programmblöcke 19a und 19b enthält.
Die Ausführung des Blockes 12 und der darin enthaltenen Substruktur-Programmblöcke 13 bis 19 erfolgt hier solange, wie sich ein vorgegebener Wert, der z.B. durch ein nicht dargestelltes Datenobjekt zugewiesen ist, innerhalb eines bestimmten Bereiches „Range" befindet. Der Programmblock 12 stellt somit eine Schleife mit Abbruchbedingung dar.
Auch hier kann die Programmierung objektorientiert durch Übernahme von entsprechenden Programmblock-Typen aus der Bibliothek im Bibliotheksbereich 2 erfolgen, so dass durch die Typen die im Instanzbereich dargestellte Programminstanz gebildet wird.
Umgekehrt kann die fertig programmierte Instanz, wie sie im Instanzbereich 1 dargestellt ist in einen Programmblocktypen gewandelt und in der Bibliothek für z.B. spätere Wiederverwendung abgelegt werden.
Eine Datenobjektzuweisung kann z.B. ebenfalls grafisch erfolgen, z.B. dadurch dass ein Benutzer per Maus einen durch einen Kasten dargestellten Programmblock anklickt, wodurch sich ein Kontextfenster oder -Menue öffnet, um die zu einem Programmblock typischen Variablen anzugeben. Z.B. kann für den Programmblock 12 der Wertebereich „Range" durch einen Benutzer angegeben werden. Ebenso können die Bedingungen im Bedingungs-Programmblock 19 so parametriert werden.
Die 3 zeigt verschiedene Ausprägungen der Programmblöcke. Ersichtlich bilden Programmblock 20 und Datenobjekt 40 jeweils Programmelemente 60. Ein Programmblock 20 kann Datenobjekte 40 enthalten. Blöcke 20 können eine Aggregation 21 weiterer Blöcke enthalten, z.B. einer parallelen 22 oder seriellen 23 Anordnung weiterer Blöcke.
Programmblöcke 20 können auch eine Kategorie aufweisen, gemäß der hierarchisch nebeneinander eine unterschiedliche Anzahl weiterer Blöcke angeordnet sind, sogenannte Slots. Innerhalb eines solchen Blocks kann sich der Kontrollflussablauf je nach Bedingung in gleichwertige Slots und somit gleichwertige andere Blöcke verteilen.
Blöcke 20, die je nur einen weiteren Block umfassen sind z.B. For 24, While 25 oder Repeat 26 Schleifen. Blöcke 20 mit zwei gleichwertigen Blöcken sind z.B. Bedingungsblöcke 27. In den Blöcken 28 können eine beliebige Anzahl gleichwertige Blöcke angeordnet sein, die je nach Bedingung abgearbeitet werden.
Ebenso können Blöcke 20 vorgesehen sein, die nur einen einzelnen Schritt ausführen, wie z.B. einen Meßausgang 29 abfragen
Der Selbstverweis 30 macht deutlich, dass ein Block 20 weiterhin mehrere Blöcke unterschiedlicher Art umfassen kann.
Die 4 zeigt analog spezifische Ausprägungen von Datenobjekten 40 die ein Programmblock 20 enthalten kann.
Datenobjekte definieren im allgemeinen Fall Wertevariablen, wie z.B. Integer 41, Fließkommavariablen 42, Textvariablen 43, Listen 44, Wörterbücher 45 etc. Auch können Datenobjekte 40 von außen definiert werden, z.B. durch eine Benutzerdefinition 46. Datenobjekte können auch spezielle komplexe Konfigurationsobjekte definieren, für die eigene Dialoge existieren.
Die 5 zeigt im Wesentlichen die Eigenschaften von Programmblöcken 20 oder Datenobjekten 40. Beide zählen zur Kategorie von Programmelementen 60, die gemeinsame Eigenschaften aufweisen können. So kann z.B. in einem solchen Programmelement 60 vermerkt sein, welchen Namen es trägt, ob es sich um eine Instanz oder einen Typ handelt, das Element über die Eigenschaft verfügt von sich selbst eine Kopie oder einen Repräsentanten zu erzeugen, um diesem in einen Ergebnisbaum einzufügen usw. wie es vorangehend beschrieben wurde.
Gemäß der Eigenschaftendarstellung wird deutlich, dass ein Programmblock 20 darüber hinaus weitere Eigenschaften aufweisen kann, z.B. dass ein Programmblock 20 Datenobjekte 40 enthalten kann, dass ein Programmblock weitere Programmblöcke aggregieren kann, dass er ausführbar ist und für den Ergebnisbaum einen Repräsentanten bilden kann.
Ein Datenobjekt 40 kann als weitere Eigenschaft einen bestimmten Wert definieren oder durch Referenz zuweisen und selbst eine Referenz für andere Datenobjekte bilden.

Claims

Verfahren zum Testen eines technischen Systems, insbesondere eines elektronischen Steuergerätes, umfassend wenigstens eine Datenverarbeitungsanlage zur Ausführung einer in einem Speicher als Programm abgelegten Testsequenz und eine Anzeigevorrichtung, wobei die Datenverarbeitungsanlage über wenigstens eine Schnittstelle mit dem technischen System verbunden ist und mittels der ausgeführten Testsequenz Daten an das technische System übertragen und/oder von diesem gelesen werden und wobei die Testsequenz zur Durchführung eines Tests auf der Anzeigevorrichtung grafisch dargestellt wird, dadurch gekennzeichnet, dass die Testsequenz durch Datenobjekte und ausführbare Programmblöcke grafisch zusammengesetzt wird, wobei mittels einer grafischen hierarchischen Anordnung von Programmblöcken ein gleichzeitiges Ausführen von Programmblöcken gleicher Hierarchiestufe durch ein grafisches Nebeneinander-Anordnen der Programmblöcke und ein zeitlich aufeinander folgendes Ausführen von Programmblöcken unterschiedlicher Hierarchiestufe durch ein grafisches Untereinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmt wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass ein Ausführen eines Programmblockes innerhalb eines Programmblocks durch ein grafisches Ineinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmt wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass einem Programmblock wenigstens ein Datenobjekt zugeordnet wird, insbesondere durch grafische Anordnung.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass ein Datenobjekt die für einen Test benötigten und/oder die in einem Test erhaltenen Daten umfasst und/oder auf ein anderes Datenobjekt verweist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass Programmblöcke und Datenobjekte jeweils Programmelemente darstellen, die zumindest einen Teil eines durchzuführenden Tests oder einer Testsequenz bilden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass ein Programmelement in eine Bibliothek einspeicherbar und/oder aus einer Bibliothek abrufbar ist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass während der Ausführung der Testsequenz ein Ergebnisbaum erzeugt wird, der die hierarchische Abfolge der Testsequenz repräsentiert.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein Programmelement eine Kopie und/oder einen Repräsentanten seiner selbst erzeugt und in den Ergebnisbaum einfügt.
System zum Testen anderer technischer Systeme, insbesondere von elektronischen Steuergeräten, umfassend wenigstens eine Datenverarbeitungsanlage zur Ausführung einer in einem Speicher als Programm abgelegten Testsequenz und eine Anzeigevorrichtung, wobei die Datenverarbeitungsanlage über wenigstens eine Schnittstelle mit dem zu testenden technischen System verbindbar ist und mittels einer ausführbaren Testsequenz Daten an das zu testende technische System übertragbar und/oder von diesem lesbar sind und wobei eine Testsequenz zur Durchführung eines Tests auf der Anzeigevorrichtung grafisch darstellbar ist, dadurch gekennzeichnet, dass das System eine grafische Programmierumgebung umfasst, mit der die Testsequenz durch Datenobjekte und ausführbare Programmblöcke zusammensetzbar ist, wobei mittels einer grafischen hierarchischen Anordnung von Programmblöcken ein gleichzeitiges Ausführen von Programmblöcken gleicher Hierarchiestufe durch ein grafisches Nebeneinander-Anordnen der Programmblöcke und ein zeitlich aufeinander folgendes Ausführen von Programmblöcken unterschiedlicher Hierarchiestufe durch ein grafisches Untereinander-Anordnen der Programmblöcke in der Anzeigevorrichtung bestimmbar ist.