Eine strukturierte Methode zur Generierung von SystemVerilog- Testumgebungen aus textuellen Anforderungsbeschreibungen

Transkript

1 Eine strukturierte Methode zur Generierung von SystemVerilog- Testumgebungen aus textuellen Anforderungsbeschreibungen Alexander Bol, Wolfgang Müller, Alexander Krupp C-LAB/Universität Paderborn Paderborn Kurzfassung Diese Arbeit stellt ein strukturiertes Verfahren zum Generieren von Testumgebungen aus textuellen Anforderungsbeschreibungen mittels UML und der Klassifikationsbaummethode für eingebettete Systeme vor. Nach der Umsetzung in eine textuelle Normalform werden die hieraus automatisch erzeugten UML-Klassen schrittweise in eine Form transformiert, die in erweiterte Klassifikationsbäume übersetzt wird und dann weiter automatisch in ausführbare SystemVerilog-Testumgebungen umgesetzt werden. Das Verfahren wird anhand des Beispiels einer Abstandsdistanzregelung (Adaptive Cruise Controller) eines Fahrzeugs erläutert und evaluiert. 1 Einleitung Seit der Einführung der elektronischen Einspritzung wuchs der Anteil elektronischer Systeme und der Software überproportional. Mittlerweile sind in modernen Automobilen Mikrocontroller, sog. ECUs (Electronic Control Units), zu finden. Mit der Akzeptanz des AUTOSAR-Standards und den zugehörigen Werkzeugketten wächst in der Entwicklung automobiler elektronischer Systeme das Bedürfnis nach weiterer Automatisierung im Entwurfsprozess. Testprozesse in der Automobilindustrie sind z.b. gekennzeichnet durch werkzeugintensive und technologisch heterogene Testinfrastrukturen [7]. In der industriellen modellbasierten Entwicklung muss ein Produkt verschiedene Abstraktionsebenen und Tests durchlaufen, wie Model-in-the-Loop (MIL), Software-in-the-Loop (SIL) und Hardware-in-the- Loop (HIL) Tests. Verschiedene Testsysteme kommen hier zum Einsatz, wie z.b. MTest und AutomationDesk von dspace. Gleichzeitig nutzt jedes Testsystem seine eigene proprietäre Testbeschreibungssprache. Ein erster Ansatz zur Vereinheitlichung und Standardisierung ist die Automatic Test Mark-up Language ATML [1]. Mit TestML [7] wurde ein Austauschformat entwickelt, das neben funktionalen Tests auch Regressions-, Back-to-Back-, und Time-Partition- Tests [16] unterstützt, wobei Stimuli mit verschiedenen Beschreibungsformen wie der Klassifikationsbaummethode CTM/ES definiert werden können [5]. Während der modellbasierte Test in diesem Bereich mittlerweile gut durch existierende Werkzeuge abgedeckt ist, bleibt die zentrale Herausforderung immer noch die Ableitung von Testumgebungen aus einem Pflichtenheft. Anforderungsbeschreibungen in Pflichtenheften werden meist in natürlichsprachlichen Sätzen formuliert und mit Werkzeugen wie z.b. DOORS von Telelogic oder einfach nur mit Excel verwaltet. Es gibt zurzeit kein vollständiges Verfahren, das solche Anforderungsbeschreibungen direkt oder indirekt in ausführbare Testumgebungen umsetzt. Diese Arbeit stellt ein strukturiertes Verfahren zum Generieren von Testumgebungen mittels UML und der Klassifikationsbaummethode für eingebettete System (Classification Tree Method for Embedded Systems - CTM/ES) aus textuellen Anforderungsbeschreibungen vor. Das Generieren einzelner UML-Diagramme erfolgt in mehreren Schritten bevor diese in erweiterte Klassifikationsbäume übersetzt werden. Im ersten Schritt werden die Anforderungsbeschreibungen analysiert und in ein UML-Klassendiagramm übersetzt. Um die automatisched Übersetzung der textuellen Anforderungsbeschreibungen in das UML-Klassendiagramm zu realisieren, wurde eine eigene Notation entwickelt, die eine Teilmenge der natürlichen englischen Sprache darstellt, die Textuelle Normalform (TNF). Die UML-Diagramme sind so

2 strukturiert, dass aus ihnen einfach eine Testumgebung abgeleitet werden kann. Im Rahmen dieser Arbeit wird als Testumgebungsbeschreibungssprache SystemVerilog und der QuestaSim Simulator von Mentor Graphics verwendet. SystemVerilog unter QuestaSim erlaubt die einfache Integration mit verschiedenen anderen Sprachen wie mit SystemC und mit aus Matlab/Simulink erzeugtem C-Code. Der verbleibende Teil dieses Artikels ist wie folgt strukturiert. Das nächste Kapitel gibt eine kurze Einführung in die Grundlagen. Dies sind im Wesentlichen die Klassifikationsbaummethode für eingebettete Systeme und das Prinzip von Testumgebungen, die auf dem Prinzip der funktionalen Verifikation beruhen. Hiernach stellen wir unsere Methode zur Generierung von Testumgebungen aus Anforderungsbeschreibungen vor. Kapitel 4 stellt danach die Ergebnisse der Fallstudie eines Adaptive Cruise Controllers vor, bevor Kapitel 5 die Ergebnisse der Arbeit zusammenfasst. 2 Grundlagen Unser Verfahren basiert auf erweiterten Klassifikationsbäumen als Zwischenformat und auf den Prinzipien der funktionalen Verifikation in der Implementierung, welche beide im Folgenden näher erläutert werden. 2.1 Klassifikationsbäume Zur strukturierten Darstellung von Testfällen wurden Anfang der 90er Jahre bei der Daimler- Benz AG Klassifikationsbäume entwickelt [8]. Ausgehend von einem Wurzelknoten erfolgt eine Zerlegung der möglichen Testeingaben in Klassifikationen und Klassen. Eine Klasse ist eine abstrahierte Menge möglicher Belegungen. Die Klassen bilden die Blätter des Baumes, wobei jeder Klasse eine Spalte in einer Kombinationstabelle zugeordnet wird. Eine Zeile der Kombinationstabelle stellt einen Testfall dar. Jedem Testfall werden Klassen von Eingabewerten derart zugeordnet, dass zu jeder Klassifikation genau eine Klasse ausgewählt wird. Die Erstellung von Klassifikationsbäumen und der Kombinationstabelle wird durch die auf der Category-Partition-Methode basierende Klassifikationsbaummethode unterstützt [13]. Abbildung 1. Klassifikationsbaum

3 In der ursprünglichen Ausprägung beschreiben Klassifikationsbäume verschiedene Eingabekonstellationen für ein Testobjekt. Um auch zeitabhängige Testverläufe formulieren zu können, wurde die Notation von Conrad zur Klassifikationsbaum-Methode für eingebettete Systeme (CTM/ES) erweitert [5]. Der Klassifikationsbaum wird hierzu aus der technischen Schnittstelle des Testobjektes abgeleitet, d.h. jede Eingabegröße des Testobjektes wird durch eine Klassifikation dargestellt. Der zulässige Wertebereich einer Eingabegröße ist dann über Intervalle oder Einzelwerte in Klassen aufzuteilen. Die abstrakte Darstellung von Testszenarien wird aus den einzelnen Testschritten aufgebaut, die als zeitliche Abfolge in die Zeilen der Kombinationstabelle abgebildet werden. Eine solche Folge von Testschritten wird als Testsequenz bezeichnet. Jeder Testschritt definiert damit die Eingaben des Testobjektes über eine Zeitspanne. Der Aktivierungszeitpunkt eines Testschritts wird als Synchronisationspunkt bzw. als Stützstelle bezeichnet. Diese Zeitpunkte werden in einer zusätzlichen Spalte zu jedem Testschritt angegeben. Der Signalverlauf zwischen den Synchronisationspunkten wird durch verschiedene Übergangsfunktionen beschrieben, wobei der Übergang z.b. als Sprung-, Rampen-, oder als Sinusfunktion erfolgen kann. In der Kombinationstabelle werden die verschiedenen Übergangsfunktionen durch verschiedene Linien zwischen den Synchronisationspunkten repräsentiert (siehe Abb. 6). 2.2 Funktionale Verifikation Zur Testautomatisierung basiert unsere Teststeuerung auf den Prinzipien der funktionalen Verifikation. Die industrielle Einführung der Methodik der funktionalen Verifikation wird durch umfassende Werkzeugunterstützung und durch Standardisierungsbe-mühungen unterstützt wie z.b. die IEEE Standards SystemVerilog [9] und PSL [10]. Sie ermöglichen die formale und austauschbare Definition von Systemeigenschaften für die funktionale Verifikation. Zum Einen wird die Beschreibung von Assertions unterstützt, die zur Spezifikation von Eigenschaften zum Zweck der Laufzeitüberprüfung während der Simulation oder zur formalen Verifikation Verwendung finden. Zum Anderen wird die Beschreibung von Testumgebungen durch dedizierte Überdeckungsspezifikationen (Functional Coverage) und der Definition von Constraints zum gesteuertem Random-Test unterstützt. Standardisierte APIs (Application Programming Interface) wie z.b. das SystemVerilog DPI ermöglichen die Implementierung individuell angepasster Ausführungsplattformen. Mittlerweile stehen Richtlinien und Bibliotheken zur weiteren Unterstützung der entsprechenden Standards und Werkzeuge zur Verfügung [3,12]. 3 Generierung von Testumgebungen aus Anforderungsbeschreibungen Unsere Methode zur schrittweisen Umsetzung von textuellen Anforderungsbeschreibungen in eine ausführbare Testumgebung besteht aus 4 Teilschritten: 1. Formalisierung der Anforderungen 2. Transformation der Klassendiagramme in Klassifikationsbäume 3. Definition der Testszenarien 4. Generierung der Testumgebung Im ersten Schritt werden die allgemeinen (englischen) natürlich-sprachlichen Anforderungen in strukturierte natürlich-sprachliche Anforderungen übersetzt. Letztere entsprechen schon einer formalisierten Form der Anforderungen, die leicht in einem zweiten Schritt automatisch in UML-Klassendiagramme übersetzt werden können. Diese setzt man dann nach einigen Transformationen in Klassifikationsbäume (CTM/ES) ohne Testsequenzen um. Parallel hierzu müssen zur Vervollständigung der Klassifikationsbäume manuelle Testszenarien entwickelt werden. Ausgangspunkt hierzu können z.b. UML-Use Case und/oder UML-Sequenzdiagramme

4 sein. Die vollständigen Klassifikationsbäume sind schließlich der Ausgangspunkt zur automatischen Generierung der ausführbaren Testumgebung. In unserem Fall verwenden wir SystemVerilog [9]. Es könnten aber durchaus auch andere Verifikationssprachen wie PSL [10] Anwendung finden. Die einzelnen Teilschritte werden in den folgenden Abschnitten näher erläutert. Wir verwenden hier Teile einer industriellen Fallstudie aus dem Automobilbereich, einen sog. Adaptive Cruise Controllers (ACC). Ein ACC ist ein Tempomat mit radar-basierter Abstandsregelung, der unter Eingabe einer vorgegebenen Geschwindigkeit (desired speed) und in einem gewissen Abstand zum vorausfahrenden Fahrzeug (desired distance) das Fahrzeug in derselben Spur (vehicle in same lane) mit einer zu berechnenden Geschwindigkeit halten soll. 3.1 Formalisierung der Anforderungen Ausgehend von einer unstrukturierten textuellen Beschreibung erfolgt die Formalisierung der Anforderungen in zwei Teilschritten: Umsetzung in eine textuelle Normalform Erstellung eines UML-Klassendiagramms In der ausgehenden Anforderungsbeschreibung befinden sich Originalsätze, die wie im folgenden Beispiel zunächst mit strukturierten manuellen Umformungen schrittweise in eindeutigere Formen umgesetzt werden. Ursprünglicher Satz The ACC system includes a long-range radar sensor capable of data about moving objects travelling in the same direction as the driven vehicle. Transformierte Sätze ACC includes LongRangeRadarSensor. ACC gets data of ObjectsInFrontOfTheVehicle from LongRangeRadarSensor. ObjectsInFrontOfTheVehicle moves in the same direction as the Vehicle. Aus Platzgründen kann diese strukturierte Transformation im Folgenden leider nur skizziert werden. Das wesentliche Ziel dieser ersten Transformation ist eine textuelle Darstellung in der Redundanzen, Unvollständigkeiten und Wiedersprüche durch visuelle Inspektion wesentlich besser erkannt werden können als bei unstrukturierten Sätzen. Hierzu werden z.b. Füllwörter wie absolut, äußerst entfernt und u.a. Nebensätze in Hauptsätze umgeformt, so dass eine Menge von kurzen Sätzen in Subjekt-Prädikat-Objekt-Struktur entsteht, die mit Werkzeugen wie Excel einfach nach Subjekten sortiert werden können, was das technische Review erheblich erleichtert. So kann z.b schnell entdeckt werden, falls ein Subjekt durch mehr als einen Begriff beschrieben wird oder ob eine nicht vollständige Spezifikation vorliegt, wie z.b. am Ende der zweiten Spalte der obigen Tabelle, mit der keine stehenden oder entgegenkommenden Objekte betrachtet werden. Dies ist innerhalb komplexer Satzstrukturen in vielen Fällen nicht so einfach möglich. Am Ende der schrittweisen manuellen Umsetzung steht eine textuelle Normalform (TNF), die i.w. nur Entitäts-, Attribut-, Operations- und Relationsdeklarationen umfasst. Die TNF lehnt sich an frühen Arbeiten von Bailin [2] an und wurde von uns so definiert, dass aus ihr automatisch eine entsprechende Repräsentation als UML-Klassendiagramm erstellt werden kann. Durch die schrittweisen Transformationen in UML können die ursprünglichen Anforderungen direkt mit Entitäten des UML-Klassendiagramms verknüpft werden, was ihre direkte Verfolgbarkeit bis hin zur ausführbaren Testumgebung gewährleistet.

5 TNF-Beispiele für das obige Beispiel sind AdaptiveCruiseController is Entity. LongRangeRadarSensor is Entity. AdaptiveCruiseController has currentdistance. AdaptiveCruiseController getsdatafrom LongRangeRadarSensor. Abb. 2 zeigt das daraus generierte UML-Klassendiagramm dessen direkte Korrespondenz zu den obigen Sätzen sofort erkenntlich ist und deshalb hier auch nicht näher erläutert wird. Abbildung 2. UML-Klassendiagramm 3.2 Transformation der Klassendiagramme in Klassifikationsbäume Die Transformation der Klassendiagramme in Klassifikationsbäume ist eine notwendige Vorstufe zur Identifikation weiterer Einzelheiten, die zur endgültigen Definition der gesamten Testumgebung als Basis zur automatischen Generierung von ausführbaren Testumgebungen zwingend notwendig ist. Im ersten Schritt wird die Einteilung aller Klassen in die Kategorien <<environment>> und <<system>> durch UML-Stereotypen durchgeführt, wobei <<system>> das zu testende System bezeichnet. Danach ist für jedes Attribut aller Klassen vom Typ <<environment>> der Wertebereich als Annotation zu definieren und in Teilintervalle, die als einzelne Testbereiche von Interesse sind, aufzugliedern. Abb. 3 zeigt das Endresultat der Transformen eines Teils des Klassendiagramms unseres Beispiels. In diesem Beispiel ist z.b. der Wertebereich des Attributs desiredtimegap in die Intervalle {[0:19], 20, [21:124], 125, [126,250]} km/h unterteilt. Die Eckwerte sind normalerweise aus den Details der Anforderungsspezifikation zu entnehmen oder abzuleiten. Die Notation zur Beschreibung der Intervalle ist in unserem Beispiel der Syntax von SystemVerilog angelehnt. Aus diesem Grund sind hier auch ohne Einschränkung der Allgemeinheit geschlossene Testintervalle und Testpunkte auf Basis von Integer-Werten angegeben. Abbildung 3. Teil des UML-Klassendiagrams

6 Die endgültige Version des UML-Klassendiagramms kann nun 1:1 in einen Klassifikationsbaum umgesetzt werden, an dessen Wurzel das zu testende <<system>> steht. Die verschiedenen <<environment>>-klassen bilden die Kompositionen, während deren Attribute die Klassifikationen und die Intervalle deren Klassen bilden. Abbildung 4. Umgesetzter Klassifikationsbaum 3.3 Definition der Testszenarien Nachfolgend müssen zur Vervollständigung des Klassifikationsbaums Testszenarien als Vorstufe zur Definition der eigentlichen Testsequenzen entwickelt werden. Wir erläutern dies anhand des folgenden einfachen Szenarios mit vier Schritten. Zu dessen Erstellung muss zunächst eine oder mehr <<environment>>-klassen ausgewählt werden (hier: Fahrer) wonach deren Interaktion mit dem <<system>> beschrieben wird: 1. Fahrer stellt Geschwindigkeit (Cruisespeed) ein. 2. Fahrer stellt Abstand zum vorderen Fahrzeug (TimeGap) ein. 3. Fahrzeug meldet eine Geschwindigkeit im mittleren Bereich. 4. Fahrzeug meldet hohe Geschwindigkeit. Der nächste Schritt ist die Zuordnung der Subjekte und Objekte in dieser Beschreibung auf die Klassifikationen im Klassifikationsbaum und die Konkretisierung dieses Szenarios als UML- Sequenzdiagramm, wobei die Einzelschritte durch eine kausale Abfolge von Nachrichten zwischen den Objekten definiert werden. Das resultierende Sequenzdiagramm bildet nun die Grundlage für mehrere Instanziierungen über verschiedene Abbildungen in den Wertebereich der Nachrichtenparameter und der Zeitachse der Lebenslinien. Abb. 5 gibt das Beispiel einer möglichen Instanziierung. In diesem Beispiel werden den Lebenslinien die Zeitpunkte 0s, +2s, +3s, und +5s zugeordnet. Man sieht dort, dass in dieser Instanz des Szenarios das Fahrzeug bei 3s eine Geschwindigkeit zwischen 21 und 124 km/h hat. Jedes dieser Sequenzdiagramme kann nun als Testsequenz dem Klassifikationsbaum in Abb. 4 zugeordnet werden, zu dessen Vollständigkeit dann nur noch die Interpolationsvorschriften zwischen den diskreten Wertewechseln innerhalb einer Klassifikation hinzugefügt werden müssen. Als Beispiel sei an dieser Stelle das Sequenzdiagramm von Abb. 5 in die Testsequenz von Abb. 6 umgesetzt.

7 Abbildung 5. Testsequenz als UML-Sequenzdiagramm Abbildung 6. Erweiterter Klassifikationsbaum 3.4 Generierung der Testumgebung Im letzten Schritt des Verfahrens wird eine Testumgebung zur Ausführung der zuvor definierten Testfälle aufgebaut. Obwohl die Testumgebung in unserem Fall in der Hardwareverifikationssprache SystemVerilog [9] realisiert wurde, können aber auch andere Sprachen wie PSL [10] oder e [11] Verwendung finden, die dedizierte Konstrukte zur Definition von Verifikations- und Testumgebungen zur Verfügung stellen. Hier wird ausgenutzt, dass diese Sprachen bzw. Werkzeuge eine effiziente Stimuligenerierung als auch die Bewertung von Testergebnissen unterstützt. Wir beschränken uns im Folgenden allerdings nur auf die Generierung von Stimuli zum Random-Test mittels SystemVerilog Constraint-Definitionen. Nach der Randomisierung unter Berücksichtigung der Constraints werden die so definierten Signalverläufe adaptiert und entsprechend der Vorgaben im Klassifikationsbaum interpoliert, so dass sie über die Schnittstellen auf das Model-under-Test einwirken können. Dieser Ablauf wird durch eine ebenfalls in SystemVerilog definierte Kontrollstruktur gesteuert. Die Übersetzung der Testsequenzen Klassifikationsbaum-Testsequenzen in SystemVerilog-Code erfolgt nach dem folgenden Prinzip. Jede Testsequenz wird zunächst auf eine SystemVerilog- Klasse abgebildet. Jede SystemVerilog-Klasse bekommt eine Reihe von Array-Variablen. Jede dieser Variablen entspricht einer der Klassifikationen des Klassifikationsbaums, d.h. einem der Eingabesignale des Testobjekts für die kurze Code-Segmente wie folgt erzeugt werden:

8 class AdaptiveCruiseController_Sequence1; rand Int_class_sp currentdrivenvehiclespeed[]; Ein Array-Element korrespondiert mit einem Testschritt der Klassifikationsbaum-Testsequenz über die dann mit rand randomisiert wird. Ein Array-Element enthält eine Datenstruktur, die jeweils ein Attribut für den Zeitpunkt des Testschrittes, den Wert des Signals und die Interpolationsvorschrift aus dem Klassifikationsbaum (z.b. Rampe oder Sinus) bis zum nächsten Zeitpunkt enthält. Jede SystemVerilog-Klasse bekommt einen Constraint-Block, der die Einschränkungen der Array-Variablen gemäß dem zugehörigen Klassifikationsbaum beschreibt. Eingeschränkt werden Attribute, die für den Zeitpunkt des Testschrittes und den Wert des Signals stehen. Die Einschränkungen geben den zeitlichen Verlauf einer Testsequenz und die Auswahl der Äquivalenzklassen wieder: constraint ctmemb{ currentdrivenvehiclespeed[0].t == 0*SEC; currentdrivenvehiclespeed[0].v == 125; currentdrivenvehiclespeed[1].t == currentdrivenvehiclespeed [0].t+2*SEC; currentdrivenvehiclespeed[1].v == 125; desiredtimegap[0].t == currentdrivenvehiclespeed [0].t; desiredtimegap[0].v == 0; desiredtimegap[1].t == currentdrivenvehiclespeed[1].t; desiredtimegap[1].v inside {[2:4]}; } Hier sind Constraints für die ersten beiden Schritte (Index 0 und 1) der Testsequenz Sequence1 für die beiden Signale currentdrivenvehiclespeed und desiredtimegap abgebildet. Es wird jeweils der Wert für den Zeitpunkt t und den Wert v des jeweiligen Signals gesetzt. Für die Anpassung auf die Zeitgranularität der Simulation wird der Multiplikator SEC verwendet, mit dem Zeitangaben in Sekunden ermöglicht werden. Wie im Klassifikationsbaum angegeben, liegt der Zeitpunkt des zweiten Synchronisationspunktes 2 Sekunden nach dem ersten. In der letzten Zeile des Constraints wird das Werteintervall [2,4] für desiredtimegap direkt aus dem Klassifikations-baum in SystemVerilog übernommen. Zusätzlich enthält die SystemVerilog-Klasse eine Funktion pre_randomize(). Die Aufgabe dieser Funktion ist die Instanziierung der Array-Inhalte zur Vorbereitung der constraint-basierten Randomisierung, sowie die Initialisierung von Werte, die nicht der Randomisierung unterliegen, wie z.b. die Interpolationsart. function void pre_randomize(); foreach (currentdrivenvehiclespeed[i]) currentdrivenvehiclespeed[i]=new(); currentdrivenvehiclespeed[1].ipol = ramp; 4 Evaluierung Wir haben das Verfahren auf die Anforderungsbeschreibung eines Adaptive Cruise Controllers (ACC) aus [4] angewandt. Der Kern der ursprünglichen Anforderungsbeschreibungen bestand aus 23 Sätzen. Diese Sätze wurden mit unserer strukturierten Methode in die Textuelle Normalform (TNF) transformiert, die zum Schluss 79 Sätze enthielt. Diese Sätze konnten

9 automatisch in ein UML-Klassendiagramm mit 10 Klassen übersetzt werden. Die Tabelle in Abb. 8 gibt einen Überblick über dessen Details. Das modifizierte Klassendiagramm erhielt dann nach manuellen Transformationen nur noch 6 Klassen, die dann in einen erweiterten Klassifikationsbaum übersetzt wurden, dessen Einzelheiten in Abb. 9 zu sehen sind. Bei der Beschreibung der Testszenarien wurde sich auf 2 UML-Sequenzdiagramme beschränkt, die in 2 Klassifikationsbaum-Testsequenzen mit je 14 Testschritten umgesetzt wurden. Die endgültige Testumgebung bestand letztendlich aus 526 Zeilen SystemVerilog-Code. Abbildung 7. Generiertes Klassendiagramm Abbildung 8. Erweitertes Klassifikationsdiagramm 5 Zusammenfassung und Konklusion Dieser Artikel stellte ein strukturiertes Verfahren zum Generieren von Testumgebungen aus textuellen Anforderungsbeschreibungen mittels UML und der Klassifikationsbaummethode für eingebettete Systeme vor. Nach der Umsetzung in eine textuelle Normalform wurden die hieraus erzeugten UML-Klassen schrittweise in eine Form transformiert, die in erweiterte Klassifikationsbäume übersetzt und dann weiter automatisch in ausführbare SystemVerilog- Testumgebungen umgesetzt werden kann. Das Verfahren wurde erfolgreich anhand des Beispiels einer Anforderungsbeschreibung eines Adaptive Cruise Controllers validiert, der selbst als SystemC-Modell bereits vorlag.

10 Die Evaluierung hat sehr deutlich gezeigt, dass insbesondere in der ersten manuellen Umsetzung in TNF sehr viele unvollständige und redundante Spezifikationen aufgedeckt werden konnten, die sonst erst wesentlich später aufgefallen wären. In der Praxis würde dies eine sehr frühzeitige Vervollständigung und Korrektur der Anforderungen bedeutenden, die frühzeitig in den Entwurfsprozess mit einfließen können und so unnötige Iterationen durch Fehlentwürfe vermeiden. Wir können uns nicht vorstellen, dass dies in einer solch frühen Phase schneller mit anderen Werkzeugen wie z.b. der formalen Verifikation erreicht werden kann, da zur Verifikation ja erst ein formales Modell erstellt werden muss. Obwohl wir in unserer Studie nur ein einfaches Tabellenkalkulationsprogramm verwendet haben, können wir die Einzeltransformationen von den Originalsätzen bis hin zur TNF sehr gut nachverfolgen, was sehr wichtig für die weitere Nachverfolgbarkeit ab der ersten formalen Spezifikation (in unserem Fall: UML-Klassendiagramme) ist. Dies ist in der Praxis ein wichtiger Punkt, da hierdurch die exakte Rückkopplung mit dem Kunden auf Basis eines Pflichtenheftes unterstützt. Nichtsdestotrotz sind hier weitere Untersuchungen bzgl. einer zusätzlichen Werkzeugunterstützung zur Automatisierung nötig und sinnvoll. Vollständig Automatisieren lässt sich unserer Meinung nach nicht, da zur Umformung dieser Sätze sehr dediziertes Ingenieurwissen aus der spezifischen Domäne notwendig ist. Im Gegensatz hierzu scheint jedoch nach der automatischen Generierung der UML-Klassendiagramme bis auf die Erstellung der Testszenarien eine vollständige Automatisierung möglich, welchem wir uns auch in zukünftigen Arbeiten widmen. Danksagungen Die hier beschriebenen Arbeiten wurden teilweise durch den SFB 614 Selbstoptimierende Systeme des Maschinenbaus und das BMBF-Projekt SANITAS (01 M 3088) gefördert. Literatur [1] IEEE. ATML specification drafts and IEEE ATML status reports. SCC20 ATML Group, [2] S. C. Bailin. An object-oriented requirements specifications method. In: Communication of the ACM, 32(5), May [3] J. Bergeron, E. Cerny, A. Nightingale, A. Hunter. Verification methodology manual for SystemVerilog, Springer, [4] F. Bernin, M. Lundell, O. Lundkvist. Automotive System Case Study, Deliverable D1.1 PUSSEE Project IST , [5] M. Conrad. Modell-basierter Test eingebetteter Software im Automobil: Auswahl und Beschreibung von Testszenarien. Deutscher Universitätsverlag, [6] U. Frank. Spezifikationstechnik zur Beschreibung der Prinziplösung selbstoptimierender Systeme. Dissertation, Fakultät für Maschinenbau, Universität Paderborn, HNI-Verlagsschriftenreihe, Band 175, Paderborn, 2006 [7] J. Grossmann, M. Conrad, I. Fey, A. Krupp, K. Lamberg, C. Wewetzer. TestML A Test Exchange Language for Model-based Testing of Embedded Software. In: Automotive Software Workshop 06, San Diego, Mar [8] M. Grochtmann, K. Grimm. Software Testing, Verification and Reliability: Classification Trees for Partition Testing. John Wiley & Sons Verlag, [9] IEEE. IEEE Std Standard for SystemVerilog Unified Hardware Design, Specification and Verification Language. IEEE, November [10] IEEE. IEEE Std IEEE Standard for Property Specification Language (PSL). IEEE, September [11] IEEE. IEEE Std The Functional Verification Language e. IEEE, March [12] OVM Homepage. [13] T. J. Ostrand, M. J. Balcer. The category-partition method for specifying and generating functional tests. ACM, 1988.