Eine oft gestellte Frage: Brauchen wir für Functional Safety RTOS? Grundsätzlich nein. Functional Safety verlangt keinen RTOS-Einsatz als Grundbedingung. Ein sicherheitsbezogener Embedded-Controller kann auch mit Bare-Metal-Software arbeiten, wenn das System seine funktionalen Anforderungen, seine Zeitbedingungen und die aus den Sicherheitszielen abgeleitete FTTI deterministisch erfüllt. Ein RTOS wird dann fachlich naheliegend, wenn Scheduling, Task-Trennung, Ressourcenverwaltung, Stack-Überwachung oder Partitionierung Teil des Sicherheitsnachweises werden.
Inhalt
Ausgangslage
Entwickler und Architekten müssen bei Embedded-Software entscheiden, ob sie Bare Metal, ein Standard-RTOS oder ein Safety-RTOS verwenden. Die Entscheidung betrifft nicht nur Laufzeitverhalten und Entwicklungsaufwand. Sie beeinflusst auch den Safety Case, die Nachweisführung, die Qualifikation von Softwarebestandteilen und die Architektur des Systems.
Bare-Metal-Software läuft direkt auf dem Mikrocontroller oder Prozessor. Die Applikation verwaltet Hardwarezugriffe, Speicher, Interrupts und zeitliche Abläufe selbst. Ein typisches Muster ist eine Endlosschleife, in der Aufgaben nacheinander ausgeführt werden. Interrupts unterbrechen diese Schleife, führen eine Service-Routine aus und geben die Ausführung anschließend zurück. Periodische Aufgaben können über Timer-Interrupts angestoßen werden.
Ein RTOS stellt dagegen Dienste für Task-Scheduling, Synchronisation, Kommunikation zwischen Tasks, Timer, Speicherverwaltung und Fehlerbehandlung bereit. Es übernimmt nicht die Sicherheitsfunktion selbst, kann aber Mechanismen liefern, auf denen sicherheitsbezogene Software aufbaut.
Fachlicher Hintergrund
Funktionale Sicherheit entsteht durch mitnichten durch die bloße Wahl eines Betriebssystems. Sie entsteht durch Anforderungen, Architektur, Implementierung, Verifikation, Sicherheitsmechanismen und einen nachvollziehbaren Sicherheitsnachweis. Theoretisch und praktisch kann ein System mit Bare Metal, mit einem Standard-RTOS oder mit einem Functional Safety RTOS sicherheitskonform entwickelt werden, wenn der Safety Case für das Gesamtsystem tragfähig ist.
Für einfache Steuergeräte kann Bare Metal ausreichen. Das gilt besonders, wenn die Funktion überschaubar bleibt, die Anzahl der Interruptquellen gering ist, keine umfangreichen Kommunikationsstacks benötigt werden und die zeitlichen Anforderungen in einer Superloop- oder Timer-Struktur nachweisbar eingehalten werden. Auch SIL-Ziele können in solchen Systemen mit Bare Metal umgesetzt werden, sofern die nötigen Safety-Mechanismen, Speicherabsicherung, Tool-Qualifikation und Verifikationsmaßnahmen berücksichtigt werden.
Ein RTOS verändert die Nachweisfrage. Es fügt Software hinzu, die selbst verstanden, konfiguriert, integriert und geprüft werden muss. Dafür kann es Dienste bereitstellen, die bei umfangreicheren Systemen sonst selbst entwickelt werden müssten: prioritätsbasiertes Scheduling, Ereignisverarbeitung, Queues, Semaphore, Stack-Überwachung, Ressourcenverwaltung und Systemanalyse.
Warum die Make-or-Buy-Entscheidung nicht beim Zertifikat endet
Bei Functional Safety wirkt ein zertifiziertes RTOS zunächst wie die einfachere Beschaffungsentscheidung. Produkte wie SAFERTOS von Wittenstein High Integrity Systems, embOS in Safety-Varianten (embOS-Safe von Segger) oder PikeOS von SysGO werden eingesetzt, wenn Teams Safety-Nachweise nicht vollständig für eine selbst zusammengestellte Laufzeitumgebung führen wollen. Ein Zertifikat ersetzt aber nicht die Systemverantwortung. Die konkrete Konfiguration, die Nutzung der APIs, die Task-Architektur, Prioritäten, Speicherbereiche und Fehlerreaktionen bleiben Teil des Projektnachweises.
Ein Standard-RTOS wie FreeRTOS oder Zephyr kann in einem Safety-Projekt verwendet werden, wenn der eigene Safety Case die Nutzung abdeckt. Der Aufwand liegt dann bei der Qualifikation, der Eingrenzung des verwendeten Funktionsumfangs, der Verifikation und der Dokumentation. Dieser Aufwand kann bei sicherheitsbezogenen Produkten höher sein als die Lizenz- und Integrationskosten eines Safety-RTOS. Er kann aber geringer sein als ein Safety-RTOS-Wechsel, wenn die Anwendung klein ist und der genutzte RTOS-Anteil eng begrenzt bleibt.
Bare Metal ist ebenfalls keine aufwandsfreie Lösung. Sobald Scheduling-Logik, Prioritäten, Kommunikationspuffer, gegenseitiger Ausschluss, Watchdog-Reaktionen und Stack-Kontrollen selbst gebaut werden, entsteht eine projektspezifische Laufzeitumgebung. Diese muss im Safety Case wie andere sicherheitsbezogene Software behandelt werden.
Grundannahmen zu Scheduler, Tasks und Zeitverhalten
Der Scheduler ist bei einem RTOS der Mechanismus, der Tasks anhand von Prioritäten, Zuständen und Ereignissen ausführt. Für Functional Safety ist er dann relevant, wenn Sicherheitsfunktionen innerhalb definierter Zeitgrenzen reagieren müssen. Die FTTI beschreibt den Zeitraum, in dem ein Fehler erkannt und eine Reaktion ausgelöst werden muss, bevor die Sicherheitsverletzung eintritt.
Bei Bare Metal lässt sich dieses Verhalten gut begründen, wenn die Reihenfolge der Abläufe fest ist und die maximale Laufzeit jeder Schleifenpassage bekannt ist. Neue Funktionen verändern aber die Reaktionszeiten aller gepollten Ereignisse, wenn sie in dieselbe Schleife eingefügt werden. Kritische Ereignisse können über Interrupts priorisiert werden, aber auch diese Struktur braucht eine nachvollziehbare Analyse der Laufzeiten, Sperrzeiten und Nebenwirkungen.
Ein RTOS kann die zeitliche Kopplung zwischen Aufgaben reduzieren. Ereignisse werden Tasks zugeordnet, Tasks erhalten Prioritäten, und blockierende Wartezeiten können über RTOS-Primitive statt über Polling abgebildet werden. Das hilft nur, wenn Prioritäten, Stackgrößen, Laufzeiten und Sperrbereiche analysiert werden. Ein falsch eingesetztes RTOS kann Deadlocks, Priority Inversion, Stacküberläufe oder nicht eingehaltene Reaktionszeiten verursachen.
Was leisten Task-System, Ressourcen und Fehlerbehandlung?
Ein Task-System trennt Softwarefunktionen in ausführbare Einheiten. Diese Trennung kann den Code verständlicher machen, wenn Kommunikationsstacks, Sensorverarbeitung, Aktuatoransteuerung und Diagnose eigene Ausführungskontexte benötigen. Queues und Semaphore bilden dann geregelte Übergaben zwischen diesen Kontexten.
Für Safety ist diese Trennung nur dann nützlich, wenn die Datenflüsse und Abhängigkeiten dokumentiert sind. Ein Task, der sicherheitsbezogene Daten verarbeitet, darf nicht unkontrolliert durch eine weniger kritische Funktion blockiert werden. Gemeinsame Ressourcen müssen so geschützt werden, dass Race Conditions und inkonsistente Datenzustände erkannt oder vermieden werden.
Viele RTOS bieten Mechanismen zur Fehlerbehandlung. Dazu gehören Stack-Overflow-Erkennung, Behandlung ungültiger Zustände, Hooks für Laufzeitfehler oder Diagnosefunktionen zur Task-Auslastung. Diese Mechanismen können Teil einer Sicherheitsarchitektur sein. Sie müssen aber zur konkreten Gefährdungsanalyse passen. Ein Stack-Overflow-Hook ist kein Sicherheitskonzept, wenn nicht festgelegt ist, welche Reaktion das System im Fehlerfall ausführt.
Speicher- und Hardware-Partitionierung
Hardwaremechanismen können den Bedarf an einem vollständig zertifizierten Software-Stack verringern. Mikrocontroller mit Memory Protection Unit können Speicherbereiche voneinander trennen. Lockstep-Kerne können bestimmte Hardwarefehler erkennen. Solche Mechanismen unterstützen den Safety Case, weil sie Fehlerausbreitung begrenzen oder Fehler sichtbar machen.
Ein RTOS kann diese Hardwarefunktionen nutzen, wenn es Speicherbereiche pro Task oder Partition verwaltet. Bei Systemen mit gemischter Kritikalität kann räumliche und zeitliche Partitionierung verhindern, dass eine weniger kritische Funktion den Ablauf einer sicherheitsbezogenen Funktion beeinträchtigt. Das setzt geeignete Hardware und eine RTOS-Konfiguration voraus, die diese Trennung tatsächlich durchsetzt.
Ein Hypervisor ist in diesem Zusammenhang nur bei Systemen sinnvoll, die mehrere Betriebssysteme, Partitionen oder Funktionsdomänen auf einer Hardware ausführen. Für ein kleines MCU-System mit einer überschaubaren Steuerfunktion ist ein Hypervisor meist zusätzlicher Nachweis- und Integrationsaufwand. Bei HPC-Plattformen oder Systemen mit getrennten Safety- und Non-Safety-Anteilen kann er Bestandteil der Architektur sein. Für Hypervisor-Funktionen ist mitunter der Einsatz spezialisierter Multicore-Controller ratsam.
Standard-RTOS, Functional Safety RTOS oder Bare Metal?
Die Entscheidung lässt sich über konkrete Systemmerkmale eingrenzen. Bare Metal passt, wenn die Software klein bleibt, die Zeitpfade berechenbar sind, Kommunikationsprotokolle begrenzt bleiben und keine Task-Isolation benötigt wird. Die Quellen nennen als grobe Orientierung, dass sehr kleine MCU-Anwendungen unterhalb von etwa 64 KB häufig kein RTOS benötigen, während Anwendungen im Bereich von 1 MB oft RTOS-basierte Strukturen verwenden. Diese Größen sind keine Safety-Regel, sondern eine technische Daumenregel für Softwareumfang und Architekturform.
Ein Standard-RTOS passt, wenn Multitasking, Kommunikationsstacks, Treiber, Debug-Werkzeuge oder Wiederverwendung benötigt werden, der Safety Case aber die Qualifikation des verwendeten RTOS-Anteils leisten kann. Der Projektumfang muss dann den Nachweis für die konkrete RTOS-Version, Konfiguration und API-Nutzung tragen. Eine grundlegende Schwachstelle von freien RTOS-Systemen jedoch ist, dass eine Fehleroffenbarung, d.h. ein Anzeigen und Kategorisieren von Fehlern in Threads oder Tasks nicht intrinsisch Teil der Software ist.
Ein Safety-RTOS passt, wenn der Nachweisaufwand für ein Standard-RTOS den Projektaufwand belastet oder wenn Partitionierung, qualifizierte Artefakte, Safety-Handbücher und vordefinierte Nutzungseinschränkungen benötigt werden. Das Zertifikat ist dabei ein Baustein. Es beantwortet nicht automatisch, ob die Applikation ihre Safety-Anforderungen erfüllt.
Grenzen, Risiken und offene Punkte
Ein RTOS kann Timing-Probleme verdecken, wenn Tasks ohne Laufzeitanalyse priorisiert werden. Polling verschwindet dann zwar aus der Superloop, aber Blockierzeiten, Interrupt-Latenzen und Ressourcenkonflikte bleiben messbar und nachweispflichtig. Auch Kommunikationsstacks und Treiber aus einem RTOS-Paket müssen auf ihren Einfluss auf sicherheitsbezogene Funktionen geprüft werden.
Bare Metal kann einfacher zu prüfen sein, solange die Softwarestruktur klein bleibt. Die Grenze wird erreicht, wenn eine selbst entwickelte Scheduler-Logik, Queues, Task-Zustände und Synchronisationsmechanismen entstehen. Dann wird aus Bare Metal faktisch ein projektspezifischer RTOS-Ersatz mit weniger Dokumentation und weniger vorgeprüften Werkzeugen.
Open-Source-RTOS sind nicht automatisch ungeeignet für Functional Safety. Der Aufwand liegt in Qualifikation, Konfigurationskontrolle, Testabdeckung, Änderungshistorie, Toolchain und Eingrenzung des verwendeten Codes. Bei Normen wie IEC 61508 oder vergleichbaren Safety-Rahmenwerken muss das Projekt den Nachweis führen, dass die gewählte Softwarebasis für die geforderte Sicherheitsintegrität beherrscht wird.
Was daraus für die Praxis folgt
Die erste Frage lautet nicht, ob ein RTOS vorhanden sein soll. Die erste Frage lautet, ob die Sicherheitsfunktion ihre Zeit-, Diagnose- und Fehlerreaktionsanforderungen mit der gewählten Laufzeitarchitektur nachweisbar erfüllt.
Für Bare Metal müssen mindestens folgende Punkte belastbar beantwortet werden: maximale Schleifenlaufzeiten, Interrupt-Latenzen, FTTI-Abdeckung, Speicherzugriffe, Stack-Verbrauch, Fehlerreaktionen, Toolchain und Schutz sicherheitsbezogener Daten. Wenn diese Punkte mit vertretbarem Aufwand nachweisbar sind, kann Bare Metal eine passende Architektur sein.
Für ein RTOS müssen Task-Modell, Prioritäten, Synchronisation, Speicherbereiche, Fehlerhooks, Treiber, Kommunikationsstacks und Konfiguration in den Safety Case einbezogen werden. Bei einem Functional Safety RTOS kommen Herstellerartefakte hinzu, die den Nachweis unterstützen können. Oft sind diese „Closed Source“, was bedeutet, dass mitunter die Individualisierung extern, d.h. beim Hersteller eingekauft werden muss. Bei einem Standard-RTOS muss das Projekt den Qualifikationsanteil selbst tragen.
Scheduler, Task-System, Thread-Management und Hypervisor sind nur dann zu rechtfertigen, wenn sie eine konkrete Aufgabe im System erfüllen: Zeitverhalten strukturieren, Ressourcen kontrollieren, Fehlerausbreitung begrenzen oder Funktionsdomänen trennen. Ohne diese Aufgabe erhöhen sie den Nachweisumfang, ohne die Safety-Argumentation zu verbessern.
