Mobile-Menu

Systemarchitekturen für sicherheitskritische Systeme

Seite: 4/4

Zweikanal-Architekturen

Bei sicherheitskritischen Systemen ohne unmittelbar sicheren Zustand lässt sich der Systembetrieb mithilfe von Zweikanal-Architekturen aufrechterhalten, auch wenn ein Kanal aufgrund eines Fail-Stop anhält. Abbildung 9 zeigt eine Zweikanal-Architektur; jeder Kanal basiert auf der Einkanal-Architektur aus Abbildung 8.

Der zweite Kanal dient als Standby- oder Backup-Kanal, der den Systembetrieb übernehmen kann, wenn im aktuellen Primärkanal Fehler oder Störungen auftreten.

Bildergalerie
Bildergalerie mit 10 Bildern

Je nach Anforderung des sicherheitskritischen Systems kann der Standby-Kanal den normalen Systembetrieb weiterführen, wenn er aktiv wird. Oder er überführt das System letztlich in einen sicheren Zustand, nachdem eine möglicherweise lange und komplexe Abfolge von Schritten durchlaufen wurde.

Hier ein Beispiel: Eine Herz-Lungen-Maschine in einem OP muss lebenserhaltende Dienste weiter erbringen, auch wenn einer ihrer internen Embedded-Verarbeitungskanäle ausfällt. Die Steuerung eines Kernreaktors müsste bei einem solchen Ausfall dagegen noch lange genug weiterlaufen, um den Reaktor mithilfe einer längeren Aktivitätenabfolge herunterfahren zu können: Graphitstäbe schrittweise und vollständig in die Tiefe des Reaktorkerns absenken, gleichzeitig den Kühlflüssigkeitsfluss im Reaktor beschleunigen und die allmähliche Verlangsamung der Kernreaktion über unzählige Sensoren überwachen – so lange, bis der Reaktor für den Eingriff durch das Bedienpersonal freigegeben werden kann.

Eine Zweikanal-Architektur verursacht höhere Systemkosten als die zuvor beleuchteten Architekturen. Sie beinhaltet redundante Embedded-Verarbeitungskanäle mit redundanter Hardware sowie redundante Sensoren. Der große Vorteil dieser Architektur ist aber, dass der Betrieb im Fehlerfall weitergeführt werden kann.

Zweikanal-Architekturen werden in verschiedenen Varianten verwendet. Wenn die zwei Kanäle in Abbildung 9 dieselbe replizierte Software und Hardware verwenden, kann die Architektur zufällige Fehler gut behandeln, nicht jedoch systematische Fehler aus dem Softwareentwurf oder der Programmierung. Diese würden in beiden Kanälen reproduziert. Wenn dieser Aspekt in Ihrem System eine Rolle spielt, wäre eine heterogene Zweikanal-Architektur bestehend aus zwei Kanälen, die völlig unterschiedlich implementiert wurden, geeigneter. Die Software für die beiden Kanäle könnte beispielsweise von zwei separaten Entwicklungsteams kommen und auf der gleichen Software-Anforderungsspezifikation basieren. Dieses Vorgehen nennt man auch N-Version-Programming bzw. „Dissimilar Software” (diversitäre Software). Die damit verbundenen Entwicklungs- und Materialkosten wären natürlich sehr hoch.

Eine weitere Variante ist die Mehrkanal-Voting-Architektur. Dabei wird das Verfahren der Triple-Modular-Redundanz (TMR), wie sie im Kontext der Sensorfehlererkennung besprochen wurde, auf replizierte Verarbeitungskanäle ausgeweitet. In dieser Architektur gibt es drei (oder mehr) parallel laufende Kanäle. Ein „Voter“ vergleicht die Werte aus diesen Kanälen. Stimmt bei der Mehrheit ein Ausgangswert überein, reicht der Voter diesen als Ausgangwert für das System weiter. Wenn jedoch mehrere Kanäle nicht übereinstimmen, werden sie per Fail-Stop angehalten.

Ein Beispiel für eine Mehrkanal-Architektur in Anwendungen der Luftfahrt ist die Dual-Dual-Redundanz. Vier unabhängige Verarbeitungskanäle sind als zwei Paare mit je zwei Kanälen angeordnet. Ein Paar ist jeweils aktiv, und seine beiden Kanäle gleichen kontinuierlich die Ergebnisse ab. Solange die Kanäle übereinstimmen, bleibt das Paar aktiv. Andernfalls übertragen sie die Steuerung sofort an das andere Paar, welches dann aktiv wird.

Monitor-Aktor-Architektur

Viele sicherheitskritische Systeme haben keinen unmittelbar sicheren Zustand, führen jedoch aufgrund einer Zweikanal- bzw. Mehrkanal-Architektur zu hohen Kosten. Eine kostengünstigere Lösung ist die in Abbildung 10 dargestellte Monitor-Aktor-Architektur.

In dieser Architektur gibt es keine replizierten, identischen Kanäle, sondern heterogene Kanäle, die sich voneinander unterscheiden. Es gibt nur einen primären Aktor-Kanal, der das System normalerweise steuert (oberer Bereich in Abbildung 10). Der Betrieb und die Ergebnisse dieses Kanals werden von einem separaten, einfacheren Monitoring-Kanal untersucht (mittlere Ebene im Bild). Wenn der Monitoring-Kanal einen Fehler im Aktor-Kanal entdeckt, kann dieser nicht normal weiterlaufen, und die Steuerung des Systems wird einem separaten Sicherheitskanal übertragen (unten im Bild). Dieser muss veranlassen, dass das System in einen sicheren Zustand gebracht wird. Je nach Anforderung des sicherheitskritischen Systems führt er es dazu durch eine möglicherweise lange und komplexe Abfolge von Schritten.

Die Monitor-Aktor-Architektur bietet sich als sinnvolle und kostengünstige Alternative für Applikationen wie z.B. die Steuerung chemischer Prozesse oder elektrische Fensterheber im Auto oder auch für Applikationen an, bei denen eine sanfte Leistungsminderung von Funktionen möglich und sinnvoll ist, z.B. Brake-By-Wire-Systeme. Die sanfte Leistungsminderung der Systemfunktion kann dabei im Sicherheitskanal implementiert werden.

Resümee

Die Auswahl einer Architektur für ein sicherheitskritisches System sollte nicht nur auf der herkömmlichen Systemanforderungsdefinition basieren, sondern auch auf einer gründlichen Gefährdungsanalyse mit anschließender Risikoanalyse. Beim Systementwurf können Kombinationen aus redundanten Sensorkonfigurationen, Shutdown-Systemen, Aktor-Monitoring, Mehrkanal-Architekturen und/oder Monitor-Aktor-Strukturen zum Einsatz kommen. Solche Embedded-Systemarchitekturen sind quasi unbezahlbar – ihr wahrer Wert liegt darin, dass sie Menschenleben schützen.

* David Kalinsky ist Berater, Trainer und Dozent für Echtzeit- und Embedded-Programmierung in Sunnyvale/Kalifornien (USA)

(ID:44853387)

Weiterführende Inhalte