Embedded Systems & ISO 13849: Elektronik nach Kochrezept?

Vor Kurzem erreichte uns eine Kundenanfrage mit einer auf den ersten Blick naheliegenden Idee: Mehrere ältere oder bereits portierte Embedded-Systeme sollten in einer Maschine weiterverwendet und durch eine zusätzliche Sicherheits-Hardware nach DIN EN ISO 13849 ergänzt werden. Die bestehende Elektronik sollte also nicht vollständig neu entwickelt werden. Stattdessen sollte eine neue Platine sicherheitsbezogene Signale redundant einlesen, Zustände überwachen und definierte Abschaltpfade ansteuern. Ist das ein probater Weg? Wir werfen einen Blick darauf.

Grundidee Embedded Systems & ISO 13849

Der Gedanke ist nachvollziehbar: Bestehende Embedded-Systeme übernehmen weiterhin ihre Betriebs- und Prozessfunktionen. Eine zusätzliche Sicherheitsplatine kümmert sich um die sicherheitsbezogenen Funktionen. So lässt sich eine Maschine technisch ertüchtigen, ohne alle vorhandenen Steuerungsteile neu aufzubauen.

Gerade mit Blick auf ältere Maschinen, portierte Steuerungen und neue regulatorische Anforderungen ist dieser Ansatz interessant. Wenn bestehende Embedded-Systeme nicht als sicherheitsrelevante Instanz betrachtet werden, sondern durch eine separate Sicherheitsarchitektur ergänzt werden, kann ISO 13849 grundsätzlich ein geeigneter Rahmen sein. Die Norm erlaubt eine funktionsbezogene Betrachtung: Welche Sicherheitsfunktion wird benötigt? Welcher Performance Level ist erforderlich? Welche Sensorik, Logik und Aktorik gehören dazu? Welche Kategorie wird angestrebt?

Damit entsteht zunächst ein plausibles Konzept: Legacy-Steuerungen bleiben für den Betrieb und die eigentliche Maschinenfunktion zuständig, während eine neue sicherheitsbezogene Elektronik die eigentlichen Sicherheitsfunktionen übernimmt.

Der kritische Punkt liegt jedoch in der Umsetzung. Denn eine Sicherheitsfunktion, die auf Maschinenebene trivial wirkt – beispielsweise Eingang einlesen, Zustand bewerten, Ausgang abschalten – wird in Embedded-Elektronik schnell komplex. Sobald ein Mikrocontroller die sicherheitsbezogene Entscheidung trifft, muss auch dieser Mikrocontroller selbst überwacht werden. Aus einer einfach erscheinenden An/Aus-Funktion wird eine sicherheitsbezogene Rechenplattform mit Core Safety, Diagnose, Validierung und Dokumentationspflichten. Das klingt teuer

Kann eine Maschine durch Individualelektronik und ISO 13849 auf Safety-Niveau gebracht werden?

Grundsätzlich: ja.

Eine Maschine kann durch zusätzliche Embedded-Elektronik um sicherheitsbezogene Steuerungsfunktionen erweitert werden. Das ist insbesondere bei bestehenden Maschinen interessant, bei denen bereits Legacy-Embedded-Systeme vorhanden sind, die nach früheren Anforderungen entwickelt wurden. Mit Blick auf die neue Maschinenverordnung rücken solche Maschinen stärker in den Fokus: bestehende Steuerungen, vorhandene Mechanik, vorhandene Aktorik — aber neue Anforderungen an Nachweis, Stand der Technik und funktionale Sicherheit.

Ein typisches Szenario ist eine zusätzliche Sicherheitsplatine, die Eingänge redundant einliest, Zustände plausibilisiert, Diagnosefunktionen ausführt und definierte Abschaltpfade ansteuert. Die vorhandene Maschinensteuerung bleibt für Betriebsfunktionen zuständig. Die neue Sicherheitslogik übernimmt jedoch die sicherheitsbezogenen Funktionen.

Beispiel:

Eine Maschine besitzt eine bestehende Embedded-Steuerung. Diese Steuerung bleibt unverändert und führt weiterhin die Prozesslogik aus. Zusätzlich wird eine Sicherheitsplatine integriert, die Schutztüren, Endlagen, Freigaben oder Drehzahlsignale zweikanalig einliest. Bei einer Abweichung, einem Diagnosefehler oder einer geöffneten Schutzeinrichtung schaltet diese Platine über redundante Ausgänge sichere Abschaltpfade, beispielsweise Schütze, STO-Eingänge oder Ventile.

Aus Sicht der ISO 13849 ist das grundsätzlich ein plausibler Ansatz. Entscheidend ist, dass das Sicherheitskonzept stimmt: Welche Sicherheitsfunktionen werden benötigt? Welcher Performance Level ist erforderlich? Welche Sensorik, Logik und Aktorik gehören zur jeweiligen Sicherheitsfunktion? Welche Kategorie wird angestrebt? Wie werden MTTF_D, DC und CCF bewertet? Wie wird validiert?

ISO 13849 eignet sich hier gut als maschinennaher Bewertungsrahmen. Die Norm arbeitet nicht abstrakt auf Produktebene, sondern funktionsbezogen: Sicherheitsfunktion definieren, erforderlichen Performance Level bestimmen, Architektur auslegen, Diagnosen bewerten, Validierung durchführen.

ISO 13849 als „Safety nach Kochrezept“?

ISO 13849 wird im Maschinenbau häufig als vergleichsweise pragmatischer Zugang zur funktionalen Sicherheit verstanden. Das ist nicht ganz falsch. Für Maschinenintegratoren ist das anschlussfähig, weil sich viele Sicherheitsfunktionen aus bekannten Bausteinen zusammensetzen lassen.

In diesem Sinn ist ISO 13849 näher an einem Rezept als IEC 61508. Die Norm beschreibt einen Weg, wie sicherheitsbezogene Teile von Steuerungen bewertet und validiert werden können. Gerade bei Nachrüstungen oder Erweiterungen bestehender Maschinen ist das attraktiv, weil der Scope begrenzt werden kann. Es muss nicht die gesamte Maschine neu entwickelt werden. Stattdessen werden konkrete Sicherheitsfunktionen betrachtet.

Das verkürzt den Entwicklungsprozess aber nur unter bestimmten Bedingungen.

Der Vorteil liegt nicht darin, dass Embedded Safety dadurch technisch einfach wird. Der Vorteil liegt darin, dass die Norm eine maschinennahe Struktur vorgibt und sich der Nachweis auf definierte Sicherheitsfunktionen begrenzen lässt. Für einfache elektromechanische oder zugekaufte Safety-Komponenten funktioniert diese Logik gut. Warum? Weil bekannte Safety-Marken Ihre Geräte nicht nach der ISO 13849, sondern der IEC 61508 entwickeln.

Es lohnt sich ein Blick in die Konformitätserklärungen bzw. die Baumusterprüfbescheinigungen relevanter Komponenten:

Hier gilt das „Voraus-Argument“: Da die IEC 61508 branchenübergreifend höhere oder gleichwertige Anforderungen an Hardware-Fehlertoleranzen und Software-Lebenszyklen stellt, ist es naheliegend, dass das Device auch die Kriterien für den Performance Level (PL) erfüllt.

Bei eigener komplexer Embedded-Elektronik entsteht somit eigentlich praktisch immer der Entwicklungs- und Nachweisaufwand nach IEC 61508.

Die Sicherheitsfunktion ist trivial. Die sichere Ausführungsplattform ist es nicht.

Viele Sicherheitsfunktionen sehen auf Maschinenebene einfach aus:

• Schutztür offen → Maschine stoppt.
• Not-Halt betätigt → Energie wird abgeschaltet.
• Grenzwert überschritten → Bewegung wird gestoppt.
• Freigabe fehlt → Antrieb bleibt gesperrt.

In diskreter oder elektromechanischer Technik kann eine solche Funktion vergleichsweise direkt aufgebaut werden. Bei einer MCU-basierten Lösung verschiebt sich die Komplexität in die Elektronik und Software. Denn der Mikrocontroller ist nicht nur ein passiver Signalpfad. Er ist die Instanz, die entscheidet.

Ein sicherheitsbezogenes Embedded-System muss daher nicht nur Eingänge redundant erfassen und Ausgänge abschalten. Es muss auch die eigene Rechenplattform überwachen. Ein paar Beispiele:

• CPU- und Core-Überwachung,
• Watchdog-Konzept,
• Clock- und PLL-Überwachung,
• Überwachung von Interrupt-Controller und NVIC,
• Program-Flow-Monitoring,
• Stack- und Speicherüberwachung,
• RAM-Tests,
• Flash-Tests und CRC-Prüfungen,
• Register- und CPU-Selbsttests,
• Brown-out- und Spannungsüberwachung,
• Reset-Konzept,
• sichere Initialisierung,
• Peripherie-Überwachung,
• GPIO- und ADC-Plausibilisierung,
• Fehlerreaktion und sicherer Zustand.

Das ist der Teil, der von außen oft nicht sichtbar ist. Der Kunde sieht Eingänge, Ausgänge und Abschaltung. Tatsächlich entwickelt man aber eine sicherheitsbezogene Rechenplattform mit Core Safety, Diagnosemechanismen und dokumentierter Fehlerreaktion.

Ein Beispiel sind Functional-Safety-Libraries von Mikrocontroller-Herstellern. ST bietet etwa Functional-Safety-Libraries für STM32 an, die unter anderem Mechanismen zur Überwachung und Prüfung von CPU, Speicher, Clock-System, Interrupt-Strukturen wie NVIC und weiteren sicherheitsrelevanten MCU-Funktionen bereitstellen. MCU-Hersteller sichern sich in der Regel über Safety Manuals ab, dass für das Erreichen eines SIL-Niveaus bestimmte Entwicklungsschritte vonnöten sind.

Der entscheidende Punkt ist dabei immer: Eine Applikation kann nicht einfach behaupten, dass ein Mikrocontroller korrekt arbeitet. Sie muss Maßnahmen definieren, mit denen Fehler erkannt oder beherrscht werden. Genau deshalb wächst der Aufwand bei eigener Embedded-Elektronik schnell, auch wenn die eigentliche Maschinenfunktion einfach wirkt.

Das Safety Manual als zentrales Bindeglied

Bei sicherheitsbezogener Elektronik wird das Safety Manual zu einem wichtigen Dokument. Es beschreibt, unter welchen Annahmen eine Komponente oder Plattform in einer Sicherheitsfunktion verwendet werden darf.

Ein Safety Manual enthält typischerweise Informationen zu:

• zulässigen Betriebsbedingungen,
• Annahmen zur Systemintegration,
• Diagnosemechanismen,
• erforderlichen externen Maßnahmen,
• Fehlerreaktionen,
• Grenzen der Verwendung,
• sicherheitsrelevanten Konfigurationsvorgaben,
• bekannten Einschränkungen,
• Annahmen zu Takt, Versorgung, Reset, Watchdog und Peripherie,
• Hinweisen zu FMEDA, FIT-Werten oder Failure Modes.
• und ganz besonders: Anforderungen an Software im Betrieb und während der Initialisierung

Bei zugekauften Safety-Komponenten ist das Safety Manual oft die Grundlage für die Integration in eine Maschine. Bei eigener Embedded-Elektronik muss eine vergleichbare Argumentation erstellt werden. Dann reicht es nicht, eine Platine zu entwickeln und anschließend einen PL zu berechnen. Es muss beschrieben werden, wie diese Platine sicherheitsbezogen verwendet werden darf, welche Annahmen gelten und welche Maßnahmen zwingend erforderlich sind.

Das Safety Manual verbindet damit Produktentwicklung und Maschinenintegration. Es macht aus einer Elektronik nicht automatisch eine sichere Komponente, aber es dokumentiert die Bedingungen, unter denen sie in einer Sicherheitsfunktion eingesetzt werden kann.

Gerade bei wiederverwendbaren Sicherheitsplatinen ist das entscheidend. Eine Platine, die in mehreren Maschinen Sicherheitsfunktionen übernehmen soll, braucht klare Integrationsgrenzen. Welche Eingänge dürfen für welche Signale verwendet werden? Welche Ausgangspfade sind für welche Abschaltfunktionen geeignet? Welche Diagnose muss aktiviert sein? Welche Fehler führen zu Abschaltung? Welche externen Tests sind notwendig? Welche Reaktionszeiten gelten? Welche Annahmen zur Umgebung, Verdrahtung und Instandhaltung wurden getroffen?

Validierung nach ISO 13849-2: Der unterschätzte Aufwand

Mit Blick auf die Maschine kann die ISO 13849-2 herangezogen werden. Sie muss zeigen, dass die sicherheitsbezogenen Teile der Steuerung die spezifizierten Anforderungen erfüllen. Das ist ein geringfügig geringerer Dokumentationsaufwand gegenüber der IEC 61508, aber dennoch bleibt eine große Anzahl prozessualer Evidenzen.

Dazu gehören insbesondere:

• Validierung der Sicherheitsfunktionen,
• Validierung der Performance Levels und Kategorien,
• Validierung der Festlegungen von Kategorien,
• Validierung von MTTF_D, DC und CCF,
• Validierung von Maßnahmen zur Vermeidung systematischer Ausfälle,
• Validierung der sicherheitsbezogenen Software,
• Verifizierung und Validierung des erreichten Performance Levels,
• Validierung der Umgebungsanforderungen,
• Validierung der Instandhaltungsanforderungen,
• Validierung der technischen Dokumentation und Benutzerinformation.

Für die sichere Embedded-Elektronik kann eigentlich dann der gesamte Prozess der IEC 61508 dargelegt werden: Es braucht Spezifikationen, Architektur, Tests und Nachweise. Die Sicherheitsfunktion muss spezifiziert werden. Die Hardware muss spezifiziert werden. Die Hardware-Architektur muss nachvollziehbar sein. Die Software muss beschrieben werden.

Bei komplexeren Systemen sind Software-Architektur und Modulspezifikationen erforderlich. Die Tests müssen geplant, durchgeführt und dokumentiert werden.

Typische Nachweise sind:

• Software-Modultests,
• Software-Integrationstests,
• Hardware-Software-Gesamttests,
• Funktionsprüfungen,
• Fehleranalysen,
• Tests der Diagnosemechanismen,
• Tests der Fehlerreaktion,
• Tests der sicheren Zustände,
• Tests der Wiederanlaufbedingungen,
• Testberichte,
• Validierungsbericht.

Damit nähert sich die Praxis stark dem, was man aus IEC 61508 oder IEC 62061 kennt. Mitunter fallen Gesamtvalidierung und Co. geringer aus, weil man argumentieren kann, dass diese in der Gesamtintegration stattfinden. Eine eigenständige Zertifizierung der Individualelektronik kann somit ausfallen. IEC 61508 muss jedoch verpflichtend angewandt werden.

Das letzte Wort hat dabei aber immer der Notified Body. Auch wenn ISO 13849 auf Maschinenebene pragmatischer wirkt, entsteht bei komplexer Embedded-Elektronik ein vollständiger Entwicklungs- und Nachweisprozess.

ISO 13849, IEC 62061 und IEC 61508: Wo liegt der Unterschied?

ISO 13849, IEC 62061 und IEC 61508 sind in vielen Punkten kompatibel, aber sie haben unterschiedliche Schwerpunkte.

ISO 13849 ist maschinennah und technologieoffen. Sie kann elektrische, elektronische, mechanische, hydraulische und pneumatische Komponenten in sicherheitsbezogenen Steuerungsteilen berücksichtigen. Die Bewertung erfolgt über Performance Level.

IEC 62061 ist stärker auf elektrische, elektronische und programmierbare elektronische Steuerungssysteme im Maschinenbau ausgerichtet. Die Bewertung erfolgt über SIL.

IEC 61508 ist die generische Grundnorm für funktionale Sicherheit von E/E/PE-Systemen. Sie betrachtet den Sicherheitslebenszyklus umfassender und ist besonders relevant, wenn eine wiederverwendbare Safety-Elektronik oder Safety-Plattform entwickelt werden soll.

Für die konkrete Maschine kann ISO 13849 sehr gut passen. Für die Entwicklung einer komplexen Embedded-Safety-Platine kann eine IEC-61508-orientierte Vorgehensweise jedoch sauberer sein, selbst wenn die spätere Maschinenintegration nach ISO 13849 oder IEC 62061 erfolgt.

Das führt zu einer wichtigen Unterscheidung:

• Wenn eine bestehende Maschine um konkrete Sicherheitsfunktionen ergänzt wird, ist ISO 13849 oft der naheliegende Rahmen.
• Wenn eine wiederverwendbare Safety-Elektronik entwickelt wird, die in unterschiedlichen Maschinen eingesetzt werden soll, sollte die Entwicklung stärker an IEC 61508 ausgerichtet werden.
• Wenn eine Maschine mit E/E/PE-Sicherheitsfunktionen gesamthaft über SIL betrachtet werden soll, ist IEC 62061 naheliegend.

In der Praxis können diese Ansätze kombiniert werden. Sicherheitsbezogene Teile einer Maschinensteuerung können nach ISO 13849 bewertet werden und gleichzeitig Komponenten enthalten, die nach IEC 61508 oder IEC 62061 entwickelt wurden.

Für den beschriebenen Use Case ist somit der beschriebene Ansatz aus ISO 13489 und IEC 61508 für die Gesamtelektronik

ISO 13849 unter der Maschinenverordnung

Die Maschinenverordnung (Verordnung (EU) 2023/1230) wird ab 2027 in der Europäischen Union verbindlich gelten und die bisherige Maschinenrichtlinie ablösen. Für Hersteller, Betreiber und Integratoren bedeutet das: Sicherheitsfunktionen, Software, Sicherheitsbauteile und technische Dokumentation geraten stärker in den Fokus.

ISO 13849 ist unter der Maschinenrichtlinie harmonisiert. Eine Harmonisierung unter der Maschinenverordnung gilt als naheliegend. Für die Praxis bleibt die Norm damit ein wichtiger Weg, um sicherheitsbezogene Steuerungsteile von Maschinen nachvollziehbar auszulegen und zu validieren.

Für Legacy-Maschinen entsteht daraus ein typischer Anwendungsfall: Bestehende Maschinensteuerungen können weiterverwendet werden, wenn sie nicht als sicherheitsrelevante Instanz betrachtet werden. Die sicherheitsbezogenen Funktionen werden durch zusätzliche Hardware, sichere Sensorik, sichere Abschaltpfade und ein dokumentiertes Sicherheitskonzept ergänzt.

Das ist keine nachträgliche Legalisierung unsicherer Technik. Es ist eine technische und normative Entkopplung: Die bestehende Steuerung bleibt Prozesssteuerung. Die neue Sicherheitsarchitektur übernimmt die Sicherheitsfunktionen.

Fazit

ISO 13849 ist ein geeigneter Rahmen, um Maschinen durch zusätzliche Sicherheitsfunktionen zu ertüchtigen. Die Sicherheitsfunktion selbst kann dabei sehr einfach wirken. Technisch entsteht jedoch eine sicherheitsbezogene Rechenplattform.

Bei Indivdualelektronik müssen die Prinzipien der IEC 61508 gelten. Der Mikrocontroller muss überwacht werden. Speicher, Clock, Interrupts, Programmlauf, Versorgung und Peripherie müssen betrachtet werden. Functional-Safety-Libraries können dabei unterstützen, ersetzen aber nicht Sicherheitskonzept, Safety Manual, Validierung und Systemnachweis.

Eine eigenständige Zertifizierung der Individualelektronik ist dabei nicht zwingend erforderlich, wenn die Elektronik ausschließlich im Kontext der konkreten Maschine bewertet und als Teil des sicherheitsbezogenen Steuerungsteils nach ISO 13849 validiert wird. Die Sicherheit wird dann nicht als isolierte Produkteigenschaft der Platine nachgewiesen, sondern innerhalb der jeweiligen Sicherheitsfunktion der Maschine.

Das reduziert jedoch nicht die technischen Anforderungen an die Entwicklung. Bei komplexer Embedded-Elektronik muss der Entwicklungsprozess trotzdem die Denkweise der funktionalen Sicherheit aufnehmen: systematische Fehlervermeidung, Diagnosekonzept, sichere Fehlerreaktion, Software-Architektur, Tests, Änderungsmanagement, technische Dokumentation und Safety Manual. Eine IEC-61508-orientierte Entwicklung kann hierfür der sinnvollere interne Maßstab sein, auch wenn der formale Maschinennachweis über ISO 13849 erfolgt.

Kurz gesagt: ISO 13849 kann den Nachweisrahmen für die Maschine liefern. Die Individualelektronik muss nicht zwingend eigenständig zertifiziert werden. Entwickelt werden sollte sie dennoch mit der Disziplin einer Safety-Elektronik.