Startseite > Embedded > Hardware > Funktionale Sicherheit in verteilten Embedded-Systemen

PES

Funktionale Sicherheit in verteilten Embedded-Systemen

8. Juli 2013, 9:29 Uhr | Olaf Winne

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Systematische Fehler entdecken und vermeiden

Zur Vermeidung und Entdeckung systematischer Fehler in der Design- und der Realisierungsphase verteilter Sicherheitsfunktionen werden erweiterte Vorgehensmodelle benötigt, um die Fehlerquellen der Synchronisation und Kommunikation der PE-Komponenten ausreichend zu berücksichtigen. So soll sichergestellt werden, dass Fehlermodelle, die durch eine Verteilung entstehen, nicht zum Versagen einer Sicherheitsfunktion führen. Dafür wird z.B. in der ISO 26262 auf das Thema der Integration verschiedener PE-Komponenten besonders eingegangen (ISO 26262-4, Chapter 8, Item integration and testing) und es werden diverse Maßnahmen gefordert (ISO 26262-4, Tabelle 4-19, z.B. vollständiger Test externer und interner Schnittstellen, Kommunikation, Fehlerfälle, Ressourcennutzung, Stress- und Langzeittests). Abgebildet werden diese Prozesse im doppelten V-Modell (Bild 3), wobei das untere V-Modell weitestgehend der IEC 61508 entspricht und auf eine einzelne PE-Komponente angewendet wird. Das obere V-Modell behandelt die Integration und die Gesamtvalidierung der verteilten Sicherheitsfunktion.

Die Sicherheitsanforderungen müssen über das gesamte Vorgehensmodell rückverfolgbar sein (Traceability), was beim doppelten V-Modell eine durchdachte Methodik erfordert.

Fehlerbeherrschung in der Kommunikation

Damit PE-Komponenten zusammen Funktionen ausführen können, müssen Daten ausgetauscht werden. Normen, z.B. die EN 60730, klassifizieren Daten (Tabelle 1) und fordern eine zuverlässige Übertragung sicherheitsrelevanter Daten.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Daten	sicherheitsrelevant(Auflistung nicht erschöpfend)	nicht sicherheitsrelevant (Auflistung nicht erschöpfend)
Betriebsdaten	Nachrichten, z.B. »Wiederherstellung aufgrund Störabschaltung«	Nachrichten, z.B. AN/AUS-Befehl, Information zur Raumtemperatur
Konfigurationsparameter	Modifikationsnachrichten von Parametern zur Bestimmung sicherheitsrelevanter Funktionen	Modifikationsnachrichten von Parametern zur Bestimmung nicht sicherheitsrelevanter Funktionen
Software-Module	Geladene Systemmodule zur Bestimmung sicherheitsrelevanter Funktionen	Geladene Systemmodule zur Bestimmung nicht sicherheitsrelevanter Funktionen

Tabelle 1. Klassifikation von Daten.

Datenverfälschung darf nicht zu einem unsicheren Zustand führen. Fehlerzustände wie permanentes oder wiederholtes Senden von Nachrichten, aber auch eine Unterbrechung der Datenübertragung (Kommunikationsausfall) müssen zusätzlich beachtet werden. Weiterhin ist die zeitliche Gültigkeit eines Datums entscheidend, insbesondere wenn es sich um echtzeitkritische Informationen handelt, z.B. Sicherheits-Eingang. Mögliche Maßnahmen zur Erkennung definierter Kommunikationsfehler sind in der IEC 61784-3, EN 60730 sowie EN 50159-2 definiert und können in einem Sicherheitsprotokoll implementiert werden (Tabelle 2).

Fehler	Laufende Nummer	Zeit-stempel	Zeitüber-schreitung	Feedback-Nachricht	Quell-Ziel-Erkennung	Identifikations-maßnahmen	Redundanz mit Kreuzvergleich	Kryptographische Techniken
Wiederholung einer Nachricht	x	x					x
Datenverlust einer Nachricht	x			x			x
Datenzuwachs einer Nachricht	x			x	x	x	x
Geänderte Datenabfolge	x	x					x
Verfälschte Daten einer Nachricht							nur für serielle Busse	x
Sende-/Empfangsverzögerung		x	x
Maskierung				x		x		x

Tabelle 2. Maßnahmenkatalog für Kommunikationsfehler.

Je Kommunikationsfehler ist mindestens eine adäquate Maßnahme erforderlich. Die Implementierung dieser Maßnahmen erfolgt in einer Sicherheitskommunikationsschicht, welche sich entweder in einer höheren Protokollschicht oder in der physikalischen Schicht der sicheren Kommunikationsschnittstelle realisieren lässt (White- oder Black-Channel, IEC 61784). Applikationsabhängige inkonsistente Maßnahmen, z.B. funktionsabhängige Zeitüberschreitungen, lassen sich ggf. auch in der Applikation flexibel implementieren.