Model Checking

HAUPTBEITRAG / MODEL CHECKING}

Informatik_Spektrum_26_April_2004146

EinführungMikroprozessoren wer-den neben ihrer Ver-wendung in Computernimmer häufiger auch intechnischen Gerätenwie medizinischen Sys-temen, Kraftfahrzeu-gen, Telekommunikati-onsgeräten, industriel-len Anlagen und alltäg-lichen Konsumgütern

wie Fernbedienungen, Waschmaschinen und Kü-chengeräten eingesetzt. Computersysteme, die intechnische Systeme integriert sind, bezeichnet manals „eingebettete Systeme“. Im Gegensatz zu her-kömmlichen Systemen zeichnen sie sich oftmalsdurch strengere nichtfunktionale Anforderungenaus, wie harte Realzeitanforderungen, einen ge-ringen Energieverbrauch oder eine geringe Störan-fälligkeit hinsichtlich elektromagnetischer Felder.Die Entwicklung eingebetteter Systeme wird u.a.aufgrund immer höherer Anforderungen, einerwachsenden Anzahl von Komponenten und einerkontinuierlich steigenden Entwurfstiefe immerkomplexer [15]. Die damit verbundene Beherr-schung ihrer funktionalen und nichtfunktionalenKorrektheit mit gängigen Verfahren der Fehler-suche wie Reviews, Simulations- und Testverfahrenstößt immer öfter an ihre Grenzen, da diese Verfah-ren lediglich die manuelle und damit zeit- und kostenintensive sowie fehleranfällige Überprüfungeiniger Systemläufe zulassen. Eine kurzfristigeKompensation gelingt durch die Intensivierung derAnstrengungen in diesem Segment, was einen kon-

tinuierlich ansteigenden Anteil der damit verbun-denen Kosten am Entwicklungsaufwand zur Folgehat. Trotz dieser umfangreichen manuellen Tests,wurden in zahlreichen Projekten mit industriellenPartnern des Bereichs „Sicherheitskritische Syste-me“ des Forschungsinstituts OFFIS [36] immernoch Fehler, die vorwiegend durch lange Testse-quenzen erreichbar waren, nachgewiesen. Diesspiegelt sich auch in zahlreichen Rückrufaktionenund Pressemitteilungen wider [43, 44]. Da die Sicherstellung der Korrektheit von Hard- und Soft-ware insbesondere im Bereich sicherheitskritischerSysteme das zentral zu lösende Problem darstellt,werden in Prozessmodellen (z.B. V-Modell [48, 46])und Standards (z.B. DO-178B [40]) bereits seit geraumer Zeit formale Nachweise der Korrektheit

Model CheckingGrundlagen und Praxiserfahrungen

Ralf Buschermöhle · Mark BrörkensIngo Brückner · Werner Damm

Wilhelm Hasselbring · Bernhard JoskoChristoph Schulte · Thomas Wolf

DOI 10.1007/s00287-004-0381-1© Springer-Verlag 2004

R. Buschermöhle · M. Brörkens · I. Brückner · B. JoskoC. Schulte · T.WolfOldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme (OFFIS),Bereich Sicherheitskritische Systeme,Escherweg 2, 26121 OldenburgE-Mail: {buschermoehle, broerkens, brueckner, josko,schulte, wolf}@offis.de

W. DammCarl von Ossietzky Universität Oldenburg,Fakultät II Informatik,Wirtschafts- und Rechtswissenschaften,Department für Informatik, Abteilung Sicherheitskritische Eingebettete SystemeE-Mail: [email protected]

W. HasselbringCarl von Ossietzky Universität Oldenburg,Fakultät II Informatik,Wirtschafts- und Rechtswissenschaften,Department für Informatik, Abteilung Software EngineeringE-Mail: [email protected]

Die Gewährleistung der korrekten Funktions-

weise von Hard- undSoftware ist ein ent-

scheidender Faktor beider heutigen Systement-wicklung. Dies trifft ganz

besonders auf das Gebiet der sog.„sicher-

heitskritischen“ Systemezu, bei dem ein System-

versagen Menschen-leben gefährden kann.

Informatik_Spektrum_26_April_2004 147

gefordert. Grundlage dafür ist die Erstellung einesSystemmodells sowie die Formulierung der Anfor-derungen auf Basis formaler Notationen mit ein-deutiger Semantik. Durch mathematische Verfah-ren kann nachgewiesen werden, dass das Modelldie spezifizierten Anforderungen erfüllt. Im Gegen-satz zu herkömmlichen Testverfahren sind formale Kor-rektheitsnachweise vollständig, d.h. beim Testenkann nur eine begrenzte Auswahl möglicher Sys-temläufe betrachtet werden. Wird dabei kein Fehler gefunden, kann trotzdem einerexistieren. Ein formaler Korrektheitsnachweis be-trachtet hingegen alle Systemläufe. Derartige Nach-weise mussten bislang ebenso wie auch die Trans-formation bzw. Formalisierung des Systemmodellsund der Spezifikation manuell durch einen Verifi-kationsexperten angefertigt werden. Dies hat zwarden Vorteil der Vollständigkeit, ist aber ebenfallszeit- und kostenintensiv sowie fehleranfällig. ZurVermeidung dieser Nachteile müssen Automatismenentwickelt werden, die bei der Konstruktion derBeweise unterstützen bzw. diese vollständig rech-nergestützt auf Basis der im Entwicklungsprozessentstehenden Zwischenergebnisse anfertigen kön-nen. Ein aussichtsreicher Ansatz zur Lösung dieserProblematik ist das sog. „Model Checking“ [14], beidem es sich um ein automatisiertes Verfahren zurVerifikation von endlichen zustandsbasierten ne-benläufigen Systemen handelt. Die Anfertigung desmathematischen Nachweises geschieht vollständigdurch einen Rechner. Sollte die nachzuweisende Eigenschaft verletzt werden, so kann dem Entwick-ler (beispielsweise in Form einer computergestütz-ten Debug-Sitzung) automatisch der Fehler samt einem zu ihm führenden Systemablauf präsentiertwerden.

Das bislang nicht abschließend gelöste primäreProblem des Model Checking ist die sog.„Zustands-explosion“. Darunter versteht man das exponentiel-le Wachstum der Anzahl der zu untersuchendenSystemzustände bei einer „naiven“ Verifikation. Esexistieren jedoch bereits zahlreiche Ansätze aus derForschung, um dieses Problem wirkungsvoll anzu-gehen, so dass sich mittlerweile viele praktisch rele-vante Modelle erfolgreich verifizieren lassen [8].

Die Anwendung von Verifikationsmethoden istumso sinnvoller, je früher im Entwicklungsprozesssie stattfindet, um resultierende Änderungskostenmöglichst gering zu halten. Da Modelle früh im

Entwicklungsprozess erstellt werden und zudemeinen inhärent hohen Abstraktionsgrad im Sinneeiner Plattformunabhängigkeit aufweisen, bietet es sich geradezu an, diese zu verifizieren und an-schließend im Zuge einer „Sichtung“ des Entwick-lungsraumes hinsichtlich der nichtfunktionalenAnforderungen an verschiedene Plattformen (z.B.Programmiersprachen) anzupassen. Diese Vorge-hensweise spiegelt sich u.a. in den aktuellen Spezi-fikationen der Object Management Group (OMG[35]) wider, wie z.B. der Model Driven Architecture,die den universellen Einsatz der Modellierungenfokussiert, und in der Version 2.0 der Unified Mo-deling Language (UML [45]), in der die Ausführ-barkeit der Modelle im Mittelpunkt steht. Zur Ver-deutlichung des Potenzials dieser Methoden wird in den folgenden Abschnitten auf Basis einer (for-malen) Systemmodellierung und Spezifikation temporaler Eigenschaften das Verfahren des ModelCheckings nebst einiger Optimierungsansätze erläutert und durch Praxiserfahrungen seitens derIndustrie abgerundet.

Formale SystemmodellierungTypischerweise fallen eingebettete Systeme in dieKlasse der sog. „reaktiven Systeme“ [30]. Diese terminieren nicht und sind daher nur einge-schränkt aufgrund ihres Ein- und Ausgabeverhal-tens beschreibbar. Aus diesem Grund ist es i.d.R.notwendig, sich ein Bild über die internen System-abläufe zu verschaffen, was auf Basis sog. „Zu-

ZusammenfassungAuch in weniger kritischen Bereichen wird die Korrektheit der bereitgestellten Funktionali-tät immer wichtiger. Weiterhin erhöht sich dieKomplexität der Systemfunktionalität ständig,so dass manuelle Test- und Simulationsverfah-ren viele Fehler nur noch unter unverhältnis-mäßig großem zeitlichen und personellen Auf-wand aufdecken können. Vor diesem Hinter-grund stellt dieser Artikel die Grundlagen dessog. „Model Checkings“ vor, einer automatischdurchführbaren, vollständigen Verifikationsme-thode. Ergänzt wird diese Einführung durch einige Beispiele von Erfahrungen, die durch dieAnwendung von Model-Checking-Werkzeugenin industriellem Umfeld gewonnen wurden.

MODEL CHECKING}


stände“ geschieht. Ein Zustand entspricht einerMomentaufnahme, die alle Variablen des reaktivenSystems mit ihren Wertebelegungen zu einem bestimmten Zeitpunkt enthält. Eine Zustandsände-rung (Transition) wird jeweils durch einen Aus-gangszustand und einen Folgezustand charakteri-siert. Auf diese Weise lassen sich Berechnungen reaktiver Systeme als Transitionsfolgen beschrei-ben. Die Grundlage einer Systemmodellierung isteine formale Notation, mit deren Hilfe sich die ver-wendeten Modellierungskonstrukte eindeutig inter-pretieren lassen. Ein gängiger Vertreter zur for-malen Modellierung reaktiver Systeme sind sog.„Kripke-Strukturen“ [28], eine Form zustandsba-sierter Transitionsgraphen.

Definition 1Sei A eine Menge von atomaren Aussagen. Dann ist eine Kripke-Struktur M über A ein Tupel M=(S, S0, R, L) mit einer endlichen Menge von Zu-ständen S, einer Menge von Anfangszuständen S0 ⊂ S,einer totalen Transitionsrelation R⊂ S×S (d.h. für jeden Zustand s∈S existiert eine Folgezustand s' in S mit R(s, s')) sowie einer Funktion L:S→ 2A, die jeden Zustand auf eine Menge von zugehörigen gül-tigen atomaren Aussagen abbildet.

Insbesondere die Definition der totalen Transi-tionsrelation kann mit viel Aufwand verbunden sein,da alle Übergänge einzeln aufgezählt werden müs-sen. Deshalb bedient man sich i.d.R. anderer Nota-tionen, z.B. der Prädikatenlogik, um die Berechnungdes Folgezustands zu definieren und daraus automa-tisch die Transitionsrelation abzuleiten. Das Binde-glied stellt in diesem Fall die Funktion L dar, wobeidann mit Hilfe der Prädikatenlogik korrekte Aus-sagen formuliert werden, z.B. hinsichtlich der Transi-tionsrelation zur Berechnung des Folgezustands.

Um die Anwendung modellbasierter Verifika-tionsverfahren zu veranschaulichen, wird eine Klimasteuerung betrachtet. Diese regelt die Zim-mertemperatur auf einen angenehmen Wert undkühlt bzw. heizt, wenn es zu warm bzw. zu kaltwird. Zur Darstellung des Modells der Klimaanlagebenutzen wir ein stark vereinfachtes UML-Dia-gramm. Die Anforderungen an die Klimasteuerungregeln die Reaktionen auf die von dem umgebenden

System in jedem Schritt übermittelten Temperatur-werte, jeweils in drei Ereignissen, auf die im nächs-ten Schritt folgendermaßen reagiert werden soll:

ZUKALT: Heizeinheit wird aktiviert und Kühleinheit wird deaktiviert.

ANGENEHM: Heiz- und Kühleinheit werden deaktiviert.

ZUWARM: Heizeinheit wird deaktiviert,Kühleinheit wird aktiviert.

Abbildung 1 zeigt das Klassen- und Zustands-diagramm der Klimasteuerung. Das Klassendia-gramm enthält die beiden booleschen Attributekuehlen und heizen sowie die zu empfangendenEreignisse in Form der Operationen ZUKALT,ANGENEHM und ZUWARM.

Das Zustandsdiagramm besteht aus den dreiZuständen Aufheizen, Warten und Abkueh-len, wobei Warten der Startzustand ist. Die Be-dingungen für die Zustandsübergänge sind mit denzu empfangenden Ereignissen beschriftet. Die An-weisungen der „action scripts“ sind jeweils in den Zuständen nach dem Schlüsselwort do dargestellt.Die Heiz- bzw. Kühleinheit wird aktiviert, wennheizen bzw. kuehlen zu wahr ausgewertet werden,

AbstractThe correct functioning of hard- and softwarecomponents is often a crucial factor in comput-er-based system engineering. Particularly,this is the case in the area of “safety critical”systems, where a system failure can endangerhuman life. But also in less critical areas thecorrectness of provided functionality becomesmore and more important. Furthermore thecomplexity of system functionality increasessteadily. Therefore manual test and simulationmethods can detect many errors only with inacceptable high effort concerning time andresources. Starting from this background, thisarticle presents the basics of “model checking”,an automatic and complete verification method.Based on this introduction, experience gainedwith the application of model checking tools inindustrial contexts is presented and discussed.

Abb. 1UML-Klassen- und Zustandsdiagramm„Klimasteuerung“


ansonsten werden sie deaktiviert. Aus dem Modelllassen sich nun entsprechende prädikatenlogischeFormeln extrahieren (z.B. ¬kuehlen^¬heizen^(Ereignis=ZUKALT)^¬kuehlen'^heizen'),die wiederum die Transitionsrelation einer Kripke-Struktur beschreiben, wobei die ungestrichenen Variablen im Ausgangszustand und die gestriche-nen im Folgezustand gelten. Hierbei ist zu beach-ten, dass die Temperaturereignisse auf Variablen-ausprägungen abgebildet werden müssen, da Tran-sitionen in Kripke-Strukturen nicht annotiert wer-den. Grundsätzlich ist die Anzahl der Zustände derKripke-Struktur gleich dem Produkt der Größe derVariablenwertebereiche, was in diesem Fall zwölfZuständen entspräche. Von diesen Zuständen sindin Abbildung 2 allerdings nur die neun erreichba-ren dargestellt, da es im UML-Diagramm keinenZustand gibt, in dem gleichzeitig geheizt und ge-kühlt wird.

In den durch Ellipsen symbolisierten undnummerierten Zuständen sind die jeweils gelten-den Variablenbelegungen dargestellt. Zunächst ist das die Belegung der Variablen Ereignis und darunter von links nach rechts die Belegung derbooleschen Variablen kuehlen und heizen,wobei Variable bzw. ¬Variable bedeutet, dass dieVariable in dem jeweiligen Zustand zu wahr bzw. zufalsch ausgewertet wird. Des Weiteren sind die ent-sprechenden UML-Zustände durch gestrichelte

Ellipsen gekennzeichnet. Die Startzustände 1, 2 und3 sind mit einer Eingangskante von oben mit demgleichen Ursprung versehen. Dies bedeutet, dassnur ein Zustand nach dem Start aktiv ist.

Zudem wurde angenommen, dass die Umge-bung in jedem Schritt (selbst bei der Initialisie-rung!) einen Temperaturwert übermittelt. Der Voll-ständigkeit halber sei angemerkt, dass man in dieKripke-Struktur noch einen weiteren Zustand jeweils in einen Bereich der skizzierten UML-Zustände einfügen müsste, wenn die Umgebungnicht in jedem Schritt ein Ereignis sendet (was lautUML-Semantik und ohne die angestellte Annahmein dem Modell so wäre), sprich: Ereignis=⊥.Diese Zustände würden dazu dienen, die fortschrei-tende Schrittzahl zu erfassen, falls kein Ereignisvon der Umgebung kommt.

Temporale LogikenDa sich mit Hilfe der klassischen Aussagen- oderPrädikatenlogik nicht direkt zeitliche Aussagen for-mulieren lassen, hat man diese durch Zeitoperato-ren zu sog. „Temporallogiken“ erweitert. TemporaleLogiken lassen sich derart interpretieren, dass Zeitals Folge von Schritten in einem Berechnungsbaumeiner Kripke-Struktur betrachtet wird. Dieser kanndurch das Auffalten einer Kripke-Struktur in allevon ihr möglichen Berechnungen gewonnen wer-den. In Abbildung 3 ist ein solcher Berechnungs-

Abb. 2 Erreichbare Zustände der Kripke-Struktur der Klima-steuerung

Abb. 3 Berechnungs-baum der berechen-baren Zustände zurKripke-Struktur aus Abbildung 2

MODEL CHECKING}


baum für die Kripke-Struktur aus Abbildung 2 dar-gestellt, wobei die Nummerierung der Knoten den Zustandsnummern der Kripke-Struktur ent-spricht und in diesem Fall vom Startzustand 1 aus-gegangen wurde.

Temporallogiken lassen sich grundsätzlich dahingehend klassifizieren, ob sie Verzweigungenim zugrunde liegenden Berechnungsbaum betrach-ten, wie z.B. bei der „Computation Tree Logic“ (CTL [13]), oder ob sich mit ihrem Vokabular ledig-lich lineare Berechnungsabläufe ausdrücken lassen,wie z.B. mit der „Linear Temporal Logic“ (LTL[38]). Im Folgenden wird CTL zur Spezifikation vonSystemeigenschaften genutzt.

In CTL sind prädikatenlogische Ausdrücke umdie in Tabelle 1 dargestellten temporalen Operato-ren sowie um zwei „Pfadquantoren“ erweitert. DiePfadquantoren geben an, ob eine darauffolgendeAussage für alle ausgehenden Pfade des betrachte-ten Knotens im Berechnungsbaum gilt (A) oder nurfür mindestens einen (E). In der Syntax der CTL(vgl. [14], S. 28) sind nur Formeln enthalten, in denen jedem temporalen Operator einer der beidenPfadquantoren unmittelbar vorangeht. Zur Veran-schaulichung sind in Abb. 4 zwei Berechnungsbäu-me dargestellt, in denen die CTL-Formeln EG f bzw.AF f erfüllt sind. Die schwarz ausgefüllten Kreiserepräsentieren Zustände, in denen die Pfadformelf erfüllt ist.

Temporallogische Formeln bieten eine großeMächtigkeit zur Spezifikation temporaler Eigen-schaften von formalen Systemen. Ihre Anwendungs-freundlichkeit ist jedoch, je nach verwendeter Notation zur Systembeschreibung, verbesserungs-würdig, da die Systemdarstellung nicht zwangsläu-fig den aufgefalteten Berechnungsbaum erkennenlässt. Zur Lösung dieser Problematik existieren verschiedene Herangehensweisen, zu denen bei-spielsweise die Entwicklung sog. „Pattern“ für häu-fig verwendete temporallogische Formeln oderauch verschiedene graphische Darstellungsformenwie symbolische Zeitdiagramme, sog. „Symbolic Timing Diagrams“ (STD [17]) für hardwarenaheBereiche oder sog. „Life Sequence Charts“ (LSC[16]) gehören, die sich insbesondere zur Darstel-lung von Eigenschaften objektorientierter Systemeeignen, da sie an die bekannten Message SequenceCharts (MSCs [41]) angelehnt sind. Im Gegensatzzu MSCs besitzen LSCs allerdings eine größereAusdruckskraft, da sie zwischen möglichem (exis-tenziellem) und notwendigem (universellem) Verhalten differenzieren.

Model CheckingDie Idee des Model Checking ist im Prinzip ein-fach. Auf Basis einer Kripke-Struktur M=(S, S0, R, L)und einer geforderten temporalen Formel f werdenalle Startzustände gesucht, die f erfüllen, d.h. ge-sucht wird die Menge {s∈S0|M, s|= f } (für die

Tabelle 1

Temporale Operatoren von CTL (mit den Pfadformeln f und g)

Operator Gelesen (natürlichsprachliche) Bedeutung

X f neXt time Im nächsten Zustand gilt f.F f in the Future In mindestens einem Zustand auf dem Pfad gilt f.G f Globally In allen Zuständen auf dem Pfad gilt f.f U g Until Mindestens ein Zustand auf dem Pfad erfüllt g und alle vorherigen Zustände erfüllen f.f R g Release Genau wie „Until“, allerdings sind die Gültigkeiten von f und g vertauscht.

Abb. 4 Visualisierungvon EG f und AF f


formale Definition von „|=“ vgl. [14]). Für die zu verifizierende Kripke-Struktur betrachten wir dasModell aus Abb. 2 und für die dagegen zu verifizie-rende Eigenschaft die Anforderung „jeweils einenSchritt nach dem Senden des Ereignisses ZUWARMist die Kühleinheit aktiviert und die Heizeinheit deaktiviert“. Mit Hilfe des bereits vorgestelltenCTL-Vokabulars lässt sich dies folgendermaßenformalisieren: AG((Ereignis=ZUWARM)→AX(kuehlen^ ¬heizen)).

Model Checking wird nun basierend auf demCTL-Model-Checking-Verfahren aus [14] erläutert.Der zugrundeliegende Algorithmus basiert aufder Anwendung einer Beschriftungsfunktion la-bel(s), die in mehreren aufeinanderfolgendenAusführungsschritten jeden Zustand s∈S mit gülti-gen Teilformeln von f beschriftet. Im ersten Schrittder Ausführung sind dies die in den jeweiligen Zuständen gültigen atomaren Aussagen. Somit istlabel(s)=L(s). In den anschließenden Schrit-ten wird dann sukzessive die nächst größere Teil-formel aus der zu prüfenden Eigenschaft verarbei-tet. Somit beschriftet der i-te Ausführungsschrittdie Zustände der Kripke-Struktur mit den CTL-Teilformeln von f, die eine Verschachtelungstiefevon i–1 aufweisen. Bei Terminierung des Algo-rithmus gilt: M, s|= f genau dann, wenn f ∈ la-bel(s). In Tabelle 2 sind die zu prüfenden Teilfor-meln und die Zustände der Kripke-Struktur ausAbb. 2 gegenübergestellt, in denen sie gültig sind.

In Tabelle 2 ausgelassen ist lediglich die Impli-kation von f, die verlangt, dass die Zustände, in de-nen Ereignis=ZUWARM gilt, eine Teilmenge derZustände ist, die AX(kuehlen ^ ¬heizen) erfül-len. Da dies jedoch nicht der Fall ist, schlägt derNachweis von f fehl. Dies liegt daran, dass von Zustand 5 (UML-Zustand Aufheizen) nicht wie gefordert in einen der Zustände 7, 8 oder 9 (UML-Zustand Abkuehlen) geschaltet wird. Der Fehlerkönnte durch eine Erweiterung des UML-Dia-gramms um zwei weitere Transitionen behobenwerden, die direkt von Aufheizen nach Abküh-len bzw. umgekehrt schalten, wie in Abb. 5 darge-stellt. In runden Klammern ist jeweils der entspre-chende Zustand der (geänderten) Kripke-Strukturannotiert.

Der zugrundeliegende Algorithmus hat dieZeitkomplexität O(|f |*(|S|+|R|)), wobei | f | die An-zahl der zu verarbeitenden Teilformeln, |S| die Anzahl der zu prüfenden Zustände und |R| die An-zahl verbindender Relationen repräsentiert. |R|muss in die obere Komplexitätsgrenze einbezogenwerden, wenn die aktuelle Teilformel zwei zeitlichrelationale Teileigenschaften, wie z.B. f U g, prüft.In diesem Fall müssen zunächst alle g erfüllendenZustände und anschließend alle Zustände, dieTransitionen zu den bereits beschrifteten Zustän-den besitzen, beschriftet werden. TemporallogischeFormeln weisen üblicherweise keine große Kom-plexität auf, da diese sich proportional zur Ver-

Tabelle 2Teilformeln und die Zustände der Kripke-Struktur, in denen sie gültig sind

Teilformel Gültige Zustände der Kripke-Struktur

kuehlen {7, 8, 9}¬heizen {1, 2, 3, 7, 8, 9}kuehlen¬heizen {7, 8, 9}AX (kuehlen ¬heizen) {3, 8, 9} Ereignis = ZUWARM {3, 5, 8}

Abb. 5 Korrigiertes Zustandsdiagramm„Klimasteuerung“

MODEL CHECKING}


schachtelungstiefe verhält und die Formeln schnellunübersichtlich werden können. Anders kann dasbei anderen Notationen für temporale Eigenschaf-ten aussehen. Bei der Verwendung temporallogi-scher Formeln stammt daher das bereits erwähnteZustandsexplosionsproblem im wesentlichen vomhinteren Teil der Komplexitätsformel (|S|+|R|), derdie Modellkomplexität darstellt. Diese basiert aufder Anzahl der möglichen Zustände, die eingenom-men werden können, sowie auf ihren Verbindungenuntereinander, wobei die Anzahl der Zuständegleich der Mächtigkeit des kartesischen Produktsder Wertebereiche aller Variablen ist. Diese Anzahlwird zwar durch die Konzentration auf die erreich-baren Zustände reduziert, allerdings liegt sie beipraxisrelevanten Modellen häufig jenseits von„praktischen“ (d.h. innerhalb einer gegeben Zeit-spanne mit einer gegebenen Rechnerkonstellation)oder sogar theoretischen (d.h. jeder noch so starkeRechner würde unendlich lange benötigen) Bere-chenbarkeitsgrenzen, sofern man das ModelChecking „naiv“ anwendet. Daher wurden bereitsvor geraumer Zeit Ansätze zur Zustandsraumopti-mierung entwickelt [14], von denen im Folgendeneinige kurz vorgestellt werden. Die damit erziel-baren Optimierungsfaktoren hängen jedoch immerwesentlich vom verwendeten Modell bzw. der Modellierungssprache und der zu verifizierendenEigenschaft ab, weshalb über sie i.d.R. keine allge-meingültigen Aussagen gemacht werden können.

Lösungsansätze für das Problem der Zustandsexplosion

Eine Klasse von Optimierungen betrifft das sog.symbolische Model Checking, bei dem man System-repräsentationen nutzt, die im Vergleich zu Kripke-Strukturen viele Modelle vom Rechner schnellermanipulieren lassen und beim Model Checking weniger Speicher verbrauchen, z.B. sog. „orderedbinary decision diagrams“ (OBDDs [9]). Alle Ele-

mente der Transitionsrelation werden auf OBDDsabgebildet. Es sind azyklische Graphen über einerlinear geordneten Menge von booleschen Variablen,die als Nichtterminalsymbole innerhalb des Gra-phen fungieren. Seine Terminalsymbole sind jeweilsmit 0 oder 1 beschriftet und jeder Nichtterminal-knoten hat zwei ausgehende gerichtete Kanten, einemit 0 und eine mit 1 beschriftet. Die Reihenfolgeder Beschriftungen auf jedem Pfad gemäß der Kan-tenrichtung ist strikt steigend hinsichtlich der ge-wählten Ordnung der Variablenmenge. Jeder OBDD-Knoten repräsentiert einen booleschen AusdruckOv. Jeder Terminalknoten repräsentiert den kon-stanten Wert seiner Beschriftungen, d.h. entweder 1 oder 0. Jeder Nichtterminalknoten v mit der Be-schriftung av, dessen Nachfolger entlang der 1- bzw. 0-Kante die Knoten u bzw. w sind, definiertden booleschen Ausdruck Ov := (av^Ou) ∨ (¬av^Ow),bei dem es sich um den Teilausdruck des gesamtenOBDDs handelt, den das vom Knoten v ausgehendeTeil-OBDD repräsentiert.

Abbildung 6 zeigt einen Ausschnitt des bi-nären Entscheidungsbaums und des zugehörigen OBDDs des Elements ¬kuehlen^¬heizen^(Ereignis=ZUKALT)^¬kuehlen'^heizen'^(Ereignis'=ZUKALT) der Transitionsrelationvon der Kripke-Struktur der Klimasteuerung.Da sich die Anzahl der Knoten auf jeder Ebene im Baum verdoppelt, hat der vollständige Baum127 Nichtterminal- und 128 Terminalknoten. Ausdiesem Grund und da die gekürzten Teilbäume alle zu Null ausgewertet werden, zeigt der Baumnur den Pfad, den das Element der Transitions-relation beschreibt. In analoger Weise reduziertdas OBDD den Entscheidungsbaum. Problematischsind OBDDs, die wenige Redundanzen aufweisenund dementsprechend nur wenige Reduktionenzulassen. Zudem ist die gewählte Reihenfolge derin dem OBDD kodierten Binärvariablen ein weiterer Einflussfaktor für seine Größe, da sie

Abb. 6 Binärer Ent-scheidungsbaum undzugehöriges OBDD eines Elements derTransitionsrelation


die anwendbaren Optimierungen beeinflussenkann.

Die Bezeichnung symbolisches Model Checkingstammt daher, dass das Model Checking rein syn-taktisch auf den OBDDs in Form von rückwärts-gerichteten Fixpunktberechnungen durchgeführtwird. Der Vorteil des symbolischen ModelCheckings liegt in seiner „Gedächtnislosigkeit“,da man sich im Vergleich zu Kripke-Strukturennicht merken muss, welche Zustände mit welchenBeschriftungen versehen worden sind. Dadurchfällt u.U. der zur Verifikation notwendige Speicher-platz wesentlich kleiner aus. 1987 wurde die Anwen-dung von OBDDs erstmals von Ken McMillan,der zum damaligen Zeitpunkt ein Student an derCarnegie Mellon Universität war, zur Verifikationgroßer Systeme vorgeschlagen [32]. Mit Hilfe dieserRepräsentation war er in der Lage, Modelle mitmehr als 1020 Zuständen [12] zu verifizieren. DieseGrenze konnte mittlerweile durch zusätzliche Optimierungen wesentlich erhöht werden, so dassder Exponent in der obigen Komplexitätsangabefür viele Modelle signifikant weiter angewachsen ist[10, 11]. Da symbolisches Model Checking eine voll-kommen andere Repräsentation als Kripke-Struk-turen besitzt und damit auch andere Systeme effizi-ent oder nicht effizient berechnen können, sprichtman in diesem Kontext bei exponentiell wachsen-den Problemgrößen nicht mehr von einer Zu-stands- sondern von einer sog. „BDD-Explosion“.

Neben der Nutzung von effizienter manipulier-baren Systemrepräsentationen nutzt man Verfahrenzur Reduktion des Zustandsraums, die in Abhän-gigkeit vom Modell und der zu verifizierenden Eigenschaft angewendet werden. In diesem Zusam-menhang bilden Abstraktionstechniken Zustands-mengen auf abstraktere Teilmengen ab, wobei diezu verifizierende Eigenschaft nicht direkt oder indirekt von einem der zu abstrahierenden Modell-elemente abhängen sollte. Abstraktionen lassensich entweder manuell oder automatisch anwen-den, wobei erstere von der Kreativität und Erfah-rung des Modellierers abhängen. Letztere hingegenuntersuchen z.B. automatisch Berechnungsbezie-hungen zwischen Variablen, um daraus Hinweisefür eine Wertebereichsreduktion abzuleiten [29];sie analysieren die Unabhängigkeit konkurrierendausgeführter Transitionen zur Beschleunigung derVerifikation asynchroner nebenläufig ausgeführterSoftwareprozesse (sog. „Partial Order Reduction“

[47]) und sie nutzen Symmetrien im Systemmodell[2], um die Anzahl der notwendigen Beschriftun-gen bei der Verifikation durch günstiges Kopierender symmetrischen Teile zu reduzieren. DerartigeAnsätze lassen sich unter dem Begriff „explizites“Model Checking zusammenfassen, da abstraktesund konkretes Modell immer das gleiche Verhaltenhinsichtlich der für das Modell zu verifizierendenEigenschaft aufweisen. Im Gegensatz dazu basiertder Ansatz einer weiteren Abstraktionstechnik aufder Berechnung sog. „Überapproximationen“ desOriginalmodells. Hierbei werden Transitionen beider Approximation auf Kosten eines größeren Zustandsraums entfernt. Dies funktioniert immerdann, wenn es günstiger ist, eine Menge von Zu-ständen zu beschriften als ihre exakte Teilmenge zu bestimmen, die über Transitionen miteinanderin den Berechnungen beschrieben ist. Für die nachzuweisende Eigenschaft bedeutet dies: Wennsie für das abstrakte Modell wahr ist, dann ist sieauch wahr für das Ausgangsmodell. Sollte sie je-doch falsch sein, könnte sich bei dem Versuch derDarstellung des Gegenbeispiels zeigen, dass sichdas Verhalten des abstrakten und des Ausgangs-modells unterscheidet. Ist dies der Fall, wird dasabstrakte Modell in Richtung des abweichendenVerhaltens des Gegenbeispiels verfeinert. Die Be-rechnung der Überapproximationen geschiehtdurch eine Sammlung weiterer Abstraktionstechni-ken, z.B. dem sog. „Freeing“, das den möglicher-weise beschränkten Wertebereich einer Variablen,die durch eine Systemkomponente berechnet wird,durch den vollständigen Wertebereich ihres Daten-typs ersetzt. In Kombination mit der sog. „Cone-of-Influence-Methode“, welche die Modularität vonSystemstrukturen nutzt, um hinsichtlich der Spezi-fikation abhängige Teile zu identifizieren, könnenso „Überapproximationen“ bestimmt werden, in-dem z.B. die Transitionen einer Systemkomponenteentfernt werden und ihre Ausgangsvariablen jeweilsden kompletten Wertebereich einnehmen. Ein Beispiel für einen solchen Überapproximationsan-satz ist die sog. „Automatic Abstraction/RefinementMethodology“ [7]. Mit Hilfe dieser Technik konntedie Verifikation zahlreicher Modelle industriellerAnwender beschleunigt bzw. erstmalig innerhalbeiner praktischen Berechenbarkeitsgrenze von 24 Stunden durchgeführt werden. Die folgendeÜbersicht gibt einen Eindruck von den erzieltenResultaten. Als Maß für die Komplexität der Model-

MODEL CHECKING}


le sind jeweils die Zustands-Bits, die Input-Bits unddie Größe der Transitionsrelation angegeben. DieZustands- und Input-Bits korrelieren mit der An-zahl von BDD-Variablen, die notwendig waren, umdas Modell zu kodieren. Die Größe der Transitions-relation gibt Auskunft darüber, wie viele BDD-Knoten notwendig waren, um das interne Verhaltenabzubilden.

Beispielsweise sollte das Modell „Radio BasedSignaling System“ verifiziert werden. Das Modellbeschreibt ein funkgesteuertes Signalsystem füreinen Bahnübergang. Es sollte u.a. geprüft werden,ob die Signale gesichert werden, nachdem dieBahnschranke geschlossen wurde (E1) und ob einZug nur passiert, wenn der Bahnübergang zuvorgesichert wurde (E2). Zur Verifikation kam ein UltraSparc-III System mit 750 MHz und 2.5 GBRAM zum Einsatz.

Bei den zur Verifikation notwendigen Lauf-zeiten weiterer Modelle konnten ähnliche Optimie-rungsfaktoren erzielt werden (für eine vollständigeÜbersicht vgl. [7]). Im schlechtesten Fall benötigteeine Iteration bei der Verifikation des abstraktenModells die gleiche Zeit wie zuvor auf Basis gängi-ger Optimierungsverfahren. Die Ergebnisse in Tabelle 3 verdeutlichen anschaulich das Potenzialadäquater Optimierungstechniken.

Model Checking in der PraxisDie manuelle Transformation von Modellen sowiedie Anwendung von Model-Checking-Methoden istzwar zur Veranschaulichung der Funktionsweisenin kleinen Beispielen durchaus adäquat; bei prak-tisch relevanten Modellgrößen ist sie jedoch i.d.R.kaum durchführbar. Daher wurden Werkzeuge für verschiedene Anwendungsbereiche entwickelt,die diese Aufgaben automatisch erledigen. Um deren Potenzial einschätzen zu können, wird im

Folgenden über einige Erfahrungen berichtet, dieinsbesondere die Breite der Anwendungsmöglich-keiten des Model Checking verdeutlichen. Setzteman Model-Checking-Methoden anfangs nahezuausschließlich zur Verifikation von Hardware ein[33], findet man sie seit einiger Zeit verstärkt auchin Projekten industriell relevanter Größen-ordnungaus dem Bereich der „reinen“ Software-Entwick-lung. Zudem nutzt man neuerdings immer häufigereine Kombination aus modellbasierten Entwurfs-und Verifikationsmethoden, um Fehler bereits frühim Entwicklungsprozess zu erkennen, und somitaufwändige Änderungsarbeiten später in der Ent-wicklung zu vermeiden.

Einsatz von Tools zur formalen Verifikationbei Motorola

In den letzten Jahren hat die Halbleitersparte vonMotorola im Entwicklungsprozess die Verwendungformaler Methoden eingeführt, um Fehler auf derTransistorschaltebene sowie funktionale Fehler aufder Registertransferebene (RTL) zu vermeiden.Entwickelt wurden dabei das Werkzeug Versys2 so-wie eine auf CBV (Cycle-Based Verilog) basierendeWerkzeug-Suite [1].

Die Entwicklung von individuellen Speicher-chips nach Kundenwünschen („custom memory“)erfolgt durch einen manuellen Entwurf auf Transis-torschaltebene, auf der das Layout des zu fertigen-den Chips festgelegt wird. Zusätzlich wird ein Modell auf der Registertransferebene (RTL) eben-falls manuell entwickelt. Die RTL-Sicht ist einefunktionale Beschreibung mit Hilfe von Registernund logischen Schaltungen. Diese Sicht wird für diefunktionale Verifikation des restlichen Entwurfsverwendet. Mit Hilfe von Versys2 ist es möglich, dieAnforderungen, die aus der Registertransferebeneautomatisch extrahiert werden können, gegen die

Tabelle 3

Ergebnisse der automatischen Abstraktion am Beispielmodell des funkgesteuerten Signalsystems

Eigenschaft Z I B E T

E1 (V) 81 16 8615 wahr 5 sE1 (N) 24 29 5958 wahr 1.7 s E2 (V) 126 26 18603 k.A. >24 h E2 (N) 10 36 1132 wahr 0,4 s

Abkürzungen: Z Zustands-Bits, I Input-Bits, B BDD-Knoten, E Ergebnis, T Zeit, V/N vor/nach der Optimierung


Transistorschaltung zu verifizieren. Versys2 ist einsymbolischer Simulator. Er simuliert das Schal-tungsmodell des Transistorschaltbildes und verifi-ziert die Annahmen und Bedingungen, die aus derRegistertransferebene extrahiert wurden. Motorolahat Versys2 in den Entwurfsprozess für Speicher-chips eingeführt und hat damit eine Vielzahl anDiskrepanzen zwischen der Registertransferebeneund den zugehörigen Transistorschaltbildern fin-den können.

Die auf der Spezifikationssprache Cycle-basedVerilog (CBV) basierende Werkzeug-Suite dient der funktionalen Verifikation auf der RTL-Ebene.Motorola setzt die Werkzeugsuite in der unabhän-gigen Verifikation kleiner individueller Entwurfs-blöcke bis hin zur kompletten Chip-Simulation ein.Die Spezifikationssprache CBV, auf der die Werk-zeug-Suite basiert, ist eine temporallogische Spezi-fikationssprache für die Verifikation des Hardware-Entwurfs und wurde insbesondere für Entwicklerlogischer Schaltungen entwickelt, die keine akade-mische Ausbildung haben. Die Sprache ähnelt zu-dem weniger einer temporallogischen Spezifikati-onssprache als eher einer Programmiersprache undsoll bereits nach einer kurzen Einarbeitungsphasedie Erstellung komplexer Spezifikationen ermögli-chen.

CBV wird verwendet, um zulässige Eingabenfür Unterkomponenten, zu verifizierende Eigen-schaften und zu erfassende Events, die während der simulationsbasierten Verifikation aufzuzeich-nen und aufzuspüren sind, zu definieren. Beispiel-haft sei die folgende Codierung einer Anforderungin CBV gezeigt, welche beschreibt, dass einem Eingangssignal req innerhalb von drei Zyklen einSignal resp folgen soll:

if (~ req)// Das Signal req soll „low“

sein,if +(1) : (req)

// und nach einem Takt auf„high“ wechseln.

if +(1 to 3) : (~ resp) // Die nächsten 3 Takte soll aufresp gewartet werden,

0; // sollte das Signal nicht kom-

men, soll abgebrochen werden.

Analyse von Software mit dem Model Checker SPIN

Eines der bekanntesten Werkzeuge für die „lineartemporal logic“ (LTL) wurde an den amerikani-schen Bell Laboratories entwickelt: Der Model Checker SPIN (Simple Promela Interpreter, wobei Promela (Process Meta Language) die Eingabespra-che für SPIN ist [24, 25]). Dieser war in der Lage,in zahlreichen Fallstudien Modelle von industriellrelevanter Größe zu verifizieren, die regelmäßig aufden seit 1995 jährlich stattfindenden Workshopspräsentiert werden [42]. Bei SPIN handelt es sichum ein Verifikationssystem, das mit dem Ziel ent-wickelt wurde, den Entwurf und die Verifikationasynchroner Prozesse zu unterstützen. Eine relativjunge Anwendung von SPIN existiert im Werkzeug„FeaVer“ (Feature Verification System, [26]), dasursprünglich dafür entwickelt wurde, die Anrufver-arbeitungs-Software der kommerziellen Telefon-anlage „PathStar Access Server“ zu überprüfen, da-rüber hinaus jedoch in der Lage ist, beliebigenANSI-C-Quellcode mit Model-Checking-Methodenzu analysieren. Das initiale Projekt zur Analyse derTelefonanlagen-Software wurde über einen Zeit-raum von 18 Monaten begleitend zur Entwicklungder Telefonanlage und in kontinuierlicher Zusam-menarbeit mit den Entwicklern der Software durch-geführt, beginnend beim ursprünglichen Entwurfim Jahr 1998 bis zum kommerziellen Vertrieb desProdukts im Jahr 2000.

Die Erstellung des formalen Systemmodells erfolgt bei „FeaVer“ zu großen Teilen automatisiert,basierend auf der eigentlichen Software sowie aufeiner manuell erstellten sog. „Test Harness“. Dieselegt verschiedene Parameter fest, die für die Extrak-tion des Promela-basierten Automaten nötig sind,der schließlich vom Model-Checker-SPIN analy-siert werden kann. Insbesondere ist es hier mög-lich, Regeln für Abstraktionen zu definieren, die dieKomplexität der betrachteten Programme so reduzieren, dass der Model Checker in akzeptablerZeit Ergebnisse für LTL-Eigenschaften dieses Mo-dells berechnen kann. Diese Abstraktionen könnensehr unterschiedlich aussehen. Beispielsweise kön-nen Funktionsaufrufe dadurch abstrahiert werden,dass im Modell nur noch der Funktionsaufruferhalten bleibt, nicht aber der in der Funktion ent-haltene Code, wenn für die Verifikation beispiels-weise nur die Reihenfolge der Funktionsaufrufe

MODEL CHECKING}


interessant ist. Eine andere mögliche Form der Ab-straktion besteht darin, in Abhängigkeit von derAbbildung bestimmter Datentypen deterministi-sche durch nichtdeterministische Verzweigungenzu ersetzen.

Abbildung 7 stellt einen Ablauf einer Verifikati-on mit „FeaVer“ dar, wobei die gestrichelten Liniendiejenigen Punkte kennzeichnen, die das Ergebnismanueller Aktivitäten sind. Dazu gehört zunächstdie Erstellung des C-Codes als Ausgangsbasis,des Weiteren die Abstraktionsfunktionen, auf derenGrundlage der Automaten-Extraktor die abstra-hierten Modelle erstellt, sowie die Formulierungder LTL-Eigenschaften, die schließlich durch SPINnachgewiesen werden sollen. Obwohl bei dem An-satz von „FeaVer“ die Notwendigkeit der zeitinten-siven und fehleranfälligen manuellen Konstruktionvon Verifikationsmodellen umgangen wird, sind die verbleibenden Arbeitsschritte nach wie vorrecht aufwändig. Nachdem eine Konfiguration füreinen Verifikationslauf mit „FeaVer“ eingerichtetwurde, stellt sich der Rest der Verifikation aller-dings als verhältnismäßig einfach dar und erfordertauch bei Modifikationen des Quelltextes keinen wesentlichen zusätzlichen Aufwand, solange die zu verifizierenden Eigenschaften und die Abstrak-tionen nicht von den Änderungen abhängen. Fürdie initiale Entwicklung einer geeigneten Kon-figuration für Verifikationsläufe ist jedoch nach wievor ein nicht unerheblicher Aufwand notwendig,der aufgrund der damit verbundenen manuellenArbeit auch selbst wiederum eine Fehlerquelle seinkann.

Die mit „FeaVer“ gewonnenen Erfahrungenzeigen jedoch, dass ein deutlich größerer Anteil

von Entwurfs- und Implementierungsfehlern beider Softwareentwicklung als mit herkömmlichenMethoden des Testens erkannt werden kann. DieseAnwendungsergebnisse von „FeaVer“ konnten inmehreren Projekten (z.B. [23]) erfolgreich bestätigtwerden. Nach Auskunft von Gerard Holzmann

We measured ten times more errors beingcaught with our verification framework, com-pared to the traditional approach (70 vs 7).We also used ten times fewer people (2 insteadof 20).

konnte eine Effizienzsteigerung um zwei Größenord-nungen bei der Fehlersuche verzeichnet werden.

Modellbasierte Analyse mit der OFFIS Verification Environment

Am Forschungsinstitut OFFIS wird seit geraumerZeit eine Umgebung zur Anbindung formaler Methoden, wie Verifikation, automatischer Testvek-torgenerierung und Sicherheitsanalyse entwickelt.Für eine Anbindung an Entwicklungswerkzeugewurden bislang primär Modellierungswerkzeugeausgewählt, um die Mächtigkeit formaler Methodenzur Fehlerfindung bereits frühestmöglich im Ent-wicklungsprozess zur Verfügung zu stellen.

Neben dem Modellierungswerkzeug Statemate(I-Logix, [27]) wurden unter anderem ASCET-SD(ETAS, [21]), Rhapsody (I-Logix, [27]) und SCADE(Esterel Technologies, [20]) angebunden. Seitensder Model Checker können VIS (University ofCalifornia at Berkeley, [49]) und der SAT-SolverProver CL (Prover Technologies, [39]) eingesetztwerden. In experimentellem Stadium befinden sich

Abb. 7 „FeaVer“ Framework zur Extrak-tion von Modellen ausANSI-C-Programmen


darüber hinaus Anbindungen an die SAT-SolverGoblin (Universität Oldenburg, [22]) sowie anzChaff (Princeton University, [51]). Zudem sichertder modulare Aufbau der Umgebung die zukünftigeIntegration noch kommender Entwicklungswerk-zeuge und Model Checker. Im Gegensatz zum vorherigen Abschnitt kommen hierbei vollständigautomatisch mittels eines Rechners durchführbareOptimierungstechniken zum Einsatz. Diese Verifi-kationsumgebung hat das Unternehmen OSC-Embedded Systems AG [37], ein Spin-Off von OFFIS, mittlerweile zur Marktreife weiterentwickeltund realisiert momentan zugleich eine Ankopplungan das Modellierungswerkzeug Matlab/Simulink/Stateflow (The Mathworks, [31]) unter Verwendungdes Produktionscodegenerators TargetLink(dSPACE, [19]).

Die Evaluation der Verifikationsumgebungwurde bereits durch mehrere industrielle Projekt-partner vorgenommen. Unter anderen begleiteteder Automobilkonzern BMW die Verifikation vonASCET-SD-Modellen [18]. Bei der Evaluation konn-te erfolgreich eine sog. „Failsafe-Komponente“ der aktiven Lenkunterstützung im neuen 5er BMWverifiziert werden. Die zu überprüfende Eigenschaftbetraf das unbedingte Abschalten der Lenkunter-stützung im Fehlerfall, das im System durch zweiredundante Komponenten sichergestellt wird, diebei einer korrekten Funktionalität immer die glei-chen Werte ermitteln. Durch die Verifikation wurdeein Fall gefunden, in dem das System sich trotz eines Fehlers nicht abschaltete. Dieser Fehler wurdezwar auch mit manuellen Testverfahren gefunden,allerdings war der damit verbundene Aufwand ungleich höher. Ein weiterer industrieller Partnerist das Unternehmen DaimlerChrysler, das die Model-Checking-Lösung von OSC auf der Basis vonStatemate (I-Logix, [27]) zu einem Kernelement seines Software-Entwicklungs-Prozesses im Bereich„By-Wire-Systeme“ gemacht hat. Abschließend seiauf den Automobilkonzern Nissan verwiesen, derzur Sicherstellung der Entwurfsanforderungen denEinsatz von Model-Checking-Technologien bereitsauf Modellebene und damit noch vor der Erstel-lung aufwändiger Prototypen fest im Entwurfspro-zess vorsieht [34].

Aber nicht nur im Automobil-, sondern auchim Bahn- und Luftfahrtbereich bestätigen Anwen-der den sinnvollen Einsatz formaler Methoden.Eine der genannten primären Schwierigkeiten be-

steht häufig noch in der Formalisierung der An-forderungen in entsprechenden temporalen Nota-tionen. Daher wird bereits seit längerem an derEntwicklung von weiteren anwendungsspezifischentextuellen und visuellen Darstellungen temporalerEigenschaften gearbeitet.

FazitModel Checking ist bereits seit langem eine interes-sante Methode zur automatischen Anwendung formaler Verifikationstechniken. Die praktischenAnwendungsbereiche fokussierten bislang jedocheher auf kleinere Systeme. Aufgrund aktueller Forschungsergebnisse in Kombination mit immerleistungsfähigeren Rechnern konnten die prakti-schen und theoretischen Berechenbarkeitsgrenzenimmer weiter ausgeweitet werden, so dass mittler-weile komplexere praxisrelevante Systeme erfolg-reich verifiziert werden konnten. Neben den in diesem Artikel dargestellten Ansätzen des ModelCheckings werden außerdem verschiedene andereTechniken verfolgt, mit denen beispielsweise auchSysteme mit Echtzeitanforderungen behandelt werden können [4, 5] oder mit denen es möglichist, Modelle hybrider Systeme zu analysieren, beidenen kein endlicher Zustandsraum vorausgesetztwird [3]. Zusammenfassend lässt sich feststellen,dass die Entwicklungszeit eingebetteter Systemedurch die formale Verifikation verkürzt werdenkann. Außerdem ermöglicht sie es, Fehler zu entde-cken, die mit konventionellen Testmethoden nichtgefunden worden wären [6]. Ist zudem die nahtloseIntegration in den Entwicklungsprozess gewährleis-tet, dürfte es nur noch eine Frage der Zeit sein, bisformale Methoden ein fester Bestandteil von Ent-wicklungsprozessen geworden sind.

DanksagungDas diesem Artikel zugrundeliegende Vorhabenwurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkenn-zeichen „01ISA02G“ („ViSEK“, Virtuelles Software Engineering Kompetenzzentrum) gefördert. DieVerantwortung für den Inhalt dieser Veröffent-lichung liegt bei den Autoren. Weitere Informatio-nen zu den Themen formale Methoden, modell-basierte Entwicklung und Unterstützung von Ent-wicklungsprozessen sind im ViSEK-Portal [50] zu finden.

MODEL CHECKING}


Literatur1. Abadir, M.S., Albin, K.L., Havlicek, J., Krishnamurthy, N., Martin, A.K.: Formal verification

successes at Motorola. Formal Methods in System Design 22:117–123 (2003)2. Ajami, K., Haddad, S., Ilië, J.-M.: Exploiting symmetry in linear time temporal logic

Model Checking: one step beyond. Lecture Notes in Computer Science 1384 (1998)3. Alur, R., Courcoubetis, C., Henzinger, T.A., Ho, P.-H.: Hybrid automata: An algorithmic

approach to the specification and verification of hybrid systems. In: Grossman, R.L.,Nerode, A., Ravn, A.P., Rischel, H. (eds.): Hybrid systems, vol 736. Berlin HeidelbergNew York Tokio, Springer 1993, pp. 209–229

4. Alur, R., Dill, D.: A theory of timed automata.Theor Comp Sci 126, 283–235 (1994)5. Alur, R., Henzinger, T.A.: Logics and models of real time: A survey. In Real time: Theory

in practice, vol. 600. Berlin Heidelberg New York Tokio: Springer 1992, pp. 74–1066. Bienmüller, T., Bohn, J., Brinkmann, H., Brockmeyer, U., Damm, W., Hungar, H.,

Jansen, P.: Verification of automotive control units. Correct System Design1710:319–341 (1999)

7. Bienmüller, T.: Reducing complexity for the verification of statemate designs. PhDthesis, Fachbereich Informatik, Carl von Ossietzky Universität Oldenburg 2003

8. Bohn, J., Damm, W., Klose, J., Moik, A., Wittke, H.: Modeling and validating train systemapplications using statemate and live sequence charts. In: Society for Design and Process Science:Proceedings of the Conference on Integrated Design and ProcessTechnology (IDPT2002). Society for Design and Process Science 2002

9. Bryant, R.E.: Graph-based algorithms for boolean function manipulation. IEEE Trans.Comput. C-35 (8): 677–691 (1986)

10. Burch, J.R., Clarke, E.M., Long, D.E.: Symbolic Model Checking with partitioned transition relations. In: Halaas, A., Denyer, P.B. (eds.): International Conference on VeryLarge Scale Integration, North-Holland, Edinburgh/Scotland 1991, pp. 49–58

11. Burch, J.R., Clarke, E.M., Long, D.E., MacMillan, K.L., Dill, D.L.: Symbolic Model Checkingfor sequential circuit verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 13 (4): 401–424 (1994)

12. Burch, J.R., Clarke, E.M., McMillan, K.L., Dill, D.L., Hwang, L.J.: Symbolic ModelChecking: 1020 States and Beyond. In: Proceedings of the Fifth Annual IEEE Symposium on Logic in Computer Science.Washington: IEEE Computer Society 1990,pp. 1–33

13. Clarke, E.M., Emerson, E.A., Sistla, A.P.: Automatic verification of finite-state concurrentsystems using temporal logic specifications. ACM TOPLAS 8 (2): 244–263 (1986)

14. Clarke, E.M., Grumberg, O., Peled, D.A.: Model Checking. Boston: MIT Press 199915. Damm, W., Cohen, M.: Advanced validation techniques meet complexity challenge

in embedded software development. Embedded Systems Journal (2001)16. Damm, W., Harel, D.: LSCs: Breathing life into message sequence charts. In: Ciancarini,

P., Fantechi, A., Gorrieri, R. (eds.): FMOODS „99 IFIP TC6/WG6.1, Third International Conference on Formal Methods for Open Object-Based Distributed Systems.Dordrecht: Kluwer 1999, pp. 293–312

17. Damm, W., Josko, B., Schlör, R.: Specification and verification of VHDL-based system-level hardware design. In: Börger, E. (ed.): Specification and validation methods.Oxford: Oxford Univ Press 1995, pp. 331–410

18. Damm, W., Schulte, C., Segelken, M., Wittke, H., Higgen, U., Eckrich, M.: Formale Verifikation von ASCET Modellen im Rahmen der Entwicklung der Aktivlenkung.Informatik 200 GI-workshop automotive SW engineering & concepts, September2003

19. dSPACE GmbH,http://www.dspace.de/ 200320. Esterel Technologies,http://www.esterel-technologies.com/ 200321. ETAS,http://www.etas.de/ 2003

22. Fränzle, M., Herde, C.: Efficient SAT engines for concise logics: Accelerating proofsearch for zero-one linear constraint systems. In Vorbereitung

23. Gluck, P., Holzmann, G.: Using SPIN model checking for flight software verification.In: IEEE (ed.): Proc. 2002 Aerospace Conference. Big Sky/MT, USA, March 2002

24. Holzmann, G.J.: Design and verification of computer protocols. London: Prentice Hall1991

25. Holzmann, G.J.: Tutorial: Design and validation of protocols. London: Prentice Hall1991

26. Holzmann, G.J.: Software analysis and model checking. In: Brinksma, E., Larsen, K.G.(eds): Computer aided verification. 14th International Conference, CAV 2002.Copenhagen, Denmark, July 2002. Berlin Heidelberg New York Tokio: Springer 2002

27. I-Logix,http://www.ilogix.com/ 200328. Kripke, S.A.: Semantical considerations on modal logic. In: Linsky, L. (ed.): Reference

and modality. Oxford: Oxford Univ Press 197129. Loiseaux, C., Graf, S., Sifakis, J., Bouajjani, A., Bensalem, S.: Property preserving

abstractions for the verification of concurrent systems. Formal Methods in SystemDesign 6 (1):11–44 (1995)

30. Manna, Z., Pnueli, A.: Temporal verifications of reactive systems. Berlin HeidelbergNew York Tokio: Springer 1995

31. The MathWorks,http://www.mathworks.com/ 200332. McMillan, K.L.: Symbolic Model Checking – an approach to the state explosion prob-

lem. PhD thesis, Carnegie Mellon University, 199233. Meinel C., Theobald, T.: Geordnete binäre Entscheidungsgraphen und ihre Bedeutung

im rechnergestützten Entwurf hochintegrierter Schaltkreise. Informatik Spektrum20:268–275 (1997)

34. Nissan selects I-Logix“ Statemate MAGNUM Tool Chain for Complete Model BasedDevelopment Process of Body Electronics Systems,http://www.ilo-gix.com/news/press_detail.cfm?pressrelease=2002_09_09_ 115242_749386pr.cfm2003

35. Object Management Group,http://www.omg.org 200336. Homepage: Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-

Werkzeuge und Systeme,http://www.offis.de 200337. OSC-Embedded Systems AG,http://www.osc-es.de/ 200338. Pnueli, A.: The temporal logic of programs. In 18th Annual Symposium on Founda-

tions of Computer Science, IEEE, 1977, pp. 46–5739. Prover Technologies,http://www.prover.com/ 200340. RTCA. DO-178B. RTCA, 1140 Connecticut Avenue, Northwest, Suite 1020, Washington,

D.C. 20036–4001 USA, 199241. Rumbaugh, J., Jacobson, I., Booch, G.: The unified modeling language reference

manual. Addison-Wesley Longman 1999. 0–201-30998-X42. Spin – Formal Verification,http://spinroot.com/spin/whatispin.html 200343. Touring Club Suisse: Rückruf von Personenwagen.http://www.tcs.ch/WEBTCS/

Resources.nsf/(ImageName)/3229de.pdf/$FILE/3229de.pdf 200344. Thailändischer Minister in BMW gefangen,http://www.spiegel.de/panora-

ma/0,1518,248319,00.html 200345. Unified Modeling Language,http://www.omg.org/uml 200346. UML-Repräsentation des V-Modells.http://www.visek.de/?7445 200347. Valmari, A.: A stubborn attack on state explosion. In: DIMACS. ACM, 1990, pp. 25–4248. Versteegen, G.: Das V-Modell in der Praxis – Grundlagen, Erfahrungen, Werkzeuge.

dpunkt.verlag 200049. VIS Homepage,http://www-cad.eecs.berkeley.edu/ vis/ 200350. ViSEK Homepage,http://www.visek.de 200351. zChaff,http://www.ee.princeton.edu/ chaff/zchaff.php 2003

Documents

Model Checking