Das HSI – Hardware Software Interface – ist ein Arbeitsprodukt aus der ISO 26262, welches Teil 4, 5 und 6 der Norm quasi verbindet. Erstmals wird das HSI auf Systemebene (Teil 4.7) erstellt und iterativ während der Softwareentwicklung nach Teil 6 gepflegt. Ziel ist es, den Signalpfad bis zu den Daten zu spezifizieren. Eine Art Tabelle reicht aus, um die Übersicht der Signalpfade zu erhalten. Neben den HW-/SW-Signalnamen, den Signalarten (Digital/Analog) und Memorymapping, stehen auch Genauigkeiten, Grenzfrequenzen und MUX-Konfigurationsregisterwerte im Fokus. All diese Aspekte werden indirekt im Technischen Sicherheitskonzept festgelegt. Dabei kommt es weiterhin auch auf die Wahl der Hardware an. Ein einfacher DSP oder ein Mikrokontroller (µC) sind in Peripherie-Teil i.d.R. einfacher augebaut als sicherheitsgerichtete leistungsfähige Elemente, welche oft als SEooC mit spezieller Safety-Peripherie ausgestattet sind.
Folgendes Beispiel zeigt einfache Elemente eines elektrisch programmierbaren Systems (z.B. SoC). Dabei sind mehrere Kern-Elemente an einen leistungsfähigen Systembus und die Peripherie i.d.R. an einem etwas weniger leistungsfähigen Peripheriebus angeschlossen. Es sind Arbitrierlogiken und ein Interruptcontroller notwendig, um einen reibungslosen Ablauf der Funktion in Hardware und Software zu ermöglichen. Diese müssen im HSI – Hardware Software Interface – im Hinblick auf deren Konfiguration erwähnt werden. Auf Systemebene ist das Zeitverhalten und somit der Scheduler (Software) und z.B. die Trigger der Peripherien zu spezifizieren. Nebenläufige Datentransfer-Prozesse wie die des DMA sind auch im HSI zu dokumentieren (Trigger, Sender-Empfänger, Ausnahme-Regelung usw…).
Diese Beispiel zeigt Abhängigkeiten im Bussystem und damit fehlende Wechselwirkungsfreiheit zwischen Sensor 1 und 2. Dieses System kann nur ein einkanaliges System mit Fail-Safe-Charakteristik (Energieabschaltung) sein. Eine weitere Modifikation durch ein externen Überwachungsbaustein ist notwendig.
HSI (Hardware Software Interface) und der Umfang
Oft kann scheinbar von einer Kopie des Datenblattes eines elektrisch programmierbaren/konfigurierbaren Systems gesprochen werden. Je nach Komplexität und Vielfalt der verwendeten Peripherie, kann es notwenig sein, das HSI umfangreich zu gestalten. Nicht verwendete bzw. unkonfigurierte Peripherie darf z.B. die Sicherheitsziele nicht gefährden oder den Übergang in den sicheren Zustand nicht verzögern oder verhindern.
Das Aufwand-Nutzenverhältnis des HSI – Hardware Software Interface – beschränkt sicht auf die Verletzung von Sicherheitszielen und ist abhängig von dem Sicherheitskonzept bzw. möglicher Wechselwirkungen und Funktionalitäten in der Peripherie, welche technologieabhängig sind.
Im obigen Beispiel ist Folgendes (nur auszugweise dargestellt) in der HSI – Hardware Software Interface – Spezifikation zu berücksichtigen:
- Betriebsmodi der Peripherien (init, normal, fail …)
- Konfigurationsparameter (Prescaler, Frequenz …)
- HW-Eigenschaften zur Unabhängigkeit zwischen Elementen
- geteilte/exklusive Nutzung der Ressourcen (Memory-Mapping, IRQ, Timer, I/O, ADC …)
- Zugriffsmechanismus und Verfahren (Seriell, Master, Slave, Round-Robin …)
- Zeitvorgaben aus dem technischen Sicherheitskonzept (TSC)
- HW-Diagnosefunktion und deren Verwendung in der SW (z.B. Unterspannung->Diagnose-Datensatz-Speicherung im persistenten Speicher)
Die Kernziele des HSI
Das HSI – Hardware Software Interface – hilft Komplexität zu beherrschen. Weiterhin ist die geforderte Traceability (Vor- & Rückverfolgbarkeit) zwischen physikalischen Werten über die Disziplinen (Hardware/Software) damit leicht erfüllbar. Auch systematische Fehler wie Fehlkonfiguration während der Entwicklung und den weiteren Aktivitäten im Sicherheitslebenszyklus (Produktion, Wartung, Stillsetzung) können vermieden werden. Wechselwirkungen und Anforderungen zur Wechselwirkungsfreiheit (Arbitrierung, Memory-Protection, Partition usw….) sind im Hinblick auf die V&V-Aktivitäten mit diesem Workproduct (Dokument) effektiv prüfbar.
Eine Tabellenform mit eindeutiger Signalbezeichnung (z.B. Drehzahl, Strom …) bzw. Beziehungen für alle Ebenen (Hardware/Software/System), Bit-Konfiguration (z.B. MUX), Adressen, Daten-Konsistenz-Gruppen (z.B. Conversiongroups), Datentypen, Wertebereiche und deren Genauigkeit [LSB], Gesamtgenauigkeit [%]
Stand: 01.07.2020
