Assurer le comportement de synchronisation du logiciel dans les systèmes embarqués multicœurs critiques

Pour arriver quelque part en toute sécurité, il ne suffit pas de bons freins, de feux arrière fonctionnels et d'une personne dotée d'excellents réflexes au volant. De plus en plus, les composants qui maintiennent votre voiture sur la route et votre avion dans les airs ne sont pas seulement humains, ni même simplement mécaniques. Ce sont des logiciels embarqués sophistiqués fonctionnant sur des processeurs multicœurs hétérogènes complexes, contrôlant tout, du système de gestion de vol à la direction assistée, et s'exécutant dans des délais stricts mesurés en microsecondes.

C'est là que réside le défi. Le comportement de synchronisation du logiciel dans un système multicœur est affecté non seulement par le logiciel exécuté sur celui-ci et ses entrées, mais également par les autres logiciels exécutés sur d'autres cœurs.

Les systèmes embarqués critiques nécessitent un effort et un investissement immenses (millions d'euros/dollars et des années d'effort d'ingénierie) pour être développés. La sécurité doit être au cœur de l'architecture et de la conception, dès les premières étapes du processus de développement logiciel. En particulier, les concepteurs de systèmes doivent comprendre le comportement de synchronisation de leur logiciel, pour s'assurer qu'il peut s'exécuter dans des délais sûrs.

Résoudre le casse-tête de l'analyse temporelle multicœur (MTA)

Bien que l'impressionnante capacité de calcul d'un processeur multicœur devrait (en théorie) rendre les systèmes embarqués plus puissants et efficaces, les logiciels exécutés sur un cœur peuvent ralentir l'exécution des logiciels exécutés sur les autres cœurs. Dans cette situation, l'exécution du logiciel peut prendre plus de temps en raison des interférences causées par la contention des ressources partagées telles que les bus, la mémoire, les caches, les périphériques, les FPGA et les GPU qui sont partagés avec des tâches s'exécutant sur d'autres cœurs.

Comment quantifier les effets de cette interférence ? Comment analysez-vous, testez-vous et fournissez-vous des preuves concrètes que votre logiciel critique pour la sécurité, lorsqu'il s'exécute sur une plate-forme multicœur, peut toujours s'exécuter dans les délais impartis ?

Les experts du Barcelona Supercomputing Center (BSC), de Rapita Systems Ltd (RPT), de Raytheon Technologies (RTRC) et de Marelli Europe (MAR) étudient les réponses à ces questions depuis de nombreuses années. BSC et Rapita ont développé une solution qui sera bientôt déployée dans les secteurs de l'aérospatiale et de l'automobile. Un outillage et une automatisation spécialisés, combinés à une méthodologie basée sur les exigences et axée sur la sécurité, ont été les clés de la résolution de l'énigme.

Ce travail a constitué la base du projet MASTECS, un projet de recherche et développement multidisciplinaire financé par la Commission européenne et lancé en décembre 2019. Le projet MASTECS fera mûrir les technologies et soutiendra leur utilisation pour la certification des systèmes avioniques et automobiles. Un élément clé du projet MASTECS est de fournir une démonstration de l'approche dans deux industries à travers des études de cas déployées par RTRC et MAR.

Outils de pointe

Les outils disponibles dans le commerce pour prendre en charge l'analyse de la synchronisation sont efficaces pour l'électronique simple (monocœur), mais ne s'adaptent pas pour répondre aux nouvelles exigences et recommandations de certification spécifiques au multicœur.

• Les solutions d'analyse temporelle statique [1] sont confrontées à un mur de complexité et ne peuvent ni modéliser efficacement le matériel de plus en plus complexe, ni traiter efficacement les caractéristiques structurelles et syntaxiques de fonctionnalités logicielles exceptionnellement complexes.
• Les solutions basées sur la mesure ont atteint un bon niveau de pénétration sur le marché de l'analyse monocœur (l'ensemble d'outils RVS de Rapita Systems étant parmi les plus performants). Cependant, de tels outils ne sont toujours pas en mesure de répondre pleinement aux défis posés par l'introduction des multicœurs. Ils se concentrent généralement sur des scénarios de mesure tels que déterminés par des stratégies de test fonctionnel consolidées, mais ne disposent pas d'une méthodologie basée sur l'expertise matérielle qui permet de dériver des limites temporelles fiables pour les tâches s'exécutant en multicœur avec les preuves nécessaires et un niveau de traçabilité adéquat.

À notre connaissance, aucun outil commercial n'est disponible sur le marché, autre que celui en cours de maturation dans MASTECS, capable d'analyser le timing des logiciels sur des plates-formes multicœurs, en mettant fortement l'accent sur les normes de sécurité applicables et les nouvelles exigences de certification.

Analyse et contrôle des interférences en action

La clé pour comprendre les interférences est une méthodologie de test structurée, utilisant des experts en matériel et en logiciel pour produire des preuves sur le comportement de synchronisation multicœur. Une technologie spécialisée de BSC (connue sous le nom de technologie de micro-étalonnage multicœur ou MμBT, commercialisée par Rapita sous le nom de RapiDaemons) permet aux concepteurs de systèmes d'analyser et de quantifier les effets des interférences dans une application multicœur en créant des scénarios d'interférence supplémentaires pour tester différentes parties de le processeur multicœur.

Les micro-benchmarks, au cœur de MuBT, sont des morceaux de code bien conçus qui fonctionnent à l'interface la plus basse entre le matériel et le logiciel pour mettre l'accent sur une ressource partagée spécifique. Les micro-benchmarks exposent l'impact des canaux d'interférence sur la synchronisation du logiciel. Pour ce faire, des micro-benchmarks peuvent être déployés pour provoquer une pression paramétrable et quantifiable sur une application spécifique. Les micro-benchmarks sont spécifiquement conçus pour présenter un comportement unique et clairement défini avec un effet anticipé sur une ressource matérielle spécifique, tout en empêchant autant que possible de générer des conflits sur d'autres canaux d'interférence. Les fonctionnalités clés du micro-benchmark sont les suivantes :

1. Ils exercent une pression quantifiable sur une ressource partagée spécifique.
2. Leur comportement peut être vérifié via des moniteurs d'événements.
3. Ils capturent des exigences spécifiques liées au calendrier, par exemple, si les mesures d'atténuation que vous mettez en place pour maîtriser les conflits sont efficaces.

cliquez pour agrandir l'image

Figure 1 :Utilisation de micro-benchmarks dans l'analyse des interférences. (Source :Auteurs)

Un large éventail de micro-indices de référence ont été développés pour avoir des rôles spécifiques, notamment correspondre à un niveau d'interférence souhaité, maximiser l'interférence sur la ressource ou simplement être très sensible aux conflits (« victimes »).

Lors de l'analyse des effets des interférences, l'utilisation de MμBT est prise en charge par un modèle de conflit de tâches (TCM) qui fournit des estimations précoces du retard de conflit que les tâches peuvent subir. Les outils logiciels d'automatisation et de test RapiTest et RapiTime développés par Rapita permettent d'écrire des tests et de les exécuter sur la cible embarquée.

Méthodologie de conception

En suivant un processus de conception de test en sept étapes tout au long du processus de développement logiciel standard en « V » (Figure 2), les ingénieurs peuvent mieux comprendre l'impact des interférences.

1. Paramètre de configuration critique du processeur multicœur, analyse du canal d'interférence et du moniteur d'événements. Les experts en matériel aident à identifier les paramètres de configuration critiques pour définir le cadre dans lequel les canaux d'interférence sont également identifiés ainsi que les mesures d'atténuation. L'identification des moniteurs d'événements matériels est également essentielle pour fournir un moyen de vérification pour toutes les étapes suivantes.
2. Identifier les exigences de temps. Aidez l'utilisateur final à identifier ses besoins spécifiques, les exigences de temps, les risques et les problèmes de sécurité pour le système. Par exemple, vérifiez les performances de toute approche d'isolation matérielle pour minimiser les interférences.
3. Conception de cas de test. Développer des cas de test spécifiques (description d'un test) pour vérifier l'ensemble d'hypothèses soutenant les besoins des utilisateurs, y compris la définition des éléments MμBT qui seront requis pour fournir des preuves dans l'analyse du canal d'interférence. Cela implique une exécution isolée (aucune interférence), une exécution par rapport à des micro-benchmarks pour évaluer le temps d'exécution de l'application et la sensibilité du matériel aux interférences dans différents scénarios de stress quantifiables.
4. Mise en œuvre des procédures de test. Actuellement, un processus manuel à automatiser dans MASTECS, cette étape construit les procédures de test consistant en un cadre de test, des micro-benchmarks et des sondes de mesure pour enregistrer/tracer les résultats.
5. Collecte de preuves (tests). Les procédures de test sont exécutées sur la plate-forme pour recueillir des preuves de test. Impliquant actuellement du travail manuel, cela sera automatisé dans MASTECS à l'aide du cadre d'automatisation RapiTest pour exécuter ces tests et les lier aux exigences de vérification.
6. Analyse des résultats. Un examen des résultats des tests par des experts techniques pour vérifier comment les résultats des tests vérifient (ou non) les exigences de vérification. Par exemple, la figure 3 montre une capture d'écran de RapiTime sur les temps d'exécution signalés pour différentes fonctions d'un programme.
7. Valider les résultats et générer de la documentation. Examen final des exigences, génération de la documentation et des résultats de qualification pour soutenir l'argument de sécurité du système. Le client peut utiliser l'ensemble complet de rapports et d'artefacts d'analyse directement pour la certification de logiciels fonctionnant sur multicœur.

cliquez pour agrandir l'image

Figure 2 : étapes du MTA dans le processus de développement logiciel du modèle V. (Source :Auteurs)

Expertise matérielle et processus d'analyse temporelle

L'injection d'expertise matérielle (multicœur) est un élément clé de l'approche MTA proposée pour son succès sur les multicœurs complexes modernes. Pendant les premières étapes du développement du logiciel :

1. Les experts en matériel identifient les configurations multicœurs (paramètres de configuration critiques dans le jargon avionique) car elles jouent un rôle clé dans la détermination du comportement fonctionnel et de synchronisation du logiciel, et affectent largement la quantité de tâches de conflit qui se génèrent mutuellement. À titre d'exemple, les processeurs actuels implémentent des mécanismes d'isolement et de ségrégation qui, s'ils sont correctement déployés, peuvent fortement réduire les conflits.
2. Les experts multicœurs jouent un rôle clé dans l'identification des ressources dans lesquelles des conflits de tâches peuvent survenir (ceux-ci sont appelés canaux d'interférence en avionique). La capacité des experts en matériel à parcourir les manuels de référence technique des processeurs de plusieurs milliers de pages et à formuler les questions appropriées sur les informations manquantes potentielles sur les manuels aux fournisseurs de puces est fondamentale pour conduire un processus MTA approprié.
3. Une fois les canaux d'interférence identifiés, les experts en matériel identifient les moniteurs d'événements qui peuvent être utilisés pour suivre l'activité que les tâches génèrent sur ces canaux d'interférence en tant que métrique proxy pour limiter le conflit que les tâches peuvent subir. L'exactitude de ces moniteurs d'événements doit également être vérifiée [2] pour laquelle un ensemble spécialisé de micro-benchmarks a été conçu.
4. Enfin, les experts en matériel travaillent main dans la main avec des experts en analyse temporelle pour dériver, à partir des exigences des utilisateurs, des exigences de haut et de bas niveau et des tests spécifiques pour valider les hypothèses soutenant les exigences des utilisateurs. Chaque test instancie un ou plusieurs programmes de micro-benchmark conçus par des experts en matériel informatique pour appliquer le niveau de charge souhaité sur le ou les canaux d'interférence cibles.

Pendant les dernières étapes de la conception :

1. Les experts en matériel contribuent à l'analyse des résultats des tests pour évaluer s'ils confirment ou rejettent les hypothèses.
2. Les experts en matériel contribuent également à établir de nouvelles hypothèses et les tests correspondants au cas où ils seraient nécessaires sur la base des résultats obtenus à l'étape précédente.

cliquez pour agrandir l'image

Figure 3 :Analyse des résultats (RapiTime). (Source :Auteurs)

La vue d'ensemble

Le processus de conception de test en 7 étapes n'est qu'une partie d'une méthodologie de vérification multicœur plus large illustrée plus haut dans la figure 2. Cette méthodologie, qui continuera à évoluer dans le cadre du projet MASTECS, est conçue pour assurer une traçabilité complète, à partir de preuves complètes et résultats aux exigences et conceptions correspondantes. La méthodologie est conçue pour répondre aux objectifs définis dans CAST-32A, le document d'orientation clé publié par les autorités de certification aérospatiale. Elle est également spécifiquement alignée sur la norme ISO 26262, la norme de sécurité pour le secteur automobile, qui préconise l'absence d'interférences.

CAST-32A a été publié par l'équipe logicielle des autorités de certification (CAST) en 2016 et identifie les facteurs qui ont un impact sur la sécurité, les performances et l'intégrité des systèmes logiciels embarqués exécutés sur des processeurs multicœurs. Si vous souhaitez utiliser du matériel multicœur dans un système avionique, c'est le document de référence. Elle fournit des objectifs destinés à guider la production de systèmes avioniques multicœurs sûrs, y compris des objectifs liés à l'identification et à la limitation de l'impact des canaux d'interférence. Consultez l'exposé de position de CAST-32A ici. L'EASA et la FAA travaillent sur une adaptation du CRI générique multicœur en un matériau AMC/AC commun (AMC 20-193). Il devrait être publié « plus tard cette année »[3].

L'expertise ne peut pas être automatisée

Les effets d'interférence sont complexes. Pour percer leurs mystères, vous avez besoin d'experts qui comprennent à la fois les composants de l'architecture multicœur et les systèmes de planification et d'allocation des ressources du logiciel. La collaboration entre les experts en matériel et en logiciel sera un élément central du projet MASTECS à mesure qu'il se poursuivra dans le futur. Mais alors que la collaboration conduit à de grands progrès dans les outils logiciels et l'automatisation, il est important de se rappeler que vous ne pouvez pas automatiser chaque étape d'un processus de validation, surtout pas lorsqu'une analyse temporelle multicœur est impliquée.

Vous avez besoin d'ingénieurs expérimentés qui connaissent les systèmes en détail. Par exemple, au cours des premières étapes, les experts multicœurs peuvent identifier les configurations de processeur (également appelées paramètres de configuration critiques pour le matériel) qui déterminent le comportement fonctionnel et de synchronisation du logiciel, ainsi que les canaux d'interférence potentiels. Lorsqu'il s'agit d'analyser les résultats des tests, rien ne vaut la contribution d'un expert humain expérimenté pour revoir et évaluer les hypothèses originales formulées à propos de la plate-forme, et utiliser ses connaissances pour alimenter un nouveau cycle de test.

Références

[1] Reinhard Wilhelm. Sentiments mitigés sur la criticité mixte. Atelier sur l'analyse du temps d'exécution dans le pire des cas, 2018.

[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. Unités de surveillance des performances à haute intégrité dans les puces automobiles pour une synchronisation fiable 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/