Coded-Processing-Automatisierung: Ein neuer Weg zur funktionalen Sicherheit?

DKE: Herr Dr. Süßkraut, Sie haben als erster unabhängiger Lösungsanbieter eine Tool-gestützte Lösung für Coded Processing zur Marktreife entwickelt. Was hat Sie ursprünglich dazu bewegt?

Süßkraut: Vor der eigentlichen Entwicklung stand eine Forschungsfrage: Wie kann man Coded Processing automatisieren? Coded Processing als Idee gibt es seit Ende der 1980er Jahre. Schon damals war es reizvoll, über eine rein softwarebasierte Technologie zum Aufdecken von zufälligen Fehlern in sicherheitskritischen Systemen zu verfügen. Der Vorteil war damals schon, dass statt durch zwei redundante Hardware-Kanäle die Aufdeckung von Fehlern in Software stattfindet. Allerdings sahen die damaligen Ansätze für Coded Processing aufwendige und hoch-komplexe manuelle Schritte vor. Coded Processing als Diagnosemethode steht seit Anfang an in der Norm IEC 61508. Die Methoden des Coded Processing sind auch schon langjährig in der Industrie bei Sicherheitssteuerungen im Einsatz. 

DKE: Können Sie hier Beispiele nennen?

Süßkraut: Siemens verwendet seit Jahren bereits in seiner Steuerungslösung SIMATIC F-CPUs das Prinzip des Coded Processing. Ein weiteres Beispiel ist das ehemalige französische Unternehmen Matra Transport International S.A.S., das Anwendungen mit sogenannten „Vital Processing“-Konzepten für den Einsatz in Schienenfahrzeugen weiterentwickelt hat. An der Technischen Universität Dresden haben wir in einem kleinen Team erforscht, wie Coded Processing mit einem Entwicklungswerkzeug automatisiert in die Hochsprache C eingebaut werden kann. Wir haben bereits im Jahr 2004 die Flexibilität eines rein softwarebasierten und hardwareunabhängigen Ansatzes gesehen. Unsere Forschung zielte darauf ab, diesen Ansatz einfach nutzbar zu machen und auch unabhängig von Programmiersprachen wie FBD (Funktionsbausteindiagramme) oder ST (Strukturierter Text) für speicherprogrammierbare Steuerungen. Zahlreiche Patente sind in dieser Zeit dazu entstanden.

DKE: Und nun haben Sie eine praxistaugliche Lösung vorgestellt, die alle Herausforderungen bewältigt?

Süßkraut: Ja, das Thema Performance, also die Geschwindigkeit mit der Programme mit Coded Processing ausgeführt werden, war von Anfang an die größte Herausforderung. Auf diesem Gebiet haben wir nach der Firmengründung der SIListra Systems GmbH im Jahr 2012 noch große Fortschritte gemacht. Erst diese Optimierungen ergaben die praxistaugliche Lösung mit dem SIListra Safety Transformer, die wir jetzt anbieten können und die bereits industriell im Einsatz ist. In der Zwischenzeit sind weitere Möglichkeiten hinzugekommen: C++ und die Skalierung auf Multi-Core Architekturen.

Coded Processing: Hardwareunabhängige Vorteile und Integrationsherausforderungen

DKE: In welchen konkreten Anwendungsfällen bietet Coded Processing Vorteile?

Süßkraut: Coded Processing bietet durch seine Hardwareunabhängigkeit eine größere Flexibilität als klassische Sicherheitsarchitekturen, die bedingt durch die starke Kopplung von Sicherheitsmaßnahmen auf Hardware- und auf Softwareebene an eine konkrete Hardwarearchitektur gebunden sind. Der Wechsel der zu Grunde liegenden Hardware, zum Beispiel aus Performance-Gründen oder weil eine Hardware-Komponenten nicht mehr lieferbar ist, ist wesentlich einfacher, wenn die Sicherheit nicht von der Hardware abhängt. 

Außerdem ermöglicht Coded Processing völlig neue Einsatzszenarien wie die Umsetzung neuer Architekturansätze beziehungsweise vorher nicht realisierbare Orchestrierungen von verteilten Sicherheitssystemen. Beispielsweise werden virtualisierte Sicherheitssteuerungen in der Industrieautomatisierung und der Robotik, die auf klassischer IT-Server-Hardware oder Industrie-PCs ausgeführt werden, durch Coded Processing überhaupt erst möglich. Auch in Fällen, in denen schlicht kein Platz für eine zwei- oder mehr-kanalige Hardware ist, ist Coded Processing ein industrietauglicher Lösungsansatz.

DKE: Herr Gregorio, was sind die größten praktischen Herausforderungen bei der Einführung von automatisierten Coded-Processing-Lösungen?

Gregorio: Ich sehe zwei wesentliche Herausforderungen. Zum einen ist die automatische Erstellung von Coded Processing in sicherheitskritischen Anwendungen noch Neuland. Viele Experten – sei es in der Industrie oder bei Zertifizierungs- und Prüfinstitutionen – haben bislang wenig Erfahrung damit, ähnlich wie beim Paradigmenwechsel zum „Software Defined Vehicle“ im Automotive-Bereich: Da sich die Technologie rasant entwickelt, braucht es Zeit, bis alle Beteiligten damit vertraut sind. Die zweite Herausforderung betrifft die Anpassung bestehender Systeme. Sicherheitskonzepte werden in der Regel über Jahre hinweg entwickelt, und wenn die Architektur bereits klassisch definiert ist, ist eine nachträgliche Umstellung auf den Coded-Processing-Ansatz sehr aufwendig – man muss quasi von Grund auf neu beginnen.

Beispiel aus der Praxis: Virtualisierte Sicherheitssteuerung dank Coded Processing

DKE: Können Sie ein Beispiel nennen, in dem Coded Processing zu einer konkreten Verbesserung der Systemsicherheit geführt hat?

Gregorio: Primäres Ziel von Coded Processing ist vor allem höhere Flexibilität und kürzere Entwicklungszeiten unter anderem durch Einsparung der Entwicklung einer sicherheitskritischen Hardware. Die im Vergleich zur klassischen Lösung hohen Fehleraufdeckungsraten können vor allem genutzt werden, um die Betrachtung der zu Grunde liegenden Hardware zu vereinfachen. Statt die Fehlerraten durch eine detaillierte Analyse der Hardware zu ermitteln, kann bei Coded Processing auf eine grobe Abschätzung zurückgegriffen werden. Diese grobe Abschätzung verringert dann auch die Abhängigkeit von einer konkreten Hardware und ermöglicht dadurch völlig neue Anwendungen.

Süßkraut: Zum Beispiel hat im Januar 2025 die CODESYS GmbH aus Kempten ihre zertifizierte CODESYS Virtual Safe Control SL Lösung herausgebracht. Diese virtualisierte Sicherheitssteuerung basiert intern auf unserem Coded-Processing-Ansatz und kann sicherheitskritische Anwendungen bis SIL3 auf einkanaliger x86 Hardware ausführen.

DKE Tagung Funktionale Sicherheit: 13.05.2025 bis 14.05.2025 in Erfurt

Neue Technologien und Lösungen erobern die Welt – aber wie kann funktionale Sicherheit dabei Schritt halten? Eine berechtigte Frage, die wir diskutieren wollen und müssen! Und wo wäre das besser möglich als in Erfurt? Die "Erfurter Tage" haben sich mittlerweile als fester Begriff und Branchentreff etabliert. Alle zwei Jahren kommen Expertinnen und Experten im Kaisersaal zusammen und tauschen sich aus. Seien auch Sie dabei und freuen Sie sich auf zwei intensive Konferenztage!

Dual-Kanal-Architektur & Hardwareanforderungen: Von 64-Bit bis Lockstep-Vergleich

DKE: Welche Anforderungen muss eine bestehende Architektur erfüllen, um Coded Processing zu integrieren?

Gregorio: Eine sicherheitskritische Anwendung für Coded Processing muss zu einer Software-Architektur mit den zwei Kanälen passen. Sicherheitskritische Anwendungen die auf klassische Architekturen aufbauen, erfüllen diese Voraussetzung oftmals schon. Größer sind die Herausforderungen, wenn eine vormals nicht-sichere Anwendung auf Coded Processing portiert wird.

Coded Processing ist kompatibel mit gängigen Betriebssystemen wie Linux, ohne dass diese extra zertifiziert werden müssen, da zufällige Fehler – egal ob durch das Betriebssystem oder die Hardware – erkannt werden. Aufgrund der arithmetischen Kodierung benötigt der kodierte Kanal mehr CPU-Ressourcen als der native Kanal. Durch langjährige Optimierung konnte man diesen Mehrbedarf auf ein akzeptables Verhältnis von 1:5-15 reduzieren. Zudem ersetzt Coded Processing andere rechenintensive Sicherheitsmaßnahmen, wie zyklische RAM-Checks, sodass Performance und Ressourcenanforderungen der Anwender vollständig erfüllt werden – etwas, das vor fünf bis zehn Jahren noch nicht möglich war.

DKE: Durch Coded Processing sollen Sicherheitsfunktionen auf nicht SIL-zertifizierter Hardware laufen können. Gibt es trotzdem Mindestanforderungen an die Hardware?

Süßkraut: Wie schon gesagt, benötigt der kodierte deutlich mehr Rechenressourcen als der native Kanal. Wenn die Hardware nativen Support für 64-Bit-Arithmetik hat, dann wird der kodierte Kanal deutlich beschleunigt. Hingegen haben wir Einschränkungen bei der Anwendung von Coded Processing auf kleinen Microcontrollern festgestellt, zum Beispiel auf Microcontrollern, die nativ nur 8- oder 16-Bit-Ganzzahlarithmetik unterstützen. Solche Microcontroller sind in Verbindung mit Coded Processing nur für sehr einfache Sicherheitsfunktionen geeignet.

DKE: Wie verhält sich Coded Processing im Vergleich zu klassischen Lockstep-Architekturen?

Süßkraut: Klassische Lockstep-Architekturen erreichen in der Regel maximal SIL2. Mit Coded Processing ist SIL3 auf einkanaliger Hardware möglich. Für LockStep-Architekturen ist außerdem eine aufwändige Integration der Hardware- und der Software-Sicherheitsmaßnahmen notwendig. Bei Coded Processing in automatisierten Form können sich die Entwickler auf die Sicherheitsmaßnahmen in Software konzentrieren.

Leistung & Grenzen: Hohe Effizienz, aber geringere IO-Integration

DKE: Welche Auswirkungen hat Coded Processing auf die Systemleistung?

Süßkraut: Auf den Zielarchitekturen ist der zusätzliche Speicherverbrauch durch Coded Processing meist keine Herausforderung in der Praxis. Auf Systemen mit mehreren Gigabyte RAM sind eine paar zusätzliche Megabyte Speicher für Coded Processing ohne Einschränkungen umsetzbar. Die Performance ist immer eine Diskussion und muss gemessen und bei Bedarf optimiert werden, da diese neben der Hardware auch von der konkreten Implementierung der Anwendung abhängt. Allerdings trifft das auch auf jede andere Software-Entwicklung zu. Latenzen im Bereich von unter einer Millisekunde sind mit Coded Processing möglich. Hier liegen industrielle Anwendungsbestätigungen vor, beispielsweise aus dem Robotik-Bereich.

DKE: In welchen Szenarien stößt Coded Processing an seine Grenzen?

Gregorio: Coded Processing ist ideal für die Absicherung von Anwendungen, die wiederum auf sicherer Kommunikation basieren. Somit kann Coded Processing gut für Steuerungen in Industrie und Robotik verwendet werden, die über sichere Kommunikationsprotokolle mit Aktuatoren, wie beispielsweise IO-Module (Input/Output-Module), verbunden sind. Für die Implementierung von IO-Modulen selber ist Coded Processing allein nicht geeignet. Hier sind in jedem Fall zusätzliche Hardware-Komponenten notwendig wie zum Beispiel ein smarter Watchdog, der den sicheren Zustand unabhängig von der Haupt-CPU des IO-Modules herstellen kann.

Mit unserem DKE Newsletter sind Sie immer top informiert! Monatlich ...

• fassen wir die wichtigsten Entwicklungen in der Normung kurz zusammen
• berichten wir über aktuelle Arbeitsergebnisse, Publikationen und Entwürfe
• informieren wir Sie bereits frühzeitig über zukünftige Veranstaltungen

Zukunft von Coded Processing: Normintegration und Virtualisierung als Schlüsseltrends

DKE: Wie könnte sich Coded Processing weiterentwickeln?

Süßkraut: Coded Processing ist eine Basistechnologie, ähnlich wie die IEC 61508 als Basisnorm – sie ist branchenunabhängig anwendbar, wo funktionale Sicherheit erforderlich ist. Die technische Weiterentwicklung besteht weniger in Neuerungen als in der Anpassung an branchenspezifische Sicherheitsnormen. Referenziert die Branchennorm die IEC 61508, fällt die Integration leichter aus; ansonsten kann zusätzliche Aufbereitung der Nachweise notwendig sein. 

Bereits jetzt ist Coded Processing zertifiziert für die IEC 61508, ISO 26262 (Automobilbau) sowie die Automatisierungsnormen ISO 13849-1 und IEC 62061. Im ersten Quartal 2025 folgt die Bahn-Norm EN 50716. Aktuell unterstützen wir Coded Processing für C und C++. Für die Zukunft, können wir uns vorstellen auch weitere Sprachen – etwa die Systemprogrammiersprache RUST der Mozilla Foundation – zu integrieren.

DKE: Welche Trends in der funktionalen Sicherheit werden Coded Processing beeinflussen?

Gregorio: Im Bereich funktionale Sicherheit ist Coded Processing ein Enabler für Virtualisierung. Mit Coded Processing wird es zukünftig möglich sein, Anwendungen mit sicherheitskritischen Anteilen wie beispielsweise neue Apps nachzuinstallieren. Dafür muss die Hostplattform nur ausreichend Rechenleistung zur Verfügung stellen.

DKE: Vielen Dank Herr Dr. Süßkraut und Herr Gregorio für ihre Zeit und Ihre spannenden Einsichten in Coded Processing Automation.

DKE Tagung Funktionale Sicherheit 2025: Keynotes, Fachdiskussionen, Community

Sie möchten vom 13. bis 14. Mai 2025 an der Veranstaltung in Erfurt teilnehmen? Wir freuen uns auf Sie!

Core Safety & Information Technologies umschließt alle Aspekte der Sicherheit: grundlegende  Sicherheitsanforderungen, funktionale Sicherheit, Informationssicherheit sowie deren Wechselwirkungen. Außerdem befasst sich Core Safety mit wichtigen Querschnittsthemen und definiert grundlegende Anforderungen die allgemein einzuhalten sind – zum Beispiel für Elektromagnetische Verträglichkeit, Umwelt- und Ressourceneffizienz, Schadstoffe, Größen, Einheiten und Kennzeichnungen. Weitere Inhalte zu diesem Fachgebiet finden Sie im