Safety-Software für Mikrocontroller und Prozessoren SIL3-Entwicklung mit Plattform-Software vereinfachen

Mit zertifizierter Plattform-Software, Referenzdesigns und modularen Safety-Apps lässt sich der Aufwand für SIL3-fähige Embedded-Systeme deutlich reduzieren.

In der internationalen Basisnorm für funktional sichere elektronische und programmierbare Systeme, der IEC 61508, wird bei der Softwareentwicklung zwischen Full Variability Language (FVL) und Limited Variability Language (LVL) unterschieden. Für komplexe Sicherheitsfunktionen werden meistens Programmiersprachen mit voller Variabilität (z. B. C, C++ oder strukturierter Text) verwendet.

Programmiersprachen mit eingeschränkter Variabilität ermöglichen die Erstellung von Sicherheitsfunktionen durch die Konfiguration bereits zertifizierter Funktionsbausteine und deren Verschaltung. In der Automatisierungstechnik kommen häufig PLCopen-konforme Funktionsbausteine zum Einsatz. In der Lehrveranstaltung „Funktionale Sicherheit“ an der TH Köln werden Sicherheitssteuerungen von der Firma Pilz eingesetzt. Mit der LVL-programmierbaren Sicherheitssteuerung PNOZmulti ist die Erstellung von Sicherheitsfunktionen so einfach, dass die Studierenden des 5. Semesters Elektrotechnik im Rahmen eines Praktikumsversuchs im TH-Labor sehr gut damit zurechtkommen.

Bildergalerie

Bei der PNOZmulti werden die Blöcke zunächst grafisch ausgewählt und platziert. Falls notwendig, werden sie anschließend konfiguriert und dann grafisch verschaltet. Die Sicherheitsfunktion wird automatisch zweikanalig, also mit Redundanz, ausgeführt. Auch um die notwendige Diagnose muss sich der Anwender nicht kümmern, da die Testfunktionen automatisch hinzugefügt und im Hintergrund ausgeführt werden.

Die Entwicklung und Zertifizierung von funktional sicheren FVL-programmierten Subsystemen wie Safety-Sensoren und -Aktoren war bisher sehr zeitaufwändig und teuer. Für die Entwicklungen von sicheren Embedded-Systemen wurden oft spezialisierte externe Dienstleister beauftragt, da die erforderlichen Erfahrungen in vielen Firmen nicht vorhanden sind. Diese hohen initialen Hürden stellen für kleine bis mittelständische Unternehmen eine Herausforderung dar.

Moderne Prozessoren für sicherheitskritische Embedded-Systeme benötigen in der Regel Selbsttestbibliotheken, die üblicherweise von den jeweiligen Herstellern zertifiziert und oft kostenfrei zur Verfügung gestellt werden. Der Halbleiterhersteller Renesas stellt darüber hinaus einen zertifizierten Compiler für die Renesas-eigenen (RX) Cores, zertifizierte sicherheitsgerichtete Feldbusprotokolle, das zertifizierte SIL3 System Software Kit, ein Safety Manual, Safety-Referenz-Hardwaredesigns und User Guides zur Verfügung. Bemerkenswert ist, dass das SIL3-FuSa-Solution-Portfolio seit Dezember 2025 nicht mehr gekauft werden muss, sondern für den kostenfreien Download lediglich ein End User License Agreement (EULA) mit Renesas erforderlich ist.

Mit dem SIL3-FuSa-Solution-Portfolio, welches unter anderem die Functional Safety Platform Software (PL-SW) enthält, lassen sich funktional sichere Embedded-Systeme jetzt in vier Schritten deutlich schneller und kostengünstiger entwickeln:

• 1. Auswahl eines geeigneten Hardware-Referenzdesigns

• 2. Konfiguration der Plattform-Software von Renesas

• 3. Modulare Implementierung von Safety-Algorithmen als PL-SW-Applikationen (App), vorzugsweise in der Programmiersprache C

• 4. Zertifizierung der Konfiguration und der selbst implementierten Safety-PL-SW-Apps

Der für Embedded-Systeme neue Ansatz ähnelt der bewährten Vorgehensweise bei Sicherheitssteuerungen für die Automatisierungstechnik.

• Der Anwender kauft die erforderlichen Hardwarekomponenten.

• Der Anwender nutzt bereitgestellte, kauft oder erstellt die gewünschten Safety-Algorithmen der PL-SW-Apps, die in der Programmiersprache C als FVL-Anwendung programmiert sind. Diagnose, Quervergleich etc. werden dagegen weitgehend von der entsprechend konfigurierten PL-SW ausgeführt.

Im Folgenden werden die einzelnen Schritte näher erläutert:

Auswahl eines geeigneten Referenzdesigns

Die Redundanz bei PL-SW basiert auf der Nutzung von zwei Mikrocontroller-Units (MCU) bzw. zwei Mikroprozessor-Units (MPU), mit einem Safety-Master und einem Safety-Slave. Dadurch ergibt sich die in Bild 1 dargestellte weit verbreitete 1oo2-Architektur (1-out-of-2) für Fail-Safe-Anwendungen. Ein zusätzlicher Watchdog wird nicht benötigt. Beide MCUs verfügen über separate Taktgeneratoren und Spannungsversorgungen, die sich gegenseitig monitoren und die Betriebstemperatur redundant überwachen. Es ist nicht möglich, SIL3-Safety-Anwendungen mit einer MPU mit zwei Prozessoren aufzubauen. Die Kommunikation zwischen den beiden Prozessoren erfolgt seriell im Voll-Duplex-Modus über UART-Schnittstellen mit LVTTL-Pegeln.

Je nach Anwendung werden MCUs oder MPUs ausgewählt. Die Entscheidung hängt hauptsächlich von der gewünschten Rechenleistung ab. Es ist möglich, zwei MCUs klassisch ausschließlich für Safety-Anwendungen zu nutzen, wie z. B. bei einer Safety-Optionskarte für Antriebe. Alternativ lassen sich auch mit MPUs gemischt kritische Anwendungen entwerfen. Dabei stellen Methoden aus der IT, wie die Memory Protection Unit, die Rückwirkungsfreiheit von nicht sicherheitsrelevanten auf sicherheitskritische PL-SW-Apps sicher. Bei MPUs mit zwei CPUs kann Shared RAM für die Kommunikation zwischen nicht sicheren Workloads, wie z. B. ein EtherCAT Stack, und sicherheitsrelevanten PL-SW-Apps, wie z. B. die Bearbeitung des FSoE-Protokolls, genutzt werden.

Renesas bietet für verschiedene MCUs und MPUs FuSa-Evaluation-Kits an. Diese basieren auf zertifizierungsfähigen Schaltungen und sind häufig auch mit funktional sicheren 24 V Ein- und Ausgängen ausgestattet. Zudem sind die UART-Schnittstellen der Prozessoren bereits für die Safety-Diagnose verschaltet. Auf dem RZ/T2L Safety-Network-Kit mit zwei MPUs, die auf einer Arm-Cortex-R52-Architektur basieren und mit bis zu 800 MHz getaktet werden, lassen sich beispielsweise auch von Renesas zur Verfügung gestellte sichere Feldbus-Stacks nutzen.

Konfiguration der Plattform-Software

Die PL-SW umfasst C-Quelltexte, Headerdateien sowie bereits kompilierte Objektdateien [1]. Für die Renesas-eigenen RX-Prozessoren steht ein Safety-zertifizierter C-Compiler von Renesas bereit. Bei Prozessoren mit Arm-Architektur empfiehlt Renesas den Safety-zertifizierten C-Compiler von IAR Systems.

Die Basis von der PL-SW ist der Scheduler, der sowohl sicherheitsrelevante als auch nicht sicherheitsrelevante PL-SW-Apps zyklisch ausführt. Die Basis-Zykluszeit von PL-SW kann über eine Konstante in einer Header-Datei in Mikrosekunden parametriert werden. Maximal sind 65 ms einstellbar. Für jede PL-SW-App werden feste Zeitfenster innerhalb der Basis-Zykluszeit parametriert, in dem die App ausgeführt werden soll. Auf diese Weise stellt der Scheduler eine sicherheitsrelevante Echtzeit-Multithreading-Umgebung bereit.

Bild 2 zeigt ein Blockdiagramm einer beispielhaften PL-SW-Konfiguration mit zwei sicherheitsrelevanten und einer nicht sicherheitsrelevanten PL-SW-App. Der grün dargestellte Scheduler läuft synchron auf beiden MPUs im Exception Level 2 (EL2), dem Hypervisor-Modus. Die PL-SW sorgt dafür, dass Selbsttests von CPU, Memory etc. zyklisch ausgeführt werden und dass beide Kanäle die Safety-PL-SW-Apps synchron ausführen.

Die Safety-PL-SW-Apps, dargestellt durch gelbe Blöcke, werden redundant im Supervisor- oder Systemmodus (EL1) auf beiden MPUs ausgeführt. Die nicht sicherheitsrelevante PL-SW-App, dargestellt durch einen einzelnen weißen Block, wird dagegen nur auf einer MPU in einer isolierten Umgebung im Benutzermodus (EL0) ausgeführt. Es können bis zu 16 verschiedene PL-SW-Apps konfiguriert werden, welche auch mehrmals pro Basiszyklus ausgeführt werden können. Die Memory Protection Unit verhindert den Zugriff auf sicherheitsrelevante Speicherbereiche und sicherheitsrelevante MPU-Peripherie.

Die vom Anwender zu erstellende Hook-Funktion wird bei Systemfehlern von der PL-SW aufgerufen. Sie aktiviert beispielsweise bei Safety-Ausgängen den sicheren Zustand. Systemfehler führen in einen Fehlerzustand, bei dem gemäß der Norm kein automatischer Neustart erfolgt. Zu beachten ist außerdem, dass auch nicht sichere PL-SW-Apps bei Systemfehlern nicht mehr ausgeführt werden.

Die PL-SW erkennt und meldet verschiedene Fehler:

• Zeitüberschreitungen während der Initialisierung,

• Fehler während der CPU- und RAM-Tests,

• nicht erlaubte Zugriffe auf Speicher oder Peripherie,

• Fehler während der Scheduler-Überwachung, und

• Abweichungen beim Cross-Monitoring.

Bei den Safety-PL-SW-Apps sollte jeweils eine geeignete Fehlerreaktion vorgesehen werden. Tritt beispielsweise bei einer sicheren Feldbusverbindung ein Fehler auf, reicht es aus, die davon abhängigen Signale in den sicheren Zustand zu schalten, bis die Verbindung neu aufgebaut ist. Bei internen Fehlern von PL-SW-Apps, z. B. bei einem fehlerhaften Kreuzvergleich bei der redundanten S-PDU-Verarbeitung (Safety Protokoll Data Units), sollte die Hook-Funktion genutzt werden.

Wie in Bild 3 dargestellt gibt es bei der Ausführung der PL-SW drei Phasen:

• 1. Starten, Initialisieren, Systemtest und Synchronisation der Kanäle

• 2. Zyklisch-synchrone Ausführung der PL-SW-Apps, gesteuert und überwacht vom Scheduler

• 3. INur im Falle von Systemfehlern wird zur Diagnose eine Fehlermeldung gespeichert. Anschließend werden die Ausgänge mit der Hook-Funktion sicherheitsgerichtet abgeschaltet, um einen sicheren Zustand zu erreichen.

Bei den RZ/T2M-MPUs mit 800 MHz Prozessortakt werden am Anfang der Basis-Zykluszeit ca. 35 µs von der PL-SW für Software-Selbsttests etc. benötigt. Anschließend werden die konfigurierten PL-SW-Apps ausgeführt, bis am Ende der Basis-Zykluszeit die Synchronisation der Kanäle erfolgt.

Modulare Implementierung von Safety-Algorithmen

Es gibt verschiedene Bezugsmöglichkeiten für PL-SW-Apps:

• Bezug von einem Hersteller wie Renesas, zum Beispiel FSoE, Profisafe oder CIP Safety (kostenlos gegen EULA);

• Kauf als Software-IP von einem Drittanbieter, zum Beispiel ein Protokoll-Stack zur Verarbeitung eines funktional sicheren Encoderprotokolls; oder

• Erstellung durch den Anwender für sein spezielles Produkt.

Die Prozessdatenkommunikation mit PL-SW-Apps wird durch fest definierte Shared-RAM-Bereiche, bevorzugt im TCM, realisiert. So kann beispielsweise ein nicht sicherer Feldbus-Stack wie EtherCAT als Teil des Black-Channels zyklisch FSoE S-PDUs im Shared RAM bereitstellen. Eine FSoE PL-SW-App bearbeitet das FSoE S-PDU dann redundant und stellt die übertragenen Safety-Daten zyklisch im konfigurierten Shared-RAM-Bereich beider MPUs bereit.

Zur Überwachung der Systemintegrität und zur Programmablaufkontrolle generieren sicherheitsrelevante PL-SW-Apps in jedem Zeitfenster zwei Signaturwerte. Jede PL-SW-App muss die CPU vor Ablauf des konfigurierten Zeitfensters wieder aktiv an den Scheduler zurückgeben. Besonders bei Safe-Motion-Anwendungen ist es von Vorteil, dass auch die Double-Precision Floating-Point-Units (FPU) der CPUs genutzt werden können.

Zwar sind Safety-IRQs möglich, aufgrund des erforderlichen EL-Kontextwechsels haben sie jedoch einen deutlich höheren Overhead. Da der Hypervisor-Modus nicht von IRQs unterbrochen wird, kann außerdem eine Verzögerung entstehen.

Das SIL3-FuSa-Solution-Portfolio verringert den Aufwand für die Zertifizierung erheblich. Zusätzlich stellt Renesas Musterdokumente und einen Leitfaden zur Vorbereitung der Zertifizierung nach IEC 61508 zur Verfügung. Die Zeit und die Kosten für die Zertifizierung der anwendungsspezifischen Hardware- und Softwareerweiterungen sollten jedoch nicht unterschätzt werden. Insbesondere, solange keine ausreichenden Erfahrungen mit der Zertifizierung von Embedded-Safety-Anwendungen vorhanden sind, sollten spezialisierte externe Dienstleister hinzugezogen werden.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Virtualisierung der Safety-Karte für Antriebe

Bei Antrieben war es lange üblich, die Safe-Motion-Sicherheitsfunktionen auf einer optionalen Steckkarte auszuführen. Auf der PCIM 2026 im Juni 2026 wurde vorgestellt, wie sich mit zwei MPUs und ohne FPGA oder ASIC ein sehr performanter 2-Achs-Servoantrieb inklusive Safe-Motion mit einer virtuellen Safety-Karte designen lässt.

Bild 4 zeigt eine Steuerungsarchitektur für einen Doppelachsantrieb mit Safe-Motion, für die lediglich zwei MPUs erforderlich sind. Auf CPU0 vom RZ/T2M werden drei sichere PL-SW-Apps als Safety-Master ausgeführt sowie eine nicht sichere PL-SW-App für Motor-Control. Die Motor-Control-PL-SW-App ersetzt die sonst übliche Interrupt-Serviceroutine und wird zyklisch mit 16 kHz aufgerufen. Konfiguriert sind dafür 50 % der Rechenzeit. CPU1 wird hauptsächlich für die Feldbusanschaltung genutzt. Die Hardware des RZ/T2M unterstützt ohne zusätzliche ASICs oder FPGAs die Protokolle EtherCAT, PROFINET IRT, Ethernet IP und viele weitere Feldbusse sowie verbreitete Encoder-Protokolle wie EnDat 2.2, EnDat 3, Hiperface DSL, BiSS, etc.

Der RZ/T2L wird ausschließlich als PL-SW Safety-Slave genutzt und kommuniziert über UARTs mit dem Safety-Master.

Trotz der sehr hohen Rechenleistung der MPUs verringert diese Architektur sowohl die Energieaufnahme als auch die benötigte Leiterplattenfläche. Dadurch wird das Hardwaredesign kompakter, weniger komplex und kostengünstiger.

Ausblick

Nachdem die ersten funktional sicheren Embedded-Systeme vor fast 20 Jahren kommerzialisiert und standardisiert wurden, ändern sich durch das inzwischen kostenlos angebotene SIL3-FuSa-Solution-Portfolio von Renesas die Rahmenbedingungen nun deutlich zugunsten der Anwender:

• PL-SW vereinfacht die modulare und strukturierte Entwicklung von Embedded-Safety-Systemen erheblich, sodass sich Entwickler viel schneller einarbeiten können.

• Mit PL-SW können Studierende jetzt auch FVL-Safety-Anwendungen im Rahmen von Abschlussarbeiten funktional (ohne Zertifizierung) erstellen. Dadurch werden Innovationen erleichtert.

• Embedded-Safety wird skalierbar. Es ist sehr wahrscheinlich, dass die Kosten für PL-SW-Software-IP aufgrund der erwartbar höheren Stückzahlen deutlich sinken werden. Auch bei Safety führen höhere Stückzahlen in der Regel zu einer besseren Produktqualität.

• Jetzt wird es möglich, dass Anbieter von Komponenten, z. B. von Safety-Encodern, auch eine dazu passende PL-SW-App bereitstellen, die das zugehörige Safety-Protokoll verarbeitet.

In einem künftigen Folgeartikel zu diesem Beitrag gehen wir auf Wahl und Entwicklung einer besonders kostengünstigen, zertifizierbaren Referenzhardware ein. (sg)

* Prof. Dr.-Ing. Jens Onno Krah ist Professor für Regelungstechnik, Motion Control, FPGA-basierte digitale Signalverarbeitung und funktionale Sicherheit an der TH Köln.

* Joschka Laufs-Randerath ist wissenschaftlicher Mitarbeiter mit den Schwerpunkten Safe Motion, Funktionale Sicherheit und Antriebstechnik an der TH Köln

(ID:50969786)