{"id":2266,"date":"2026-05-27T19:04:37","date_gmt":"2026-05-27T19:04:37","guid":{"rendered":"https:\/\/www.pickplace.de\/?p=2266"},"modified":"2026-06-08T09:53:27","modified_gmt":"2026-06-08T09:53:27","slug":"functional-safety-rtos","status":"publish","type":"post","link":"https:\/\/www.pickplace.de\/en\/functional-safety-rtos\/","title":{"rendered":"Do we need functional safety RTOS software?"},"content":{"rendered":"<p class=\"wp-block-paragraph\">Eine oft gestellte Frage: Brauchen wir f&#xFC;r <a href=\"https:\/\/www.pickplace.de\/funktionale-sicherheit\/\" data-type=\"page\" data-id=\"947\">Functional Safety<\/a> <a class=\"glossaryLink\"  href=\"https:\/\/www.pickplace.de\/glossar\/rtos\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>RTOS<\/a>? Grunds&auml;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&uuml;llt. Ein RTOS wird dann fachlich naheliegend, wenn Scheduling, Task-Trennung, Ressourcenverwaltung, Stack-&Uuml;berwachung oder Partitionierung Teil des Sicherheitsnachweises werden.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Inhalt<\/h2><nav><ul><li class=\"\"><a href=\"#ausgangslage\">Ausgangslage<\/a><\/li><li class=\"\"><a href=\"#fachlicher-hintergrund\">Fachlicher Hintergrund<\/a><\/li><li class=\"\"><a href=\"#warum-die-make-or-buy-entscheidung-nicht-beim-zertifikat-endet\">Make-or-Buy-Entscheidung Safety RTOS<\/a><\/li><li class=\"\"><a href=\"#das-thema-mit-der-tool-qualifikation\">Das Thema mit der Tool-Qualifikation<\/a><\/li><li class=\"\"><a href=\"#grundannahmen-zu-scheduler-tasks-und-zeitverhalten\">Grundannahmen zu Scheduler, Tasks und Zeitverhalten<\/a><\/li><li class=\"\"><a href=\"#was-leisten-task-system-ressourcen-und-fehlerbehandlung\">Was leisten Task-System, Ressourcen und Fehlerbehandlung?<\/a><\/li><li class=\"\"><a href=\"#speicher-und-hardware-partitionierung\">Speicher- und Hardware-Partitionierung<\/a><\/li><li class=\"\"><a href=\"#standard-rtos-functional-safety-rtos-oder-bare-metal\">Standard-RTOS, Functional Safety RTOS oder Bare Metal?<\/a><\/li><li class=\"\"><a href=\"#grenzen-risiken-und-offene-punkte\">Grenzen, Risiken und offene Punkte<\/a><\/li><li class=\"\"><a href=\"#was-daraus-fur-die-praxis-folgt\">Was daraus f&#xFC;r die Praxis folgt<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 id=\"ausgangslage\" class=\"wp-block-heading\">Ausgangslage<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Entwickler und Architekten m&#xFC;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&#xFC;hrung, die Qualifikation von Softwarebestandteilen und die Architektur des Systems.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bare-Metal-Software l&auml;uft direkt auf dem <a class=\"glossaryLink\"  href=\"https:\/\/www.pickplace.de\/glossar\/mikrocontroller\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Mikrocontroller<\/a> oder Prozessor. Die Applikation verwaltet Hardwarezugriffe, Speicher, Interrupts und zeitliche Abl&auml;ufe selbst. Ein typisches Muster ist eine Endlosschleife, in der Aufgaben nacheinander ausgef&uuml;hrt werden. Interrupts unterbrechen diese Schleife, f&uuml;hren eine Service-Routine aus und geben die Ausf&uuml;hrung anschlie&szlig;end zur&uuml;ck. Periodische Aufgaben k&ouml;nnen &uuml;ber Timer-Interrupts angesto&szlig;en werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein RTOS stellt dagegen Dienste f&#xFC;r Task-Scheduling, Synchronisation, Kommunikation zwischen Tasks, Timer, Speicherverwaltung und Fehlerbehandlung bereit. Es &#xFC;bernimmt nicht die Sicherheitsfunktion selbst, kann aber Mechanismen liefern, auf denen sicherheitsbezogene Software aufbaut.<\/p>\n\n\n\n<h2 id=\"fachlicher-hintergrund\" class=\"wp-block-heading\">Fachlicher Hintergrund<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Funktionale Sicherheit entsteht mitnichten durch die blo&#xDF;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&#xFC;r das Gesamtsystem tragf&#xE4;hig ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r einfache Steuerger&#xE4;te kann Bare Metal ausreichen. Das gilt besonders, wenn die Funktion &#xFC;berschaubar bleibt, die Anzahl der Interruptquellen gering ist, keine umfangreichen Kommunikationsstacks ben&#xF6;tigt werden und die zeitlichen Anforderungen in einer Superloop- oder Timer-Struktur nachweisbar eingehalten werden. Auch SIL-Ziele k&#xF6;nnen in solchen Systemen mit Bare Metal umgesetzt werden, sofern die n&#xF6;tigen Safety-Mechanismen, Speicherabsicherung, Tool-Qualifikation und Verifikationsma&#xDF;nahmen ber&#xFC;cksichtigt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein RTOS ver&#xE4;ndert die Nachweisfrage. Es f&#xFC;gt Software hinzu, die verstanden, konfiguriert, integriert und gepr&#xFC;ft werden muss. Daf&#xFC;r kann es Dienste bereitstellen, die bei umfangreicheren Systemen sonst selbst entwickelt werden m&#xFC;ssten: priorit&#xE4;tsbasiertes Scheduling, Ereignisverarbeitung, Queues, Semaphore, Stack-&#xDC;berwachung, Ressourcenverwaltung und Systemanalyse.<\/p>\n\n\n\n<h2 id=\"warum-die-make-or-buy-entscheidung-nicht-beim-zertifikat-endet\" class=\"wp-block-heading\">Make-or-Buy-Entscheidung Safety RTOS<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Functional Safety wirkt ein zertifiziertes RTOS zun&#xE4;chst wie die einfachere Beschaffungsentscheidung. Produkte wie <a href=\"https:\/\/www.highintegritysystems.com\/safertos\/\" target=\"_blank\" rel=\"noopener\">SAFERTOS<\/a> von Wittenstein High Integrity Systems, embOS in Safety-Varianten (<a href=\"https:\/\/www.segger.com\/products\/rtos\/embos\/editions\/embos-safe\/\" target=\"_blank\" rel=\"noopener\">embOS-Safe<\/a> von Segger) oder <a href=\"https:\/\/www.sysgo.com\/pikeos\" target=\"_blank\" rel=\"noopener\">PikeOS<\/a> von SysGO werden eingesetzt, wenn Teams Safety-Nachweise nicht vollst&#xE4;ndig f&#xFC;r eine selbst zusammengestellte Laufzeitumgebung f&#xFC;hren wollen. Ein Zertifikat ersetzt aber nicht die Systemverantwortung. Die konkrete Konfiguration, die Nutzung der APIs, die Task-Architektur, Priorit&#xE4;ten, Speicherbereiche und Fehlerreaktionen bleiben Teil des Projektnachweises. Der Vorteil eine Functional Safety Certification ist in der Regel eine vorhandene Tool-Qualifikation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xF6;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bare Metal ist ebenfalls keine aufwandsfreie L&#xF6;sung. Sobald Scheduling-Logik, Priorit&#xE4;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.<\/p>\n\n\n\n<h2 id=\"das-thema-mit-der-tool-qualifikation\" class=\"wp-block-heading\">Das Thema mit der Tool-Qualifikation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Toolqualifikation bedeutet, dass Entwicklungswerkzeuge quantitativ bewertet werden m&#xFC;ssen, wenn ihre Ergebnisse in sicherheitsrelevante Entwicklungsnachweise einflie&#xDF;en. Entscheidend ist dabei nicht das Tool als Ganzes, sondern die konkret verwendete Funktion im konkreten Entwicklungsprozess: Ein Compiler, ein Codegenerator, ein statisches Analysewerkzeug oder ein Testtool kann je nach Einsatz entweder nur unterst&#xFC;tzend wirken oder selbst sicherheitsrelevante Fehler einbringen beziehungsweise verdecken. Deshalb muss bewertet werden, welche Toolfunktionen tats&#xE4;chlich relevant sind, welche Fehlfunktionen denkbar sind und ob diese Fehlfunktionen durch nachgelagerte Pr&#xFC;fungen entdeckt w&#xFC;rden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In der Praxis bedeutet Toolqualifikation vor allem, f&#xFC;r kritische Toolfunktionen einen belastbaren Vertrauensnachweis aufzubauen. Eine sinnvolle Praxis ist daher, die eingesetzten Tools regressiv zu testen: F&#xFC;r definierte, bekannte Eingaben wird regelm&#xE4;&#xDF;ig gepr&#xFC;ft, ob das Tool die erwarteten Ergebnisse erzeugt und ob typische Fehlerf&#xE4;lle zuverl&#xE4;ssig erkannt werden. Tool-Qualifikation ist somit ein technischer Kontrollmechanismus im Entwicklungsprozess. Bei einem Safety qualified Compiler oder einem Safety-qualified RTOS wurde ein wesentlicher Teil dieses Nachweises bereits durch den Hersteller erbracht: definierte Annahmen zur Nutzung, dokumentierte Einschr&#xE4;nkungen, Qualifikationsartefakte und Testnachweise in Form von z.B. Regressionstests.<\/p>\n\n\n\n<h2 id=\"grundannahmen-zu-scheduler-tasks-und-zeitverhalten\" class=\"wp-block-heading\">Grundannahmen zu Scheduler, Tasks und Zeitverhalten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der Scheduler ist bei einem RTOS der Mechanismus, der Tasks anhand von Priorit&#xE4;ten, Zust&#xE4;nden und Ereignissen ausf&#xFC;hrt. F&#xFC;r Functional Safety ist er dann relevant, wenn Sicherheitsfunktionen innerhalb definierter Zeitgrenzen reagieren m&#xFC;ssen. Die FTTI beschreibt den Zeitraum, in dem ein Fehler erkannt und eine Reaktion ausgel&#xF6;st werden muss, bevor die Sicherheitsverletzung eintritt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Bare Metal l&#xE4;sst sich dieses Verhalten gut begr&#xFC;nden, wenn die Reihenfolge der Abl&#xE4;ufe fest ist und die maximale Laufzeit jeder Schleifenpassage bekannt ist. Neue Funktionen ver&#xE4;ndern aber die Reaktionszeiten aller gepollten Ereignisse, wenn sie in dieselbe Schleife eingef&#xFC;gt werden. Kritische Ereignisse k&#xF6;nnen &#xFC;ber Interrupts priorisiert werden, aber auch diese Struktur braucht eine nachvollziehbare Analyse der Laufzeiten, Sperrzeiten und Nebenwirkungen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein RTOS kann die zeitliche Kopplung zwischen Aufgaben reduzieren. Ereignisse werden Tasks zugeordnet, Tasks erhalten Priorit&#xE4;ten, und blockierende Wartezeiten k&#xF6;nnen &#xFC;ber RTOS-Primitive statt &#xFC;ber Polling abgebildet werden. Das hilft nur, wenn Priorit&#xE4;ten, Stackgr&#xF6;&#xDF;en, Laufzeiten und Sperrbereiche analysiert werden. Ein falsch eingesetztes RTOS kann Deadlocks, Priority Inversion, Stack&#xFC;berl&#xE4;ufe oder nicht eingehaltene Reaktionszeiten verursachen.<\/p>\n\n\n\n<h2 id=\"was-leisten-task-system-ressourcen-und-fehlerbehandlung\" class=\"wp-block-heading\">Was leisten Task-System, Ressourcen und Fehlerbehandlung?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Task-System trennt Softwarefunktionen in ausf&#xFC;hrbare Einheiten. Diese Trennung kann den Code verst&#xE4;ndlicher machen, wenn Kommunikationsstacks, Sensorverarbeitung, Aktuatoransteuerung und Diagnose eigene Ausf&#xFC;hrungskontexte ben&#xF6;tigen. Queues und Semaphore bilden dann geregelte &#xDC;bergaben zwischen diesen Kontexten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r Safety ist diese Trennung nur dann n&#xFC;tzlich, wenn die Datenfl&#xFC;sse und Abh&#xE4;ngigkeiten dokumentiert sind. Ein Task, der sicherheitsbezogene Daten verarbeitet, darf nicht unkontrolliert durch eine weniger kritische Funktion blockiert werden. Gemeinsame Ressourcen m&#xFC;ssen so gesch&#xFC;tzt werden, dass Race Conditions und inkonsistente Datenzust&#xE4;nde erkannt oder vermieden werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Viele RTOS bieten Mechanismen zur Fehlerbehandlung. Dazu geh&#xF6;ren Overflow-Erkennung, Behandlung ung&#xFC;ltiger Zust&#xE4;nde, Hooks f&#xFC;r Laufzeitfehler oder Diagnosefunktionen zur Task-Auslastung. Diese Mechanismen k&#xF6;nnen Teil einer Sicherheitsarchitektur sein. Sie m&#xFC;ssen aber zur konkreten Gef&#xE4;hrdungsanalyse passen. Ein Stack-Overflow-Hook ist kein Sicherheitskonzept, wenn nicht festgelegt ist, welche Reaktion das System im Fehlerfall ausf&#xFC;hrt bzw. dass sie &#xFC;berhaupt ausgef&#xFC;hrt wird.<\/p>\n\n\n\n<h2 id=\"speicher-und-hardware-partitionierung\" class=\"wp-block-heading\">Speicher- und Hardware-Partitionierung<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hardwaremechanismen k&#xF6;nnen den Bedarf an einem vollst&#xE4;ndig zertifizierten Software-Stack verringern. Mikrocontroller mit Memory Protection Unit k&#xF6;nnen Speicherbereiche voneinander trennen. Lockstep-Kerne k&#xF6;nnen bestimmte Hardwarefehler erkennen. Solche Mechanismen unterst&#xFC;tzen den Safety Case, weil sie Fehlerausbreitung begrenzen oder Fehler sichtbar machen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein RTOS kann diese Hardwarefunktionen nutzen, wenn es Speicherbereiche pro Task oder Partition verwaltet. Bei Systemen mit gemischter Kritikalit&#xE4;t kann r&#xE4;umliche und zeitliche Partitionierung verhindern, dass eine weniger kritische Funktion den Ablauf einer sicherheitsbezogenen Funktion beeintr&#xE4;chtigt. Das setzt geeignete Hardware und eine RTOS-Konfiguration voraus, die diese Trennung tats&#xE4;chlich durchsetzt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Hypervisor ist in diesem Zusammenhang nur bei Systemen sinnvoll, die mehrere Betriebssysteme, Partitionen oder Funktionsdom&#xE4;nen auf einer Hardware ausf&#xFC;hren. F&#xFC;r ein kleines MCU-System mit einer &#xFC;berschaubaren Steuerfunktion ist ein Hypervisor meist zus&#xE4;tzlicher Nachweis- und Integrationsaufwand. Bei HPC-Plattformen oder Systemen mit getrennten Safety- und Non-Safety-Anteilen kann er Bestandteil der Architektur sein. F&#xFC;r Hypervisor-Funktionen ist mitunter der Einsatz spezialisierter Multicore-Controller ratsam.<\/p>\n\n\n\n<h2 id=\"standard-rtos-functional-safety-rtos-oder-bare-metal\" class=\"wp-block-heading\">Standard-RTOS, Functional Safety RTOS oder Bare Metal?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Entscheidung l&#xE4;sst sich &#xFC;ber konkrete Systemmerkmale eingrenzen. Bare Metal passt, wenn die Software klein bleibt, die Zeitpfade berechenbar sind, Kommunikationsprotokolle begrenzt bleiben und keine Task-Isolation ben&#xF6;tigt wird. Die Quellen nennen als grobe Orientierung, dass sehr kleine MCU-Anwendungen unterhalb von etwa 64 KB h&#xE4;ufig kein RTOS ben&#xF6;tigen, w&#xE4;hrend Anwendungen im Bereich von 1 MB oft RTOS-basierte Strukturen verwenden. Diese Gr&#xF6;&#xDF;en sind keine Safety-Regel, sondern eine technische Daumenregel f&#xFC;r Softwareumfang und Architekturform.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Standard-RTOS passt, wenn Multitasking, Kommunikationsstacks, Treiber, Debug-Werkzeuge oder Wiederverwendung ben&#xF6;tigt werden, der Safety Case aber die Qualifikation des verwendeten RTOS-Anteils leisten kann. Der Projektumfang muss dann den Nachweis f&#xFC;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Safety-RTOS passt, wenn der Nachweisaufwand f&#xFC;r ein Standard-RTOS den Projektaufwand belastet oder wenn Partitionierung, qualifizierte Artefakte, Safety-Handb&#xFC;cher und vordefinierte Nutzungseinschr&#xE4;nkungen ben&#xF6;tigt werden. Das Zertifikat ist dabei ein Baustein. Es beantwortet nicht automatisch, ob die Applikation ihre Safety-Anforderungen erf&#xFC;llt.<\/p>\n\n\n\n<h2 id=\"grenzen-risiken-und-offene-punkte\" class=\"wp-block-heading\">Grenzen, Risiken und offene Punkte<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xFC;ssen auf ihren Einfluss auf sicherheitsbezogene Funktionen gepr&#xFC;ft werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bare Metal kann einfacher zu pr&#xFC;fen sein, solange die Softwarestruktur klein bleibt. Die Grenze wird erreicht, wenn eine selbst entwickelte Scheduler-Logik, Queues, Task-Zust&#xE4;nde und Synchronisationsmechanismen entstehen. Dann wird aus Bare Metal faktisch ein projektspezifischer RTOS-Ersatz mit weniger Dokumentation und weniger vorgepr&#xFC;ften Werkzeugen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Open-Source-RTOS sind nicht automatisch ungeeignet f&uuml;r Functional Safety. Der Aufwand liegt in Qualifikation, Konfigurationskontrolle, Testabdeckung, &Auml;nderungshistorie, Toolchain und Eingrenzung des verwendeten Codes. Bei Normen wie <a class=\"glossaryLink\"  href=\"https:\/\/www.pickplace.de\/glossar\/iec-61508\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>IEC 61508<\/a> oder vergleichbaren Safety-Rahmenwerken muss das Projekt den Nachweis f&uuml;hren, dass die gew&auml;hlte Softwarebasis f&uuml;r die geforderte Sicherheitsintegrit&auml;t beherrscht wird.<\/p>\n\n\n\n<h2 id=\"was-daraus-fur-die-praxis-folgt\" class=\"wp-block-heading\">Was daraus f&#xFC;r die Praxis folgt<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xE4;hlten Laufzeitarchitektur nachweisbar erf&#xFC;llt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r Bare Metal m&#xFC;ssen mindestens folgende Punkte belastbar beantwortet werden: maximale Schleifenlaufzeiten, Interrupt-Latenzen, FTTI-Abdeckung, Speicherzugriffe, Stack-Verbrauch, Fehlerreaktionen, Toolchain und Schutz sicherheitsbezogener Daten. In der Regel sind diese Punkte mit vertretbarem Aufwand nachweisbar. Daher kann Bare Metal bei kommunikationsarmen Systemen immer eine passende Architektur sein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r ein RTOS m&#xFC;ssen Task-Modell, Priorit&#xE4;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&#xFC;tzen. Oft sind diese &#x201E;Closed Source&#x201C;, 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. Das ist in der Regel ebenfalls kosten- und personalintensiv.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Scheduler, Task-System, Thread-Management und Hypervisor sind nur dann zu rechtfertigen, wenn sie eine konkrete Aufgabe im System erf&#xFC;llen: Zeitverhalten strukturieren, Ressourcen kontrollieren, Fehlerausbreitung begrenzen oder Funktionsdom&#xE4;nen trennen. Ohne diese Aufgabe erh&#xF6;hen sie den Nachweisumfang, ohne die Safety-Argumentation zu verbessern.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>While functional safety doesn't require an RTOS as a prerequisite, an RTOS becomes technically advisable when scheduling, task separation, resource management, stack monitoring, or partitioning become part of the safety case.<\/p>","protected":false},"author":1,"featured_media":2354,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,31],"tags":[],"class_list":["post-2266","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-functional-safety-2","category-software"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/posts\/2266","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/comments?post=2266"}],"version-history":[{"count":5,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/posts\/2266\/revisions"}],"predecessor-version":[{"id":2355,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/posts\/2266\/revisions\/2355"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/media\/2354"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/media?parent=2266"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/categories?post=2266"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/tags?post=2266"}],"curies":[{"name":"WP","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}