– ZUVERL ¨ ASSIGKEITSTECHNISCHE SYNTHESE UND ANALYSE DEGRADIERTER SYSTEMZUST ¨ ANDE –

REDUNDANZMANAGEMENT FEHLERTOLERANTER FLUGZEUG–SYSTEMARCHITEKTUREN

– ZUVERL ¨ ASSIGKEITSTECHNISCHE SYNTHESE UND ANALYSE DEGRADIERTER SYSTEMZUST ¨ ANDE –

D. Rehage , U. B. Carl , A. Vahl Technische Universit¨at Hamburg–Harburg

Arbeitsbereich Flugzeug–Systemtechnik, D-21071 Hamburg

UBERSICHT¨

Der Entwurfsprozeß von Flugzeug–Systemarchitekturen moderner Verkehrsflugzeuge wird immer komplexer. Be- dingt ist dies durch die wachsenden Anforderungen an Sicherheit und Zuverl¨assigkeit bei gleichzeitig zunehmen- den Funktions– und Leistungsanforderungen. Da diese Maßgaben in einem Spannungsfeld zueinander stehen, so- wie der Entwicklungszeitraum an einen engen Zeit– und Kostenrahmen gebunden ist, sind schon in der Fr¨uhphase der Systementwicklung rechnergest¨utzte Methoden und Verfahren erforderlich.

Dieser Artikel zeigt den Entwicklungsstand eines Software–Tools, welches den Ingenieuren unterschiedlich- ster fachlicher Ausrichtungen eine Plattform f¨ur die Syn- these und Analyse komplexer und eingebetter Hardware–

und Software–Systeme bietet.

Basis hierzu ist ein hybrides Systemmodell mit einer strukturorientierten Modellierung der Architektur in Zu- verl¨assigkeitsblockdiagrammen sowie einem neuartigen Konzept der zustandsorientierten Modellierung abgebilde- ter Komponenten mit hierarchischen, nebenl¨aufigen endli- chen Automaten. Zur Analyse von fehlerfreien und degra- dierten Systemzust¨anden werden auf das Zuverl¨assigkeits- blockdiagramm Algorithmen der Zuverl¨assigkeitsanalyse angewandt. Im Bereich des Redundanzmanagements zur Visualisierung und Analyse von Zustands¨ubergangspro- zessen bei Fehlerinjektion, Fehlerausbreitung und Rekon- figuration sind dies Algorithmen derK¨unstlichen Intelli- genz.

SCHLAGWORTE

Endlicher Automat; degradiertes System; Fehlertoleranz;

Redundanzmanagement; Systementwurf; Zuverl¨assig- keitsanalyse; Zuverl¨assigkeitsblockdiagramm

1 EINLEITUNG

Die Entwicklung von Flugzeug-Systemarchitekturen f¨uhrt gerade durch die hohen Sicherheits– und Zuverl¨assigkeits- anforderungen, in Verbindung mit hohen Verf¨ugbarkeiten zur Senkung der Betriebskosten, auf eine fehlertolerante

Architektur. Hierbei handelt es sich um eine grundlegen- de Eigenschaft von Flugzeugsystemen zu deren Voraus- setzung Redundanz geh¨ort. Der Entwurf solcher Systeme ist multidisziplin¨ar und erstreckt sich ¨uber die Bereiche von Rechnersystemen, Kommunikationssystemen und pe- ripheren Systemprozessen (z.B. Stellsysteme und Senso- rik). Rechnerunterst¨utzung ist in diesem Rahmen notwen- dig, um die Entwurfskomplexit¨at der Systeme besser zu bew¨altigen und auch bessere Entw¨urfe in k¨urzerer Zeit zu erm¨oglichen, damit die nachfolgend aufgef¨uhrten Frage- stellungen leichter und auf Basis eines Software–Tools zu beantworten sind:

”Erf¨ullt die Fluzeug–Systemarchitektur, aufgrund der Redunzanordnung die Zuverl¨assigkeitsanforde- rung im fehlerfreien Nominalzustand?“,

”Wie rekonfiguriert das Flugzeugsystem unter Feh- lereinfl¨ussen?“,

”Ist der Redundanzgrad der Fluzeug–

Systemarchitektur hinreichend, um die Zu- verl¨assigkeitsanforderungen in degradierten Sy- stemzust¨anden zu gew¨ahrleisten?“

Schon in der Phase der konzeptionellen Architek- turfindung, wird den Systemingenieuren mit SYRE-

LANTM (SYSTEM RELIABILITY ANALYSIS) eine rech- nergest¨utzte Entwurfsumgebung zur Verf¨ugung gestellt, mit der Architekturen zuverl¨assigkeitstechnisch synthe- tisiert und analysiert werden k¨onnen. Im Rahmen des- sen erfolgt zun¨achst die zuverl¨assigkeitstechnische Mo- dellierung der fehlertoleranten Architekturen durch lo- gische Verkn¨upfung in Zuverl¨assigkeitsblockdiagrammen (RBD,engl. Reliability Block Diagram) inpositiver Lo- gik. Neben der Modellierung in RBDs und der Analyse der Ausfallwahrscheinlichkeit aus dem fehlerfreien No- minalzustand, basierend auf Exponentialverteilungen der Komponentenausfallraten, wird das Systemverhalten un- ter Einfluß von Fehlerszenarien im RBD–Modell abgebil- det und analysiert. Dazu werden den RBD–Bl¨ocken hierar- chische, nebenl¨aufige endliche Automaten (HCFSM,engl.

Hierarchical Concurrent Finite State Machine) hinterlegt,

welche die Arbeitsweise des Redundanzmanagements be- schreiben und dessen visuelle Abbildung im RBD un- terst¨utzen.

2 HIERARCHISCHES MODELL

Die Modellierung der Flugzeug–Systemarchitekturen un- terteilt sich in zwei hierarchische Entwurfsumgebungen.

Zun¨achst wird in der oberen Modellebene, der RBD–

Umgebung, die fehlerfreie Systemarchitektur durch lo- gische Verkn¨upfung von RBD–Bl¨ocken abgebildet. Dem schließt sich die Modellierung des Redundanzmangements in der unteren Modellierungsebene durch Definition der im Hintergrund betriebenen HCFSM–Modelle an. Gekop- pelt sind die beiden Modelle aus Sicht der RBDs durch Zuweisung von Komponenzust¨anden an die dar¨uberlie- genden RBD–Bl¨ocke (Bild 1). Bei den Systemzust¨anden werden nur diejenigen angesprochen, die aus zuverl¨assig- keitstechnischer Sicht relevante Degradationsstufen re- pr¨asentieren [7]. Die Zuweisung entsprechender Farben zu solchen Komponentenzust¨anden zeigt die nachfolgende Auflistung:

”aktiv“ GR ¨UN: Die Arbeitskomponente A ist von Missionsbeginn an der vollen Belastung ausgesetzt. Die Ausfallrate istλA.

”aktiv–heiss“GELB: Reserveelement H ist von Mis- sionsbeginn an der gleichen Belastung ausgesetzt wie die eigentliche Arbeitskomponente A. F¨ur die Ausfallrate gilt λHλA.

”passiv–warm“ ORANGE: Reserveelement W ist bis zum Ausfall der Arbeitskomponente A (oder bis zum eigenen vorzeitigen Ausfall) einer geringeren Belastung ausgesetzt. F¨ur die Ausfallrate gilt 0λW λA.

”passiv–kalt“HELLBLAU: Reserveelement K ist bis zum Ausfall der Arbeitskomponente A keiner Belastung ausgesetzt. F¨ur die Ausfallrate giltλK0.

Aus Sicht der HCFSM–Modelle besteht die Kopplung durch Fehlerinjektion in den RBD–Block, da zu dem Kom- ponentenausfall im RBD Zustands¨uberg¨ange im HCFSM–

Modell hervorgerufen werden.

2.1 RBD–Modell

Ausgangspunkt der Modellierung von Systemarchitektu- ren bildet die strukturelle Abbildung des fehlertoleran- ten Systems in RBDs. Dazu muß in einem ersten Schritt ein TOP–EVENT definiert werden, welches den zu ana- lysierenden Ausfallzustand beschreibt. Dieser Zustand re- pr¨asentiert entweder das fehlerfreie oder das degradierte System in Abh¨angigkeit der Komponentenzust¨ande. Ma- thematisch wird dies durch die BOOLSCHE–Algebra be- schrieben, die auf einerzweiwertigen Logik basiert [6].

F¨ur die Darstellung der einzelnen Komponenten wird die stochastisch unabh¨angigeIndikatorvariable K_ieingef¨uhrt, f¨ur die gilt [6]

Komponentenzustände

K o m p o n e n t e m

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s K o m p o n e n t e 2

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s K o m p o n e n t e 1

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s . . .

. . . H C F S M - M o d e l l :

Komponentenfehler

a k t i v a k t i v - h e i s s p a s s i v - w a r m p a s s i v - k a l t i s o l i e r t

G R Ü N G E L B O R A N G E H E L L B L A U R O T K o m p o n e n t e m

a k t i v a k t i v - h e i s s p a s s i v - w a r m p a s s i v - k a l t i s o l i e r t

G R Ü N G E L B O R A N G E H E L L B L A U R O T K o m p o n e n t e 2 a k t i v a k t i v - h e i s s p a s s i v - w a r m p a s s i v - k a l t i s o l i e r t

G R Ü N G E L B O R A N G E H E L L B L A U R O T K o m p o n e n t e 1

. . .

. . .

. . .

. . . F e h l e r i n K o m p o n e n t e m F e h l e r i n K o m p o n e n t e 2 F e h l e r i n K o m p o n e n t e 1

R B D - M o d e l l :

F e h l e r t o l e r a n t e s F l u g z e u g - S y s t e m

K o m p o n e n t e m 1 . 0 0 e - 0 5 K o m p o n e n t e 2

1 . 0 0 e - 0 5 K o m p o n e n t e 1 1 . 0 0 e - 0 5

m

2 1

1 . 0 0 e - 0 5

1 . 0 0 e - 0 5

1 . 0 0 e - 0 5

S E

BILD 1: Kopplung der hierarchischen Modellie- rungsumgebungen von RBD und HCFSM

(1) K_i1 Komponente K_iist funktionsf¨ahig und

(2) K_i0 Komponente K_iist ausgefallen Die Bildung des Erwartungswertes der Indikatorvariablen ist die Wahrscheinlichkeit, daß die Komponente K_ifunkti- onsf¨ahig oder ausgefallen ist [6]

(3) EK_i0PK_i01PK_i1PK_i1 Dies ist gleich der Komponentenzuverl¨assigkeit R_i [6].

Im Bereich von Flugzeugsystemen werden im Allge- meinen Komponentenausf¨alle altersunabh¨angig und da- mit rein zuf¨allig angenommen, so daß die Komponenten-

zuverl¨assigkeit durch folgendeExponentialverteilungbe- schrieben wird [6]

(4) Rite^λit

Die Verkn¨upfung der Variablen zu einer Systemarchitek- tur erfolgt ¨uber logische Operatoren UND, ODER und NICHT, die sich auch durch reell–algebraische Schreib- weise ausdr¨ucken lassen [6].

Unter der Annahme, daß die BOOLSCHENSysteme Mono- toniebedingungen erf¨ullen, kann die Systemfunktionφauf Basis logisch verkn¨upfter Komponenten gebildet werden [6]:

(5) φK1 Systemφist funktionsf¨ahig und

(6) φK0 Systemφist ausgefallen

Das RBD–ModellφKdes gesamten Flugzeug–Systems ist eine Funktion der in ihm enthaltenen Bl¨ocke K (7) φK mit KK1KiKmT

Im Rahmen der Systemmodellierung werden verschie- denartige Komponenten verwandt. Sie lassen sich in drei Block–Kategorien einordenen:Hardware–Block,mul- tifunktionaler Hardware–Block und multifunktionaler Software–Block. In den beiden Hardwarebereichen sind den Bl¨ocken entsprechende zuverl¨assigkeitstechnische Ei- genschaften wie eine konstante oder exponentialverteilte Ausfallwahrscheinlichkeit Ft, eine konstante Ausfallrate λsowie ein Checkintervall zuzuordnen.

Uber die logische Verkn¨upfung dieser Bl¨ocke, entspre-¨ chend ihrer funktionellen Abh¨angigkeit im System, wird die Architektur abgebildet. Dies schließt auch eine Mehr- fachverwendung einzelner Bl¨ocke im RBD nicht aus, da alle Bl¨ocke in der zuverl¨assigkeitstechnischen Analyse durch Orthogonalisierung der BOOLSCHENSystemfunkti- on nur als einmal physikalisch auftretend bewertet werden.

2.2 HCFSM–Modell

Die untere Modellierungsebene besteht aus hierarchi- schen, nebenl¨aufigen endlichen Automaten, die den RBD–Bl¨ocken hinterlegt werden k¨onnen. Das Bild 2 zeigt die in das RBD eingebetteten HCFSMs, sowie die Eingriffsm¨oglichkeit in das Gesamtmodell ¨uber den Komponenten–Fehlervektor F (Eingangsvektor) und die Ausgabe des aktuellen Zustands Y (Ausgangsvektor).

H C F S M - M o d e l l : R B D - M o d e l l : f ( K )

A k t u e l l e r Z u - s t a n d s v e k t o r Y K o m p o n e n t e n -

F e h l e r v e k t o r F f : ( F Z ) Z S p e i c h e r g : Z Y ZF

BILD 2: In das RBD–Modell eingebette HCFSM–

Modell

Beschrieben werden k¨onnen die HCFSMs durch einen 6–

TupelFYZZˆfg[2]:

F ist der Eingangsvektor,

Y ist der Ausgangsvektor,

Z ist die endliche nichtleere Menge interner Zust¨ande,

Zˆ Z ist die Menge der Anfangszust¨ande,

f : FZZ heißt ¨Ubergangsfunktion,

g : ZY heißt Ausgangsfunktion.

Eine spezielle Eigenschaft dieser Automaten ist, daß die Ausgaben Y von den internen Zust¨anden Z ¨uber die Aus- gangsfunktion g erzeugt werden und damit unabh¨angig von der Eingabe sind. Graphisch werden diese soge- nannten MOORE–HCFSMs durch Zustandsdiagramme repr¨asentiert. Das sind gerichtete Graphen GVE ⁱⁿ denen jeder Knoten vV einen Zustand und jede Kante eE eine Transition darstellt [2, 5]. Tritt in einem aktu- ellen Zustand ZZ ein entsprechendes Eingabeereignis F F ein, dann erfolgt ein Zustands¨ubergang unter der Voraussetzung, daß das Eingabeereignis die Transitions- bedingung T erf¨ullt.

Die Hierarchisierung der endlichen Automaten wird durch die Zerlegung von Superzust¨anden in Subzust¨ande erzielt [2]. Als ein anschauliches Beispiel erweist sich die Unter- teilung des fehlerfreien Anfangszustands eines Systems in die Menge einzelner Anfangszust¨ande ˆZ der HCFSMs, die den entsprechenden RBD–Bl¨ocken hinterlegt sind.

Desweiteren sind diese endlichen Automaten durch Nebenl¨aufigkeit charakterisiert. Bei dieser Modell- form k¨onnen einerseits die Transitionen zwischen den Zust¨anden eines HCFSM–Modells in Abh¨angigkeit von Zust¨anden benachbarter HCFSMs schalten [5]. Bild 3 zeigt die Serienverkn¨upfung von zwei Komponenten im RBD, deren HCFSMs beispielhaft ¨uber den Zustand

”aktiv“von Komponente 1 und die Transition T1von Komponente 2 gekoppelt sind. Andererseits treten Verkopplungen immer dann auf, wenn durch ein Eingabeereignis die Transitions- bedingungen mehrer HCFSMs erf¨ullt sind. Diese Art der Verkopplung wird in Bild 3 durch die Transition T₂darge- stellt, wo beide HCFSMs zu den Komponenten 1 und 2 auf Basis desselben Eingabeereignisses F₂schalten k¨onnen.

K o m p o n e n t e 1 p a s s i v - k a l t

i s o l i e r t a k t i v

a k t i v - h e i s s H C F S M - M o d e l l

R B D - M o d e l l

T 1

K o m p o n e n t e 2 1 . 0 0 e - 0 5

K o m p o n e n t e 1 1 . 0 0 e - 0 5

2

1

1 . 0 0 e - 0 5 1 . 0 0 e - 0 5

S E

p a s s i v - k a l t

i s o l i e r t a k t i v

K o m p o n e n t e 2 T 1= f( K o m p o n e n t e 1 = a k t i v) T 2

T 2 T 2= f(F 2)

BILD 3: Kopplung der HCFSMs

Die formelle HCFSM–Modellbeschreibung erfordert zun¨achst die Darstellung der Modellierungsoptionen im Breich der HCSFMs in Abh¨angigkeit von den dar¨uberlie- genden RBD–Bl¨ocken. Die Optionen sind anwendungs- spezifisch und unterteilen sich in drei Kategorien (Bild 4).

Der einfache Hardware–Block in Bild 4a wird eingesetzt, um Hardware–Komponenten wie beispielsweise Stellsy- steme, Spannungsversorgungen etc. abzubilden. Um die- sen Block im Rahmen des Redundanzmanagements einzu- setzen, wird eine einzelne HCFSM im Hintergrund betrie- ben.

Ein Spezialfall des Hardware–Blocks ist der multifunk- tionale Hardware–Block in Bild 4b. Eine Abbildung die- ses Blocks erfolgt bei Hardware–Komponenten, die von verschiedenen Anwendungen – multifunktional – ge- nutzt werden. Hierzu z¨ahlen beispielsweise Eingangs–

/Ausgangs–Einheiten auf Rechnersystemen, Bussysteme, Internet–Switches etc.. Der Hintergrundbetrieb verschie- dener HCFSMs ist bei diesen Anwendungen notwendig.

Der multifunktionale Software–Block in Bild 4c wird verwandt, um einzelne bzw. auch integrierte Software–

Applikationen abzubilden, die auf einer gemeinsam ge- nutzten Rechnerressource durch Partitionierung betrieben werden. Dies erfordert den Hintergrundbetrieb mehrerer HCFSMs.

Aufgrund des RBD–Hintergrundbetriebs der HCFSMs l¨aßt sich dieses Modell nur in Abh¨angikeit der RBD–

Komponenten K_i beschreiben. Dies f¨uhrt im HCFSM–

Modell auf einen Automatenvektor (8), der aus einzel- nen Automaten A_{i j}iK_ibesteht. Der Index jiIN be- schreibt in diesem Zusammenhang die Anzahl der im Hin- tergrund betriebenen HCFSMs zu einzelnen Komponenten i1m

A

A₁₁K₁A_{1 j}1K₁ ...

A_i1K_iA_{i j}iK_i ...

A_m1K_mA_{m j}mK_m

(8)

jiIN

Jeder der endlichen Automaten im Automatenvektor (8) kann durch ein Zustandsdiagramm mit bis zu f¨unf Zust¨anden und 16 Transitionen repr¨asentiert werden (Bild 5).

K o m p o n e n t e i

p a s s i v - w a r m

p a s s i v - k a l t

i s o l i e r t a k t i v a k t i v -

h e i s s

T 1 T 2 T 3

T 7 T 8

T 1 1

T 1 2

T 1 3

T 1 4

A i j ( i )[K i]

Z i j ( i )1 Z i j ( i )5

Z i j ( i )2Z i j ( i )3 Z i j ( i )4

H C F S M - M o d e l l

T 4

T 1 0

T 9 T 5 T 6

T 1 5

T 1 6

BILD 5: Zust¨ande und Transitionen einer HCFSM Die maximale Zustandsanzahl einzelner HCFSMs aus dem Automatenvektor (8) wird durch folgende Zustandsmenge beschrieben

Z˜_{i j}i

Z_{i j}i1Z_{i j}i5

(9)

i 1m und jiIN

Die Belegung der HCFSMs–Zust¨ande mit entsprechenden Redundanzmerkmalen ist in Tabelle 1 aufgef¨uhrt.

Zust¨ande der HCFSMs

Redundanz–

merkmale Endung

Z_{i j}i1 ”aktiv“ a

Z_{i j}i2 ”aktiv–heiss“ h Z_{i j}i3 ”passiv–warm“ w Z_{i j}i4 ”passiv–kalt“ k Z_{i j}i5 ”isoliert“ i TAB 1: Zuordnung der Komponentenzust¨ande

K o m p o n e n t e 1

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s

K o m p o n e n t e 1 1 . 0 0 e - 0 5

1

E

S

(a) Hardware–Block

A n w e n d u n g j ( 1 )

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s A n w e n d u n g 2

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s A n w e n d u n g 1

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s

K o m p o n e n t e 1 1 . 0 0 e - 0 5

1

1 . 0 0 e - 0 5

H W ^{1 E}

S

(b) Multifunktionaler Hardware–Block

P a r t i t i o n j ( 1 )

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s P a r t i t i o n 2

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s P a r t i t i o n 1

p a s s i v

- w a r m p a s s i v

- k a l t i s o l i e r t a k t i v a k t i v -

h e i s s

K o m p o n e n t e 1 1 . 0 0 e - 0 5

1

1 . 0 0 e - 0 5

S W ^{1 E}

S

(c) Multifunktionaler Software–Block BILD 4:RBD–Bl¨ocke mit hinterlegten HCFSMs

Da es bei den meisten Systemarchitekturen nicht notwen- dig ist, alle f¨unf Zust¨ande im Systemmodell abzubilden, wird eine Teilmenge verwandt

Z_{i j}i Z˜_{i j}i

(10)

i 1m und jiIN

Aus der Beschreibung der HCFSM–Zustandsteilmengen (10) wird der Zustandsvektor bestimmt

(11) Z

Z11Z_{1 j}1

...

Z_i1Z_{i j}i

...

Z_m1Z_{m j}m

jiIN

Ein Spezialfall des Zustandsvektors (11) ist der Vektor der Anfangszust¨ande zum Zeitpunkt der Inbetriebnahme t₀ (12) Zˆt₀Z

In diesem Vektor wird der fehlerfreie Anfangsbelegung der HCFSMs festgelegt, von dem aus das System w¨ahrend des Betriebs tst0unter Fehlereinfl¨ussen degradiert.

Die Transitionen der HCFSMs in Bild 5 beschreiben die ¨Uberg¨ange zwischen den Zust¨anden (9). Bei einer vollst¨andigen HCFSM werden die maximal 16 Transitio- nen durch nachfolgende Transitionsmenge charakterisiert

T˜_{i j}i

T_{i j}i1Z_{i j}i2Z_{i j}i1

(13)

T_{i j}i16Z_{i j}i4Z_{i j}i5

i 1m und jiIN

Die Bedingungen zu denen die Zustands¨uberg¨ange er- folgen sollen, werden ¨uber logische Gleichungen defi- niert. Die Gleichungen, die in diesem Rahmen von SYRE-

LANTMverarbeitet werden k¨onnen, st¨utzen sich auf eine spezielle Syntax, welche die Komponentenzust¨ande ¨uber die Endungen aus Tabelle 1 adressieren. Nachfolgend wird beispielhaft das Ansprechen des Zustands

”aktiv–heiss“ ei- ner HCFSM zum Hardware–Block von Komponente K₁ aufgezeigt

(14) 1 h

Dar¨uber hinaus muß bei den HCFSMs der multifunktiona- len Hardware– und Software–Bl¨ocke ein Unterscheidungs- kriterium bereitgestellt werden, das ein einzelnes Anspre- chen der verschiedenen endlichen Automaten erm¨oglicht.

Dazu wird neben der Identifikation des RBD–Blocks zur Komponente K₁und der Zuordnung des Zustands

”passiv–

warm“ eine Identifikation hinzugef¨ugt, die in diesem Bei- spiel die HCFSM

”Partition1“ anspricht (15) 1 Partition1 w

Verkn¨upft werden die adressierten Zust¨ande im Software- Tool ¨uber die logischen Operatoren UND, ODER und NICHT (&, v,-).

Auch die Transitionen der HCFSM einer Komponente K_i sind abh¨angig vom Gesamtmodellkontext in den die Komponente eingebettet ist. Dies hat zur Konsequenz, daß die Menge der Transitionen nur eine Teilmenge von (13) ist, weil die meisten Systeme eine nicht vollst¨andige Zu- stands¨ubergangsbeschreibung wie in Bild 5 ben¨otigen

T_{i j}i T˜_{i j}i

(16)

i 1m und jiIN

Auf Basis dieser Zustandsteilmengen, l¨aßt sich der Transi- tionsvektor des Gesamtsystems aufstellen

(17) T

T₁₁T_{1 j}1

...

T_i1T_{i j}i

...

T_m1T_{m j}m

jiIN

Der Eingangsvektor F enth¨alt die ins System zu injizieren- den Fehler A_{i j}iK_i. Beim einfachen Hardware–Block bewirkt dies den ¨Ubergang der einzelnen HCFSM in den Fehlerzustand

”isoliert“, sowie bei den multifunktionalen Hardware–Bl¨ocken den simultanen ¨Ubergang s¨amtlicher HCFSMs in den Zustand

”isoliert“. Im Gegensatz dazu kann bei den multifunktionalen Software–Bl¨ocken eine einzelne HCFSM individuell durch Fehlerinjektion in den Zustand

”isoliert“ transformiert werden. Der entsprechen- de vollst¨andige Fehlervektor lautet

F

A₁₁K₁A_{1 j}1K₁ ...

A_i1K_iA_{i j}iK_i ...

A_m1K_mA_{m j}mK_m

(18)

jiIN

Da es sich bei den HCFSMs um einen MOORE–Automaten handelt, wird jedem Zustand im System eine Ausgabe in Form einer Farbzuweisung an den dar¨uberliegenden Block zugeordnet. Die Ausg¨ange einer HCFSM mit f¨unf Zust¨anden, werden durch die nachfolgende Menge be- schrieben, deren Elemente eine Farbzuordnung entspre- chend Tabelle 2 erhalten

Y˜_{i j}iZ_{i j}i

Y₁Z_{i j}i1Y₅Z_{i j}i5

(19)

i 1m und jiIN Ausg¨ange der

HCFSM–Zust¨ande Farbzuordnungen Y₁Z_{i j}i1 GR ¨UN Y₂Z_{i j}i2 GELB Y₃Z_{i j}i3 ORANGE Y₄Z_{i j}i4 HELLBLAU Y₅Z_{i j}i5 ROT TAB 2: Farbzuordnungen zu den Ausg¨angen

Durch die Verkn¨upfung der Ausg¨ange mit entsprechend ausgew¨ahlten Zust¨anden (10) kann auch der Ausgangsvek- tor eines Systems nur durch Teilmengen der Ausg¨ange (19) repr¨asentiert werden

Y_{i j}iZ_{i j}i Y˜_{i j}iZ_{i j}i

(20)

i 1m und jiIN Aus dieser Beziehung l¨aßt sich der vollst¨andige Ausgangs- vektor eines Systems aufstellen

Y

Y₁₁Z₁₁Y₁₁Z_{1 j}1

...

Y_i1Z_i1Y_{i j}iZ_{i j}i

...

Y_m1Z_m1Y_{m j}mZ_{m j}m

(21)

jiIN

3 REDUNDANZMANAGEMENT

Die fehlertolerante Auslegung von Systemen ist gera- de im Bereich der Flugzeugsysteme das g¨angige Kon- zept im Entwurf solcher Systeme, um neben der System–

Funktionalit¨at auch die Zuverl¨assigkeits– und Sicherheits- anforderungen zu erf¨ullen. Die Fehlertoleranz bezeichnet die F¨ahigkeit des Systems, auch mit einer begrenzten An- zahl fehlerhafter Komponenten die spezifizierte Funktion zu erf¨ullen. Dies erfordert Redundanz. Die Redundanz ist dabei das Vorhandensein von mehr technischen Mitteln als zum Betrieb des Systems notwendig w¨aren [1].

Damit ein fehlertoleranter Systembetrieb realisierbar ist, muß das System ¨uber zwei Eigenschaften verf¨ugen. Das ist einerseits die Fehlerdiagnose, bei der Redundanz in Form von BITE–Komponenten (BITE,engl.Build In Test Equipment) eingesetzt wird, um eine fehlerhafte zu detek- tieren und zu lokalisieren [1]. Andererseits wird Redun- danz zur Fehlerbehandlung verwandt. Nach Identifizierung eines Fehlers, wird dieser durch die Fehlerbehandlung ein- gegrenzt. Dem schließen sich strukturelle Maßnahmen zur Funktionserhaltung an. Die sogenannte Fehlerausgrenzung entfernt die fehlerhaften Komponenten aus dem System und sichert durch die Rekonfigration eine ¨Uberf¨uhrung in einen funktionsf¨ahigen Zustand [1].

Dies erfordert eine Strategie die festlegt, wie sich das System unter Fehlereinfl¨ussen zu verhalten hat, um die gew¨unschte Funktionalit¨at wiederzuerlangen. Dieser Pro- zeß ausFehlerausbreitungundRekonfigurationbezeichnet die Arbeitsweise desRedundanzmanagements.

3.1 Fehlerausbreitung und Rekonfiguration

Die Durchf¨uhrung des Redundanzmangements st¨utzt sich nach der Injektion eines Fehlers auf zwei Prozesse, die Fehlerausbreitung und die Rekonfiguration. Damit diese beiden Prozesse eine realit¨atsnahe und zeiteffektive Um- setzung erfahren, werden bei der algorithmischen Imple- mentierung neben RBD–Eigenschaften auch Prinzipien von fehlertoleranten und rechnergest¨utzten Systemen an- gewandt.

Das Bild 6 zeigt zur Veranschaulichung des Redundanzmanagement–Algorithmus das RBD einer H¨ohenrudersteuerung eines Verkehrflugzeugs mit hinter- legten HCFSMs. Die aktuellen Zust¨ande der einzelnen endlichen Automaten sind hier aus ¨Ubersichtlichkeits- gr¨unden durch angef¨ugte Zustandsattribute nach den Ta- bellen 1 und 2 den Bl¨ocken zugeordnet, damit die Unter- scheidung zwischen den Zust¨anden m¨oglich ist. Ausge- nutzt wird in diesem Rahmen die strukturelle Eigenschaft des RBD–Modells. Da dieses Modell die Information ¨uber die Verkn¨upfung von Komponenten besitzt, k¨onnen sich die Fehlerausbreitungs– und Rekonfigurationsprozesse an den logischen Abh¨angigkeiten benachbarter Bl¨ocke orien- tieren.

Dem Fehlerausbreitungsprozeß wird in diesem Zusam- menhang eine Suchstrategie f¨ur benachbarte Bl¨ocke ¨uber- lagert. Differenziert wird dabei zwischen der fehlerhaften Komponente sowie deren direkten Nachbarn. Das Krite- rium ist, daß die Suchstrategien sich an deren Zust¨anden

”aktiv“ oder nicht

”aktiv“ auf Basis der HCFSMs ausrich- ten. Zu den Zust¨anden nicht

”aktiv“ z¨ahlen

”aktiv–heiss“,

”passiv–warm“,

”passiv–kalt“ und

”isoliert“.

Bild 6 zeigt bei der Fehlerinjektion in Komponente K₁₆den Fehlerausbreitungsprozeß FA1₁, der sich an den benach- barten Bl¨ocken im Zustand

”aktiv“ orientiert. Ausgehend von der fehlerhaften Komponente wird dabei zun¨achst die Fehlerausbreitung hin zum START–Block erfolgen.

Um anschließend eine schnelle Rekonfiguration einleiten zu k¨onnen, werden die Rekonfigurations–Knotenpunkte

RK₁RK₂RK₃ des RBDs gespeichert, die aus Sicht der Komponente mit dem aktuell schaltbaren HCFSM links- seitig liegen und zu dieser mindestens eine parallele Kom- ponente besitzen m¨ussen. Der zweite Teil der Fehleraus- breitung FA1₂wirkt von der fehlerhaften Komponente K₁₆ hin zum END–Block. F¨ur beide Fehlerausbreitungsrich- tungen gilt nat¨urlich, daß bei RBD–Knotenpunkten s¨amt- liche Verzweigungen in parallele Pfade untersucht werden.

Bei der Fehlerinjektion in einer Komponente deren HCFSMs sich in einem der Zust¨ande nicht

”aktiv“ be- findet, wird nach benachbarten Komponenten gesucht, die schaltbare Transitionen besitzen. Auch hier gilt, ¨ahnlich wie bei der Suche nach Komponenten im Zustand

”ak- tiv“, daß ausgehend von der fehlerhaften Komponente K₁₈ eine Fehlerausbreitung FA2₁hin zum START–Block einschließlich der Speicherung von Rekonfigurations–

KnotenpunktenRK₄RK₂RK₃ erfolgt, sowie die Feh- lerausbreitung FA2₂hin zum END–Block (Bild 6).

Die Rekonfiguration erfolgt dann ¨uber die Komponenten die rechtsseitig der Rekonfigurations–Knotenpunkte lie- gen. Dies schließt nat¨urlich die Komponenten aus, deren HCFSMs bei der Fehlerausbreitung schon geschaltet ha- ben.

Bei den meisten rechnergest¨utzen Systemen werden detek- tektierte Fehler, sofern sie nicht auf der Rechnerressource selbst auftreten und vom Betriebssystem verarbeitet wer- den, in der Applikations–Software behandelt.

aktiv

Power Supply Unit 4

3.00e-06

4

Failure:

6.60e-011

End

Mission Time: 1. H

Start

FA12

FA11

FA22

FA21

RK1

RK3

RK2

aktiv

aktiv

aktiv aktiv

passiv-kalt aktiv

aktiv

aktiv

aktiv

aktiv

aktiv

aktiv

passiv-kalt

aktiv aktiv

aktiv aktiv

passiv-kalt passiv-warm

passiv-warm passiv-heiss

passiv-kalt SWFB

Power Supply Unit 4

3.00e-06

4

3.00e-06

4

aktiv

RK4

Priorität 1

Priorität 3

Priorität 2

Priorität 4

Power Supply Unit 1

3.00e-07

1

Power Supply Unit 2

3.00e-07

2

Power Supply Unit 3

3.00e-07

3

Power Supply Unit 4

3.00e-07

4

Software LOA, ROA

SWLOA⁵

Software LOA, ROA

SWROA⁶

Software LIA, RIA

SW⁷LIA

Software LIA, RIA

SWRIA⁸ _{CPIOM 4}^1.00e-0512 CPIOM 3

1.00e-05

11

CPIOM 2 1.00e-05

10

CPIOM 1 1.00e-05

9

Hydraulic System 1 1.00e-05

13

Hydraulic System 2 1.00e-05

14

Hydraulic System 3 1.00e-05

15

Valve 4 1.00e-06

19

Valve 3 1.00e-06

18

Valve 2 1.00e-06

17

Valve 1 1.00e-06

16

Left Outer Actuator 2.00e-06

20

LOA

Left Inner Actuator 2.00e-06

21

LIA

Right Inner Actuator 2.00e-06

22

RIA

Right Outer Actuator 2.00e-06

23

ROA

BILD 6: Fehlerausbreitungs– und Rekonfigurationsprozesse innerhalb des Redundanzmangements Dementsprechend enth¨alt die Applikations–Software be-

stimmte Routinen, wie im Fehlerfall zu verfahren ist, da- mit Systemfunktionalit¨at gew¨ahrleistet werden kann. Die- se Maßnahmen werden auch im Rahmen der Visualisie- rung des Redundanzmangements ausgenutzt. Nach der Fehlerausbreitung und der Rekonfiguration ¨uber die Re- konfigurationsknotenpunkte werden deshalb die HCFSMs der Software–Applikationen hinsichtlich schaltbarer Tran- sitionen untersucht. Bild 6 zeigt den Schleifendurchlauf der Software–Fehlerbehandlung (SWFB) f¨ur Software–

Applikationen, der bei einer schaltbaren HCFSM unterbro- chen wird. In diesem Fall schließt sich eine Fehlerbehand- lung wie bei der Suche nach schaltbaren Bl¨ocken nicht

”ak- tiver“ Komponenten (FA2₁und FA2₂) sowie die Rekonfi- guration ¨uber die dar¨uber aufgenommenen Rekonfigurati- onsknotenpunkte an. Beendet wird die Schleife, wenn kei- ne HCFSM einer Software–Applikation schaltbar ist.

In seltenen F¨allen besteht dennoch die M¨oglichkeit, daß die bisher vorgestellten Maßnahmen nicht alle schalt- baren HCFSMs ber¨ucksichtigen. Dies bedingt, daß sich der Software–Schleife noch eine ¨Uberpr¨ufung s¨amtli- cher HCFSMs (KFB) entsprechend zugeh¨origer Block–

Identit¨at (Block–ID) anschließt. Wird in diesem Zusam- menhang eine HCFSM mit schaltbarer Transition lokali- siert, dann wird wie bei den zuvor vorgestellten Software–

Applikationen verfahren. Die ¨Uberpr¨ufung der HCFSMs ist genau dann abgeschlossen, wenn keine mehr schaltbar ist.

3.2 Redundanzmanagement Algorithmus

Eine Verkn¨upfung der vorgestellten Fehlerbehandlungs–

und Rekonfigurations–Prozesse zu einem gesamten Algo- rithmus erfolgt in diesem Unterkapitel.

Eine Eigenschaft dieses Algorithmus ist, daß immer nur ei- ne Komponente ¨uber einen RBD–Block als fehlerhaft de-

klariert werden kann. Das hat zur Konsequenz, daß die Ausfallwahrscheinlichkeit der Komponente auf Ft1 gesetzt wird und die unterliegende HCFSM in den Zustand

”isoliert“ ¨ubergeht. Eine Unterscheidung wird in diesem Rahmen zwischen den multifunktionalen Hardware– und Software–Bl¨ocken getroffen. Das Kriterium ist, daß bei den Hardware–Bl¨ocken ein Simultanausfall aller HCFSMs erfolgt und die Ausfallwahrscheinlichkeit der abgebilde- ten Komponente auf Ft1 gesetzt wird. Dem entgegen werden bei den Software–Bl¨ocken die HCFSMs einzeln als fehlerhaft deklariert.

Um bei den Fehlerausbreitungsprozessen die beiden Such- strategien nach Komponenten im Zustand

”aktiv“ und im Zustand nicht

”aktiv“ durchzuf¨uhren, wird ein Suchal- gorithmus aus der K¨unstlichen Intelligenz mit TIEFE–

ZUERST–SUCHE als Suchstrategie eingesetzt [4]. Dieser Such–Algorithmus bewegt sich sowohl im RBD–Modell, wo die logische Abh¨angigkeit benachbarter Komponenten ausgenutzt wird, als auch im HCFSM–Modell, dessen ak- tuelle Zust¨ande in Verbindung mit schaltbaren Transitio- nen als Orientierung im Rahmen der Suchstrategien ver- wandt werden.

Bild 7 zeigt die Bestandteile des Redundanzmanagement–

Algorithmus, dessen erste Abfragen sich auf fehlerhaft de- klarierte Komponenten sowie deren Nachbarkomponen- ten beziehen und testen, ob diese sich im Zustand

”aktiv“

oder nicht

”aktiv“ befinden. Auf Basis der Auswahl wird der entsprechende Fehlerausbreitungsprozeß angewandt, bei dem Rekonfigurationsoptionen ¨uber Rekonfigurations–

Knotenpunkte abgespeichert werden.

Anhand der Struktur in Bild 7 ist ersichtlich, daß der Al- gorithmus das Auftreten einer Komponente i mit unter- schiedlichen Block–IDs zul¨aßt. Dies unterst¨utzt eine wich- tige Eigenschaft der Zuverl¨assigkeitsanalyse auf Basis des RBD–Modells, wo im Rahmen der RBD–Modellierung

das mehrfache Auftreten einer Komponente i im Mo- dell zul¨assig ist, diese jedoch physikalisch in der Analyse nur als einmalig auftretend ber¨ucksichtigt wird. Eine Un- terscheidung identischer Komponenten findet ¨uber unter- schiedliche Block–IDs statt.

Die zu durchlaufenden Fehlerausbreitungen und Rekonfi- gurationen sind im Rahmen dieses Algorithmus erst dann beendet, wenn keine schaltbaren Transitionen mehr im Sy- stem verf¨ugbar sind und damit ein stabiler aber degradier- ter Systemzustand erreicht ist.

T r i t t d e r F e h l e r i n e i n e r S o f t w a r e - A p p l i k a t i o n a u f ?

F e h l e r i n K o m p o n e n t e i m i t d e r B l o c k - I D k

B e f i n d e t s i c h d i e H C F S M v o n K o m p o n e n t e i i m Z u s t a n d a k t i v? U N D

I s t m i n d e s t e n s j e e i n e H C F S M d e r l i n k s - u n d r e c h t s s e i t i g e n N a c h b a r k o m p o n e n t e n z u i i m Z u s t a n d a k t i v? B e f i n d e t s i c h m i n d e s t e n s e i n

H C F S M v o n K o m p o n e n t e i i m Z u s t a n d a k t i v?

U N D

I s t m i n d e s t e n s j e e i n e H C F S M d e r l i n k s - u n d r e c h t s s e i t i g e n N a c h b a r k o m p o n e n t e n z u i i m Z u s t a n d a k t i v?

F e h l e r b e h a n d l u n g - a k t i v F e h l e r a u s b r e i t u n g ( F A 11) h i n z u m S T A R T - B l o c k u n d S p e i c h e r u n g d e r R e k o n - f i g u r a t i o n s - K n o t e n p u n k t e ( R K ) F e h l e r a u s b r e i t u n g ( F A 1₂) h i n z u m E N D - B l o c k

R e k o n f i g u r a t i o n R e k o n f i g u r a t i o n ü b e r R e k o n - f i g u r a t i o n s - K n o t e n p u n k t e ( R K )

S t a b i l e r S y s t e m z u s t a n d

F e h l e r b e h a n d l u n g - n i c h t a k t i v F e h l e r a u s b r e i t u n g ( F A 21) h i n z u m S T A R T - B l o c k u n d S p e i c h e r u n g d e r R e k o n - f i g u r a t i o n s - K n o t e n p u n k t e ( R K ) F e h l e r a u s b r e i t u n g ( F A 2₂) h i n z u m E N D - B l o c k

F e h l e r a u s b r e i t u n g / R e k o n f i g u r a t i o n G i b t e s e i n e w e i t e r e K o m p o n e n t e i f ü r d e s s e n B l o c k - I D ¹ k g i l t ?

B e f i n d e t s i c h m i n d e s t e n s e i n e H C F S M v o n K o m p o n e n t e i m i t B l o c k - I D ¹ k i m Z u s t a n d a k t i v?

U N D

I s t m i n d e s t e n s j e e i n e H C F S M d e r l i n k s - u n d r e c h t s s e i t i g e n N a c h b a r k o m p o n e n t e n z u i m i t B l o c k - I D ¹ k i m Z u s t a n d a k t i v?

j a n e i n

j a n e i n

j a

j a

n e i n

n e i n

F e h l e r a u s b r e i t u n g / R e k o n f i g u r a t i o n d u r c h A n a l y s e a l l e r H C F S M s v o n S o f t w a r e - A p p l i k a t i o n e n ( S W F B )

j a n e i n

F e h l e r a u s b r e i t u n g / R e k o n f i g u r a t i o n d u r c h A n a l y s e a l l e r H C F S M s v o n R B D - B l ö c k e n ( K F B )

BILD 7: Redundanzmanagement–Algorithmus

4 SYNTHESE UND ANALYSE

Der Entwurf fehlertoleranter Flugzeug–Systemarchitekturen mit diesem Software–Tool st¨utzt sich auf die Synthese und Analyse des Systems im fehlerfreien Nominalzustand und in degradierten Systemzust¨anden. Beispielhaft wird hierzu die Modellierung und Analyse der H¨ohenrudersteuerung eines Verkehrsflugzeugs auf RBD– und HCFSM–Ebene vorgestellt. Bei diesem System handelt es sich um ein si- cherheitskritisches System der prim¨aren Flugsteuerung;

ein unsymmetrischer Ausschlag großer Amplitude von

Aktuatoren der linken und rechten Ruderseite ist nach JAR 25 als

”Catastrophic“ zu klassifizieren und der Feh- ler mit der entsprechenden Eintrittswahrscheinlichkeit von maximal F10 ⁹pro Flugstunde verbunden [3]. Eine un- symmetrische Ansteuerung der Aktuatoren f¨uhrt zu einem Torsionsmoment auf die Flugzeugzelle, was in Konse- quenz fatale Folgen f¨ur das Flugzeug und dessen Insassen haben kann.

4.1 Synthese und Analyse des RBD–Modells

Ausgangspunkt des Systementwurfs bildet das TOP

EVENT auf dessen Basis die Modellierung und Analyse erfolgt. F¨ur die H¨ohenrudersteuerung lautet es:

”Symmetrische Funktionsf¨ahigkeit der fehlertoleranten H¨ohenrudersteuerung eines Verkehrsflugzeugs“.

Bild 6 zeigt das RBD bez¨uglich der Definition des TOP

EVENTS, in dem voneinander abh¨angige Komponenten des Systems durch logische Verkn¨upfung RBD–Bl¨ocke ab- gebildet sind. Jedem RBD–Block wird in diesem Zusam- menhang eine Ausfallrate λ zugeordnet. Ausgenommen davon sind jedoch die Software–Bl¨ockeK₅K₈ , de- nen nur die Wahrscheinlichkeitenfunktionsf¨ahigF0 undausgefallen F1zugeordnet werden k¨onnen. An die Funktionalit¨at des Systems ist bei diesem Beispiel der Symmetriebetrieb der linken und rechten Ruderseite ¨uber eine sogenannte n–von–m Bedingung gekn¨upft [1]. Die Eingabe erfolgt ¨uber logische Nebenbedingungen (22) in der RBD–Modellierung und wird in der Analyse entspre- chend ber¨ucksichtigt [6]

Γ K₂₀K₂₂K₂₀K₂₃ (22)

K₂₁K₂₂K₂₁K₂₃

Zur Zuverl¨assigkeitsanalyse des fehlerfreien Nominalsy- stems wird der sogenannte CAOS Orthogonalisierungs–

Algorithmus auf das RBD–Modell des Systems ange- wandt [6]. Die Wahrscheinlichkeit, daß in diesem In- itialzustand ein Systemausfall in einer Flugstunde ein- tritt betr¨agt F1h66010 ¹¹ und erf¨ullt damit die Zuverl¨assigkeitsanforderungen. Er handelt sich bei der Ausfallwahrscheinlichkeit um eine konservative Berech- nung, da die redundanten Komponenten ausschließlich als

”aktiv–heiss“ betrachtet werden.

4.2 Synthese und Analyse des HCFSMs–Modells Aufbauend auf der in verschiedenen Industriean- wendungen schon bew¨ahrte zuverl¨assigkeitstechnische Modellierungs– und Analyseumgebung von SYRE-

LANTM, wird die neuartige Erweiterung des Software–

Tools hinsichtlich der Visualisierung des Redundanzma- nagements am Beispiel H¨ohenrudersteuerung aus Bild 6 vorgestellt.

Ausgangpunkt bildet das RBD–Modell, in dem jeder ein- zelnen Komponente ein bzw. mehrere HCFSMs zugeord- net werden. Die Mehrfachzuordnung von HCFSMs erfolgt in diesem Beispiel bei den multifunktionalen Software–

Bl¨ocken. In Bild 8 ist der BLOCKEDITORder erweiterten SYRELANTM Version abgebildet, in dem ¨uber die TY-

PE–Option die Eigenschaft eines Software–Blocks K₇aus- gew¨ahlt wurde.