Betrouwbare timing garanderen in safety-critical multicore embedded systemen

Moderne voertuigen en vliegtuigen vertrouwen niet meer uitsluitend op mechanische componenten. Hun veiligheid en prestaties hangen af van embedded-software die draait op complexe heterogene multicore-processoren, die alles managen van vluchtcontrole tot stuurbekrachtiging met microseconden-deadlines.

In een multicore-omgeving wordt de uitvoeringstijd van een taak niet alleen beïnvloed door zijn eigen code, maar ook door andere taken die dezelfde hardware-resources delen. Deze interferentie kan een systeem buiten zijn veiligheidsmarges duwen.

Het ontwikkelen van safety-critical embedded-software vereist een multi-miljoen-euro, multi-jaar inspanning. Vanaf de vroegste ontwerpfasen moet veiligheid ingebakken zitten in de architectuur en het timing-gedrag van elke taak rigoureus begrepen worden om deadlines te garanderen.

De multicore timing-analyse puzzel oplossen

Terwijl multicore-processors hogere prestaties beloven, introduceren ze ook contention voor gedeelde resources zoals bussen, geheugen, caches, en accelerators. Een taak die draait op één kern kan taken op andere kernen vertragen, wat onvoorspelbare timing-variaties creëert.

Kernvragen rijzen: Hoe kunnen we de impact van dergelijke interferentie kwantificeren? Hoe analyseren, testen, en documenteren we dat safety-critical software altijd binnen zijn deadlines zal finishen op een multicore-platform?

Industrie-leiders – Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC), en Marelli Europe (MAR) – hebben jaren besteed aan het adresseren van deze uitdagingen. BSC en Rapita leveren nu een oplossingsset die binnenkort geadopteerd zal worden over aerospace- en automotive-sectoren. Het succes hangt af van gespecialiseerde tooling, automatisering, en een safety-georiënteerde, requirements-gedreven methodologie.

Dit werk ondersteunt het MASTECS-project, een European Commission-gefinancieerde, multidisciplinaire R&D-initiatief gelanceerd in december 2019. MASTECS zal de technologieën volwassen maken en een bewezen benadering bieden voor het certificeren van avionics- en automotive-systemen, met case-studies van RTRC en MAR die real-world-impact illustreren.

State-of-the-art Tools

Commerciële tools excelleren voor single-core-analyse maar worstelen met de complexiteit van multicore-certificering. De beperkingen omvatten:

• Statische timing-analyse-tools [1] raken een complexiteitsmuur, onstaat om gesofisticeerde hardware of extreem complexe software te modelleren.
• Measurement-based oplossingen – hoewel prevalent in single-core-testing (bijv. Rapita's RVS-toolset) – missen een hardware-expert-methodologie om betrouwbare timing-bounds te produceren voor multicore-workloads met adequate traceerbaarheid.

Tot op heden biedt geen commercieel tool buiten de MASTECS-ontwikkelinspanning uitgebreide multicore-timing-analyse die aligned is met veiligheidsstandaarden en opkomende certificeringsvereisten.

Interferentie-analyse en -controle in actie

Micro-benchmarks – kleine, low-level code-snippets – opereren aan de hardware-software-interface om kwantificeerbare druk op een target-resource uit te oefenen. Ze onthullen het effect van interferentie-kanalen en kunnen afgestemd worden om contention te induceren, meten, of valideren. Kernkenmerken omvatten:

1. Gerichte, kwantificeerbare druk op een gedeelde resource.
2. Verifieerbaar gedrag via event-monitors.
3. Afstemming op specifieke timing-vereisten, zoals het testen van mitigatie-effectiviteit.

Een diverse bibliotheek van micro-benchmarks bestaat om gewenste interferentie-niveaus te matchen, resource-impact te maximaliseren, of te fungeren als gevoelige "victim"-tests.

Bij het analyseren van interferentie, koppelen we MμBT met een Task Contention Model (TCM) dat vroege schattingen van contention-delays levert. Rapita's RapiTest en RapiTime automatiseren testcreatie en -uitvoering op de embedded-target.

Ontwerp-methodologie

Volgend een zeven-stappen-proces geïntegreerd in de V-model software-lifecycle (zie Figuur 2), krijgen ingenieurs diep inzicht in interferentie-effecten:

1. Hardware-configuratie & interferentie-kanaal-identificatie. Hardware-experts duiden kritieke instellingen, interferentie-paden, en mitigatie-opties aan, terwijl ze event-monitors selecteren voor verificatie.
2. Timing-vereisten definiëren. Vangen gebruiker-specifieke behoeften, risico's, en veiligheidsconstraints, en evalueer hardware-isolatiestrategieën.
3. Testcase-ontwerp. Vak testbeschrijvingen die hypothesen valideren, specificerend de micro-benchmarks nodig voor interferentie-analyse onder geïsoleerde en gestreste condities.
4. Testprocedures implementeren. Assembleer een test-framework, micro-benchmarks, en meetprobes. Momenteel handmatig, dit zal geautomatiseerd worden binnen MASTECS.
5. Bewijs verzamelen. Voer tests uit op het target-platform, verzamel data die direct gerelateerd is aan verificatie-vereisten.
6. Resultaten analyseren. Technische experts beoordelen uitkomsten tegen vereisten. Bijvoorbeeld, Figuur 3 toont RapiTime's uitvoeringstijd-breakdown.
7. Valideren & documenteren. Finale review, rapportage-generatie, en kwalificaties-artefacten klaar voor certificeringsinzettingen.

Hardware-expertise en het timing-analyseproces

Hardware-inzicht is vitaal vanaf het begin. Vroeg betrokkenheid omvat:

1. Identificeren van multicore-configuraties die functioneel en timing-gedrag vormgeven, en isolatiemechanismen bepalen die contention reduceren.
2. Interferentie-kanalen spotten door complexe processor-handboeken te navigeren en vendors te raadplegen voor ontbrekende details.
3. Event-monitors selecteren die taakactiviteit op interferentie-kanalen vastleggen, en ze valideren met toegewijde micro-benchmarks [2].
4. Samenwerken met timing-analisten om vereisten af te leiden en tests te ontwerpen die specifieke interferentie-kanalen laden.

In latere stadia beoordelen hardware-experts testresultaten, verfijnen hypothesen, en stellen additionele tests voor zoals nodig.

Het grotere plaatje

Het zeven-stappen-ontwerpproces is onderdeel van een bredere multicore-verificatiemethodologie (zie Figuur 2). Het levert volledige traceerbaarheid – van bewijs en resultaten terug naar vereisten en ontwerp – wat zowel CAST-32A als ISO 26262 ondersteunt. CAST-32A, uitgegeven door de Certification Authorities Software Team (CAST) in 2016, omrijt doelen voor veilige multicore-avionics, inclusief interferentie-bounding. EASA en FAA werken aan een unified AMC/AC (AMC 20-193) adaptatie verwacht later dit jaar.

Expertise kan niet geautomatiseerd worden

Interferentie-dynamiek is complex; geautomatiseerde tools kunnen alleen complementeren, niet vervangen, ervaren ingenieurs. Multicore-experts brengen diepe kennis van hardware-configuraties en interferentie-kanalen, terwijl software-analisten vereisten vertalen in rigoureuze tests. Menselijk inzicht is essentieel voor het valideren van assumpties, het interpreteren van resultaten, en het itereren op ontwerpen.

Referenties

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 en FAA om verdere richtlijnen voor multicore-certificering uit te geven dit jaar.