Funktionale Sicherheit (SIL): STM32 Self-Test Libraries für Entwickler

Funktionale Sicherheit (SIL): STM32 Self-Test Libraries für Entwickler ist ein Thema, das spätestens dann relevant wird, wenn ein Embedded-System nicht nur „zuverlässig“ sein soll, sondern nachweisbar sicher funktionieren muss. In Industrieantrieben, Prozessautomation, Robotik, Energieverteilung oder sicherheitsrelevanten Steuerungen geht es nicht allein um Verfügbarkeit, sondern um das kontrollierte Verhalten bei Fehlern: Erkennt das Gerät zufällige Hardwarefehler rechtzeitig? Geht es in einen sicheren Zustand, bevor ein gefährlicher Zustand entstehen kann? Genau hier setzen Normen wie IEC 61508 an und definieren, wie Safety Integrity Levels (SIL) erreicht und belegt werden. Für STM32-Entwickler stellt sich die praktische Frage: Wie integriere ich Diagnosemechanismen für CPU, Flash, SRAM, Takt- und Peripheriepfade, ohne alles selbst von Grund auf zu entwickeln und ohne das Projekt mit schwer auditierbarer Eigenlogik aufzublähen? STMicroelectronics bietet dafür fertige Sicherheitsdokumentation und Self-Test Libraries an – etwa die X-CUBE-STL Library für IEC 61508-orientierte Systeme sowie ergänzende Pakete für IEC 60730/60335 Class B. Dieser Beitrag erklärt, wie diese Bibliotheken einzuordnen sind, welche Tests typischerweise enthalten sind, wie man sie in Startup- und Laufzeittests integriert und welche „Conditions of Use“ in Safety-Projekten zwingend beachtet werden müssen.

Grundlagen: Was bedeutet SIL in der funktionalen Sicherheit?

Safety Integrity Level (SIL) beschreibt das erforderliche Maß an Risikoreduktion durch eine Sicherheitsfunktion. In der IEC 61508 werden Anforderungen an Entwicklungsprozess, Hardware- und Softwarearchitektur, Diagnoseabdeckung sowie Nachweisführung definiert. Wichtig ist die Unterscheidung zwischen:

• Systematischer Sicherheit: Fehler durch Spezifikation, Design, Implementierung oder Prozess (z. B. falsch verstandene Anforderungen).
• Zufälligen Hardwarefehlern: Ausfälle aufgrund von Alterung, kosmischer Strahlung, Fertigungsstreuung oder Umwelteinflüssen.

Self-Tests adressieren vor allem zufällige Hardwarefehler, indem sie kritische Komponenten prüfen und Fehler früh erkennen. ST positioniert die X-CUBE-STL ausdrücklich als softwarebasierte Diagnosesuite zur Erkennung zufälliger Hardwarefehler in Kernkomponenten wie CPU, SRAM und Flash und ordnet sie in den IEC 61508-Kontext ein. X-CUBE-STL Functional Safety Package

Was sind STM32 Self-Test Libraries und wofür werden sie genutzt?

Unter „Self-Test Libraries“ versteht man wiederverwendbare Softwaremodule, die standardisierte Diagnosetests implementieren. Der Vorteil: Die Tests sind in vielen Fällen bereits nach einem sicherheitsorientierten Entwicklungsprozess erstellt, dokumentiert und mit definierten Integrationsregeln versehen. ST beschreibt die X-CUBE-STL Library als compilerunabhängig und als Objektcode ausgeliefert sowie als nach IEC 61508-Prozess (bis SC3) entwickelt; zudem wird sie als durch TÜV Rheinland zertifiziert dargestellt. Produktbeschreibung X-CUBE-STL mit Safety- und Zertifizierungsangaben

Wichtig ist dabei: Eine Bibliothek „liefert“ nicht automatisch eine SIL-Zertifizierung für Ihr Endprodukt. Sie kann jedoch die Implementierung und den Nachweis der Diagnosemechanismen deutlich beschleunigen – sofern Sie die geforderten Integrationsbedingungen („Conditions of Use“) einhalten und Ihre Systemarchitektur normgerecht begründen.

ST Safety-Ökosystem: X-CUBE-STL, Safety Manuals und ergänzende Pakete

ST bündelt funktionale Sicherheitsunterstützung in einem Ökosystem aus Dokumentation und Software. Ein zentraler Einstieg ist die Functional-Safety-Übersichtsseite, die X-CUBE-STL Self-Test Libraries und umfangreiche Safety-Dokumentation für viele STM32-Geräte nennt. STM8 & STM32 Functional Safety Überblick

Zu den typischen Bestandteilen zählen:

• Safety Manuals: beschreiben Nutzerpflichten, Annahmen, Integrationsregeln und Systemanforderungen, um ein Ziel-SIL zu erreichen. Für STM32H7 existieren beispielsweise Safety Manuals, die in Übereinstimmung mit IEC 61508 erstellt sind. STM32H7 Single-Core Safety Manual (IEC 61508)
• FMEA/FM(E)DA-Informationen: ST erwähnt für X-CUBE-STL u. a. MCU-FMEA und eine FMEDA-Snapshot-Darstellung, um Ausfallarten und Diagnosen strukturiert zu bewerten. X-CUBE-STL Features: FMEA/FMEDA Snapshot
• Self-Test Library (X-CUBE-STL): Diagnosemodule für generische MCU-Komponenten (CPU, Flash, SRAM) zur Erkennung zufälliger Hardwarefehler. X-CUBE-STL Library-Umfang

Ergänzend gibt es Pakete für „Class B“-Anforderungen aus Haushalts-/Consumer-nahen Normen (IEC 60730/60335). ST führt hierfür X-CUBE-CLASSB als Functional Safety Package mit Self-Test Libraries und Integrationsbeispielen an. X-CUBE-CLASSB Package

Welche Sicherheitsziele lassen sich mit STM32 und X-CUBE-STL adressieren?

In der Praxis wird häufig gefragt, ob ein einzelner Mikrocontroller für höhere SIL-Level genügt. ST beschreibt für X-CUBE-STL, dass SIL2-Sicherheitsfunktionen mit einem einzelnen STM32 implementiert werden können, während für SIL3 eine 1oo2-Architektur (one out of two) mit zwei STM32 genannt wird. X-CUBE-STL: SIL2 mit 1 MCU, SIL3 mit 1oo2

Für Entwickler heißt das: Die Bibliothek ist ein Baustein, aber die Systemarchitektur muss zu den Zielanforderungen passen. Wenn SIL3 gefordert ist, rücken Redundanz, unabhängige Pfade, Fehlerreaktion und Diagnoseabdeckung deutlich stärker in den Vordergrund.

Typische Selbsttests: Was wird geprüft und warum?

Self-Test Libraries setzen meist bei generischen, sicherheitskritischen Grundfunktionen an – unabhängig von Ihrer konkreten Anwendung. Typische Testklassen sind:

• CPU-Tests: Registertests, ALU-/Instruction-Path-Checks, ggf. Control-Flow-Integrität (je nach Bibliotheksumfang).
• SRAM-Tests: March-Algorithmen oder Varianten, um Stuck-At-Fehler, Kopplungsfehler und Adressierungsprobleme zu erkennen.
• Flash-Tests: CRC/Signature-Checks, um Code-Integrität und Speicherfehler zu erkennen.
• Clock- und Taktüberwachung: Erkennung von Taktfehlern (zu schnell/zu langsam/ausfallend), da Zeitbasis oft sicherheitskritisch ist.
• Stack-/Programmfluss-Checks: Überwachung von Stack-Überlauf oder „unplausiblen“ Sprüngen (konzeptabhängig).

Bei Class-B-orientierten Libraries verweist ST in User Guides darauf, dass die Module aus strengeren IEC-61508-orientierten Tests abgeleitet sein können und für IEC 60730 angepasst werden. Ein Beispiel ist die STM32H7-User-Guide-Beschreibung, wonach Module aus IEC 61508-Entwicklungen abgeleitet und für IEC 60730 ausgerichtet wurden. STM32H7 IEC 60730/60335 Self-Test Library User Guide

Startup-Tests vs. Laufzeittests: Wie man Diagnose sinnvoll verteilt

Ein robustes Safety-Design kombiniert in der Regel zwei Diagnosestrategien:

• Power-on/Startup Self-Tests: Prüfen zentrale Komponenten vor dem Start der sicherheitsrelevanten Anwendung. Ziel ist, mit „bekannt gutem“ Zustand zu starten.
• Periodische Laufzeittests: Prüfen Komponenten während des Betriebs in definierten Intervallen, um Fehler zu erkennen, die erst später auftreten.

Die Kunst besteht darin, Laufzeittests so zu integrieren, dass Echtzeitanforderungen und Safety-Anforderungen gleichzeitig erfüllt werden. Häufig wird RAM in kleinen Segmenten über mehrere Zyklen geprüft (Time Slicing), während Flash-Integrität z. B. über blockweise CRC-Prüfung in Wartungsfenstern erfolgt.

Diagnoseabdeckung und FMEDA: Warum Zahlen nicht „nice to have“ sind

Für IEC 61508-Argumentationen spielt die diagnostische Abdeckung (Diagnostic Coverage, DC) eine zentrale Rolle. Vereinfacht betrachtet beschreibt DC, welcher Anteil gefährlicher, unentdeckter Fehler durch Diagnosemechanismen erkannt wird. In Projekten wird das häufig über FMEDA (Failure Modes, Effects and Diagnostic Analysis) nachvollzogen. ST nennt im X-CUBE-STL-Kontext eine FMEDA-Snapshot-Darstellung sowie FMEA-Informationen als Bestandteil des Pakets. X-CUBE-STL: MCU FMEA und FMEDA Snapshot

Als vereinfachte Denkstütze kann DC so formuliert werden, dass sie den Anteil der durch Diagnose erkannten gefährlichen Ausfälle ausdrückt. Eine häufig verwendete, vereinfachte Beziehung lautet:

$\mathrm{DC}=1–\frac{{\lambda }_{\mathrm{DU}}}{{\lambda }_D}$

Dabei steht λDU vereinfacht für die Rate gefährlicher, unentdeckter Ausfälle und λD für die Rate gefährlicher Ausfälle insgesamt. In realen Nachweisen sind Definitionen, Kategorien und Annahmen deutlich detaillierter, doch die Grundidee bleibt: Ohne nachvollziehbare Diagnosen wird ein SIL-Nachweis schnell schwierig.

Integration in STM32-Projekte: Praktische Vorgehensweise für Entwicklerteams

Damit Self-Test Libraries in der Entwicklung wirklich helfen, sollten Sie Integration, Build- und Teststrategie früh festlegen. Bewährt hat sich ein Ablauf in klaren Schritten:

• Safety-Anforderungen ableiten: Sicherheitsfunktionen, Safe State, Diagnoseintervalle, Reaktionszeiten definieren.
• Bibliothek passend zur Norm wählen: IEC 61508-orientiert (z. B. X-CUBE-STL) oder Class B (z. B. X-CUBE-CLASSB) – abhängig vom Produktziel. X-CUBE-STL / X-CUBE-CLASSB
• Conditions of Use umsetzen: Safety Manuals enthalten „Pflichten“ des Anwenders (z. B. Konfiguration, Taktüberwachung, Handling von Fehlerflags). Für STM32H7 wird explizit beschrieben, dass das Safety Manual Nutzerverantwortlichkeiten zur Erreichung des Ziel-SIL definiert. STM32H7 Safety Manual
• Testplan erstellen: Korrektheit der Tests, Fault-Reaction, Timing, Coverage, Robustheit gegen false positives/negatives validieren.
• Dokumentation „mitbauen“: Traceability von Anforderungen zu Implementierung und Tests, weil Safety-Projekte auditierbar sein müssen.

Technisch ist zudem wichtig, dass Diagnosefehler eindeutig behandelt werden: Ein Safety-Fehler darf nicht „weggeloggt“ und ignoriert werden. Stattdessen muss die definierte Fehlerreaktion (z. B. Abschalten, Degradationsmodus, Neustart in sicheren Zustand) zuverlässig greifen.

Zusammenspiel mit RTOS und Echtzeit: Diagnose ohne Systemstillstand

Viele Safety-Systeme laufen mit RTOS, Kommunikationsstacks und strengen Echtzeitanforderungen. Diagnose muss deshalb so gestaltet sein, dass sie deterministisch bleibt. Typische Muster:

• Time-Sliced RAM-Test: RAM wird in Blöcken getestet, verteilt über mehrere Zyklen, um Latenzen zu begrenzen.
• Watchdog-Strategie: Watchdog wird als Sicherheitsnetz genutzt, aber nicht als „Allheilmittel“; er muss bewusst in die Fehlerreaktion integriert werden.
• Prioritätskonzept: Safety-Diagnosen erhalten definierte Prioritäten, damit sie nicht von „nice-to-have“-Tasks verdrängt werden.
• Fehlerreaktion atomar: Sobald ein kritischer Diagnosefehler erkannt ist, muss der Übergang in Safe State zuverlässig sein.

In diesem Kontext ist es hilfreich, dass ST Safety Manuals die Rolle des Systemdesigners betonen und Verantwortlichkeiten für Installation und Betrieb beschreiben, um das Ziel-SIL zu erreichen. STM32H7 Dual-Core Safety Manual (IEC 61508)

IEC 61508 vs. IEC 60730/60335: Warum „Safety“ nicht gleich „Safety“ ist

Entwickler stoßen häufig auf unterschiedliche Normfamilien. IEC 61508 adressiert funktionale Sicherheit in der Industrie (generische Grundnorm), während IEC 60730/60335 stärker auf Haushaltsgeräte und ähnliche Anwendungen zielt (Class B). ST bietet beide Richtungen an: X-CUBE-STL als IEC 61508-orientiertes Paket und X-CUBE-CLASSB als Erweiterung für Class-B-Anforderungen. X-CUBE-STL für IEC 61508 / X-CUBE-CLASSB für IEC 60730/60335

Praktisch bedeutet das: Wählen Sie die Bibliothek nicht nach „Verfügbarkeit“, sondern nach dem Zertifizierungsziel Ihres Produkts. ST stellt zudem ein Application Note bereit, das die Anpassung des IEC-61508-orientierten X-CUBE-STL-Ansatzes auf andere Normen über eine Change-Impact-Analyse beschreibt. AN5698: X-CUBE-STL an andere Standards anpassen

Grenzen und typische Stolperfallen: Was Self-Tests nicht lösen

Self-Tests sind ein starker Baustein, aber kein Ersatz für Systemarchitektur und Prozessqualität. Häufige Stolperfallen in Safety-Projekten sind:

• Blindes Vertrauen in Bibliothek: Eine Library erleichtert Nachweise, ersetzt aber nicht die System-FMEA, Sicherheitsfunktionen und Validierung im Endgerät.
• Conditions of Use ignoriert: Safety Manuals enthalten verbindliche Integrationsbedingungen; wer sie nicht umsetzt, schwächt den Nachweis.
• Fehlerreaktion unklar: Diagnose ohne definierte Reaktion führt zu „erkannten Fehlern“, die dennoch gefährlich bleiben.
• Timing/Intervall falsch gewählt: Zu seltene Tests senken die Wirksamkeit, zu häufige Tests gefährden Echtzeit und Stabilität.
• Nur Kernkomponenten getestet: CPU/RAM/Flash sind wichtig, aber je nach Anwendung sind Sensorpfade, Aktorpfade, Kommunikation und Versorgung ebenfalls sicherheitsrelevant.

ST adressiert genau diese Systemebene durch Safety Manuals, die Nutzerpflichten und Systemverantwortlichkeiten beschreiben, um das Ziel-SIL zu erreichen. X-CUBE-STL: Safety Manual und Conditions of Use

Praktische Empfehlung: Dokumentations- und Auditfähigkeit von Anfang an mitdenken

Ein Safety-Projekt scheitert selten an einer einzelnen technischen Hürde, sondern an fehlender Nachweisführung. Selbst wenn die Software „läuft“, muss sie auditierbar sein. Daraus folgen klare, frühe To-dos:

• Traceability: Anforderungen → Design → Implementierung → Testfälle → Testergebnisse.
• Konfigurationsmanagement: Versionierung von Toolchain, Libraries, Compiler-Flags, Linker-Skripten, Option Bytes.
• Reproduzierbare Builds: „Gleicher Input, gleicher Output“ ist in Safety-Audits ein großer Vorteil.
• Fault-Injection- und Negativtests: nicht nur „Happy Path“, sondern gezielte Fehlerprovokation, um Diagnose und Reaktion zu beweisen.

ST verweist im Kontext von X-CUBE-STL auf verifizierte diagnostische Abdeckung und eine proprietäre Fault-Injection-Methodik zur Verifikation der Diagnosen. X-CUBE-STL: Verifikation der Diagnostic Coverage

Outbound-Ressourcen für Entwickler und Safety-Verantwortliche

• X-CUBE-STL: IEC 61508-orientierte STM32 Self-Test Library
• ST Functional Safety Ökosystem für STM8/STM32
• X-CUBE-CLASSB: IEC 60730/60335 Class B Self-Test Package
• STM32H7 Safety Manual (IEC 61508) als Beispiel für Conditions of Use
• AN5698: X-CUBE-STL für andere Safety-Standards adaptieren
• Arm PSA Certified: Sicherheitskonzepte und Root-of-Trust-Methodik

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.