Beispiele zur Verifikation und pratkische Probleme

Transkript

1 Martin Luther Universität Halle Wittenberg Institut für Informatik Lehrstuhl für Softwaretechnik und Programmiersprachen Beispiele zur Verifikation und pratkische Probleme Verifikation informationsverabeitender Systeme Seminararbeit Wintersemester 2007/2008 eingereicht am : 14. Februar 2008 von : Christian Berg Betreuer : Dr. Werner Gabrisch, Dipl.-Inform. Andreas Both

2 Beispiele zur Verifikation und pratkische Probleme 2 Inhaltsverzeichnis 1 Einleitung SMV Einführende Beispiele Binärzähler Bewertung des Modells Inverterring Bewertung Inverterring Zusammenfassung der einführenden Beispiele Komplexere Beispiele Mikrowelle Das Modell Via EC bezahlen Wie sieht die Realität aus? Ein Anfang Rechnungsbetrag prüfen Kasse und Bank Aufzug Zusammenfassung 15 Literatur 17 Abbildungsverzeichnis 17

3 Beispiele zur Verifikation und pratkische Probleme 3 1 Einleitung Es gibt viele Komponenten, die verifiziert werden müssen, im wesentlichen aufgrund von Sicherheitsanforderungen. Allein in einem handelsüblichen PKW gibt es mehr als 5 Komponenten, die verifiziert werden müssen - angefangen bei ABS 1 über ESP 2 bis hin zu verschiedenen Mechanismen zur automatischen Geschwindigkeitsregulierung. Nicht nur bei solch offensichtlich komplexen und potentiell lebensgefährdenden Komponenten kommt Verifikation zur Anwendung, auch in solch einfachen Geräten wie einer Mikrowelle. Des weiteren gibt es eine ganze Reihe von Industrieanlagen bei denen sicher gestellt sein muss, dass Menschen durch die Verwendung der Maschine nicht verletzt werden können. Diese Ausarbeitung soll einen kleinen Blick auf die Probleme werfen, die entstehen können, wenn man sich zum einen zu sehr auf die Tools verlässt und zum anderen welche Probleme in der Praxis auftreten können, die solch ein Tool gar nicht betrachten kann. Für all die genannten Anwendungen und noch für viele mehr kommen hierbei Tools zum Einsatz, die formal Modelle verifizieren können. Eines dieser Tools ist (Nu)SMV, welches für die (von SMV teilweise mitgelieferten) Beispiele auch verwendet werden soll. Hauptaugenmerk soll allerdings auf den Problemen liegen, die entstehen können und nicht unbedingt auf einer Erklärung der Beispiele. 1.1 SMV SMV steht für Symbolic Model Verifier. Im Gegensatz zu anderen Tools ist die Lizenz sehr liberal, sodass SMV als Teil eigener Programme genutzt werden kann. NuSMV steht für New SMV und ist eine Reimplementierung des originalen SMV und bringt schon viele Beispiele mit. Im folgenden wird nicht mehr zwischen NuSMV und SMV unterschieden, da insbesondere die Syntax sich nicht geändert hat und das Verhalten der einzelnen Versionen sich zwar in wichtigen Details unterscheidet, aber nicht grundlegend. 2 Einführende Beispiele Wie schon erwähnt kann SMV zur formalen Verfikation von Komponenten genutzt werden. Komponenten werden immer abstrahiert und in einem Modell beschrieben, auf welchem man nun formale Eigenschaften prüfen kann. Eine Eigenschaft für ein ABS wäre zum Beispiel, dass die Bremsen nur gelöst werden, wenn die Räder wirklich blockieren. SMV kann allerdings auch genutzt werden um Testbenches zu generieren. 2.1 Binärzähler Als ein einfaches einführendes Beispiel, sei ein Binärzähler gewählt. Dieser Binärzähler ist schon im Beispielpaket von SMV dabei, hat 3 Bits und soll einfach nur hoch zählen. Hierbei tritt schon ein 1 Anti-Blockier System 2 Elektronisches Stabilitätsprogramm

4 Beispiele zur Verifikation und pratkische Probleme 4 erstes Problem auf: Wie behandelt man einen Überlauf? Des weiteren muss man sich natürlich auch fragen welche weiteren Probleme auftreten können. Der Binärzähler besteht nun aus 3 einfachen Zellen, jede Zelle hat einen Eingang (carry_in) und zwei Ausgänge (carry_out und value). Listing 1: Berechnungszelle MODULE c o u n t e r c e l l ( c a r r y i n ) v a l u e : b o o l e a n ; i n i t ( v a l u e ) := 0 ; next ( v a l u e ) := ( c a r r y i n + v a l u e ) mod 2 ; DEFINE c a r r y o u t := v a l u e & c a r r y i n Der komplette Zähler besteht nun aus 3 Zellen, deren Eingangsüberträge jeweils der Ausgangsübertrag des vorherigen Zähler ist. Listing 2: 3 Bit Zähler MODULE main b i t 0 : c o u n t e r c e l l ( 1 ) ; b i t 1 : c o u n t e r c e l l ( b i t 0. c a r r y o u t ) ; b i t 2 : c o u n t e r c e l l ( b i t 1. c a r r y o u t ) ; Um nun zu sehen, was dieser Zähler macht, kann man gut, die Simulationsfunktion von SMV nutzen: Abbildung 1: Erster Teil der Ausgabe Abbildung 2: Zweiter Teil der Ausgabe

5 Beispiele zur Verifikation und pratkische Probleme 5 Da, nur die Grenzfälle interessant sind, wurde der Mittelteil ausgespart. Wie man gut erkennen kann, zählt der Zähler, bei Null beginnend bis zur Sieben hoch. Bei dem nun auftretenden Überlauf fängt der Zähler einfach wieder an bei Null zu zählen. Man könnte nun noch verschiedene Spezifikationen (Schlüsselwort: ) einfügen, die z.b. überprüfen, dass die Berechnungen immer korrekt sind. Diese sind jedoch bei diesem kleinen Beispiel auch problemlos per Hand prüfbar Bewertung des Modells Der Binärzähler wurde zwar korrekt modelliert und sollte auch funktionieren, jedoch ist die dazugehörige Schaltung nicht direkt aus dem Modell ablesbar. Während das Modell hier direkt schaltet, wird es in der Realität immer Verzögerungen geben. Auch wenn die Schaltzeiten sehr gering ausfallen können, benötigt der Strom auf einem Leiter immer eine gewisse Zeit. Auch können Low und High (0 und 1) nicht immer hundertprozentig voneinander getrennt werden. Somit kann es passieren, dass zu bestimmten Zeitpunkten ein ungültiger Zustand abgefragt wird. Ein weiteres, im allgemeinen sehr großes, Problem, welches immer wieder auftauchen wird, kann zusammengefasst werden unter dem Titel technische Abweichungen. Technische Abweichungen können zum Beispiel die schon genannten Leitungsstörungen sein, welche bei dieser Schaltung verursachen können, dass der Zähler nie anfängt hoch zu zählen. In der Zeile bit0 : counter_cell(1); wird eine Zelle initialisiert, die als Eingangsübertrag konstant 1 haben muss, damit die Zelle anfangen kann zu zählen. Tritt hierbei nun eine Leitungsstörung auf, sodass der Wert schwankt, ist der Verhalten nicht mehr vorhersagbar, d. h. in diesem Fall zählt der Zähler nicht hoch sondern könnte nahezu zufällige Werte erzeugen. Bei einem Eingang von konstant 0 fängt der Zähler wie schon erwähnt niemals an zu zählen, was auch nicht erwünscht ist. Nicht unerwähnt bleiben sollte, dass man eventuell nicht möchte, dass diese Schaltung bei einem Überlauf einfach wieder von vorne anfängt sondern auf eine zusätzliche Eingabe wartet, so muss dies modelliert werden, was mitunter sehr komplex werden kann. Mit zusätzlicher Komplexität eines Modells steigt zum einen die Zeit, die zur Verifikation benötigt wird und zum anderen die Fehleranfälligkeit. Es ist ganz klar, dass je mehr Leiter vorhanden sind, umso mehr Leitunsstörungen könnten auch auftreten. 2.2 Inverterring Der nun vorgestellte Inverterring soll ein Beispiel dafür sein, wie Schaltungen modelliert werden können, die nicht direkt schalten, sondern eine gewisse Zeit benötigen um neue Werte anzunehmen. Man kann hier einen kleinen Trick mit Hilfe von SMV verwenden, indem der zu ändernde Wert entweder den alten behält, oder den neuen bekommt. Hierzu muss man in der Zuweisung eine Menge übergeben. Der Inverterring soll nun aus 3 Invertern bestehen, die kreisförmig angeordnet werden. Hierbei geht der Ausgang eines Inverters auf den Eingang des darauffolgenden Inverters. Ein Inverter hat hierbei einen Eingang und auch einen Ausgang, wobei der Ausgang die Negation des Eingangs sein soll. Am Anfang stehen die Ausgänge alle auf 0. Nun ist es natürlich relativ problematisch herauszufinden, welcher Inverter zuerst angesprochen werden soll. Auch stellt sich die Frage, ob die Inverter parallel laufen sollen. Als Lösung wird von SMV

6 Beispiele zur Verifikation und pratkische Probleme 6 vorgeschlagen, einfach irgendeinen Inverter (zufällig, nicht-deterministisch) auszuwählen und wie oben schon beschrieben, dem Inverter die Wahl zu lassen, ob der Ausgang nun die Negation des Eingangs ist, oder nicht. Dies entspricht in SMV dem asynchronen Modell, wohingegen im synchronen Modell es vollkommen legitim wäre, dass alle Inverter immer die alte Ausgabe beibehalten. Hier sieht man wieder eines der Probleme bei der Modellierung, da man sich schon im Voraus für ein (Zeit-) Modell entscheiden muss. Wählt man das synchrone Modell wird man schnell überrascht sein, warum gar nichts passiert. MODULE i n v e r t e r ( i n p u t ) output : b o o l e a n ; i n i t ( output ) := 0 ; next ( output ) :=! i n p u t ; FAIRNESS r u n n i n g Listing 3: Invertermodul Man sieht nun auf den ersten Blick das Schlüsselwort FAIRNESS zusammen mit dem Schlüsselwort running. Dieses bewirkt, dass SMV nur Pfade zur Betrachtung zieht, in denen die Instanz unendlich oft zur Ausführung kommt. Ein Problem, was mit diesem Schlüsselwort in Zusammenhang steht, sind die schon erwähnten Unterscheide der verschiedenen SMV Versionen, da die Dokumentation von NuSMV hierbei von allen Instanzen redet und in Dokumentationen zu anderen Versionen hier von genau einer Instanz die Rede ist. Hier sollte man als Anwender die Dokumentation der betreffenden Version nochmal genau zu Rate ziehen. Das Hauptmodul des Inverterrings sieht nun wie folgt aus: Listing 4: Invertermodul MODULE main gate1 : p r o c e s s i n v e r t e r ( gate3. output ) ; gate2 : p r o c e s s i n v e r t e r ( gate1. output ) ; gate3 : p r o c e s s i n v e r t e r ( gate2. output ) ; (AG AF gate1. output ) & (AG AF! gate1. output )

7 Beispiele zur Verifikation und pratkische Probleme Bewertung Inverterring Ändert man nur geringfügig etwas an dem Aufbau des Inverterrings und der dazugehörigen Spezifikation, so gelingt es leicht, dieses Modell, was man vielleicht absichtlich falsch spezifiziert hat, dennoch zu verifizieren. Auch kann man Modelle als korrekt spezifizieren, die nicht realisierbar sind. Des weiteren darf man nicht unterschätzen welche Wirkung kleine Änderungen am Aufbau haben können. Obwohl vorhin der Trick erwähnt wurde, dass man nur vielleicht schalten muss erzeugt dies natürlicherweise Probleme, insbesondere wenn SMV versucht dies wirklich zufällig zu handhaben. SMV bringt nun ein Gegenbeispiel, und dies ist genau dann der Fall, wenn dieser Trick zur Anwendung kommt und nicht direkt umgeschalten wird. 2.3 Zusammenfassung der einführenden Beispiele Schon in diesen kleinen Beispielen, die relativ einfach sind und sogar schon bei SMV mitgeliefert werden lässt sich erkennen, wie schnell man ein Modell produzieren kann, was so nicht realisierbar ist oder in der Praxis nicht modellgemäß arbeiten könnte. Im Folgenden Teil sollen nun eigene (einfache) Modelle entwickelt werden, bei denen mehr Probleme auftreten können. 3 Komplexere Beispiele 3.1 Mikrowelle Es gibt inetwa 4 wichtige Elemente einer realen Mikrowelle: Zeitschranke Tür Wattzahl Programmfunktion Die Zeitschranke beschreibt offensichtlich, nach welcher Zeit die Mikrowelle fertig sein sollte Lebensmittel oder ähnliches zu erwärmen. Die Tür hat 2 Eigenschaften, nämlich ob diese offen oder geschlossen ist. Wattzahl und Programmfunktion bestimmen gemeinsam, wie etwas erwärmt wird, wobei Programmfunktion zum Beispiel die Auftaufunktion moderner Mikrowellen sein kann. Es gibt in modernen Mikrowellen auch Programme für bestimmte Speisen. Im Allgemeinen wird hierbei nur immer wieder eine Pause gemacht, aber all das sind technische Details, die nicht unbedingt für das kleine Modell, was nun modelliert werden soll, wichtig wären Das Modell Das Modell der Mikrowelle soll nur 3 wichtige Eigenschaften haben: 1. Die Tür kann geöffnet oder geschlossen sein.

8 Beispiele zur Verifikation und pratkische Probleme 8 2. Das Gerät kann an oder aus sein. 3. Wenn die Tür geöffnet ist, muss das Gerät aus sein. Die ersten beiden Eigenschaften sind offensichtlich. Die dritte Eigenschaft beschreibt eine wichtige Sicherheitsanforderung, nämlich, dass niemand seine Hände in das Gerät halten kann, während es an ist. Zweifellos wäre dies problematisch, da dadurch Hände verbrennen könnten, insbesondere da nicht nur die oberen Hautschichten betroffen wären, sondern sogar das Blut erwärmt werden würde. Ein Problem hieran ist natürlich, dass man aufpassen muss, wie man diese Sicherheitsanforderung spezifiziert, da man eventuell etwas spezifiziert, was unerfüllbar ist, oder sich das Gerät dennoch einschalten lässt. Ein Problem bei der Umsetzung dieser Modellierung ist allerdings die Frage, wie man erkennt, dass die Tür offen ist. Des weiteren muss man sich auch Fragen, was passiert wenn die Tür geöffnet wird, während das Gerät eingeschalten ist. Gewiss sollte dann das Gerät sofort aus sein, jedoch ist dies technisch nicht so unmittelbar möglich, da immernoch Reststrahlung emittiert werden könnte. Auch wird man nicht umhin kommen, die anderen Eigenschaften einer (realen) Mikrowelle umzusetzen, wobei diese Eigenschaften weniger Sicherheitsanforderungen genügen, zumindest insofern, dass wenn die nun modellierte Sicherheitsanforderung eingehalten wird, man andere Sicherheitsanforderungen mit abdeckt.

9 Beispiele zur Verifikation und pratkische Probleme Via EC bezahlen Wie sieht die Realität aus? In der Realität gibt es ein Kartenlesegerät, eine Kasse, eine Bank, ein Eingabegerät für die PIN und natürlich einen Menschen, der bezahlen will. Die Kasse sendet einen Betrag an das Kartenlesegerät, welches die Karte einliest und diese Daten dann mit dem - durch die PIN-Eingabe gelieferten - PIN an die Bank schickt. Die Bank überprüft dann ob genug Geld vorhanden ist, die PIN zur Karte passt und liefert dann die Meldung zurück, ob bezahlt wurde oder nicht. Früher sah die Situation etwas anders aus, denn vor nicht allzu langer Zeit wurde die PIN noch auf der Karte selbst mit gespeichert, sodass keine Anbindung an die Bank notwendig war, allerdings, und das fanden nicht wenige Menschen heraus, konnte man diese PIN auslesen und so problemlos das Geld eines Anderen ausgeben. Abbildung 3: Bezahlung via EC Ein Anfang Für den Anfang wird nun erst einmal eine PIN und Rechnungsbetragüberprüfung modelliert. Als erstes sei nur die Kasse modelliert, an der sich das Kartenlesegerät mit PIN befindet. Es soll nur ausgeben geschafft wenn genügend Geld vorhanden ist und die PIN korrekt war.

10 Beispiele zur Verifikation und pratkische Probleme 10 Angefangen wird nun mit dem Modul, das den PIN überprüft. Man kann den PIN versuchen drei mal einzugeben. Wenn der PIN einmal korrekt war, wird überprüft, ob genügend Geld vorhanden ist und in den entsprechenden Zustand gewechselt. Ist genügend Geld vorhanden und der PIN war korrekt, dann wird bezahlt, in jedem anderen Fall, wird nicht bezahlt. Wenn der PIN falsch eingegeben wurde, kann es noch vorkommen, dass ein Wartezustand erreicht wird, der auf einen erneuten Versuch der PIN - Eingabe wartet. Listing 5: Pinüberprüfung MODULE p i n c h e c k p i n o k : b o o l e a n ; g e l d : b o o l e a n ; s t a t e : { s t a r t, w1, w2, w3, nopay, p a y i n g } ; z a h l e n : { w a i t i n g, f a i l i n g, done } ; i n i t ( z a h l e n ) := w a i t i n g ; next ( z a h l e n ) := c a s e s t a t e=w1 s t a t e=w2 s t a t e=w3 s t a t e=s t a r t : w a i t i n g ; s t a t e=nopay : f a i l i n g ; s t a t e = p a y i n g : done ; e s a c ; i n i t ( s t a t e ) := s t a r t ; next ( s t a t e ) := c a s e s t a t e = s t a r t & p i n o k : w3 ; s t a t e = s t a r t &! p i n o k : w1 ; s t a t e = w1 & p i n o k : w3 ; s t a t e = w1 &! p i n o k : w2 ; s t a t e = w2 & p i n o k : w3 ; s t a t e = w2 &! p i n o k : nopay ; s t a t e = w3 & g e l d : p a y i n g ; s t a t e = w3 &! g e l d : nopay ; s t a t e = nopay : s t a r t ; s t a t e = p a y i n g : s t a r t ; e s a c ; AG s t a t e!= p a y i n g > z a h l e n!=done Response EF z a h l e n=done L e b e n d i g k e i t

11 Beispiele zur Verifikation und pratkische Probleme 11 AG! g e l d > AF z a h l e n=f a i l i n g Ohne Geld k e i n e Bezahlung f a l s c h e PIN Eingaben > k e i n e Bezahlung AG! p i n o k & AX! p i n o k & AX AX! p i n o k > AF z a h l e n=f a i l i n g Die Spezifikationen sind unter anderem nach dem in den Kommentaren stehenden Schema 3 erstellt. Listing 6: Hauptmodul MODULE main maindone : b o o l e a n ; p i n : p i n c h e c k ; i n i t ( maindone ) := 0 ; next ( maindone ) := ( p i n. z a h l e n = done ) ; EF maindone Natürlich klappt das nicht so ganz, wie gewünscht. In der Response Spezifikation fehlen nur 2 Buchstaben, und somit ist diese Spezifikation auch nicht erfüllbar. Korrekt wäre dort (AG state!=paying -> AF zahlen statt (AG state!=paying -> zahlen!=done). Ansonsten sind alle Spezifikationen in diesem Beispiel korrekt, aber auch hier könnten Leitungsstörungen auftreten, die falsche Werte erzeugen. Ein weiteres Problem, was entstehen kann sind unterschiedliche Rechnungsbeträge Rechnungsbetrag prüfen Der Rechnungsprüfer soll uns eher zufällig liefern, ob die Rechnungsbeträge, die Kasse und Bank liefern übereinstimmen. Natürlich gibt es auch einen guten Grund für die Einführung eines solchen Moduls, so könnte es passieren, dass während der Übertragung von Kasse zur Bank ein Fehler geschieht und ein falscher Wert abgebucht werden soll. Um dies korrigieren zu können liefert die Bank den Wert, den sie abbuchen will wieder an die Kasse, bzw. den Kunden wo dann verglichen wird ob die Werte übereinstimmen. Stimmen die Werte nicht überein, muss der Vorgang erneut gestartet werden, jedoch ist für uns nur wichtig, dass dann nicht bezahlt wird. MODULE r e c h c h e c k r e c h o k : b o o l e a n ; i n i t ( r e c h o k ) := 0 ; next ( r e c h o k ) := { 0, 1 } ; Listing 7: Rechnungsprüfer 3 Vorgestellt unter anderem in [Gum07]

12 Beispiele zur Verifikation und pratkische Probleme 12 EF r e c h o k=1 Nun muss natürlich noch das Hauptmodul angepasst werden: Listing 8: Hauptmodul MODULE main maindone : b o o l e a n ; p i n : p i n c h e c k ; r e c h : r e c h c h e c k ; i n i t ( maindone ) := 0 ; next ( maindone ) := ( p i n. z a h l e n = done & r e c h. r e c h o k =1); EF maindone Wie man auf den ersten Blick erkennen kann, funktioniert das soweit und arbeitet insofern korrekt, als dass SMV keine Gegenbeispiele für die Spezifikation bringt. Nun bleibt nur noch eine Kasse und eine Bank zu modellieren, womit man dann einen Geldautomaten hätte Kasse und Bank Die Kasse liefert den Rechnungsbetrag und kann 2 Zustände haben: idle und requesting, wobei requesting bedeutet, dass ein Kunde mit Karte zahlen will und idle anzeigen soll, dass kein Kunde da ist, beziehungsweise kein Kunde da ist, der mit Karte zahlen will. Für das Modell macht es prinzipiell keinen Unterschied ob kein Kunde da ist oder nur der Kunde nicht mit Karte zahlen will. Listing 9: Kasse MODULE Kasse ( kunde da ) s t a t e : { i d l e, r e q u e s t i n g } ; i n i t ( s t a t e ) := i d l e ; next ( s t a t e ) := c a s e kunde da & s t a t e = i d l e : r e q u e s t i n g ;! kunde da & s t a t e = r e q u e s t i n g : i d l e ;! kunde da & s t a t e = i d l e : r e q u e s t i n g ; kunde da & s t a t e = r e q u e s t i n g : r e q u e s t i n g ; e s a c ; AG ( kunde da > EF s t a t e = r e q u e s t i n g ) non b l o c k i n g

13 Beispiele zur Verifikation und pratkische Probleme 13 Was auf den ersten Blick an den bisherigen Modellierungen schon auffällt ist die case - Anweisung. Diese Anweisungen sind deshalb problematisch, da in der praktischen Umsetzung die Schaltung ein beliebig komplexer Multiplexer werden kann, insbesondere wenn der anzunehmende Wert nichts mit der Abfrage zu tun hat, oder wenn sich Teile der Abfrage gleichen. Nicht zu unterschätzen sind die erhöhten Laufzeiten einer Schaltung durch die Verwendung umfangreicher Multiplexer. Abbildung 4: Ein Multiplexer (Quelle: Wikipedia, [wik]) Das Modul Bank bekommt als Eingang den Rechnungsbetrag den die Kasse liefert und, einzig für die Simulation notwendig, drei Werte, die mehr oder weniger zufällig anzeigen sollen, ob die Bank überhaupt erreichbar ist, denn in der Realität steht auch recht häufig bei einem Geldautomaten da, dass dieser nicht verfügbar ist oder nicht funktioniert, was darauf zurückzuführen sein kann, dass die Bank nicht erreichbar ist. Des weiteren wird noch angezeigt, ob wir sagen sollen, dass die PIN okay war, oder die Rechnungsbeträge übereinstimmen. MODULE Bank a v a i l a b l e : b o o l e a n ; i n i t ( a v a i l a b l e ) := 0 ; next ( a v a i l a b l e ) := { 0, 1 } ; Listing 10: Bank (EF a v a i l a b l e ) L e b e n d i g k e i t Diese nun gebauten Modelle können problemlos in das schon bekannte Hauptmodul eingefügt werden. MODULE main maindone : b o o l e a n ; p i n : p i n c h e c k ; r e c h : r e c h c h e c k ; Listing 11: Hauptmodul

14 Beispiele zur Verifikation und pratkische Probleme 14 kunde : b o o l e a n ; kas : Kasse ( kunde ) ; ban : Bank ; i n i t ( maindone ) := 0 ; i n i t ( kunde ) := 0 ; next ( kunde ) := { 0, 1 } ; next ( maindone ) := ( p i n. z a h l e n = done & r e c h. r e c h o k & ban. a v a i l a b l e ) ; EF maindone AG( ( ban. a v a i l a b l e & r e c h. r e c h o k & p i n. z a h l e n=done ) > EF maindone ) AG! ban. a v a i l a b l e >! maindone AG p i n. z a h l e n!= done >! maindone AG! r e c h. r e c h o k >! maindone Auch hier liefert SMV kein Gegenbeispiel für die Spezifikationen. Natürlich entspricht dieses Modell nicht der Realität, da allein schon das Modul rech check in der Realität durch den Kunden ersetzt wird. Es wurde natürlich nicht auf Fehlertoleranz geachtet, des weiteren wurde die schon erwähnte case - Anweisung verwendet. Nicht betrachtet, wurde welches Zeitmodell in der Realität zugrunde liegt. Zusammenfassend kann man sagen, dass ein echter Geldautomat wesentlich komplexer ist, als er hier in Form von Via EC bezahlen modelliert wurde. Was hätte hierbei Probleme verursachen können: 1. Modell ist falsch 2. Spezifikationen sind falsch 3. Herangehensweise war falsch 4. Spezifikationen der Form 1 = 1 oder 0 = Aufzug Ein noch nicht erwähntes Problem, ist das Problem der Berechnungsdauer. Die bisherigen Beispiele hatten alle eine sehr kurze Berechnungsdauer, auch dadurch, dass statt zufällig Werte zu nehmen, der Binärzähler als Hilfe genommen wurde, wodurch weniger Freiheitsgrade bei der Berechnung mit einbezogen werden müssen.

15 Beispiele zur Verifikation und pratkische Probleme 15 Ein Modell, bei dem eine, im Vergleich zu den bisherigen Beispielen, wesentlich höhere Berechnungsdauer benötigt wird ist der Aufzug, welcher hier nicht so genau beschrieben werden soll, wie die bisherigen Modelle, sondern nur als Beispiel dienen soll, wie sich die Berechnungszeit bei kleinen Problemen verhält. Der Aufzug hat vier Etagen, die vollkommen ausreichen um alle Fahrstühle zu modellieren. Bei einem Fahrstuhl mit mehr als 4 Etagen sind immernoch nur die unteren und die oberen zwei Etagen von Relevanz für das Modell, da sich der Aufzug dazwischen immer wieder gleich verhalten sollte. Abbildung 5: Schematische Darstellung eines Aufzugs Der Aufzug hat natürlich noch wesentlich mehr Bedingungen, die erfüllt werden müssen, welche offensichtlich auch zur längeren Berechnungszeit beitragen. Im Allgemeinen darf man die Berechnungszeit nicht unterschätzen, da bei großen Modellen die Berechnungszeit relativ schnell in Stunden und nicht mehr Minuten sein wird. Je größer das zu verifizierende Modell ist, umso wahrscheinlicher ist es, dass das Modell nicht beim ersten Versuch verifizierbar ist, somit wird mehr als ein Programmdurchlauf nötig sein um das gewünschte Modell zu verifizieren. 4 Zusammenfassung SMV bietet dem Anwender sehr gute Rahmenbedingungen um Modelle zu verifizieren. Es unterstützt den Anwender bei der Suche von Problemen, die aufgrund der Modellierung auftreten können. Natürlich kann SMV nicht den Prozess des entwickelns solcher Modelle ersetzen, insbesondere muss sich der Anwender Gedanken darüber machen, was denn eigentlich modelliert werden soll. So sollten keine Spezifikationen der Form 1 = 1 oder 0 = 1 auftauchen.

16 Beispiele zur Verifikation und pratkische Probleme 16 SMV hilft beim Aufbau komplexer Schaltungen indem einzelne Module separat entwickelt und verifiziert werden können. Diese können dann zum Schluß eingebaut werden und funktionieren höchst wahrscheinlich in der gesamten Schaltung. Probleme bei der Umsetzung in die Praxis entstehen insbesondere dann, wenn man versucht ein Modell direkt in Hardware umzusetzen. Ein großes Problem können Leitungsstörungen sein, die, wie wir beim Binärzähler gesehen haben, das Modell zwar nicht zerstören, aber auch nicht die gewünschte Funktionalität liefern. Ein weiteres großes Problem sind die case - Anweisungen, die dazu verführen komplexere Inhalte einfach darzustellen. Allerdings können dabei dennoch beliebig komplexe Multiplexerschaltungen auftreten, die genauso von Leitungsstörungen betroffen sein können. Insbesondere darf man auch nicht unerwähnt lassen, dass man ein falsches Modell als gültig verifizieren kann, hierfür müssen nur die Gültigkeitsbedingungen entsprechend angepasst sein.

17 Beispiele zur Verifikation und pratkische Probleme 17 Literatur [DBM05] Drechsler, Rolf, Bernd Becker und Paul Molitor: Technische Informatik. Pearson Studium, [Gum07] Gumm, H.P.: Skript zur Vorlesung Model Checking (Kapitel 5) http: // www. mathematik. uni-marburg. de/ ~gumm/ Lehre/ SS07/ ModelChecking/ 05_ Verzweigungslogik. pdf, [HR00] Huth, Michael R. A. und Mark D. Ryan: Logic in Computer Science: Modelling and Reasoning about Systems. Cambridge University Press, Cambridge, England, [nusa] NuSMV Beispiele, http: // nusmv. fbk. eu/ examples/ examples. html. [nusb] NuSMV Nutzerhandbuch, http: // nusmv. fbk. eu/ NuSMV/ userman/ v24/ nusmv. pdf. [wik] Bild eines Multiplexers, http: // de. wikipedia. org/ wiki/ Bild: Mux-Symbol_ DIN svg. Abbildungsverzeichnis 1 Erster Teil der Ausgabe Zweiter Teil der Ausgabe Bezahlung via EC Ein Multiplexer (Quelle: Wikipedia, [wik]) Schematische Darstellung eines Aufzugs