Microchip Technology

MCUs übernehmen auch die Safety

6. März 2023, 14:09 Uhr | Von Bob Martin
Sicherheit ist in den unterschiedlichsten Branchen seit vielen Jahren ein wichtiges Thema. Werden die Systeme aber auch noch zunehmend autonom, muss der »Safety« mit intelligenteren Sicherheitssystemen Rechnung getragen werden
© Stanisic Vladimir|stock.adobe

Sicherheit ist in den unterschiedlichsten Branchen seit vielen Jahren ein wichtiges Thema. Werden die Systeme aber auch noch zunehmend autonom, muss der »Safety« mit intelligenteren Sicherheitssystemen Rechnung getragen werden.

Die diversen Safety-Normen in den verschiedenen Marktsegmenten zeigen, dass das Thema wirklich etabliert ist. Doch die Schwerpunkte in den Branchen verschieben sich, denn mittlerweile spielen neben dem Aspekt der Kosteneinsparungen vor allem auch der Benutzerkomfort und die Sicherheit – im Sinne von Safety – eine entscheidende Rolle. Gerade der letzte Punkt mit Hinblick auf autonome Systeme macht eine vollständige funktionale Sicherheitsebene (Functional Safety) notwendig und diese Sicherheitsebene kann mithilfe eines Co-Prozessors realisiert werden. Und das Gute daran: Diese Aufgabe kann auch von kostengünstigen Mikrocontrollern (MCUs) durchgeführt werden, vorausgesetzt sie wurden für diese Aufgabe ausgelegt.

Grundsätzlich dient der Co-Prozessor dazu, die Ein- und Ausgangssignale vom Hauptprozessor zu verifizieren und eine Plausibilitätsprüfung durchzuführen, um sicherzustellen, dass alles auch wirklich so funktioniert, wie es funktionieren soll. Dementsprechend können 8-, 16- und 32-Bit-MCUs in den drei Hauptbereichen der funktionalen Sicherheit eingesetzt werden, in denen die folgenden Standards gelten:

➔ ISO 26262: Automotive Safety Integrity Applications (ASIL) für Automobilanwendungen
➔ IEC 61508: Sicherheits-Integritätslevels (SIL) für industrielle Anwendungen
➔ IEC 60730: Funktionale Sicherheitsstandards für Haushaltsgeräte

Und klar: es gibt keine Safety ohne Security, das heißt zum Beispiel, dass natürlich auch gewährleistet sein muss, dass die Daten oder Fraktale, mit denen gearbeitet wird oder die neu geladen wurden, auch die richtigen/wahren Daten sind. Vorausgesetzt die Security ist gewährleistet, können einfache MCUs die Safety auch von autonomen Systemen deutlich erhöhen.

Anbieter zum Thema

zu Matchmaker+

MCU als Safety-Co-Prozessor

Die wichtigste Interaktion mit der Außenwelt erfolgt über Hardware-Layer, angefangen bei den direkten Sensor- und Aktorschnittstellen, die von den FuSa-fähigen MCUs im Edge bereitgestellt werden. Dementsprechend sind folgende Funktionen für Controller, die als Co-Prozessor für die Safety zuständig sind, unabdingbar.

BOD (Brown-out Detection): Nur sehr wenige Betriebsumgebungen verfügen über perfekte Stromversorgungen. Bekanntermaßen können Mikrowellenherde aber auch Laserdrucker die Beleuchtung zum Flackern bringen, große Elektrowerkzeuge wiederum können Leitungsschutzschalter auslösen. Folglich müssen sicherheitskritische Systeme genau darauf ausgelegt sein. Sie müssen wissen, dass ihre Stromversorgung ausfallen wird, bevor sie ausfällt. Denn nur dann ist es möglich, beispielsweise eine Notstromversorgung zu aktivieren oder kritische Daten zu speichern und Ausgangszustände einzustellen, mit denen eine saubere Abschaltung gewährleistet werden kann.

Sicherheitsfunktionen in einfachen 8-Bit-Mikrocontrollern, mit denen sich diese Controller als Co-Prozessor für Safety-Anwendungen auszeichnen.
Sicherheitsfunktionen in einfachen 8-Bit-Mikro-controllern, mit denen sich diese Controller als Co-Prozessor für Safety-Anwendungen auszeichnen.
© Microchip Technology

Eine BOD-Schaltung in MCUs überwacht die Versorgungsspannung kontinuierlich und reagiert auf fallende Pegel, beispielsweise indem die VLM-Funktion (Voltage Level Monitor) einen internen Interrupt auslöst, wenn ein wählbarer Schwellenwert unterschritten wird. Damit kann sichergestellt werden, dass eine Notabschaltung noch vor dem Unterschreiten des tatsächlichen BOD-Schwellenwerts eingeleitet werden kann. Wird der BOD-Schwellenwert dann wirklich unterschritten, bleibt das System im Reset-Status, bis dieser Zustand behoben ist. Darüber hinaus ist es dank einer BOD-Schaltung möglich, auch die Ursache des Reset-Ereignisses zu ermitteln. Damit kann wiederum eine geeignete Wiederherstellungsstrategie verfolgt werden, die sich durchaus vom ersten Power-on-Zyklus unterscheiden kann.

Watchdog-Timer mit Zeitfenster: Moderne MCUs nutzen Watchdog-Timer als Möglichkeit, unsichere Betriebszustände wie zum Beispiel Dead-End-Loops (Endlosschleifen) zu beenden, indem der Controller in einen definierten Zustand zurückgesetzt wird. Bei früheren Versionen wurden die Timeout-Schwellenwert im Sekunden- oder Millisekunden-Bereich gesetzt, es war aber quasi eine Art »Anstoß« durch das laufende Programm vor Ablauf des gesetzten Timeouts notwendig. Nach Quittierung wurde der Timeout-Schwellenwert zurückgesetzt, und der Countdown startete von neuem. Problem dabei war, dass die Rücksetzung des Watchdog-Timers oft willkürlich erfolgt ist, einfach weil es bequemer für die Programmierer war. Dabei ist klar, dass das Triggern des Watchdog-Timers bzw. das Rücksetzen des Watchdog-Timers nur an einer expliziten Position im Programm erfolgen sollte, ganz sicher aber nicht in einer Interrupt-Routine oder in allen möglichen Unterfunktionen.

Der Windowed Watchdog Timer vereinfacht die Sache, denn bei diesen Schaltungen kann ein Watchdog-Servicefenster spezifiziert werden. Damit ist zumindest schon einmal gewährleistet, dass der Watchdog Timer nicht zu schnell bedient wird und dass kein Programmierer sich genötigt sieht, dieses Problem mit willkürlichem Rücksetzen löst.

CRC-Code-Scan (Cyclic Redundancy Check): Ein CRC-Code-Scan-Peripherieelement sichert die Integrität des programmierten Code-Images. Dieser Ansatz ist deutlich leistungsfähiger als eine einfache Prüfsumme, denn eine Prüfsumme kann mithilfe von mathematischen Manipulationen leicht gefälscht werden. Für einen CRC-Code-Scan wird ein bestimmter Hardware-Block in der MCU so konfiguriert, dass er einen Scan des Bootloader-Abschnitts im Programmspeicher des Anwendungsabschnitts oder des gesamten Flash-Speicherarrays durchführt. Das Peripheral vergleicht dann sein CRC-Ergebnis mit der korrekten Prüfsumme, die sich am Ende des angegebenen Code-Bereichs befindet. Stimmen die beiden 16-Bit-Zahlen überein, bedeutet das, dass der Code-Bereich nicht verändert wurde. Bei Nicht-Übereinstimmung kann zur weiteren Behandlung des Problems ein »nicht-maskierbarer« Interrupt erzeugt werden.

GPIO-Peripherals (General Purpose Input/Output) mit eigenem Eingabepfad: Wenn in den Anfängen der MCUs ein GPIO-Pin als Ausgang konfiguriert war, ließ sich die Übereinstimmung des Spannungspegels am Pin (z. B. 5 V) mit dem Wert des Steuerbits (beispielsweise »1«) nur durch Nutzung eines separaten GPIO-Pins überprüfen, der zum Lesen des Spannungspegels als Eingang konfiguriert war. Ein als Ausgang konfigurierter GPIO-Pin allein konnte nicht die tatsächliche Spannung lesen, sondern nur den Wert, der ihm zugewiesen wurde; daher entsprach der »Eingangs«-Wert immer dem erwarteten Wert.

GPIO-Zellen mit eigenem Eingabepfad besitzen im Gegensatz dazu einen separaten elektrischen Pfad zu einem diskreten internen INPUT-Register, das den am Ausgangspin wirklich anliegenden Pegel wiedergibt. Auch wenn sich dieser Pegel nur als logische »1« oder logische »0« auslesen lässt, bietet er dennoch genügend Feedback für die Validierung dessen, was in das Output-Steuerregister geschrieben wurde. Eine Diskrepanz zwischen diesen beiden Werten sollte niemals auftreten. Besteht dennoch ein Unterschied zwischen beiden Werten, so liegt entweder ein Kurzschluss oder eine Unterbrechung an diesem spezifischen GPIO-Pin vor, der dann entsprechend behandelt werden muss.

MCUs mit diesen Fähigkeiten stellen die Basis für eine vollständige FuSa-Schicht dar.

Weitere Funktionen für höhere Safety

Darüber hinaus gibt es natürlich noch andere Features, die eine MCU zum prädestinierten Co-Prozessor für Safety-Aufgaben zu machen. Dazu zählt beispielsweise die automatische Erkennung eines Stack-Overflows/Underflows. Stack-Overflows können natürlich auch mit Compiler-Einstellungen vermieden werden, indem eine Funktion integriert wird, die während der Laufzeit die Größe des verbleibenden Stacks überprüft, das kostet aber Zeit. Wird das Ganze in Hardware realisiert, werden lästige und durchaus gängige Probleme verhindert, aber eben ohne Einbußen bei der Laufzeit.

Eine ebenfalls hilfreiche Funktion ist die Hardware-mäßige Überwachung des Systemtakts und falls Probleme auftreten, die automatische Umschaltung auf einen Default-System-Takt. Selbstverständlich gehört auch eine ECC-Funktionalität zu den wichtigen Funktionen, mit der Safety-kritische Systeme verbessert werden können, denn damit steht sowohl für das RAM als auch für den Flash eine Funktion zur Verfügung, die Einzelbit-/Multibit-Fehler Hardware-mäßig erkennt.

 

Der Autor

Bob Martin ist Senior Staff Engineer bei Microchip Technology.

 


Das könnte Sie auch interessieren

Verwandte Artikel

Microchip Technology GmbH