Gewährleistung des Software-Timing-Verhaltens in kritischen Multicore-basierten eingebetteten Systemen

Um sicher an einen sicheren Ort zu kommen, sind mehr als nur gute Bremsen, funktionierende Rücklichter und jemand mit hervorragenden Reflexen am Steuer gefragt. Zunehmend sind die Komponenten, die Ihr Auto auf der Straße und Ihr Flugzeug in der Luft halten, nicht nur menschlich oder gar nur mechanisch. Sie sind hochentwickelte eingebettete Software, die auf komplexen heterogenen Multicore-Prozessoren läuft, alles vom Flugmanagementsystem bis zur Servolenkung steuert und strenge Zeitvorgaben in Mikrosekunden einhält.

Hierin liegt die Herausforderung. Das Timing-Verhalten von Software in einem Multicore-System wird nicht nur von der darauf laufenden Software und ihren Eingängen beeinflusst, sondern auch von der anderen Software, die auf anderen Kernen läuft.

Die Entwicklung kritischer eingebetteter Systeme erfordert einen immensen Aufwand und Investitionen (Millionen Euro/Dollar und Jahre Entwicklungsaufwand). Sicherheit muss bereits in den frühesten Phasen des Softwareentwicklungsprozesses im Mittelpunkt der Architektur und des Designs stehen. Insbesondere Systemdesigner müssen das Timing-Verhalten ihrer Software verstehen, um sicherzustellen, dass sie innerhalb sicherer Zeitrahmen ausgeführt werden kann.

Das Rätsel der Multicore-Timing-Analyse (MTA) lösen

Obwohl die beeindruckende Rechenkapazität eines Multicore-Prozessors (theoretisch) eingebettete Systeme leistungsfähiger und effizienter machen sollte, kann Software, die auf einem Kern ausgeführt wird, die Ausführung von Software auf den anderen Kernen verlangsamen. In dieser Situation kann die Ausführung von Software aufgrund von Interferenzen aufgrund von Konflikten um gemeinsam genutzte Ressourcen wie Busse, Speicher, Caches, Geräte, FPGAs und GPUs, die mit Aufgaben, die auf anderen Kernen ausgeführt werden, gemeinsam genutzt werden, länger dauern.

Wie quantifizieren Sie die Auswirkungen dieser Interferenzen? Wie analysieren, testen und liefern Sie konkrete Beweise dafür, dass Ihre sicherheitskritische Software auf einer Multicore-Plattform immer innerhalb der Zeitvorgaben ausgeführt werden kann?

Antworten auf diese Fragen erforschen Experten des Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) und Marelli Europe (MAR). BSC und Rapita haben eine Lösung entwickelt, die in Kürze in der Luftfahrt- und Automobilindustrie eingeführt wird. Spezialisierte Werkzeuge und Automatisierung, kombiniert mit einer anforderungsbasierten, sicherheitsorientierten Methodik, waren der Schlüssel zur Lösung des Rätsels.

Diese Arbeit bildete die Grundlage für das MASTECS-Projekt, ein multidisziplinäres Forschungs- und Entwicklungsprojekt, das von der Europäischen Kommission finanziert und im Dezember 2019 gestartet wurde. Das MASTECS-Projekt wird die Technologien ausreifen und ihren Einsatz für die Zertifizierung von Avionik- und Automobilsystemen unterstützen. Ein wichtiger Teil des MASTECS-Projekts besteht darin, den Ansatz in zwei Branchen anhand von Fallstudien zu demonstrieren, die von RTRC und MAR bereitgestellt wurden.

Hochmoderne Tools

Kommerziell erhältliche Tools zur Unterstützung der Timing-Analyse sind für einfache (Single-Core-)Elektronik effektiv, lassen sich jedoch nicht skalieren, um neue Multicore-spezifische Zertifizierungsanforderungen und -empfehlungen zu erfüllen.

• Statische Timing-Analyselösungen [1] stehen vor einer Komplexitätsmauer und können weder die immer komplexer werdende Hardware effektiv modellieren noch effizient mit den strukturellen und syntaktischen Eigenschaften außergewöhnlich komplexer Softwarefunktionen umgehen.
• Messungsbasierte Lösungen haben im Single-Core-Analysemarkt eine gute Durchdringung erreicht (das RVS-Toolset von Rapita Systems gehört zu den erfolgreichsten). Allerdings sind solche Tools noch immer nicht in der Lage, die Herausforderungen, die die Einführung von Multicores mit sich bringt, vollständig zu bewältigen. Sie konzentrieren sich normalerweise auf Messszenarien, die durch konsolidierte funktionale Teststrategien bestimmt werden, aber es fehlt eine auf Hardware-Know-how basierende Methodik, die hilft, vertrauenswürdige Zeitgrenzen für Aufgaben abzuleiten, die in Multicore ausgeführt werden, mit den erforderlichen unterstützenden Nachweisen und einem angemessenen Maß an Rückverfolgbarkeit.

Unseres Wissens ist kein kommerzielles Tool auf dem Markt verfügbar, außer dem in MASTECS ausgereiften, das in der Lage ist, das Timing von Software auf Multicore-Plattformen zu analysieren, wobei der Schwerpunkt auf geltenden Sicherheitsstandards und neuen Zertifizierungsanforderungen liegt.

Störungsanalyse und -kontrolle in Aktion

Der Schlüssel zum Verständnis von Interferenzen ist eine strukturierte Testmethodik, bei der Hardware- und Softwareexperten eingesetzt werden, um Nachweise über das Multicore-Timing-Verhalten zu erbringen. Eine spezialisierte Technologie von BSC (bekannt als Multicore-Mikrobenchmark-Technologie oder MμBT, von Rapita als RapiDaemons vermarktet) ermöglicht Systemdesignern die Analyse und Quantifizierung der Auswirkungen von Interferenzen in einer Multicore-basierten Anwendung, indem zusätzliche Interferenzszenarien erstellt werden, um verschiedene Teile von der Multicore-Prozessor.

Micro-Benchmarks, das Herzstück von MuBT, sind gut ausgearbeitete Codestücke, die an der niedrigsten Schnittstelle zwischen Hardware und Software arbeiten, um eine bestimmte gemeinsam genutzte Ressource zu belasten. Mikrobenchmarks zeigen den Einfluss von Interferenzkanälen auf das Software-Timing. Dazu können Mikrobenchmarks eingesetzt werden, die einen konfigurierbaren und quantifizierbaren Druck auf eine bestimmte Anwendung ausüben. Micro-Benchmarks wurden speziell entwickelt, um ein einzelnes, klar definiertes Verhalten mit erwarteten Auswirkungen auf eine bestimmte Hardware-Ressource zu zeigen und gleichzeitig so weit wie möglich zu verhindern, dass Konflikte auf anderen Interferenzkanälen erzeugt werden. Zu den wichtigsten Funktionen des Micro-Benchmarks gehören die folgenden:

1. Sie üben einen quantifizierbaren Druck auf bestimmte gemeinsam genutzte Ressourcen aus.
2. Ihr Verhalten kann über Ereignismonitore überprüft werden.
3. Sie erfassen spezifische zeitbezogene Anforderungen, z. B. ob die von Ihnen ergriffenen Maßnahmen zur Schadensbegrenzung wirksam sind, um Konflikte zu meistern.

Klicken für größeres Bild

Abbildung 1:Verwendung von Mikrobenchmarks in der Interferenzanalyse. (Quelle:Autoren)

Eine breite Palette von Mikro-Benchmarks wurde entwickelt, um spezifische Rollen zu erfüllen, einschließlich der Abstimmung eines gewünschten Interferenzniveaus, der Maximierung der Interferenz auf die Ressource oder einfach nur sehr sensibel gegenüber Konflikten („Opfer“).

Bei der Analyse der Auswirkungen von Interferenzen wird die Verwendung von MμBT durch ein Task-Contention-Modell (TCM) unterstützt, das frühe Abschätzungen der Konfliktverzögerung von Tasks liefert. Die von Rapita entwickelten Software-Automatisierungs- und Testtools RapiTest und RapiTime werden verwendet, um Tests zu schreiben und auf dem eingebetteten Ziel auszuführen.

Designmethodik

Durch Befolgen eines siebenstufigen Testdesignprozesses entlang des Standardsoftware-V-Entwicklungsprozesses (Abbildung 2) können Ingenieure die Auswirkungen von Interferenzen besser verstehen.

1. Kritische Konfigurationseinstellungen für Multicore-Prozessoren, Analyse von Interferenzkanälen und Ereignisüberwachung. Hardwareexperten helfen bei der Identifizierung kritischer Konfigurationseinstellungen, um den Rahmen festzulegen, in dem auch Interferenzkanäle zusammen mit Maßnahmen zur Risikominderung identifiziert werden. Die Identifizierung von Hardware-Ereignismonitoren ist auch wichtig, um eine Überprüfung für alle folgenden Schritte bereitzustellen.
2. Timing-Anforderungen ermitteln. Helfen Sie dem Endbenutzer, seine spezifischen Bedürfnisse, Timing-Anforderungen, Risiken und Sicherheitsprobleme für das System zu identifizieren. Überprüfen Sie beispielsweise die Leistung eines jeden Hardware-Isolationsansatzes, um Interferenzen zu minimieren.
3. Testfalldesign. Entwickeln Sie spezifische Testfälle (Beschreibung eines Tests), um den Satz von Hypothesen zu überprüfen, die die Benutzeranforderungen unterstützen, einschließlich der Definition der MμBT-Elemente, die erforderlich sind, um bei der Störungskanalanalyse Beweise zu erbringen. Dies beinhaltet eine isolierte Ausführung (keine Störung), eine Ausführung gegen Mikrobenchmarks, um die Ausführungszeit der Anwendung und die Empfindlichkeit der Hardware gegenüber Störungen unter verschiedenen quantifizierbaren Stressszenarien zu bewerten.
4. Implementierung von Testverfahren. Derzeit ein manueller Prozess, der in MASTECS automatisiert werden soll. Dieser Schritt baut die Testverfahren bestehend aus einem Testrahmen, Mikrobenchmarks und Messsonden auf, um die Ergebnisse aufzuzeichnen/zu verfolgen.
5. Beweissammlung (Tests). Die Testverfahren werden auf der Plattform ausgeführt, um Testnachweise zu sammeln. Dies erfordert derzeit einige manuelle Arbeiten und wird in MASTECS mithilfe des RapiTest-Automatisierungs-Frameworks automatisiert, um diese Tests auszuführen und sie mit den Verifizierungsanforderungen zu verknüpfen.
6. Ergebnisanalyse. Eine Überprüfung der Testergebnisse durch technische Experten, um zu überprüfen, wie die Testergebnisse die Verifizierungsanforderungen (oder anderweitig) überprüfen. Abbildung 3 zeigt beispielsweise einen Screenshot von RapiTime zu den Ausführungszeiten, die für verschiedene Funktionen eines Programms gemeldet wurden.
7. Ergebnisse validieren und Dokumentation erstellen. Abschließende Überprüfung der Anforderungen, Erstellung von Dokumentations- und Qualifizierungsergebnissen zur Untermauerung der Sicherheitsargumentation des Systems. Der Kunde kann den vollständigen Satz an Berichten und Analyseartefakten direkt für die Zertifizierung von Software verwenden, die auf Multicore läuft.

Klicken für größeres Bild

Abbildung 2:MTA-Schritte im V-Modell-Softwareentwicklungsprozess. (Quelle:Autoren)

Hardware-Expertise und der Timing-Analyseprozess

Das Einbringen von Hardware (Multicore)-Expertise ist ein Schlüsselmerkmal des vorgeschlagenen MTA-Ansatzes für seinen Erfolg auf modernen komplexen Multicores. In frühen Phasen der Softwareentwicklung:

1. Hardware-Experten identifizieren Multicore-Konfigurationen (kritische Konfigurationseinstellungen im Avionik-Jargon), da sie eine Schlüsselrolle bei der Bestimmung der Softwarefunktionalität und des Timing-Verhaltens spielen und einen großen Einfluss auf die Menge der sich gegenseitig erzeugenden Konfliktaufgaben haben. Als veranschaulichendes Beispiel implementieren aktuelle Prozessoren Isolations- und Segregationsmechanismen, die bei richtiger Bereitstellung Konflikte stark reduzieren können.
2. Multicore-Experten spielen eine Schlüsselrolle bei der Identifizierung der Ressourcen, in denen Aufgabenkonflikte auftreten können (diese werden in der Avionik als Interferenzkanäle bezeichnet). Die Fähigkeit von Hardwareexperten, sich in den mehrtausendseitigen technischen Referenzhandbüchern für Prozessoren zurechtzufinden und die entsprechenden Fragen zu den möglicherweise fehlenden Informationen in den Handbüchern an die Chiphersteller zu formulieren, ist für einen geeigneten MTA-Prozess von grundlegender Bedeutung.
3. Sobald Interferenzkanäle identifiziert sind, identifizieren Hardwareexperten die Ereignismonitore, die verwendet werden können, um die Aktivität zu verfolgen, die Tasks auf diesen Interferenzkanälen erzeugen, als Proxy-Metrik, um die Konkurrenz zu begrenzen, die Tasks erleiden können. Die Korrektheit dieser Ereignismonitore muss auch überprüft werden [2], für die ein spezieller Satz von Mikrobenchmarks entwickelt wurde.
4. Schließlich arbeiten Hardware-Experten Hand in Hand mit Experten für Timing-Analyse, um aus den Benutzeranforderungen High-Level- und Low-Level-Anforderungen und spezifische Tests abzuleiten, um die Hypothesen zu validieren, die die Benutzeranforderungen unterstützen. Jeder Test instanziiert ein oder mehrere Micro-Benchmark-Programme, die von Hardware-Experten entwickelt wurden, um das gewünschte Maß an Last auf den/die Ziel-(Satz von) Störkanälen auszuüben.

In späten Designphasen:

1. Hardware-Experten tragen mit der Analyse von Testergebnissen dazu bei, zu beurteilen, ob sie Hypothesen bestätigen oder ablehnen.
2. Hardware-Experten tragen auch dazu bei, neue Hypothesen und die entsprechenden Tests zu erstellen, falls diese auf der Grundlage der im vorherigen Schritt erhaltenen Ergebnisse erforderlich sind.

Klicken für größeres Bild

Abbildung 3:Ergebnisse analysieren (RapiTime). (Quelle:Autoren)

Das Gesamtbild

Der siebenstufige Testentwurfsprozess ist nur ein Teil einer umfassenderen Multicore-Verifizierungsmethodik, die zuvor in Abbildung 2 gezeigt wurde. Diese Methodik, die im Rahmen des MASTECS-Projekts weiter ausgereift wird, soll eine vollständige Rückverfolgbarkeit durch umfassende Beweise und Ergebnisse zurück auf die entsprechenden Anforderungen und Konstruktionen. Die Methodik wurde entwickelt, um die Ziele zu erreichen, die in CAST-32A, dem von den Zertifizierungsbehörden für die Luft- und Raumfahrt herausgegebenen Leitdokument, definiert sind. Es ist auch speziell auf ISO 26262 ausgerichtet, die Sicherheitsnorm für den Automobilsektor, die sich für Störungsfreiheit einsetzt.

CAST-32A wurde 2016 vom Certification Authorities Software Team (CAST) veröffentlicht und identifiziert Faktoren, die sich auf die Sicherheit, Leistung und Integrität von luftgestützten Softwaresystemen auswirken, die auf Mehrkernprozessoren ausgeführt werden. Wenn Sie Multicore-Hardware in einem Avioniksystem verwenden möchten, ist dieses Dokument die richtige Wahl. Es enthält Ziele, die die Produktion sicherer Multicore-Avioniksysteme leiten sollen, einschließlich Ziele in Bezug auf die Identifizierung und Begrenzung der Auswirkungen von Interferenzkanälen. Sehen Sie sich hier das Positionspapier CAST-32A an. EASA und FAA arbeiten an einer Anpassung des generischen Multicore-CRI in ein gemeinsames AMC/AC-Material (AMC 20-193). Es wird voraussichtlich "später in diesem Jahr"[3] veröffentlicht.

Expertise lässt sich nicht automatisieren

Störeffekte sind komplex. Um ihre Geheimnisse zu lüften, benötigen Sie Experten, die sowohl die Komponenten der Multicore-Architektur als auch die Planungs- und Ressourcenzuweisungssysteme der Software verstehen. Die Zusammenarbeit zwischen Hardware- und Softwareexperten wird ein zentrales Merkmal des MASTECS-Projekts sein, das auch in Zukunft fortgeführt wird. Obwohl die Zusammenarbeit zu großen Fortschritten bei der Software-Tooling und -Automatisierung führt, ist es wichtig zu bedenken, dass Sie nicht jeden Schritt eines Validierungsprozesses automatisieren können – insbesondere nicht, wenn Multicore-Timing-Analyse beteiligt ist.

Sie brauchen erfahrene Ingenieure, die die Systeme im Detail kennen. In der Anfangsphase können Multicore-Experten beispielsweise die Prozessorkonfigurationen (auch als hardwarekritische Konfigurationseinstellungen bezeichnet) identifizieren, die das Funktions- und Timing-Verhalten der Software sowie die potenziellen Interferenzkanäle bestimmen. Wenn es um die Analyse von Testergebnissen geht, geht nichts über den Input eines erfahrenen menschlichen Experten, der die ursprünglichen Annahmen über die Plattform überprüft und bewertet und sein Wissen nutzt, um in einen neuen Testzyklus einfließen zu lassen.

Referenzen

[1] Reinhard Wilhelm. Gemischte Gefühle über gemischte Kritikalität. Workshop zur Worst-Case-Ausführungszeitanalyse, 2018.

[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. Hochintegrierte Leistungsüberwachungseinheiten in Automobilchips für zuverlässiges Timing V&V. IEEE Micro 38(1):56-65 (2018).

[3] https://www.aviationtoday.com/2020/02/28/easa-and-faa-to-issue-further-guidance-on-multicore-certification-this-year/