Zorgen voor het timinggedrag van software in kritieke multicore-gebaseerde embedded systemen

Veilig ergens komen hangt niet alleen af ​​van goede remmen, werkende achterlichten en iemand met uitstekende reflexen achter het stuur. De componenten die uw auto op de weg en uw vliegtuig in de lucht houden, zijn in toenemende mate niet alleen menselijk, of zelfs alleen mechanisch. Het zijn geavanceerde stukjes embedded software die draait op complexe heterogene multicore-processors, die alles regelen, van vluchtbeheersysteem tot stuurbekrachtiging, en uitvoeren tot strikte timing-deadlines gemeten in microseconden.

Hierin ligt de uitdaging. Het timinggedrag van software in een multicoresysteem wordt niet alleen beïnvloed door de software die erop draait en de inputs, maar ook door de andere software die op andere cores draait.

Kritische embedded systemen vergen een enorme inspanning en investering (miljoenen euro's/dollars en jaren van engineering-inspanning) om te ontwikkelen. Veiligheid moet centraal staan ​​in de architectuur en het ontwerp, vanaf de vroegste stadia van het softwareontwikkelingsproces. Systeemontwerpers moeten met name het timinggedrag van hun software begrijpen, om ervoor te zorgen dat deze binnen veilige tijdsbestekken kan worden uitgevoerd.

De puzzel met multicore timinganalyse (MTA) oplossen

Hoewel de geweldige rekencapaciteit van een multicore-processor (in theorie) embedded systemen krachtiger en efficiënter zou moeten maken, kan software die op één kern wordt uitgevoerd, de uitvoering van software op de andere kernen vertragen. In deze situatie kan het langer duren voordat de software wordt uitgevoerd vanwege interferentie die wordt veroorzaakt door twist voor gedeelde bronnen zoals bussen, geheugen, caches, apparaten, FPGA's en GPU's die worden gedeeld met taken die op andere kernen worden uitgevoerd.

Hoe kwantificeer je de effecten van deze interferentie? Hoe analyseert, test en levert u concreet bewijs dat uw veiligheidskritieke software, wanneer deze op een multicore-platform draait, altijd binnen de deadlines kan worden uitgevoerd?

Experts van het Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) en Marelli Europe (MAR) onderzoeken al jaren de antwoorden op deze vragen. BSC en Rapita hebben een oplossing ontwikkeld die binnenkort in de lucht- en ruimtevaart- en auto-industrie zal worden uitgerold. Gespecialiseerde tooling en automatisering, gecombineerd met een op vereisten gebaseerde, op veiligheid gerichte methodologie waren de sleutels tot het oplossen van de puzzel.

Dit werk vormde de basis van het MASTECS-project, een multidisciplinair onderzoeks- en ontwikkelingsproject gefinancierd door de Europese Commissie en gelanceerd in december 2019. Het MASTECS-project zal de technologieën rijpen en het gebruik ervan ondersteunen voor de certificering van luchtvaartelektronica en autosystemen. Een belangrijk onderdeel van het MASTECS-project is om een ​​demonstratie te geven van de aanpak in twee bedrijfstakken door middel van casestudies die zijn ingezet door RTRC en MAR.

Geavanceerde hulpmiddelen

In de handel verkrijgbare tools ter ondersteuning van timinganalyse zijn effectief voor eenvoudige (single-core) elektronica, maar kunnen niet worden geschaald om te voldoen aan nieuwe multicore-specifieke certificeringsvereisten en -aanbevelingen.

• Oplossingen voor statische timinganalyse [1] hebben te maken met een complexiteitsmuur en kunnen de steeds complexere hardware niet effectief modelleren en evenmin efficiënt omgaan met de structurele en syntactische kenmerken van uitzonderlijk complexe softwarefunctionaliteiten.
• Op metingen gebaseerde oplossingen hebben een goede penetratiegraad bereikt in de markt voor single-core analyse (de RVS-toolset van Rapita Systems behoort tot de meest succesvolle). Dergelijke tools zijn echter nog steeds niet in staat om de uitdagingen van de introductie van multicores volledig aan te kunnen. Ze richten zich doorgaans op meetscenario's zoals bepaald door geconsolideerde functionele teststrategieën, maar missen een op hardware-expertise gebaseerde methodologie die helpt bij het afleiden van betrouwbare timinggrenzen voor taken die in multicore worden uitgevoerd met het nodige ondersteunende bewijs en een adequaat niveau van traceerbaarheid.

Voor zover wij weten, is er geen commerciële tool op de markt beschikbaar, behalve degene die wordt ontwikkeld in MASTECS, die in staat is om de timing van software op multicore-platforms te analyseren, met een sterke focus op toepasselijke veiligheidsnormen en opkomende certificeringsvereisten.

Interferentieanalyse en controle in actie

De sleutel tot het begrijpen van interferentie is een gestructureerde testmethodologie, waarbij hardware- en software-experts worden gebruikt om bewijs te produceren over multicore-timinggedrag. Een gespecialiseerde technologie van BSC (bekend als multicore microbenchmark-technologie of MμBT, door Rapita gecommercialiseerd als RapiDaemons) stelt systeemontwerpers in staat de effecten van interferentie in een multicore-gebaseerde toepassing te analyseren en te kwantificeren door aanvullende interferentiescenario's te creëren om verschillende onderdelen van de multicore-processor.

Micro-benchmarks, de kern van MuBT, zijn goed gemaakte stukjes code die werken op de laagste interface tussen hardware en software om een ​​specifieke gedeelde bron te benadrukken. Micro-benchmarks leggen de impact van interferentiekanalen op softwaretiming bloot. Hiervoor kunnen micro-benchmarks worden ingezet om een ​​configureerbare en meetbare druk op een specifieke applicatie uit te oefenen. Micro-benchmarks zijn specifiek ontworpen om een ​​enkel, duidelijk gedefinieerd gedrag te vertonen met een verwacht effect op een specifieke hardwarebron, terwijl zoveel mogelijk wordt voorkomen dat er conflicten ontstaan ​​op andere interferentiekanalen. De belangrijkste kenmerken van de microbenchmark zijn:

1. Ze zetten meetbare druk op specifieke gedeelde bronnen.
2. Hun gedrag kan worden geverifieerd via gebeurtenismonitors.
3. Ze leggen specifieke timinggerelateerde vereisten vast, bijvoorbeeld of de mitigerende maatregelen die je hebt genomen om twisten onder de knie te krijgen, effectief zijn.

klik voor grotere afbeelding

Figuur 1:Gebruik van micro-benchmarks in interferentieanalyse. (Bron:Auteurs)

Er is een breed scala aan microbenchmarks ontwikkeld om specifieke rollen te vervullen, waaronder het afstemmen van een gewenst interferentieniveau, het maximaliseren van de interferentie op de bron of eenvoudigweg erg gevoelig zijn voor twisten ('slachtoffers').

Bij het analyseren van de effecten van interferentie wordt het gebruik van MμBT ondersteund met een taakconflictmodel (TCM) dat vroege schattingen geeft van de conflictvertragingstaken die kunnen lijden. Softwareautomatisering en testtools RapiTest en RapiTime ontwikkeld door Rapita worden gebruikt om tests te schrijven en uit te voeren op het ingebedde doel.

Ontwerpmethodologie

Door een testontwerpproces van zeven stappen te volgen langs het standaard 'V'-ontwikkelingsproces van de software (Figuur 2), kunnen ingenieurs de impact van interferentie beter begrijpen.

1. Kritische configuratie-instelling voor multicore-processor, interferentiekanaal en analyse van gebeurtenismonitor. Hardware-experts helpen bij het identificeren van kritieke configuratie-instellingen om het raamwerk te bepalen waarin ook interferentiekanalen worden geïdentificeerd, samen met mitigerende maatregelen. De identificatie van hardware-eventmonitors is ook essentieel om een ​​verificatiemiddel te bieden voor alle volgende stappen.
2. Identificeer timingvereisten. Help de eindgebruiker om hun specifieke behoeften, timingvereisten, risico's en veiligheidskwesties voor het systeem te identificeren. Controleer bijvoorbeeld de prestaties van elke hardware-isolatiemethode om interferentie te minimaliseren.
3. Testcase-ontwerp. Ontwikkel specifieke testgevallen (beschrijving van een test) om de reeks hypothesen te verifiëren die de gebruikersvereisten ondersteunen, inclusief het definiëren van de MμBT-items die nodig zijn om bewijs te leveren in de interferentiekanaalanalyse. Dit omvat uitvoering in isolatie (geen interferentie), uitvoering tegen micro-benchmarks om de uitvoeringstijd van de applicatie en hardwaregevoeligheid voor interferentie onder verschillende kwantificeerbare stressscenario's te beoordelen.
4. Implementatie van testprocedures. Momenteel is dit een handmatig proces dat moet worden geautomatiseerd in MASTECS. Deze stap bouwt de testprocedures op die bestaan ​​uit een testkader, microbenchmarks en meetsondes om de resultaten vast te leggen/te traceren.
5. Bewijs verzamelen (testen). De testprocedures worden uitgevoerd op het platform om testbewijs te verzamelen. Momenteel is er wat handmatig werk nodig, maar dit zal worden geautomatiseerd in MASTECS met behulp van het RapiTest-automatiseringsraamwerk om die tests uit te voeren en terug te koppelen aan verificatievereisten.
6. Resultatenanalyse. Een beoordeling van de testresultaten door technische experts om te controleren hoe de testresultaten (of anderszins) de verificatie-eisen verifiëren. Figuur 3 toont bijvoorbeeld een screenshot van RapiTime over de uitvoeringstijden die zijn gerapporteerd voor verschillende functies van een programma.
7. Bevestig resultaten en genereer documentatie. Definitieve beoordeling van de vereisten, het genereren van documentatie en kwalificatieresultaten ter ondersteuning van het veiligheidsargument van het systeem. De klant kan de volledige set van rapporten en analyse-artefacten direct gebruiken voor de certificering van software die op multicore draait.

klik voor grotere afbeelding

Figuur 2:MTA-stappen in het V-model softwareontwikkelingsproces. (Bron:Auteurs)

Hardware-expertise en het timinganalyseproces

Het injecteren van hardware (multicore)-expertise is een belangrijk kenmerk in de voorgestelde MTA-aanpak voor het succes ervan op moderne complexe multicores. Tijdens vroege stadia van softwareontwikkeling:

1. Hardware-experts identificeren multicore-configuraties (kritieke configuratie-instellingen in avionica-jargon) omdat ze een sleutelrol spelen bij het bepalen van het functionele en timinggedrag van de software, en grotendeels van invloed zijn op het aantal conflicttaken dat elkaar genereert. Een illustratief voorbeeld:de huidige processors implementeren isolatie- en segregatiemechanismen die, indien correct ingezet, conflicten sterk kunnen verminderen.
2. Multicore-experts spelen een sleutelrol bij het identificeren van de bronnen waarin taakconflicten kunnen ontstaan ​​(deze worden interferentiekanalen genoemd in de luchtvaartelektronica). Het vermogen van hardware-experts om door technische handleidingen van de processor van meerdere duizenden pagina's te navigeren en de juiste vragen te formuleren over de mogelijk ontbrekende informatie in de handleidingen aan de chipleveranciers, is van fundamenteel belang om een ​​geschikt MTA-proces aan te sturen.
3. Zodra interferentiekanalen zijn geïdentificeerd, identificeren hardware-experts die eventmonitors die kunnen worden gebruikt om de activiteit te volgen die taken op die interferentiekanalen genereren als een proxy-metriek om de bewering dat taken kunnen lijden te beperken. De juistheid van die eventmonitors moet ook worden geverifieerd [2] waarvoor een gespecialiseerde set microbenchmarks is ontworpen.
4. Ten slotte werken hardware-experts hand in hand met experts op het gebied van timinganalyse om uit gebruikersvereisten, vereisten op hoog en laag niveau en specifieke tests af te leiden om de hypothesen te valideren die de gebruikersvereisten ondersteunen. Elke test start een of meerdere micro-benchmarkprogramma's die zijn ontworpen door hardware-experts om het gewenste niveau van belasting op het (de) beoogde interferentiekanaal(en) te leggen.

Tijdens late ontwerpfasen:

1. Hardware-experts dragen bij aan de analyse van testresultaten om te beoordelen of ze hypothesen bevestigen of verwerpen.
2. Hardware-experts dragen ook bij aan het vaststellen van nieuwe hypothesen en de bijbehorende tests voor het geval ze nodig zijn op basis van de resultaten die in de vorige stap zijn verkregen.

klik voor grotere afbeelding

Figuur 3:Resultaten analyseren (RapiTime). (Bron:Auteurs)

Het grotere plaatje

Het 7-stappen-testontwerpproces is slechts een onderdeel van een bredere multicore-verificatiemethodologie die eerder in figuur 2 is getoond. Deze methodologie, die verder zal worden ontwikkeld als onderdeel van het MASTECS-project, is ontworpen om volledige traceerbaarheid te bereiken, van uitgebreid bewijs en resultaten terug naar de bijbehorende eisen en ontwerpen. De methodologie is ontworpen om te voldoen aan de doelstellingen die zijn gedefinieerd in CAST-32A, het belangrijkste richtsnoer dat is uitgegeven door luchtvaartcertificeringsinstanties. Het is ook specifiek afgestemd op ISO 26262, de veiligheidsnorm voor de automobielsector, die vrijheid van interferentie bepleit.

CAST-32A werd in 2016 gepubliceerd door het Certification Authorities Software Team (CAST) en identificeert factoren die van invloed zijn op de veiligheid, prestaties en integriteit van softwaresystemen in de lucht die worden uitgevoerd op multicore-processors. Als u multicore-hardware in een avionica-systeem wilt gebruiken, is dit het go-to-document. Het biedt doelstellingen die bedoeld zijn om de productie van veilige multicore-avionicssystemen te begeleiden, inclusief doelstellingen met betrekking tot het identificeren en begrenzen van de impact van interferentiekanalen. Bekijk hier het CAST-32A position paper. EASA en FAA werken aan een aanpassing van de multicore generieke CRI in een gemeenschappelijk AMC/AC-materiaal (AMC 20-193). Het wordt naar verwachting "later dit jaar"[3] gepubliceerd.

Expertise kan niet worden geautomatiseerd

Interferentie-effecten zijn complex. Om hun mysteries te ontrafelen, heb je experts nodig die zowel de componenten van de multicore-architectuur als de plannings- en resourcetoewijzingssystemen in de software begrijpen. Samenwerking tussen hardware- en software-experts zal in de toekomst een centraal kenmerk van het MASTECS-project zijn. Maar hoewel samenwerking leidt tot grote vooruitgang op het gebied van softwaretooling en -automatisering, is het belangrijk om te onthouden dat je niet elke stap van een validatieproces kunt automatiseren, vooral niet wanneer er sprake is van multicore-timinganalyse.

Je hebt ervaren engineers nodig die de systemen tot in detail kennen. Tijdens de vroege stadia kunnen multicore-experts bijvoorbeeld de processorconfiguraties (ook bekend als hardwarekritische configuratie-instellingen) identificeren die het functionele en timinggedrag van de software bepalen, evenals de potentiële interferentiekanalen. Als het gaat om het analyseren van testresultaten, gaat er niets boven de input van een ervaren menselijke expert om de oorspronkelijke aannames die over het platform zijn gemaakt opnieuw te bekijken en te evalueren, en hun kennis te gebruiken om een ​​nieuwe testcyclus in te voeren.

Referenties

[1] Reinhard Wilhelm. Gemengde gevoelens over gemengde kritiek. Workshop over analyse van uitvoeringstijd in het slechtste geval, 2018.

[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. High-Integrity Performance Monitoring Units in Automotive Chips voor betrouwbare 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/