Mikrocontroller<\/a> 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<\/p>\n\n\n\nKann eine Maschine durch Individualelektronik und ISO 13849 auf Safety-Niveau gebracht werden?<\/h2>\n\n\n\n
Grundsätzlich: ja.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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?<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
ISO 13849 als „Safety nach Kochrezept“?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Das verkürzt den Entwicklungsprozess aber nur unter bestimmten Bedingungen.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Es lohnt sich ein Blick in die Konformitätserklärungen bzw. die Baumusterprüfbescheinigungen relevanter Komponenten:<\/p>\n\n\n\n