Verifikation reaktiver Systeme - Universität Kaiserslautern

53
ändert. So wäre die Signallinie s von einer property suite, welche nur die
Eigenschaften p1, p3, p4 und p5 enthält, nicht jedoch p2, beispielsweise nicht 1-
covered, weshalb die Verifikation die in Abb. 2 dargestellte Schaltung
fälschlicherweise als richtig ansehen würde
Abb. 2. Modifizierte Schaltung des AEC
multiple(t)
error(t)
NOT
0
correct_it(t)
AND
old_State(t)
NOT
NAND
reject it(t)
AND
new_state(t)
Eine Überprüfung der Vollständigkeit der property suite mittels Coverage Measure
würde diese Lücke in der Spezifikation erkennen und dem Entwickler somit eine
Warnung geben können.
5 Effektivitätsbetrachtung
Wie man im vorangegangenen Abschnitt gesehen hat, kann eine Durchführung der
Coverage Measure Lücken in der Spezifikation erkennen und lokalisieren. Je genauer
die durchgeführte Überprüfung ist, desto mehr Lücken können erkannt werden. Da
die Aufgabe des Entwicklers jedoch in der Erstellung eines Verifikationsplanes, also
der Erzeugung einer property suite, die alle relevanten semantischen Aspekte des
Designs abdeckt, kann die Abdeckung aller Signallinien (also syntaktischen Aspekte)
einer Implementierung die Vollständigkeit der property suite nicht garantieren.
Betrachtet man sich die Tabellen 2 und 3, so fällt beispielsweise auf, dass die
Eigenschaft p1 nicht benötigt wird, damit alle Signallinien zu jedem Zeitschritt
sowohl 0- als auch 1-covered sind.
Dies führt dazu, dass eine property suite, die nur aus den Eigenschaften p2 bis p5
besteht, von der Coverage Measure als vollständig angesehen wird, was dazu führen
würde, dass eine mit dieser unvollständigen property suite durchgeführte Verifikation
mit zusätzlicher Coverage Measure die in Abb. 3 dargestellte Schaltung fälschlich als
richtig und die property suite als vollständig spezifiziert ansehen würde. Auf einen
Beweis wird an dieser Stelle verzichtet.