SPECIAL: AUTOSAR Fehlertolerante Systemarchitekturen mit AUTOSAR-Basis-Software realisieren: (Bild: Jakub Krechowicz – Fotolia; Vector Informatik) Sieht so die Zukunft aus? Hochautomatisiertes Fahren bringt neue Anforderungen an bestehende Sicherheitskonzepte. Eine Funktion einfach abzuschalten, um den sicheren Zustand zu erreichen, ist nicht mehr ausreichend. Der sichere Zustand erfordert Energie und aktive Funktionen. Von Jonas Wolf I n sicherheitsrelevanten Systemen im Fahrzeug ist heute das Ausschalten oder Zurücksetzen einer fehlerhaften Funktion die häufigste Fehlerreaktion. Sie wird als fail-silent bezeichnet. Die Maßnahme ist einfach umzusetzen und wirksam, um einen sicheren Zustand einzunehmen und zu erhalten. Zunehmend übernehmen aber E/E-Systeme im Fahrzeug auch Funktionen, die im Falle eines Fehlers verfügbar bleiben müssen, beispielsweise beim Ausfall eines Mikrocontrollers. Dieses Verhalten wird fail-operational genannt und im Weiteren als fehlertolerant bezeichnet. Die Forderung Mikrocontroller- Funktionsüberwachung übergreifende Integrität (ASIL- und ApplikationsMaßnahmen nach fehlertoleranten Syste(ASIL-abhängig) abhängig) (ASIL-abhängig) men wird im Automobilbau Watchdog Watchdog Watchdog in Zukunft stark zunehmen. (Alive Monitoring) (Logic Monitoring) (Deadline Monitoring) Ein Beispiel: Lenkunterstützungssysteme in schweren Memory Partitioning/ Lock-step CPU Sensor Monitoring Coexistence (Mixed ASIL) SUVs sind heutzutage teilweise notwendig, um die ECC RAM Actuator Monitoring Communication Beherrschbarkeit durch den Protection (E2E) ECC ROM Limiter Fahrer sicherzustellen. Wähprojektspezifische rend die Entwickler Fail-SiBITs Applikations-Software Standard-Software lent-Systeme in der ZwiBild 1. Durch ein modulares Konzept lassen sich Sicherheitsschenzeit mit ISO 26262 gut mechanismen effizient für das jeweilige Projekt zuschneiden. beherrschen, sind Fragestel (Quelle: Vector Informatik) lungen beim Auslegen von 32 Elektronik automotive 11.2015 fehlertoleranten Systemen durch die ISO 26262 aktuell schwierig zu beantworten. Insbesondere die genaue Definition des sicheren Zustands bereitet in diesem Zusammenhang noch Kopfzerbrechen. Auch die zweite Auflage von ISO 26262, deren Veröffentlichung für 2018 geplant ist, wird hier noch keine endgültige Klarheit schaffen. Unabhängig von den Vorgaben durch Standards zeigen die folgenden Kapitel, wie sich die bestehenden Sicherheitskonzepte mit AUTOSAR auf fehlertolerante Systeme ausweiten lassen. Modulares Sicherheitskonzept für Fail-Silent-Systeme Safety-Ingenieure schneiden durch ein modulares Konzept die unterschiedlichen Sicherheitsmechanismen effizient auf das jeweilige Projekt zu (Bild 1). Dabei unterscheiden sie grob zwischen Maßnahmen zur Mikrocontroller-Integri tät, Maßnahmen zur Funktionsüberwachung und übergreifenden Maßnahmen. Maßnahmen zum Herstellen der Integrität des Mikrocontrollers werden abhängig vom höchsten Automotive Safety Integrity Level (ASIL) der verwendeten Software getroffen. Diese sind unabhängig von der auszuführenden SPECIAL: AUTOSAR Priorität Task Zykluszeit Budget Die Timing Protection A 5 ms 1 ms erkennt Überschreitung B 10 ms 3 ms des erlaubten Zeit-Budgets. C 12 ms 5 ms A A B A Verzögerte Aktivierung von Task C um 1 ms. A B C C 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Zeit Bild 2. Die AUTOSAR Timing Protection erkennt frühzeitig ein Überschreiten der erlaubten Zeit-Budgets von Tasks und Interrupts. (Quelle: Vector Informatik) Funktion und ergeben sich aus dem zu erreichenden Diagnosedeckungsgrad (Diagnostic Coverage, DC) für ein bestimmtes ASIL. Oft machen die Mikrocontroller-Hersteller konkrete Vorgaben basierend auf ihren Sicherheitsanalysen. So können beispielsweise eingebaute Selbsttests (Built-in Tests, BITs), die zyklisch durch die Software angestoßen werden, für eine DC für ASIL D notwendig sein. Bereits ab ASIL B muss in der Regel die Auftretenswahrscheinlichkeit sogenannter Single Event Upsets (SEUs) oder Bit-Kipper betrachtet werden. Wirksamen Schutz gegen SEUs bieten Mikrocontroller im Lock-Step-Betrieb und Speicher mit Fehlererkennungs- und korrektur-Codes (ECC RAM, ECC ROM). Beide Sicherheitsmechanismen sind in der Hardware enthalten, nahezu transparent für die SoftwareEntwicklung und daher effiziente Lösungen. Zur Funktionsüberwachung setzt der Entwickler normalerweise weitere Maßnahmen in der Applikation um. Hierzu gehören Monitoring-Aufgaben für Sensorik und Aktuatorik genauso wie Limiter oder eine Programmablaufkontrolle (Logic Monitoring). Die Programmablaufkontrolle wird beispielsweise mit einem AUTOSAR-Watchdog erreicht. Funktionsüberwachung und Mikrocontroller-Integrität sind projektspezifisch festzulegen und umzusetzen. Es gibt jedoch auch Maßnahmen, die in fast jedem Steuergerät mit Sicherheitsbezug zum Einsatz kommen und unabhängig von Funktion und ASIL sind. Nahezu jedes Steuergerät mit ASIL-Software führt auch QM-Software aus. Um die Koexistenz nach ISO 26262 zu gewährleisten, sind eine Speicherseparierung und eine Überwachung der zeitlichen Randbedingungen notwendig [1]. Das Partitionieren des Speichers erfolgt durch das Zusammenspiel einer Memory Protection Unit (MPU) mit einem AUTOSARBetriebssystem mit Scalability Class 3 (SC3), das die Ansteuerung der MPU mit dem geforderten ASIL übernimmt. Das Überwachen der zeitlichen Anforderungen erledigt üblicherweise der Watchdog durch ein Deadline Monitoring. Sobald sicherheitsrelevante Daten zwischen mehreren Steuergeräten ausgetauscht werden, kommt eine Kommunikationssicherung (Communication Protection) ins Spiel. Hierzu bietet AUTOSAR mit der Endto-End Protection (E2E) einen wirksamen Sicherheitsmechanismus. Für diese übergreifenden Maßnahmen sind bis ASIL D zertifizierte Produkte von Vector Informatik verfügbar. Transition zu fehlertoleranten Systemen Hardware wird aktuell aus Kostengründen nahezu redundanzfrei ausgelegt. Ein Hardware-Fehler führt daher in der Regel direkt zu einer schwerwiegenden Beeinträchtigung der Funk- SPECIAL: AUTOSAR In der Luftfahrt kommen fehlertolerante Systemarchitekturen seit vielen Jahren zum Einsatz. Für die sicherheitskritischen Flugsteuerungssysteme sind oft dreioder vierfach redundante Steuergeräte zu einem komplexen System vereint. Diese Redundanz in der Hardware ist selbstverständlich äußerst kostenintensiv. Für den Einsatz fehlertoleranter Systeme in der Automobilindustrie müs34 Elektronik automotive 11.2015 Durch das Einführen von Redundanzen in der Hardware steigt grundsätzlich auch die Komplexität in der Applikation. So entstehen neue HerausforSWC SWC SWC SWC derungen im MICROSAR.RTE Bereich der ReKanalSensor- und statusStellwertgelungstechnik, Fehleraustausch MICROSAR.COM austausch IO beispielsweise zustandsaustausch bei Reglerstabilität oder Aktuatorik durch Eingriff redundanter Regler. Auch die Datenkonsistenz in NetzXCP werken („byzanMICROSAR.MCAL MICROSAR.EXT tinischer Fehler“ [6]) muss neu Mikrocontroller bewertet werLegende: mögliche Neuerungen in der Basis-Software Basis-Software Applikation den. Aus Sicht der SystemarBild 4. MICROSAR-Software-Architektur für auf AUTOSAR basierende fehlerchitektur lässt tolerante Systeme. (Quelle: Vector Informatik) MICROSAR.LIBS Fehlertolerante Systemarchitekturen Software-Architektur mit AUTOSAR für fehlertolerante Systeme Complex Drivers tion bis hin zum Ausfall. Auf der anderen Seite existieren ausgereifte Verfahren zur Quantifizierung von HardwareAusfällen wie in IEC 62380 und SN 29500 definiert, die eine Vorhersage über die gewünschte Versagensrate erlauben [2]. Das Quantifizieren von SoftwareFehlern fällt oft schwer, weil es sich ausschließlich um systematische Fehler handelt [3]. Um die Fehlertoleranz gegenüber Software-Fehlern zu erhöhen, ist die Timing Protection als Sicherheitsmechanismus ein geeignetes Mittel. Die Timing Protection schützt beispielsweise gegen Endlosschleifen in SoftwareKomponenten, die das Ausführen der eigentlich relevanten Funktion verhindern. Bei der Timing Protection vergibt der Entwickler zeitliche Budgets für die Laufzeit von Tasks und Interrupt-Routinen und für die Sperrzeiten von Interrupts und Ressourcen. Ebenso werden die zeitlichen Abstände zwischen Tasks und Interrupt-Routinen überwacht (Bild 2). Das AUTOSAR-Betriebssystem stoppt im Fehlerfall die verursachende Task oder Interrupt-Routine und schließt sie von der weiteren Ausführung aus. Die Timing Protection ist jedoch nur ein erster Schritt hin zu fehlertoleranten Systemen, wie sie in Zukunft gebraucht werden. MICROSAR.V2G Bild 3. Beispiel für eine fehlertolerante Systemarchitektur durch redundante Auslegung. (Quelle: Vector Informatik) MICROSAR.AVB 2. Spannungsversorgung MICROSAR.ETH 2. SBC/ Watchdog MICROSAR.FR 2. CANKommunikation 2. Aktuator MICROSAR.LIN 2. Mikrocontroller MICROSAR.CAN 2. Sensor MICROSAR.MEM 1. Aktuator Datenaustausch MICROSAR.DIAG 1. Mikrocontroller sich diese Komplexität zum Beispiel durch einen Hot-Standby‑Betrieb beschränken. Dabei steuert zu einem Zeitpunkt immer nur einer der beiden Kanäle die Aktuatorik. Kommt es in diesem Kanal zu einem Fehler, übernimmt der andere Kanal sofort die Steuerung. Zur vereinfachten Applikationsentwicklung ist die AUTOSAR-BasisSoftware (Bild 4) aus den folgenden Gründen von Nutzen: ➜ ➜Wiederverwendung: Die für ein modulares Sicherheitskonzept bereits oben vorgestellten AUTOSAR-Komponenten verwendet der Entwickler weiterhin für die Fehlererkennung. ➜ ➜Einsatz von bestehenden Mechanismen: Für das Umsetzen der Software der redundanten Kanäle gibt es zwei Philosophien, diversitär oder homogen. Die diversitäre Philosophie verwendet unterschiedliche Software auf beiden Kanälen. Bei gleichartigen Kanälen und Mikrocontrollern lässt sich auf beiden Kanälen dieselbe Software nutzen, die nur je nach Kanal anders parametriert ist. Dafür eignet sich der sogenannte PostBuilt-Selectable-Mechanismus von AUTOSAR, der normalerweise beim Entwickeln von Steuergerätevarianten zum Einsatz kommt. Das Verwenden von gleichartigen Kanälen erfordert das Untersuchen von Fehlern mit gemeinsamer Ursache [7]. Um eine schnelle Übernahme im Fehlerfall durch den anderen Kanal zu ermöglichen, werden Sensor- und Stellwerte ebenso wie Statusinformationen zum Kanal zwischen den Kanälen ausgetauscht (Bild 3). Durch die Mechanis- MICROSAR.AMD 1. Sensor 1. Spannungsversorgung Kanalumschaltung 1. SBC/ Watchdog MICROSAR.SYS 1. CANKommunikation sen daher neue Ansätze gesucht werden. Hierbei lässt sich in der Risikoabschätzung auch von der geringeren Schwere des Schadensausmaßes profitieren. Eine mögliche Systemarchitektur (Bild 3) weist in jedem Fall mindestens zwei Kanäle auf. Ein Kanal besteht in diesem Beispiel aus einem Sensor, einer Logikeinheit und einem Aktuator [4]. Es lässt sich schnell erkennen, dass beim Versagen des Mikrocontrollers eines Kanals auch die zugehörige Software und damit die Funktion ausfällt. Mikro controller haben aufgrund ihrer Komplexität häufig die höchsten Ausfallraten in einem Steuergerät; daher ist das korrekte Ausführen einer Funktion selbst für kleinste Zeiträume nicht sichergestellt. Damit dieses zweikanalige System fehlertolerant ist, muss jeder Kanal für sich alle Einzelfehler entdecken und sich passiv schalten [5]. Ohne diese Anforderung sind beide Kanäle für den sicheren Betrieb der Funktion notwendig. Dadurch würde sich die Ausfallrate verdoppeln und nicht wie gewünscht halbieren. Diese Systemarchitektur erfordert eine redundante Energieversorgung der beiden Kanäle ebenso wie einen redundanten Kommunikationspfad zu relevanten Partnern. IEC 61508 bezeichnet ein solches System als 1-outof-2 with Diagnostics (1oo2D). MICROSAR.OS (SC3/4) Steuergerät SPECIAL: AUTOSAR men von AUTOSAR ist das mit nur einer Konfiguration der Basis-Software umsetzbar. Die Kanalumschaltung im HotStandby‑Betrieb kann der Entwickler applikationsspezifisch als Software-Komponente (SWC) implementieren oder die flexiblen Konfigurationsmöglichkeiten der AUTOSAR-ManagerKomponenten Basic Software Mode Manager (BSWM) und ECU State Manager (ECUM) ausreizen. Zum Austausch des Fehlerzustands zwischen den Kanälen wird heute applikationsspezifische Software implementiert. Es ist jedoch vorstellbar, dass in Zukunft standardisierte Basis-Software-Komponenten für genau diesen Zweck spezifiziert werden. Werkzeugunterstützung Um den weiteren Grad an Komplexität zukünftig zu beherrschen, bedarf es bereits ab einer frühen Entwicklungsphase wirksamer und durchgehender Werkzeugunterstützung. Dadurch werden die Ressourcen auf die Applikationsentwicklung konzentriert und Ingenieure von lästiger und fehleranfälliger Arbeit entlastet, beispielsweise der manuellen Konsistenzprüfung von redundanten Signalen im Systemmodell. Ausblick Mit den AUTOSAR-Bordmitteln lassen sich bereits heute Projekte mit Sicherheitsbezug effizient umsetzen. Wenn zusätzliche Fehlertoleranz von E/E-Systemen gefordert wird, sind neue Systemarchitekturen erforderlich, die auch den Ausfall des Mikrocontrollers verkraften. Daraus ergeben sich für die Applikation und Basis-Software neue Herausforderungen. Mit der AUTOSAR-Methodik ist jedoch für diese Art von Systemarchitekturen die Komplexität beherrschbar. Die AUTOSAR-BasisSoftware bietet hier durch die Konfigurierbarkeit eine hervorragende Ausgangslage. Die zugehörige Werkzeugkette erleichtert das Beherrschen der benötigten Redundanz. Zukünftig wird sich die Unterstützung durch die BasisSoftware und deren Werkzeuge noch weiter verbessern. Ein erster Schritt ist jedoch das Bewusstsein, dass fehlertolerante Systeme auch neue Ansätze in der Systemarchitektur brauchen. eck Literatur [1]Definition des Fault tolerant time interval (FTTI) in ISO 26262-1, 1.45 [2]ISO 26262-5:9 Evaluation of safety goal violations due to random hardware failures [3]ISO 26262-10:4.3 Relationship between faults, errors and failures [4]Definition eines Systems in ISO 26262-1, 1.129 [5]ISO 26262 Single-point fault metric (SPFM) für ASIL D [6]L. Lamport et al.: The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 1982 [7]Definition einer Common Cause Failure in ISO 26262-1, 1.14 Dipl.-Ing. Jonas Wolf studierte Luft- und Raumfahrttechnik an der Universität Stuttgart. Er ist seit 2012 bei Vector und jetzt als Senior Product Management Engineer für funktionale Sicherheit und Cyber Security tätig. [email protected]
© Copyright 2024 ExpyDoc