Safety Manuals - Problem und Lösung gleichermaßen

Functional Safety Manuals sind ein unverzichtbarer Bestandteil der Sicherheitstechnologien für Prozessoren und Controller. Sie werden jedoch oft als kompliziert und missverstanden angesehen, was bei den Kunden auf Ablehnung stößt. Safety-Handbücher enthalten wichtige Informationen und Annahmen, die notwendig sind, um die Sicherheit der Systeme zu gewährleisten. Dieser Artikel beleuchtet die wesentlichen Inhalte solcher Manuals und behauptet, dass weder autorisierte Stellen noch Hersteller und Inverkehrbringer genau verstehen, was gefordert wird.

Diagnosedeckungsgrad (Diagnostic Coverage, DC)

Der Diagnosedeckungsgrad ist ein zentraler Begriff in der Sicherheitsnormung. Er misst die Wirksamkeit der Diagnosemaßnahmen, also die Fähigkeit von Selbsttest- und Überwachungsmaßnahmen, Fehler in einer Steuerung zu erkennen. Der Diagnosedeckungsgrad bezieht sich auf Bauelemente, einzelne Funktionsblöcke oder die gesamte Steuerung und wird bestimmt durch das Verhältnis der Summe der Ausfallraten der erkennbaren gefährlichen Ausfälle zur Summe der Ausfallraten aller gefährlichen Ausfälle. Ein hoher DC-Wert zeigt an, dass die Diagnosemaßnahmen effektiv sind und viele potenzielle Gefahren rechtzeitig erkannt werden können. Die funktionale Sicherheit von Prozessoren und Controllern wird durch verschiedene Sicherheitsnormen bewertet, darunter IEC 61508 und ISO 26262. Diese Normen definieren unterschiedliche Sicherheitsintegritätslevel (Safety Integrity Levels, SIL) und Automobil-Sicherheitsintegritätslevel (Automotive Safety Integrity Levels, ASIL), die auf die erforderliche Integrität und Zuverlässigkeit der Systeme abzielen. Ein zentraler Aspekt dieser Bewertung ist die Diagnosedeckungsgrad (Diagnostic Coverage, DC), der die Wirksamkeit der Diagnosemaßnahmen in einem System misst.

Die Anforderungen an den Diagnosedeckungsgrad variieren je nach dem angestrebten SIL- oder ASIL-Level. Höhere Sicherheitslevel erfordern eine höhere Diagnosedeckung, um sicherzustellen, dass potenziell gefährliche Fehler erkannt und behoben werden können, bevor sie zu einem Systemausfall führen. ISO 26262 schlägt spezifische Metriken für Einzelpunktfehler (Single Point Faults), latente Fehler (Latent Faults) und eine probabilistische Metrik für Hardwarefehler (PMHF, Probabilistic Metric of Hardware Failure) vor, die als Fehlerhäufigkeit (Failure in Time, FIT) bekannt ist. Die folgende Tabelle zeigen die vorgeschlagenen Zielwerte:

Safety und System Assumptions

Functional Safety Manuals enthalten oft eine Reihe von grundlegenden Annahmen, die als Basis für die Sicherheitsbewertung und -implementierung dienen. Diese Annahmen betreffen sowohl die Konfiguration des Systems als auch die Anforderungen an die Stromversorgung, die Überwachungseinrichtungen und die Diagnoseprozesse. Hierzu gehört unter anderem, dass der Systemintegrator alle Anforderungen des Geräte-Datenblatts befolgt, die Systeme so konfiguriert werden, dass sie den ordnungsgemäßen Betriebszustand aufrechterhalten können, und die Software in der Lage ist, Fehler zu erkennen und das System in einen sicheren Zustand zu versetzen, falls eine Fehlerbehebung nicht möglich ist. Zusätzlich müssen die Stromversorgung und Überwachungseinheiten so konfiguriert sein, dass sie die Funktionalität und Sicherheit des Systems gewährleisten können.

Ein weiterer wichtiger Punkt ist die Integration der empfohlenen Diagnosen aus dem Safety Analysis Report und dem Safety Manual in das System des Integrators. Die Software muss kontinuierliche, periodische und Test-Diagnosen gemäß dem Sicherheitskonzept des Systems initialisieren, und die Stromversorgung muss den Gerätevorgaben entsprechen und überwacht werden. Außerdem muss die Verfügbarkeit der Systemfunktionen durch externe Überwachungseinheiten sichergestellt werden, die beispielsweise über einen Watchdog realisiert werden kann.

Hersteller- und Drittparteianforderungen

Hersteller entwickeln Prozessoren und Controller in der Regel als Safety Element Out of Context (SEooC) und gemäß den relevanten Anforderungen der IEC 61508:2010. Diese Produkte werden von zertifizierten Drittparteien sicherheitsbewertet und enthalten zahlreiche Funktionen zur Unterstützung der Interferenzfreiheit (Freedom From Interference, FFI) für unterschiedliche Sicherheitsanforderungen der verschiedenen Unterelemente. Zur Erreichung der Diagnostic Coverage definieren Hersteller in der Regel konkrete Maßnahmen. Dazu gehören detaillierte Anweisungen zur Implementierung von Diagnoseverfahren und zur Überwachung kritischer Systemkomponenten. 

Konkret sind das klare Anforderungen an die Inverkehrbringer, also eine Vielzahl von Sicherheitsmechanismen, häufig unterteilt in verschiedene Kategorien:

• Hardware Safety Mechanisms: diagnostische Mechanismen, wie sie ins Silizium integriert sind, z.B. OV/UV Protection oder Monitoring-IPs
• Software Safety Mechanisms: empfohlene Tests, die von Entwicklern erstellt werden müssen. Die Ausfallmodi der in dieser Diagnose verwendeten Software werden nicht in der Sicherheitsanalyse oder FMEDA abgedeckt.
• System Safety Mechanisms: extern zum Gerät implementierte Hardware-Maßnahmen, beispielsweise durch ein externes Überwachungs-IC, das als Sicherheitsmechanismus fungiert
• Test for Diagnostics: Tests und Testfunktionen, die Abdeckung für Fehler in einem diagnostischen Mechanismus bieten

Das folgende Beispiel zeigt einen notwendigen Mapnahmenkatalog für ein Peripherie-Modul eines Prozessors aus dem Safety-Manual eines Herstellers. Die Maßnahmen in diesem Fall sichern die Diagnostic Coverage für den Vectored Interrupt Manager. Der Vectored Interrupt Manager übrigens aggrigiert die Interrupts für einen MCU und wertet die Interrupts nach Herkunft und Priorität aus. Die Maßnahmen sind ferner in Gruppen unterteilt (links), die in diesem Falle 90% oder 99% Diagnostic Coverage sichern. Rechts sind die Maßnahmen mehr oder weniger konkret definiert, die ein Hersteller software- oder hardwareseitig zu erfüllen hat.

 

Auszüge aus einem Hersteller-Functional Safety Manual für einen SIL2-Multicore-SoC

Problematische Umsetzung

In der heutigen Praxis der funktionalen Sicherheit dominieren Validations- und Verifikationsmaßnahmen basierend auf selbst gesteckten vor allem funktionalen Anforderungen. Dies führt oft zu einer Fokussierung auf verhältnismäßig nebensächliche Kennzahlen wie Fit-Rates, die im systemischen Kontext eine untergeordnete Rolle spielen. Dabei sollten Hersteller-Safety-Manuals prinzipiell ins Zentrum der Entwicklungsprozesse gerückt werden, da sie umfassende und spezifische Richtlinien bieten, um die Sicherheit von Prozessoren und Controllern zu gewährleisten. Das führt unweigerlich zu Problemen in der Anwendung der Functional Safety Manuals, die wie folgt begründet sind:

Unverständnis und Over-Engineering: Einerseits verstehen Anwender die Vielzahl der vorgeschlagenen Maßnahmen nicht vollständig, andererseits werden die eigentlichen Sicherheitsanforderungen als Over-Engineering missvertanden. 

Fehlende Kenntnisse über Prozessor- und Controller-Architekturen: Besonders im Bereich der Structural Core Tests für ALU, LSU, DAP, NVIC und ähnliche Komponenten mangelt es häufig an Verständnis der zugrunde liegenden Architektur. Ohne detailliertes Wissen über ARM-Architekturen können die vorgeschlagenen Maßnahmen nicht umgesetzt werden. Dies führt dazu, dass potenziell kritische Sicherheitsmaßnahmen schlichtweg ignoriert werden.

Mangel an umfassenden Selbsttest- und Diagnose-Tools: Während einige Hersteller von Single-Core-Controllern, wie NXP oder ST, Libraries für die Analyse von sporadischen und latenten Fehlern im Prozessorkern bereitstellen, fehlt es insbesondere im Multicore-Bereich an ausreichender Unterstützung. Oftmals werden diese Aufgaben an Drittanbieter ausgelagert, was die Konsistenz und Integration solcher Tools erschwert. ARM bietet zwar Software Test Libraries (STL) für General-Purpose-Controller an, jedoch sind spezialisierte Controller häufig auf eigene Libraries, die entweder fehlen oder nicht den gleichen Support erhalten.

Die tatsächliche Praxis: Konkret finden Safety Manuals in SIL-Bewertungen durch den Insprection/Certified Body kaum Anwendung. Assessoren und Auditoren sind in der Regel aus dem prozessualen kommend und verstehen die Safety-Maßnahmen in den meisten Fällen ebenfalls nicht. Glück gehabt sagt der Hersteller. Das Nachsehen hat der Verbraucher.

Zusammenfassung

Diese Herausforderungen verdeutlichen, dass ein Paradigmenwechsel notwendig ist. Hersteller-Safety-Manuals sollten nicht nur als begleitende Dokumentation, sondern als zentrale Leitlinien in den Entwicklungsprozessen angesehen werden. Entwickler und Systemintegratoren müssen besser geschult werden, um die Architekturen und die vorgeschlagenen Sicherheitsmechanismen zu verstehen und effektiv umzusetzen. Zudem muss die Industrie verstärkt in die Entwicklung und Bereitstellung umfassender Selbsttest- und Diagnose-Tools investieren, insbesondere für Multicore-Systeme. Hier sind insbesondere Hersteller gefragt, die bereit sein müssen, gezielten Design-In-Support zu leisten - in Form von Beratung und Software-Examples.