Zuverlässiges Timing in sicherheitskritischen Multicore Embedded Systemen sicherstellen

Moderne Fahrzeuge und Flugzeuge verlassen sich nicht mehr ausschließlich auf mechanische Komponenten. Ihre Sicherheit und Performance hängen von Embedded Software ab, die auf komplexen heterogenen Multicore Prozessoren läuft und alles von Flight Control bis Power Steering mit Mikrosekunden-Deadlines managt.

In einer Multicore Umgebung wird die Ausführungszeit eines Tasks nicht nur durch seinen eigenen Code beeinflusst, sondern auch durch andere Tasks, die dieselben Hardware-Ressourcen teilen. Diese Interferenz kann ein System über seine Safety Margins hinaus pushen.

Entwicklung sicherheitskritischer Embedded Software verlangt Multi-Millionen-Euro, Multi-Year Effort. Von frühesten Design-Stages an muss Safety in die Architektur eingewoben sein, und das Timing-Verhalten jedes Tasks muss rigoros verstanden werden, um Deadlines zu garantieren.

Das Multicore Timing Analysis Puzzle lösen

Während Multicore Prozessoren höhere Performance versprechen, führen sie auch Contention für Shared Resources wie Busse, Memory, Caches und Acceleratoren ein. Ein Task, der auf einem Core läuft, kann Tasks auf anderen Cores verlangsamen, creating unpredictable Timing Variations.

Schlüssel-Fragen entstehen: Wie quantifizieren wir den Impact solcher Interferenz? Wie analysieren, testen und dokumentieren wir, dass sicherheitskritische Software immer innerhalb ihrer Deadlines auf einer Multicore Plattform fertig wird?

Industry Leaders – Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC), und Marelli Europe (MAR) – haben Jahre damit verbracht, diese Challenges zu adressieren. BSC und Rapita liefern nun eine Solution Set, das bald across Aerospace und Automotive Sektoren adopted wird. Der Erfolg basiert auf spezialisiertem Tooling, Automation und einer Safety-Oriented, Requirements-Driven Methodology.

Diese Arbeit untermauert das MASTECS Project, eine European Commission-gefundete, multidisziplinäre R&D Initiative, gestartet Dezember 2019. MASTECS wird die Technologien reifen lassen und einen bewährten Ansatz für Zertifizierung von Avionics und Automotive Systems bereitstellen, mit Case Studies von RTRC und MAR, die Real-World Impact illustrieren.

State-of-the-Art Tools

Kommerzielle Tools excel für Single-Core Analyse, strugglen aber mit der Komplexität der Multicore Zertifizierung. Limitations umfassen:

• Static Timing Analysis Tools [1] hit eine Complexity Wall, unable zu modellieren sophisticated Hardware oder extrem komplexe Software.
• Measurement-Based Solutions – während prevalent in Single-Core Testing (z. B. Rapitas RVS Toolset) – fehlt Hardware-Expert Methodology, um trustworthy Timing Bounds für Multicore Workloads mit adequate Traceability zu produzieren.

Bis dato bietet kein kommerzielles Tool außerhalb der MASTECS Development Effort umfassende Multicore Timing Analysis, die mit Safety Standards und Emerging Certification Requirements aligniert.

Interference Analysis und Control in Action

Der Cornerstone unseres Ansatzes ist eine strukturierte Test Methodology, die Hardware und Software Expertise blended, um Evidence von Multicore Timing Behavior zu generieren. BSCs Multicore Micro-Benchmark Technology (MμBT), commercialized by Rapita als RapiDaemons, ermöglicht Designern, Interferenz-Szenarien zu erstellen, die spezifische Shared Resources stressen.

Micro-Benchmarks – tiny, Low-Level Code Snippets – operieren am Hardware-Software Interface, um quantifizierbaren Druck auf eine Target Resource auszuüben. Sie offenbaren den Effect von Interferenz-Channels und können tailored werden, um Contention zu induzieren, messen oder validieren. Key Attributes umfassen:

1. Targeted, quantifizierbarer Druck auf eine Shared Resource.
2. Verifizierbares Verhalten durch Event Monitors.
3. Alignment mit spezifischen Timing Requirements, wie Testing Mitigation Effectiveness.

Eine diverse Library von Micro-Benchmarks existiert, um gewünschte Interferenz-Levels zu matchen, Resource Impact zu maximieren, oder als sensible „Victim“ Tests zu agieren.

Bei Interferenz-Analyse paaren wir MμBT mit einem Task Contention Model (TCM), das Early Estimates von Contention Delays liefert. Rapitas RapiTest und RapiTime automatisieren Test Creation und Execution auf dem Embedded Target.

Design Methodology

Folgend einem Sieben-Schritt-Prozess, integriert in den V-Model Software Lifecycle (siehe Abbildung 2), gewinnen Ingenieure tiefen Einblick in Interferenz-Effekte:

1. Hardware Konfiguration & Interferenz Channel Identifikation. Hardware Experts pinnen kritische Settings, Interferenz-Pfade und Mitigation Options, während sie Event Monitors für Verifikation selektieren.
2. Timing Requirements definieren. Capture User-spezifische Needs, Risks und Safety Constraints, und evaluieren Hardware Isolation Strategies.
3. Test Case Design. Craft Test Descriptions, die Hypothesen validieren, spezifizierend Micro-Benchmarks needed für Interferenz-Analyse unter Isolated und Stressed Conditions.
4. Test Procedures Implementieren. Assemble Test Framework, Micro-Benchmarks und Measurement Probes. Currently Manual, dies wird innerhalb MASTECS automatisiert.
5. Evidence Gather. Execute Tests auf Target Platform, collecting Data, die direkt zu Verification Requirements tied.
6. Results Analysieren. Technical Experts review Outcomes gegen Requirements. Beispielsweise zeigt Abbildung 3 Rapitimes Execution-Time Breakdown.
7. Validieren & Dokumentieren. Final Review, Report Generation, und Qualification Artifacts ready für Certification Submissions.

Hardware Expertise und der Timing Analysis Prozess

Hardware Insight ist vital vom Start. Early Involvement umfasst:

1. Identifizieren von Multicore Konfigurationen, die Functional und Timing Behavior formen, und Bestimmen von Isolation Mechanisms, die Contention reduzieren.
2. Spotting Interferenz Channels durch Navigieren komplexer Processor Manuals und Consulting Vendors für Missing Details.
3. Selektion von Event Monitors, die Task Activity auf Interferenz Channels capture, und Validierung mit dedizierten Micro-Benchmarks [2].
4. Kollaboration mit Timing Analysts zur Ableitung von Requirements und Design von Tests, die spezifische Interferenz Channels laden.

In späteren Stages assessen Hardware Experts Test Results, verfeinern Hypothesen, und proposen Additional Tests as needed.

The Bigger Picture

Der Sieben-Schritt Design Process ist Teil einer breiteren Multicore Verification Methodology (siehe Abbildung 2). Er liefert Full Traceability – von Evidence und Results zurück zu Requirements und Design – supporting sowohl CAST-32A als auch ISO 26262. CAST-32A, released by Certification Authorities Software Team (CAST) 2016, outlines Objectives für Safe Multicore Avionics, inklusive Interference Bounding. EASA und FAA arbeiten an Unified AMC/AC (AMC 20-193) Adaptation, expected später dieses Jahr.

Expertise Cannot Be Automated

Interferenz Dynamics sind komplex; Automated Tools können nur complement, nicht replace, Seasoned Engineers. Multicore Experts bringen tiefes Wissen von Hardware Konfigurationen und Interferenz Channels, während Software Analysts Requirements in Rigorous Tests übersetzen. Human Insight ist essential für Validating Assumptions, Interpreting Results, und Iterating auf Designs.

Referenzen

1. Reinhard Wilhelm. Mixed Feelings about Mixed Criticality. Workshop on Worst-Case Execution Time Analysis, 2018.
2. Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. High-Integrity Performance Monitoring Units in Automotive Chips for Reliable Timing V&V. IEEE Micro 38(1): 56-65 (2018).
3. EASA and FAA to issue further guidance on multicore certification this year.