Startseite > Automotive > Elektromobilität > Sicherheit hoch drei

3-Ebenen-Sicherheitskonzept für Automotive-taugliche Rapid-Control-Prototyping-Plattform

Sicherheit hoch drei

10. August 2015, 10:32 Uhr | Von Christian Loske

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

3-Ebenen-Sicherheitskonzept

Vorbild für das Sicherheitskonzept der PROtroniC TopLine (Bild 2) war das standardisierte E-Gas- Überwachungskonzept [2]. Aus diesem wurden die Definition des sicheren Zustands, das Prüfkonzept sowie das 3-Ebenen-Sicherheitskonzept übernommen. Der sichere Zustand ist das zentrale Element des Sicherheitskonzeptes. Das RCP-System startet im sicheren Zustand und verlässt ihn erst, wenn es seine Integrität sichergestellt hat. Im Fehlerfall kann es in diesen Zustand zurückfallen. Hierbei muss allerdings generell zwischen dem sicheren Zustand des Steuergerätes und dem sicheren Zustand des Gesamtsystems unterschieden werden, weil diese nicht gleichbedeutend sind.

Im Gegensatz zu Seriensteuergeräten lässt sich bei einem RCP-System nicht vorhersagen, welche Ein- und Ausgänge sicherheitsrelevant sind und welche nicht. Daher muss sich in diesem Fall der sichere Zustand auf den Großteil der Ein- und Ausgänge beziehen. Die Fehlerreaktionsklassen des E-Gas-Überwachungskonzeptes beziehen sich auf die spezifischen Anforderungen von Verbrennungsmotoren und somit nur auf eine Anwendung. Die weiter unten beschriebenen Fehlerreaktionsklassen der PROtroniC TopLine sind hingegen allgemein gehalten und damit an die jeweilige Anforderung adaptierbar. Im Detail besteht das 3-Ebenen-Sicherheitskonzept (Tabelle) aus der Funktionsebene (L1), der Funktionsüberwachungsebene (L2) und der Rechnerüberwachungsebene (L3). Wichtigster Bestandteil der Funktionsebene, die im Funktionsrechner ausgeführt wird, sind Rahmen, in denen der Anwender seine eigentliche Applikation, wie Regler und Zustandsautomaten, platzieren kann.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Darüber hinaus befinden sich folgende weitere Kernfunktionalitäten der Basis-Software des Steuergerätes in der Funktionsebene:

Betriebssystem Aufbereitung der Eingangsgrößen (Sensorik)
Steuerung der Ausgangsgrößen (Aktorik)
Kalibrierungs- und Messfunktionen
Komponentenüberwachungen
Diagnose der Ein- und Ausgangsgrößen
Steuerung der Systemreaktionen im erkannten Fehlerfall

Die Funktionsüberwachungsebene ermöglicht es, die korrekte Ausführung der Funktionsebene sicherzustellen. So werden Schnittstellen bereitgestellt, um beispielsweise das Zeitraster der Zeitscheiben oder die Integrität der Kommunikationsschnittstellen zu überwachen. Für den Anwender bietet sie ebenfalls Rahmen, die er mit Überwachungsfunktionen für seine Applikation füllen kann. Aus seiner in der Funktions- und Funktionsüberwachungsebene ausgeführten Software hat der Anwender über ein „Application Programming Interface“ (API) jederzeit die Möglichkeit, das Steuergerät in den sicheren Zustand zu versetzen. So kann er zum Beispiel in der Funktionsebene berechnete Momente plausibilisieren und im Fehlerfall das System in seinen zuvor definierten sicheren Zustand überführen.

Der zentrale Teil der Rechnerüberwachungsebene befindet sich im Monitoring-Rechner. Diese ist unabhängig von der vom Anwender implementierten Funktion und befindet sich nicht in der Hauptrecheneinheit selbst. Mit einem Frage-Antwort-Verfahren wird das ordnungsgemäße Abarbeiten der Programmbefehle des Funktionsrechners verifiziert. Zusätzlich überwacht ein Watchdog ständig die Laufzeitumgebung der Funktionsüberwachungsebene. Ebenso werden auf dieser Ebene die internen Spannungen und Temperaturen überwacht. Im Fall eines Fehlers löst die Rechnerüberwachungsebene unabhängig vom Funktionsrechner eine Fehlerreaktion aus.

Anpassbare Fehlerreaktionsklassen

Im Gegensatz zur Funktions- und Funktionsüberwachungsebene (L1 und L2) ist die Rechnerüberwachungsebene (L3) applikationsunabhängig und muss daher nicht wie diese programmiert werden. Es ist möglich, die Eigenschaften der Ebenen L1 und L2 in Bezug auf Diagnose und Fehlerreaktion anwendungsbezogen zu konfigurieren. Hierzu existieren mehrere Fehlerreaktionsklassen (Abschaltpfade). Durch sie ist es möglich, verschiedene Anwendungen mit unterschiedlichen Anforderungen an die Fehlerreaktion zu unterstützen. Die einzelnen Fehlerreaktionsklassen unterscheiden sich durch ihre Reaktionszeit, den Umfang der auszuführenden Aktionen und ihre Diagnosefähigkeit.

Bevor nach einem Start des Steuergerätes die in Ebene L1 befindliche Funktions-Software ausgeführt wird, muss die Integrität des Steuergerätes sichergestellt sein. Hierzu startet das Steuergerät im sicheren Zustand und führt verschiedene Diagnosen durch. So werden beispielsweise alle sicherheitsrelevanten Code- und RAM-Sektionen auf Konsistenz geprüft oder gegebenenfalls die Anzahl der Startversuche nach einem Fehler begrenzt. Eine Skalierbarkeit der Fehlerreaktionsklassen erleichtert es den Entwicklern, Funktionen zu entwickeln und zu testen. Oft ist es erst durch selektives Abschalten von Sicherheitsfunktionen möglich, einzelne Komponenten eines Gesamtsystems isoliert zu betreiben. Grundsätzlich lassen sich damit die aus ihrem Verbund gelösten Komponenten deutlich leichter bewerten. Ebenfalls kann es sinnvoll sein, Sicherheitsfunktionen zu deaktivieren, wenn es um die Bewertung von Robustheit und Leistungsgrenzen eines Systems geht. Das Analysieren von Fehlern während der Entwicklungsphase, wie Laufzeitblockaden oder korrupte Speicherbereiche, lässt sich durch das Deaktivieren von Fehlerreaktionen deutlich beschleunigen. Hierbei ist zu beachten, dass das RCP-System das Abschalten von Fehlerreaktionen niemals zur Laufzeit ermöglichen darf, sondern nur zum Zeitpunkt der Code-Generierung.

Die Werkzeugkette

Neben dem eigentlichen Steuergerät hat die Werkzeugkette, mit der das Steuergerät bedient wird, ebenfalls einen nicht zu vernachlässigenden Anteil bei der Realisierung des Sicherheitskonzepts. Compiler und automatische Code-Generatoren haben beispielsweise einen direkten Einfluss auf den Programm-Code, der später im Steuergerät ausgeführt werden soll. Es bietet sich daher an, Compiler und automatische Codegeneratoren zu verwenden, die von ihren jeweiligen Herstellern bereits für sicherheitskritische Anwendungen zertifiziert wurden. Das sind häufig Werkzeuge, die bereits in bestehenden sicherheitsrelevanten Serienentwicklungen verwendet wurden oder die unter Umständen in einer nachfolgenden Serienentwicklung weiter verwendet werden können. Entwickler müssen sich somit nicht mit einer neuen Entwicklungsumgebung auseinandersetzen und es ist einfacher, Ergebnisse der Prototypen-Phase in die Serie zu übernehmen. Ebenso kann bestehende Serien-Software mit ihren Sicherheitsfunktionen einfach in die Software des Prototyps einfließen. Die Vorteile sind eine verkürzte Entwicklungszeit und reduzierte Kosten.

Soll die Forderung nach Diversität zwischen den Ebenen L1 und L2 des 3-Ebenen-Sicherheitskonzepts auch in Bezug auf die Werkzeugkette erfüllt werden, ist es möglich, unterschiedliche automatische Code-Generatoren in den Ebenen einzusetzen: in der Ebene L1 kann modellbasiert mit einem automatischen Codegenerator gearbeitet und die Überwachungsfunktionen in der Ebene L2 von Hand programmiert werden. Mit dem Einsatz eines RCP-Systems mit integriertem Sicherheitskonzept lassen sich die Sicherheitsfunktionen frühzeitig validieren, die in Sicherheitsbetrachtungen während der Anforderungs- und Design-Phase identifiziert wurden. Das ist deshalb besonders interessant, weil sich so schon in frühen Entwicklungsphasen eventuelle Schwachstellen in den Sicherheitsfunktionen finden lassen. Dadurch können mögliche notwendige Änderungen, beispielsweise an mechanischen Komponenten oder an der Architektur, zeitnah umgesetzt werden. Für nachfolgende Projektphasen bedeutet dies, dass sie schon mit validierten Sicherheitsfunktionen oder sogar mit einem validierten Sicherheitskonzept starten können.

Schlussfolgerung

RCP-Systeme und funktionale Sicherheit lassen sich also in Einklang bringen. Durch den Einsatz eines RCP-Systems mit integriertem Sicherheitskonzept, wie der PROtroniC TopLine, lässt sich deutlich die Gesamtsystemkomplexität von sicherheitsrelevanten Prototypen und Konzeptfahrzeugen reduzieren. Entwickler können ihr Augenmerk verstärkt auf die Entwicklung von Steuerungs-, Regelungs- und Sicherheitsfunktionen legen. Neben der Minimierung von Gefahren in frühen Phasen der Entwicklung ist es möglich, Sicherheitskonzepte frühzeitig zu validieren. Die so gewonnene Testtiefe erhöht die Sicherheit von Prototypen, Konzeptfahrzeugen oder Testflotten, die im öffentlichen Straßenverkehr betrieben werden.

Literatur

[1] J. Kohlhoff: Entwicklung der Fahrstrategie für einen Hybridfahrzeugprototyp mit Torque Vectoring / Developing the drive strategy for a hybrid prototype vehicle with torque vectoring, expert Verlag Renningen. Auflage 2015, S. 388–403
[2] Arbeitskreis EGAS: Standardisiertes E-Gas Überwachungskonzept für Motorsteuerungen von Otto- und Dieselmotoren. V 5.0 vom 30.08.2011

Der Autor

Dipl.-Ing. Christian Loske
studierte Elektrotechnik an der Universität Dortmund. Er ist seit 2005 bei Schaeffler Engineering und ist derzeit Senior Engineer im Bereich Products Development.