{"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-05-27T19:13:41","modified_gmt":"2026-05-27T19:13:41","slug":"functional-safety-rtos","status":"publish","type":"post","link":"https:\/\/www.pickplace.de\/de\/functional-safety-rtos\/","title":{"rendered":"Brauchen wir f\u00fcr 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\">Warum die Make-or-Buy-Entscheidung nicht beim Zertifikat endet<\/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 durch 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 <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> ver&auml;ndert die Nachweisfrage. Es f&uuml;gt Software hinzu, die selbst verstanden, konfiguriert, integriert und gepr&uuml;ft werden muss. Daf&uuml;r kann es Dienste bereitstellen, die bei umfangreicheren Systemen sonst selbst entwickelt werden m&uuml;ssten: priorit&auml;tsbasiertes Scheduling, Ereignisverarbeitung, Queues, Semaphore, Stack-&Uuml;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\">Warum die Make-or-Buy-Entscheidung nicht beim Zertifikat endet<\/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.<\/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=\"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 <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> bieten Mechanismen zur Fehlerbehandlung. Dazu geh&ouml;ren Stack-Overflow-Erkennung, Behandlung ung&uuml;ltiger Zust&auml;nde, Hooks f&uuml;r Laufzeitfehler oder Diagnosefunktionen zur Task-Auslastung. Diese Mechanismen k&ouml;nnen Teil einer Sicherheitsarchitektur sein. Sie m&uuml;ssen aber zur konkreten Gef&auml;hrdungsanalyse passen. Ein Stack-Overflow-Hook ist kein Sicherheitskonzept, wenn nicht festgelegt ist, welche Reaktion das System im Fehlerfall ausf&uuml;hrt.<\/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&#xFC;r Functional Safety. Der Aufwand liegt in Qualifikation, Konfigurationskontrolle, Testabdeckung, &#xC4;nderungshistorie, Toolchain und Eingrenzung des verwendeten Codes. Bei Normen wie IEC 61508 oder vergleichbaren Safety-Rahmenwerken muss das Projekt den Nachweis f&#xFC;hren, dass die gew&#xE4;hlte Softwarebasis f&#xFC;r die geforderte Sicherheitsintegrit&#xE4;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. Wenn diese Punkte mit vertretbarem Aufwand nachweisbar sind, kann Bare Metal eine passende Architektur sein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&uuml;r ein <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> m&uuml;ssen Task-Modell, Priorit&auml;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&uuml;tzen k&ouml;nnen. Oft sind diese &bdquo;Closed Source&ldquo;, 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.<\/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>Zwar verlangt Functional Safety keinen RTOS-Einsatz als Grundbedingung. Ein RTOS wird jedoch fachlich naheliegend, wenn Scheduling, Task-Trennung, Ressourcenverwaltung, Stack-\u00dcberwachung oder Partitionierung Teil des Sicherheitsnachweises werden.<\/p>\n","protected":false},"author":1,"featured_media":0,"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","hentry","category-functional-safety-2","category-software"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/posts\/2266","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/comments?post=2266"}],"version-history":[{"count":1,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/posts\/2266\/revisions"}],"predecessor-version":[{"id":2267,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/posts\/2266\/revisions\/2267"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/media?parent=2266"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/categories?post=2266"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/tags?post=2266"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}