Digitale Hardware/ Software-Systeme- P4 ppt

Allerdings m¨ussen auch die Zeitschritte f¨ur die SERE definiert werden, al- wer-so wann der Wechsel zwischen Symbolen auftreten muss.. Die PSL-Eigenschaft, dass sich die Variablen b1und

2.4 Formale Spezifikation funktionaler Anforderungen 81Andererseits gibt es CTL-Formeln, die sich nicht in LTL formulieren lassen Ein

Beispiel hierf¨ur ist: AG EF p Diese Formel besagt, dass auf allen Pfaden, von jedem Zustand aus, ein Pfad existiert, auf dem irgendwann p gilt Dies l¨asst sich nicht in

LTL ausdr¨ucken Schließlich gibt es Formeln, die sich weder in LTL noch in CTLausdr¨ucken lassen Ein solches Beispiel kann aus den beiden vorherigen Beispielenkonstruiert werden:

AF G p ∨ AG EF p

Eine temporale Aussagenlogik, die sowohl LTL-Formeln, CTL-Formeln als auch ren Kombination ausdr¨ucken kann, ist CTL* Der Zusammenhang zwischen LTL,CTL und CTL* ist in Abb 2.19 zu sehen

de-CTL*

Abb 2.19 Zusammenhang zwischen LTL, CTL und CTL* [457]

CTL* l¨asst sich formal definieren (siehe auch [272]):

Definition 2.4.9 (Syntax von CTL*) Sei V die Menge aussagenlogischer

Varia-blen (atomare Formeln) Jede Zustandsformel ist eine zul¨assige CTL*-Formel die Pfadformeln enthalten kann Dabei sind Zustandsformeln und Pfadformeln wie folgt definiert:

• Zustandsformeln:

– Fallsϕ∈ V, dann istϕeine Zustandsformel.

– Fallsϕ undψ Zustandsformeln sind, so sind ¬ϕ und ϕ∨ψ ebenfalls standsformeln.

Zu-– Fallsϕeine Pfadformel ist, dann ist Eϕeine Zustandsformel.

Definition 2.4.10 (Semantik von CTL*) Seiϕ eine Zustandsformel Dann besagt

M ,s |=ϕ, dassϕim Zustand s der temporalen Struktur M gilt Seiψeine Pfadformel.

Abb 2.20 Zustands- und Pfadformeln in CTL* [272]

Dann besagt M , ˜s |=ψ, dassψ entlang des Pfades ˜ s = s0,s1,  der temporalen Struktur M gilt.

Gegeben seien zwei Zustandsformelnϕ1undϕ2sowie zwei Pfadformelnψ1und

ψ2 Die Relation |= kann wie folgt definiert werden:

Definition 2.4.11 (G ¨ultigkeit und Erf ¨ullbarkeit von CTL*-Formeln) Eine

Zu-standsformelϕ(eine Pfadformelψ) heißt g¨ultig, falls f¨ur alle temporalen Strukturen

M und f¨ur alle Zust¨ande s (alle Pfade ˜ s) in M gilt M ,s |=ϕ(M , ˜s |=ψ) Wenn eine temporale Struktur M gegeben ist, dann heißt die Formelϕ(ψ) g¨ultig in M, falls f¨ur alle Zust¨ande s (alle Pfade ˜ s) von M gilt M ,s |=ϕ (M , ˜s |=ψ).

Eine Formelϕ(ψ) heißt erf¨ullbar, falls eine temporale Struktur M mit Zustand

s (Pfad ˜ s) existiert, so dass M ,s |=ϕ(M , ˜s |=ψ) Wenn eine temporale Struktur M gegeben ist, dann heißt die Formelϕ (ψ) erf¨ullbar in M, falls es einen Zustand s (einen Pfad ˜ s) in M gibt, so dass M ,s |=ϕ(M , ˜s |=ψ).

2.4 Formale Spezifikation funktionaler Anforderungen 83

mentanen Zustand aus erreichbar ist

• Die Gefahrlosigkeitseigenschaft kann in temporaler Aussagenlogik als

AG p

formuliert werden, wobei ¬p

”etwas Schlimmes“ ist Die Eigenschaft besagt,

dass auf allen Pfaden (A) jeder Zustand (G) mit p markiert ist.

• Die Lebendigkeitseigenschaft kann in temporaler Aussagenlogik als

AG AF p

formuliert werden Sie besagt, dass auf allen Pfaden (A) aus allen Zust¨anden (G)wiederum auf allen Pfaden (A) irgendwann ein Zustand (F) angetroffen wird, der

mit p markiert ist.

Gegenbeispiele f¨ur Gefahrlosigkeitseigenschaften bestehen aus einem Pfad cher L¨ange, w¨ahrend Gegenbeispiele f¨ur Lebendigkeitseigenschaften aus unendli-chen Pfaden bestehen Letztere enthalten dann Schleifen, in denen die geforderteEigenschaft nicht eintritt

endli-2.4.3 Die Zusicherungssprache PSL

Neben der formalen Syntax und Semantik temporallogischer Formeln wird hier auch

die Zusicherungssprache PSL (engl Property Specification Language), die

Einga-bem¨oglichkeit von funktionalen Anforderungen bei vielen Verifikationswerkzeugen,pr¨asentiert PSL unterscheidet bei der Formulierung temporallogischer Formeln dreiEbenen:

1 Die Boolesche Ebene, welche aus aussagenlogischen Variablen und Booleschen

Ausdr¨ucken besteht

2 Die temporale Ebene, welche den zeitlichen Zusammenhang zwischen den

Boo-leschen Ausdr¨ucken beschreibt

3 Die Verifikationsebene, welche angibt, wie die Eigenschaft w¨ahrend der

Verifi-kation zu verwenden ist

PSL kann in die sog Foundation Language (FL) und die sog Optional Branching Extension (OBE) unterteilt werden [234] PSL FL ist eine Mischung aus LTL und

erweiterten regul¨aren Ausdr¨ucken Somit kann mit PSL FL ¨uber einzelne nungspfade argumentiert werden Zur Formulierung von CTL-Formeln wird PSLOBE verwendet Da PSL oft in Werkzeugen zur Simulation zum Einsatz kommt,wird im Folgenden die hierzu konzipierte PSL FL betrachtet

Berech-Boolesche Ebene

Auf der Booleschen Ebene wird eine funktionale Eigenschaft anhand von Variablenund deren logischen Verkn¨upfungen beschrieben Bei den Variablen in PSL handelt

es sich um Variablen oder Boolesche Ausdr¨ucke aus dem (ausf¨uhrbaren) Modell

Beispiel 2.4.4 Verwendet die Implementierung zwei Boolesche Variablen x1und x2,

so wird der gegenseitige Ausschluss dieser Variablen in PSL als !(x1& x2)

geschrie-ben [111] Dabei beschreibt & die Konjunktion und ! die Negation

Temporale Ebene

Die zeitlichen Relationen zwischen Booleschen Ausdr¨ucken werden auf der

tempo-ralen Ebene beschrieben Hierbei werden sog sequentiell erweiterte regul¨are dr¨ucke (engl Sequential Extended Regular Expression, SERE) und Eigenschaften (engl properties) unterschieden.

Aus-Sequentiell erweiterte regul¨are Ausdr¨ucke

Sequentiell erweiterte regul¨are Ausdr¨ucke (SEREs) werden verwendet, um

tempora-le Sequenzen von Ereignissen Bootempora-lescher Ausdr¨ucke zu beschreiben

Definition 2.4.12 (SERE) Seien b ein Boolescher Ausdruck und r1und r2SEREs,

so sind die folgenden Ausdr¨ucke ebenfalls SEREs:

• [∗0] ist die leere Sequenz, diese ist ¨aquivalent zu dem ε-Symbol in regul¨aren Ausdr¨ucken.

• b ist eine SERE.

• {r1} ist eine SERE Die geschweiften Klammern sind ¨aquivalent zu den runden Klammern in regul¨aren Ausdr¨ucken.

• r1| r2ist die Disjunktion von r1und r2.

• r1[∗] ist das keinmalige bis beliebig oftmalige Auftreten von r1.

• r1; r2ist die Konkatenation von r1und r2, also r2folgt direkt r1.

• r1: r2 ist die Fusion von r1 und r2, d h der letzte Boolesche Ausdruck in r1

und der erste Boolesche Ausdruck in r2¨uberlappen sich und m¨ussen gleichzeitig wahr sein.

• r1&& r2wird als L¨angendurchschnitt bezeichnet r1&& r2ist wahr, wenn wohl r1und r2wahr sind und beide gleichzeitig starten und enden.

so-Neben den oben definierten Operatoren f¨ur SEREs wurden abk¨urzende weisen eingef¨uhrt, die allerdings nicht die Ausdruckskraft von PSL vergr¨oßern [55]

Schreib-Im Folgenden seien b ein Boolescher Ausdruck, r eine SERE, i , j,k,l ∈ N mit i ≥ j,

l ≥ k und l,k > 0 Die folgenden abk¨urzenden Schreibweisen k¨onnen dann in PSL

verwendet werden:

2.4 Formale Spezifikation funktionaler Anforderungen 85

Die Operatoren[∗k] und [∗i : j] werden als Abz¨ahlungswiederholung und

Bereichs-wiederholung bezeichnet Der Operator [->] wird auch als GOTO-Operator

bezeich-net, da er das erste Auftreten von b beschreibt.

PSL-Eigenschaften

SEREs k¨onnen als Sequenzen in PSL und damit als Eigenschaften verwendet den Hierf¨ur werden SEREs in geschweiften Klammern geschrieben, z B.{r} f¨ur die SERE r Allerdings m¨ussen auch die Zeitschritte f¨ur die SERE definiert werden, al-

wer-so wann der Wechsel zwischen Symbolen auftreten muss Zeitschritte in Sequenzenwerden ¨uber Ereignisse identifiziert Ereignisse k¨onnen dabei aus den Signalen oderaus Werte¨anderungen von Variablen in dem untersuchten Modell extrahiert werden

Beispiel 2.4.5 H¨aufig besitzt eine Implementierung ein Taktsignal clk Ein

geeig-netes Ereignis zur Identifikation von Zeitschritten ist dann die positive Taktflanke,

was in PSL durch posedge clk ausgedr¨uckt wird Die PSL-Eigenschaft, dass sich die Variablen b1und b2in jedem Zeitschritt, vorgegeben durch das Taktsignal, ausschlie-ßen, wird dann wie folgt formuliert:

!(b1& b2)@(posedge clk)

Neben SEREs als Sequenzen unterst¨utzt PSL weiterhin alle Standard Operatoren Allerdings wird PSL oft in simulativen Verifikationsmethoden einge-setzt (siehe auch Abschnitt 5.2.3) und nicht alle Kombinationen von Eigenschaften

LTL-eignen sich hierf¨ur Aus diesem Grund definiert PSL eine einfache Teilmenge der

Foundation Language, die sich f¨ur die Simulation eignet PSL-FL wird dabei art eingeschr¨ankt, dass die Negation von SEREs nicht erlaubt ist Die resultierendeSprache wird mit PSL-FL− bezeichnet PSL-Eigenschaften werden im Folgenden

der-basierend auf PSL-FL−beschrieben [55]

Seien b1und b2zwei Boolesche Ausdr¨ucke Weiterhin sei r eine SERE lich seien i , j,k,l ∈ N mit i ≥ j, l ≥ k und l,k > 0 PSL-Eigenschaften lassen sich

Schließ-wie folgt auf Basis der PSL-FL−definieren:

• b1und b2sind PSL-Eigenschaften

• {r} ist eine PSL-Eigenschaft.

Dabei wird davon ausgegangen, dass b1und b2bzw.{r} in der Simulation auftritt Ist

dies nicht der Fall, wird dies als Fehler bewertet Allerdings ist diese Bedingung eineschwache Bedingung f¨ur SEREs, d h falls die Simulation endet, bevor die gesamteSequenz erkannt werden konnte, gilt die Eigenschaft als erf¨ullt Eine Eigenschaft

kann durch den !-Operator zu einer starken Bedingung gemacht werden:

• {r}! ist eine PSL-Eigenschaft.

In diesem Fall muss die komplette Sequenz vor Beendigung der Simulation erkanntwerden

Sei im Folgenden p eine Eigenschaft Die geforderte Erf¨ullung einer

PSL-Eigenschaft kann durch den abort-Operator bei Auftreten einer Booleschen

Bedin-gung b1aufgehoben werden:

• p abort b1ist eine PSL-Eigenschaft

• {r} |-> p ist eine PSL-Eigenschaft.

• {r} |=> p ist eine PSL-Eigenschaft.

Die Operatoren |-> und |=> werden als ¨uberlappender oder nicht¨uberlappender Suffiximplikations-Operator bezeichnet Bei dem ¨uberlappenden Operator muss bei

jedem Auftreten der Sequenz{r} die PSL-Eigenschaft beginnend mit der letzten Booleschen Bedingung in r erf¨ullt sein Bei Verwendung des nicht¨uberlappenden Operators muss p irgendwann nach Auftreten der Sequenz {r} erf¨ullt sein.

In der einfachen Teilmenge von PSL ist die Anwendung des Negations- und

¨

Aquivalenzoperators auf PSL-Eigenschaften untersagt Lediglich Boolesche dr¨ucke d¨urfen negiert (!) oder auf ¨Aquivalenz (<->) getestet werden:

Aus-• !b1ist eine PSL-Eigenschaft

• b1<-> b2ist eine PSL-Eigenschaft

Bei der Disjunktion (||) und der Implikation (->) ist lediglich eine schaft p als Operand zugelassen, der andere Operand muss ein Boolescher Ausdruck

PSL-Eigen-sein Dar¨uber hinaus gilt bei der Implikation, dass die Bedingung ein BoolescherAusdruck ist, d h.:

• b1|| p ist eine PSL-Eigenschaft, wobei entweder b1= T sein muss oder p erf¨ullt

sein muss, falls b1= F ist

• b1-> p ist eine PSL-Eigenschaft, wobei sobald b1eintritt, p erf¨ullt sein muss Zwei PSL-Eigenschaften p1und p2k¨onnen konjunktiv verkn¨upft werden:

• p1&& p2 ist eine PSL-Eigenschaft, wobei sowohl p1 als auch p2 erf¨ullt seinmuss

Der LTL-Operator G wird durch den PSL always-Operator realisiert F¨ur dieNegation steht der never-Operator zur Verf¨ugung, dieser kann allerdings lediglichauf Sequenzen{r} angewendet werden.

• always p ist eine PSL-Eigenschaft.

• never {r} ist eine PSL-Eigenschaft.

• next p ist eine PSL-Eigenschaft.

2.4 Formale Spezifikation funktionaler Anforderungen 87

• next! p ist eine PSL-Eigenschaft.

Der next-Operator entspricht dem LTL-Operator X Dieser ist allerdings wiederumein schwacher Operator, d h sollte die Simulation nach Aktivierung der Eigenschaftbeendet werden, ohne dass es einen weiteren Zeitschritt gibt, gilt die Eigenschaft alserf¨ullt Durch Verwendung des next!-Operators, kann dies zu einer starken Bedin-gung gemacht werden, d h der n¨achste Zeitschritt muss simuliert werden ansonstengilt die Eigenschaft als verletzt

Der LTL-Operator U ist in PSL als until-Operator realisiert:

• p until b1ist eine PSL-Eigenschaft, wobei p erf¨ullt sein muss bis b1auftritt

• p until b1 ist eine PSL-Eigenschaft, wobei p erf¨ullt sein muss bis b1auftritt

Außerdem muss p noch w¨ahrend des Auftretens von b1erf¨ullt sein

• p until! b1ist eine PSL-Eigenschaft, wobei p erf¨ullt sein muss bis b1auftritt und

b1muss in der Simulation auftreten

• p until! b1 ist eine PSL-Eigenschaft, wobei p erf¨ullt sein muss bis b1 auftritt

und b1muss in der Simulation auftreten Außerdem muss p noch w¨ahrend des Auftretens von b1erf¨ullt sein

• b1before b2ist eine PSL-Eigenschaft, wobei b1vor b2auftritt

• b1before! b2ist eine PSL-Eigenschaft, wobei b1vor b2auftritt und b2muss inder Simulation auftreten

• b1before b2ist eine PSL-Eigenschaft, wobei b1vor b2auftritt und auch noch

w¨ahrend des Auftretens von b2gilt

• b1before! b2ist eine PSL-Eigenschaft, wobei b1vor b2auftritt und b2muss in

der Simulation auftreten Weiterhin muss b1noch w¨ahrend des Auftretens von b2gelten

Der LTL-Operator F ist in PSL nur als starker eventually!-Operator verf¨ugbar

• eventually! {r} ist eine PSL-Eigenschaft, wobei die Sequenz {r} bis zum Ende

der Simulation auftreten muss

Zur Erh¨ohung der Wiederverwendbarkeit, erlaubt PSL die Definition von schafts- und Sequenzdeklarationen mit Argumenten Die Eigenschaften und Sequen-zen k¨onnen dann an unterschiedlichen Stellen im Quelltext mit verschiedenen Para-metern instantiiert werden

Eigen-Beispiel 2.4.6 Die Eigenschaft, dass sich die Variablen x1 und x2gegenseitig schließen, l¨asst sich dann wie folgt formulieren:

aus-property mutex (boolean clk,x1,x2) = always !(x1& x2)@(posedge clk)

d h dass die Eigenschaft eine Zusicherung ist, oder diese erf¨ullt sein sollte, d h dass

es sich um eine Annahme handelt Eine Zusicherung wird mit der assert-Anweisung

ausgedr¨uckt, w¨ahrend eine Annahme durch die assume-Anweisung gekennzeichnetwird F¨ur simulative Verifikationsmethoden k¨onnen diese Anweisungen zur Gene-rierung gesteuerter, zuf¨alliger Testf¨alle verwendet werden (siehe Abschnitt 3.3).Weiterhin kann dem Verifikationswerkzeug mitgeteilt werden, welche Sequen-zen von Testfalleingaben w¨ahrend der Verifikation zu ber¨ucksichtigen sind oder aus-

geschlossen werden sollen Ersteres wird als ¨ Uberdeckung bezeichnet und durch die cover-Anweisung dargestellt Letzteres wird als Restriktion bezeichnet und mittels

der restrict-Anweisung angezeigt

Beispiel 2.4.7 Die ¨ Uberpr¨ufung der Zusicherung, dass x1 und x2 sich gegenseitigausschließen, kann man somit mit der PSL-Anweisung

assert always !(x1&x2)@(posedge clk);

erreichen Unter Verwendung der Eigenschaftsdeklaration aus Beispiel 2.4.6 kanndies auch als

assert mutex (clk,x1,x2);

formuliert werden

2.5 Formale Spezifikation nichtfunktionaler Anforderungen

Eine Anforderung an funktionale Eigenschaften beschreibt, welche Aktion ein tem in der Lage sein sollte, zu erbringen Dabei werden physikalische Randbedin-gungen der Implementierung nicht n¨aher ber¨ucksichtigt Neben diesen funktionalen

Sys-Eigenschaften spielen im Bereich eingebetteter Systeme allerdings auch die funktionalen Eigenschaften eine zentrale Rolle Typische nichtfunktionale Eigen-

nicht-schaften eines Systems sind dabei das Zeitverhalten, die Leistungsaufnahme, derFl¨achenbedarf etc Von diesen Eigenschaften ist das Zeitverhalten besonders wich-tig, da eingebettete Systeme eng mit ihrer Umgebung interagieren, wobei sicher ge-stellt sein muss, dass das System schnell genug arbeitet Die Bedeutung von

”schnellgenug“ h¨angt dabei davon ab, welche Aufgabe ein eingebettetes System ¨ubernimmt.Handelt es sich beispielsweise um eine Steuerung, so wird das Hauptaugenmerk aufder Antwortzeit liegen Bei einem MP3-Player hingegen interessiert, ob dieser dennotwendigen Durchsatz f¨ur eine unterbrechungsfreie Wiedergabe erzielt Dar¨uberhinaus ist es aber auch denkbar, dass unterschiedliche Verhalten im System imple-mentiert sind, wovon einige eine garantierte Antwortzeit, andere einen garantiertenDurchsatz ben¨otigen

Neben der Tatsache, dass das zu ermittelnde Qualit¨atsmaß f¨ur die Bewertung desZeitverhaltens nicht offensichtlich ist, eignet sich eine Formulierung wie

”schnellgenug“ wenig zur quantitativen Bewertung des Zeitverhaltens Wie schon bei derSpezifikation funktionaler Anforderungen, muss es auch im Fall der nichtfunktio-nalen Anforderungen m¨oglich sein, diese vollst¨andig, eindeutig und konsistent zu

2.5 Formale Spezifikation nichtfunktionaler Anforderungen 89formulieren Im Folgenden wird f¨ur diesen Zweck eine Erweiterung von CTL vor-gestellt Diese ist besonders gut geeignet, um quantitative Zeitanforderungen f¨ur eingegebenes Verhalten der Implementierung zu spezifizieren Genauer gesagt wird dasVerhalten des Systems, wie im Fall der temporalen Aussagenlogik, als tempora-

le Struktur beschrieben Allerdings wird die temporale Struktur mit quantitativenZeitattributen markiert Zeitliche Anforderungen k¨onnen dann als Erreichbarkeitsei-genschaften zwischen Zust¨anden bei gegeben Zeitschranken (untere und obere) ver-standen werden Die Vorstellung ist, dass sowohl der Start einer Funktionalit¨at alsauch deren Beendigung als Zustand des Systems beschreibbar ist Zeitabsch¨atzun-gen zwischen diesen Zust¨anden entsprechen dann Ende-zu-Ende-Latenzen, die auchf¨ur die Quantifizierung des Durchsatzes geeignet sind In sp¨ateren Kapiteln werdenspezielle Pr¨ufverfahren f¨ur das Zeitverhalten auf diesem Modell vorgestellt.Die in diesem Abschnitt betrachtete Erweiterung von CTL tr¨agt den Namen

TCTL (engl Timed Computation Tree Logic) In TCTL werden die temporalen ratoren (mit Ausnahme des X-Operators) mit quantitativen Zeitschranken versehen.

Ope-Zeitschranken werden als Pr¨adikate ¨uber Zeitvariablen definiert Die MengeT aller

Zeitpunkte kann entweder eine diskrete (T = Z≥0) oder eine kontinuierliche Zeit(T = R≥0) beschreiben Wenn nicht anders definiert, gilt im FolgendenT := Z≥0.Die Syntax von TCTL l¨asst sich formal definieren:

Definition 2.5.1 (Syntax von TCTL) V sei die Menge der aussagenlogischen

Va-riablen (atomaren Formeln) Eine TCTL-Formel wird rekursiv wie folgt definiert:

• Atomare Formelnϕ∈ V sind TCTL-Formeln.

• Seienϕundψ TCTL-Formeln, so sind auch ¬ϕundϕ∨ψ TCTL-Formeln.

• Seienϕundψ TCTL-Formeln, so sind auch EXϕ, EϕU∼γψ und AϕU∼γψ

TCTL-Formeln.

Dabei ist ∼γeine sog Zeitschranke mit ∼∈ {<,≤,=,≥,>} undγ∈ T.

Zur Definition der Semantik von TCTL-Formeln muss zun¨achst die Definitioneiner temporalen Struktur ebenfalls um Zeitannotationen erweitert werden Im Fol-genden wird von einer Erweiterung der Form ausgegangen, dass ein Zustands¨uber-

gang in der temporalen Struktur Zeit ben¨otigt Diese Verz¨ogerungszeit liegt in

ei-nem ZeitintervallΔi(T) Die Menge der Intervalle ¨uber T sei mitΔ(T) bezeichnet

Ein IntervallΔi (T) ∈Δ(T) kann entweder geschlossen (Δi(T) = [δl ,δu]) oder

of-fen (Δi(T) = [δl ,δu)) sein Die untere Grenzeδl eines Intervalls gibt die minimaleVerz¨ogerungszeit eines Zustands¨ubergangs an, w¨ahrend die obere Grenzeδudie ma-ximale Verz¨ogerungszeit angibt

Definition 2.5.2 (Zeitbehaftete temporale Struktur, TTS) Eine zeitbehaftete

tem-porale Struktur (engl Timed Temporal Structure, TTS) M ist ein Tripel (S,R,L),

wobei S eine endliche Menge an Zust¨anden, R ⊆ R ×Δ(T) × R eine zeitbehaftete

Beispiel 2.5.1 Gegeben ist die TTS in Abb 2.21 aus [312] Die TTS besteht aus drei Zust¨anden s0, s1und s2 Die Zustands¨uberg¨ange sind mit den Verz¨ogerungszeitenbeschriftet Man sieht, dass es zwischen zwei Zust¨anden mehrere ¨Uberg¨ange mit un-terschiedlichen Verz¨ogerungszeiten geben kann Die Bedeutung eines Zustands¨uber-gangs(s,δ,s  ) ist, dass der ¨Ubergang von Zustand s nach Zustand s  exaktδ Zeit-einheiten ben¨otigt Dabei beschreibtδ die Verz¨ogerungszeit des Zustands¨ubergangs.

21 0

Abb 2.21 Zeitbehaftete temporale Struktur [312]

Da mehrere ¨Uberg¨ange zwischen zwei Zust¨anden existieren k¨onnen, werden

Definition 2.5.3 (Semantik von TCTL-Formeln) Seiϕ eine TCTL-Formel, so deutet M ,s |=τϕ, dassϕim Zustand s der TTS M gilt Seienϕundψ zwei TCTL- Formeln, dann kann |=τwie folgt definiert werden:

2.6 Literaturhinweise 91Wie in CTL k¨onnen in TCTL weitere Operatoren als Abk¨urzung abgeleitetwerden, wie beispielsweise AXϕ = ¬EX ¬ϕ, EF∼γϕ = E T U∼γϕ, AF∼γ ϕ=

AT U∼γϕ, EG∼γϕ = ¬AF ∼γ ¬ϕ und AG∼γ ϕ= ¬EF ∼γ¬ϕ Weiterhin k¨onnendie Standard CTL-Operatoren U, F und G aus den TCTL-Operatoren abgleitet wer-den als U≥0etc Schließlich gelten die folgenden Zusammenh¨ange [287]:

Die Spezifikation von Hardware/Software-Systemen stellt aufgrund der genit¨at der Komponenten ein großes Problem dar, denn bekannte Modelle und Ent-wurfssprachen sind stark auf einen Anwendungsbereich (z B kontrollflussdominantoder datenflussdominant) bzw entweder auf die Beschreibung von Hardware (z B.VHDL [20, 233], SystemVerilog [422, 42]) oder die Beschreibung von Software(z B C, C++ [421]) zugeschnitten Die Sprache SystemC [207, 47, 236] stellt hiereinen interessanten Kompromiss dar, da sowohl die Datentypen aus C bzw C++als auch die f¨ur den Hardware-Entwurf ben¨otigten Datentypen (insbesondere Fix-punktzahlen) unterst¨utzt werden Außerdem ist die Modellierung von Nebenl¨aufig-keit durch das Modulkonzept vorhanden Modelle k¨onnen schließlich in SystemCzeitbehaftet sein oder nicht

Hetero-Die Unified Modeling Language (UML) [169, 445] stellt letztlich eigentlich

kei-ne Sprache, sondern eikei-ne Sammlung von unterschiedlichen Modellen zusammen,die dar¨uber hinaus vornehmlich nur den Entwicklungsprozess von reinen Software-Produkten unterst¨utzt haben Ab der Version 2.0 [13] wird die UML auch zuneh-mend interessanter f¨ur den Entwurf eingebetteter Hardware/Software-Systeme Vonder Intention her stellt UML eine Initiative dar, die vor allem in der Anfangspha-

se den Entwicklungsprozess von Software standardisieren und damit vereinfachensoll Zu den wichtigsten der 13 in der Version 2.0 unterst¨utzten Modelle geh¨oren

Sequenzdiagramme, eine Variante von hierarchischen endlichen Automaten, vit¨atsdiagramme, die ¨ahnlich wie eine Klasse von Petri-Netzen aufgebaut sind, Klas-sendiagramme, Kommunikationsdiagramme (zur Darstellung von Klassen und Bot-

Akti-schaften, die zwischen Objekten der Klassen transferiert werden) sowie sog Use Case-Diagramme Das große Problem von UML ist jedoch die Semantik und Kon-

sistenzpr¨ufung, wenn mehrere unterschiedliche Modelle gleichzeitig in einem wicklungsprojekt verwendet werden

Ent-Bei der Spezifikation von funktionalen Anforderungen spielen temporale sagenlogiken eine zentrale Rolle Eine ¨Ubersicht ¨uber temporale Aussagenlogikenund temporale Pr¨adikatenlogik erster Ordnung findet man in [148] Erste Ans¨atzeeiner temporalen Aussagenlogik sind in [364] f¨ur lineare Strukturen beschrieben.CTL ist in [37] und [97] diskutiert Da das lineare Zeitmodell ein Spezialfall desverzweigenden Zeitmodells ist, wurde in [286, 150] LTL auf einem verzweigendenZeitmodell definiert indem alle Pfadformeln impliziert allquantifiziert werden Hier-durch werden LTL und CTL vergleichbar Ein zentrales Ergebnis ist allerdings, dass

Aus-es LTL-Formeln gibt, die nicht in CTL ausdr¨uckbar sind und umgekehrt [286, 149].Zur Formulierung funktionaler Anforderungen als temporallogische Formel wer-

den zunehmend sog Zusicherungssprachen (engl assertion languages) verwendet.

Die beiden wichtigsten Vertreter sind System Verilog Assertions (SVA) [235] unddie in Abschnitt 2.4.3 beschriebene Property Specification Language (PSL) [234].Dar¨uber hinaus werden Bibliotheken angeboten, die wichtige Anforderungen in ei-ner parametrierbaren Form anbieten Neben dem Vorteil, dass viele Anforderungennicht mehr geschrieben werden m¨ussen, m¨ussen diese auch nicht mehr auf etwaigeFehler getestet werden Eine weit verbreitete Anforderungsbibliothek ist die OpenVerification Library (OVL) [351]

Erweiterungen von temporalen Logiken um Zeitaspekte sind in [151, 11, 8, 12]

beschrieben Viele Erweiterungen basieren auf CTL und werden als engl Timed CTL (TCTL) bezeichnet Quantitative Zeitschranken k¨onnen dabei entweder an die tem-

poralen Operatoren annotiert oder ¨uber Zeitvariablen in den Formeln beschriebenwerden Der Ansatz ¨uber Zeitvariablen ist sehr expressiv aber h¨aufig auch schwer

zu verifizieren Die Semantik von TCTL wird ¨uber zeitbehaftete temporale turen (TTS) definiert Unterschiedliche TTS werden in der Literatur betrachtet In[287] werden Zustands¨uberg¨ange im TTS mit Intervallen annotiert, wobei die un-tere Schranke die minimale Verz¨ogerungszeit und die obere Schranke die maxima-

Struk-le Verz¨ogerungszeit beim Zustands¨ubergang beschreibt Eine Beschr¨ankung diesesModells auf exakte Verz¨ogerungszeiten wird in [152] und [12] vorgestellt Eine Be-schr¨ankung der exakten Verz¨ogerungszeiten auf die Werte 0 und 1 ist in [288] dis-kutiert Schließlich beschreibt [151] ein TTS mit konstanten Verz¨ogerungszeiten derGr¨oße 1

Zeitbehaftete temporale Logiken werden zur ¨Uberpr¨ufung von zeitlichen schaften auf zeitbehafteten Verhaltens- bzw Strukturmodellen verwendet Bei denVerhaltensmodellen gibt es zu nahezu jedem zeitfreien Modell auch ein entsprechen-des zeitbehaftetes Modell Bei den zeitbehafteten Petri-Netzen gibt es im Wesentli-

Eigen-chen zwei Klassen, die sog engl time Petri nets [326] und die sog engl timed Petri nets [370] Bei time Petri nets sind die Schaltzeitpunkte der Transitionen durch Inter-

2.6 Literaturhinweise 93

valle begrenzt, w¨ahrend bei timed Petri nets die Transitionen so schnell wie m¨oglich

schalten Bei letzteren wird Zeit mit Stellen oder Transitionen assoziiert tete Automaten wurden in [9, 10] auf Basis von B¨uchi-Automaten mit Erweiterungen

Zeitbehaf-um Zeitvariablen eingef¨uhrt Dabei werden die akzeptierenden Zust¨ande verwendet,

um einen Fortschritt in den Zeitvariablen der temporallogischen Formeln zu gen Eine vereinfachte Form zeitbehafteter Automaten, wie sie auch in diesem Buch

erzwin-verwendet werden, wurden erstmals in [218] unter dem Namen engl timed safety automata vorgestellt In timed safety automata wird der Fortschritt der Zeit durch

lokale Invarianten in den Zust¨anden formuliert

Nach der Anforderungsanalyse und Durchf¨uhrung des Entwurfs (siehe [426]) den die Syntheseergebnisse verifiziert Dies ist notwendig, da, insbesondere im Be-reich eingebetteter Systeme, Implementierungen diversen Optimierungen unterwor-fen werden Dies kann einerseits auch manuelle und somit fehleranf¨allige Verfei-nerungen einschließen Andererseits sind Synthesewerkzeuge typischerweise selbstnicht verifiziert, was bedeutet, dass nicht sichergestellt ist, dass das Syntheseergebniskorrekt ist

wer-In diesem Kapitel werden nun grundlegende Fragestellungen zur Durchf¨uhrungder Verifikation diskutiert, wobei diese unabh¨angig von der Implementierungsform,also Hardware, Software oder Hardware/Software, und der gew¨ahlten Abstraktions-

ebene vorgestellt werden Dabei wird eine Unterscheidung in Verifikationsaufgabe, Verifikationsziel und Verifikationsmethodik vorgenommen Die Verifikationsaufgabe

beschreibt dabei, welche Art der Pr¨ufung durchgef¨uhrt werden soll Das onsziel definiert, was der erwartete Ausgang der Pr¨ufung ist, d h ob die Pr¨ufungpositiv oder negativ sein soll Im ersten Fall wird versucht, einen Beweis zu f¨uhren,w¨ahrend im zweiten Fall versucht wird, ein Gegenbeispiel zu finden Schließlichbeschreibt die Verifikationsmethodik, welches Verfahren zum Einsatz kommt, wobeiprinzipiell simulative und formale Methoden zu unterscheiden sind Verifikationsauf-gabe, -ziel und -methode sind eng miteinander verzahnt So k¨onnen Beweise h¨aufiglediglich sinnvoll mit formalen Methoden erzielt werden

Verifikati-3.1 Verifikationsaufgabe, -ziel und -methode

Beim Entwurf eingebetteter Systeme wird eine Spezifikation in eine rung abgebildet Die Aufgabe der Verifikation ist es, zu ¨uberpr¨ufen, ob dieser Synthe-seschritt korrekt verlaufen ist Hierbei k¨onnen unterschiedliche Fragestellungen vonInteresse sein Bevor ein System verifiziert werden kann, ist es also notwendig, die

Implementie-Verifikationsaufgabe festzulegen In Kapitel 1 wurden bereits die grundlegenden

Ve-rifikationsaufgaben im Bereich eingebetteter Systeme identifiziert: Zum einen kann

eine ¨ Aquivalenzpr¨ufung zwischen Spezifikation und Implementierung durchgef¨uhrt

C Haubelt, J Teich, Digitale Hardware/Software-Systeme, eXamen.press,

DOI 10.1007/978-3-642-05356-6 3, c Springer-Verlag Berlin Heidelberg 2010

Verhalten Anforderungen

pr¨ufung Eigenschafts- funktionale Abstraktion &

¨ Aquivalenz- pr¨ufung Abstraktion &

Qualit¨ats-merkmale

Anforderungen

Abstraktion &

pr¨ufung Eigenschafts- funktionale nicht-

Abb 3.1 a) ¨Aquivalenzpr¨ufung, b) funktionale und c) nichtfunktionale Eigenschaftspr¨ufung

Die Grenzen zwischen den drei Verifikationsaufgaben sind fließend Die ¨valenzpr¨ufung setzt voraus, dass die Spezifikation vollst¨andig ist, also jedes m¨ogli-che Verhalten des Systems spezifiziert Bei der funktionalen Eigenschaftspr¨ufung istdies nicht zwangsl¨aufig notwendig Vielmehr kann durch Auswahl besonders inter-essanter Eigenschaften eine unvollst¨andige Spezifikation entstehen Theoretisch ist

Aqui-es aber denkbar, dass man eine funktionale Eigenschaftspr¨ufung mit einer gen Spezifikation durchf¨uhrt In diesem Fall wird die Verifikationsaufgabe

vollst¨andi-”Aquiva-¨lenzpr¨ufung“ als Eigenschaftspr¨ufung formuliert und das Verhaltensmodell der Spe-zifikation liegt vollst¨andig als Menge funktionaler Anforderungen vor Somit ist die

¨

Aquivalenzpr¨ufung lediglich ein Spezialfall der funktionalen Eigenschaftspr¨ufung.Dennoch ist eine Unterscheidung sinnvoll Zum einen bilden Verfahren, die histo-risch gesehen im Kontext der ¨Aquivalenzpr¨ufung entstanden sind, ein wesentlichesFundament der funktionalen Eigenschaftspr¨ufung Zum anderen spielt die ¨Aquiva-lenzpr¨ufung in der Praxis nach wie vor eine zentrale Rolle Dies liegt darin be-gr¨undet, dass Systeme typischerweise evolution¨ar entstehen, d h durch Erweiterungoder Optimierung bestehender Systeme Das Originalsystem dient in diesem Fall