[APPLICATION LDRA] L'architecture RISC-V a été conçue pour intégrer la sûreté, la sécurité et la fiabilité afin que les développeurs puissent identifier les problèmes et atténuer les risques plus tôt dans un cycle de conception. Plusieurs propriétés du RISC-V permettent notamment un accès contrôlé à la mémoire et améliorent le déterminisme en atténuant les contraintes temporelles typiques des processeurs multicœurs traditionnels. Les processeurs multicœurs fondés sur le RISC-V peuvent tirer parti de ces nouvelles caractéristiques architecturales pour accélérer le développement, les tests et la certification de systèmes critiques tels que ceux utilisés dans l'automobile, l'aérospatiale, le contrôle industriel, etc.

Auteur : Jay Thomas
Director Field Development
LDRA

Grâce à des processeurs plus performants, les systèmes embarqués avancés sont de plus en plus définis par logiciel, ce qui leur confère une plus grande flexibilité, des fonctionnalités accrues et une meilleure personnalisation, tout en accélérant le rythme de l'innovation. Cependant, à mesure que les logiciels de ces systèmes deviennent plus complexes, les risques d'apparition de vulnérabilités susceptibles d'affecter la sûreté, la sécurité et la fiabilité augmentent.

Ces préoccupations sont encore plus pertinentes pour les systèmes fondés sur des processeurs multicœurs. La conception est d'autant plus compliquée par le rythme croissant du développement exigé par le marché. Les systèmes doivent être mis à jour plus fréquemment, non seulement pour rester compétitifs grâce à de nouvelles fonctionnalités et capacités, mais aussi pour relever le défi croissant que représente le maintien de la sécurité dans des systèmes connectés complexes.

Pour pouvoir fournir plus rapidement ces fonctionnalités, tout en garantissant la sûreté et la sécurité, il est essentiel d'adopter des approches de développement telles que DevSecOps, qui utilisent des méthodologies CI/CD, c’est à dire une approche d’'intégration et de déploiement continus. 

Le DevSecOps est une approche de développement qui utilise des méthodologies comme l'intégration continue et le déploiement continus (CI/CD, Continuous Integration/ Continuous Deployment) afin que les développeurs puissent proposer plus rapidement des innovations et de nouvelles fonctionnalités, tout en garantissant la sécurité et la sûreté.

Enfin, les systèmes critiques doivent se conformer à un large éventail de normes afin de garantir qu'ils respectent les réglementations strictes du gouvernement et de l'industrie en matière de sécurité fonctionnelle, de sûreté et de fiabilité. Ces normes établissent différents niveaux de conformité, en fonction de l'importance critique du logiciel dans le système.

Par exemple, les normes CAST-32A, AMC 20-193 et ​​AC 20-193 soulignent des considérations importantes à prendre en compte lors de la conception avec des processeurs multicœurs, notamment des objectifs non prescriptifs de cycle de vie du développement logiciel (SDLC, Software Development Life Cycle) qui peuvent guider et aider les développeurs à respecter des normes industrielles telles que la norme DO-178C utilisés dans l’avionique.

Analyser les temps d'exécution dans le pire des cas

Une caractéristique importante, et difficile à évaluer, des systèmes multicœurs est le temps d'exécution dans le pire des cas (WCET, Worst-Case Execution Time). Les tâches exécutées sur différents cœurs du même processeur partagent des ressources, ce qui peut entraîner des conflits au niveau de l'application pour l'accès à ces ressources. La contention ajoute un délai d'exécution qui est totalement invisible au niveau de l'application. Ces retards s'ajoutent et augmentent la variabilité du temps d'exécution. Comme des retards peuvent ou non survenir au cours d'une instance d'exécution donnée, cela peut entraîner une grande variabilité du temps d'exécution attendu du code.

On voit ici la plage des temps d'exécution possibles pour une tâche, y compris le temps d'exécution au pire cas (WCET). La contention des ressources partagées sur un processeur multicœur augmente la variabilité du temps d'exécution d'une tâche. Les développeurs doivent donc analyser le temps d'exécution dans le pire des cas (WCET) d'une tâche sur plusieurs exécutions afin de s'assurer que les contraintes de temps réel du système seront respectées.

Compte tenu de la variabilité des conflits entre cœurs d'une exécution à l'autre, il est extrêmement difficile de calculer le WCET maximal possible (réel). En effet, la contention dépend des tâches exécutées par les autres cœurs lors de l'exécution. Cel au signifie qu'il n'est souvent pas possible de vérifier l'impact de chaque conflit pouvant survenir entre cœurs.

En fait, les circonstances qui déclenchent le WCET réel peuvent être si rares qu'elles ne sont jamais observées en laboratoire. Cela ne signifie pas pour autant que cela ne se produira jamais sur le terrain. Il s'agit plutôt d'un échec potentiel, donc susceptible de se produire, qui pourrait entraîner des blessures ou la mort. C'est ce que les normes de sécurité fonctionnelle visent à prévenir. L'objectif de l'analyse WCET est d'utiliser les temps d'exécution observés pour estimer le WCET.

Pour garantir le respect de toutes les exigences de synchronisation en temps réel, les développeurs ajoutent un tampon afin de fournir une limite supérieure de synchronisation garantissant que le WCET réel se situe dans une fourchette acceptable. L'un des avantages de l'architecture RISC-V est la possibilité de “mapper” le cache directement sur la mémoire RAM. Cela permet un accès à la mémoire à cycle fixe, et tout programme ou toute donnée stockés dans cette mémoire auront un modèle d'accès plus déterministe. Cette fonctionnalité est disponible sur les architectures RISC-V comme les circuits PolarFire et PIC 64 de Microchip.

Les principales sources de contention multicœur étant le cache et la mémoire partagés, la gestion de la variabilité du temps d'accès d'un cœur particulier au niveau du cache de la mémoire principale peut améliorer considérablement le déterminisme et réduire le WCET.

Plusieurs approches pour calculer temps d'exécution dans le pire des cas

Plusieurs approches se sont révélées efficaces pour analyser le WCET et respecter les directives CAST-32A et A(M)C 20-193 dans les systèmes fondés sur des processeurs multicœurs. Les trois méthodes couramment utilisées sont les suivantes:

Analyse statique du code : L'approche traditionnelle pour étudier la variabilité du processeur consiste à analyser le code de manière statique et au niveau des instructions. Des métriques telles que les métriques de Halstead permettent aux développeurs de limiter la complexité et de mesurer le nombre d'instructions qu'une routine donnée peut compiler. Cependant, avec l'avènement de processeurs dotés de grandes pipelines et de vitesses d'exécution d'instructions variables, ces métriques ne suffisent plus, à elles seules, à prédire le temps d'exécution d'une routine et ne peuvent en prédire la variabilité.

Analyse empirique des temps d'exécution : Cette approche mesure, analyse et suit les temps d'exécution individuels grâce à une analyse dynamique. Pour garantir l'exactitude, l'analyse doit être effectuée dans l'environnement réel d'exécution de l'application ou dans un environnement équivalent (tel un jumeau numérique). Cela élimine l'impact de facteurs tels que les options de compilateur/éditeur de liens et les différences d’implantations des fonctionnalités matérielles. L'analyse doit également inclure suffisamment de tests répétés pour tenir compte des variations environnementales et applicatives entre les exécutions. Les outils automatisés simplifient l'analyse dynamique en rationalisant le processus de test, en réduisant le risque d'erreur humaine et en garantissant des résultats précis et cohérents.

Analyse du couplage du contrôle et des données : l’analyse du couplage des données identifie les dépendances entre les données, tandis que l’analyse du couplage du contrôle identifie les dépendances entre les tâches au sein d’une application. De nombreuses normes exigent que tous les couples soient testés afin de détecter les problèmes potentiels liés à l’interaction entre les dépendances de contrôle et données.

Le couplage des données et du contrôle peut être explicite ou implicite: lorsque plusieurs processeurs utilisent les mêmes bus de données, vers le cache et la mémoire, cela ajoute un couplage implicite des données et du contrôle. En examinant la table de répartition et en comprenant quelles parties de l'application s'exécutent ensemble et séparément, l'analyse du couplage des données et du contrôle permet d'isoler les éléments susceptibles d'interférer les uns avec les autres.

Les rapports d'analyse du couplage de données et du contrôle de la suite d'outils LDRA révèlent des problèmes potentiels liés à l'interaction entre les dépendances de contrôle et données.

Aller vers une certification du RISC-V

L’architecture RISC-V présente plusieurs caractéristiques qui simplifient et améliorent les tests et la certification des systèmes embarqués critiques.

Personnalisation pour répondre aux exigences de sécurité critique : la philosophie de conception modulaire de RISC-V permet aux fournisseurs de puces et aux architectes système d’implanter des fonctionnalités personnalisées au niveau matériel.

Cette caractéristique aide à satisfaire les exigences de sécurité spécifiques dans le cadre de normes de certification des applications spécifiques à la mission, en prenant en charge la détection et la correction d'erreurs personnalisées, les capacités de surveillance et de diagnostic au niveau matériel, ainsi que les fonctionnalités d'exécution déterministe à faible latence afin de réduire le WCET en vue de répondre aux exigences en temps réel.

La possibilité d’implanter des instructions et des fonctionnalités matérielles personnalisées permet également d'optimiser les exigences de sécurité spécifiques sans compromettre les performances globales du système.

Gestion de la mémoire : la capacité de la technologie RISC-V à implanter un “mappage” de mémoire cache de niveau 2 en tant que mémoire RAM procure aux développeurs un meilleur contrôle de la latence du système par rapport aux architectures traditionnelles. Une meilleure atténuation des conflits de cache permet alors un timing d'exécution plus prévisible et simplifie la gestion du WCET en délivrant un comportement multicœur plus déterministe. Le “mappage” du cache vers la mémoire RAM est le début d'une solution complète aux problèmes liés aux processeurs multicœurs dans les systèmes embarqués critiques tels que l'avionique.

Considérations relatives aux performances : le RISC-V procure plusieurs avantages spécifiques aux applications critiques pour la sécurité, notamment les chemins d'exécution déterministes pour les applications en temps réel, les instructions personnalisées pour la surveillance de la sécurité, le changement de contexte efficace pour les systèmes à criticité mixte et les unités de protection mémoire configurables pour minimiser la corruption de la pile et des données.

Indépendance architecturale : le modèle ouvert de RISC-V présente plusieurs avantages pour atténuer les risques liés à la chaîne d'approvisionnement. La possibilité de travailler avec plusieurs fournisseurs de silicium réduit les risques de défaillance unique dans la chaîne d'approvisionnement, ce qui est particulièrement important pour les applications à long cycle de vie qui peuvent nécessiter une maintenance et un support pendant des décennies.

Redondance dissemblable : les systèmes critiques pour la sécurité nécessitant une certification DAL-A (Design Assurance Level A) selon la norme DO-178C mettent souvent en œuvre une redondance pour se protéger contre les défaillances en mode commun. L'architecture ouverte de RISC-V offre des avantages pour la mise en œuvre de stratégies de redondance dissemblables, notamment : l'implémentation de différentes configurations de processeur au sein d'un même système, divers schémas de redondance utilisant des solutions de différents fournisseurs, et l'utilisation d'architectures différentes dans des systèmes à criticité mixte avec des niveaux d'exigences de sécurité variables.

Dynamisme industriel : un nombre croissant de cœurs IP RISC-V certifiés en matière de sécurité proposent aux concepteurs des composants pré-vérifiés qui répondent à des exigences de sécurité strictes. Microchip, SiFive, CAST et d'autres fournisseurs ont lancé des implémentations RISC-V spécialisées dotées de fonctionnalités de sécurité intégrées, de mécanismes de détection des pannes et de capacités de redondance.

Des fournisseurs tels que Frontgrade Gaisler proposent également des microprocesseurs et des cœurs IP renforcés contre les radiations pour les systèmes spatiaux.

Écosystème d'outils de développement mature : Au fil des ans, la maturation des outils de développement et des environnements de vérification pour RISC-V s'est étendue pour couvrir l'ensemble du cycle de vie des logiciels. Par exemple, le package de licences cibles (target license package, TLP) de LDRA pour les architectures RISC-V prend en charge le développement et les tests sur cible avec analyse de la couverture de code multicœur, mesure du temps d'exécution au pire cas (WCET) pour la conformité à la norme AMC 20-193, traçabilité des exigences et intégration avec les principales plateformes de développement RISC-V.

Ce TLP prépare RISC-V à la sécurité et la sûreté. De plus, LDRA est hautement intégré aux environnements RISC-V, prenant en charge les tests dynamiques avec du matériel et des environnements de simulation commerciaux et open source, y compris la simulation au niveau du silicium. Ces environnements prennent en charge des tests et vérifications complets et précis du matériel afin de développer et de tester les logiciels au fur et à mesure du développement du matériel.

L’approche de la vérification continue

Plutôt que d'attendre que le logiciel soit entièrement conçu pour effectuer tous les tests, des tests en amont permettent d'identifier les problèmes plus tôt, lorsqu'ils sont généralement plus faciles et moins coûteux à résoudre. Par exemple, les développeurs peuvent détecter les erreurs de synchronisation et contrôler le couplage des caches de données et de contrôle au fur et à mesure du développement de l'application, plutôt que d'attendre la fin du développement et que l'équipe de test constate que l'application ne fonctionne pas de manière fiable.

La clé de la création de logiciels sûrs, sécurisés et fiables réside dans un processus de développement robuste intégrant la vérification à chaque étape de la conception, un processus connu sous le nom de vérification continue. Par exemple, les métriques de complexité Halstead peuvent être utilisées tout au long du cycle de conception d'un logiciel. Les mêmes outils qui aident les développeurs à restructurer le code initial afin de réduire le risque de problèmes de timing liés au multicœur peuvent être utilisés pour identifier un code saturé devenu trop complexe au fil du temps.

La vérification continue fonctionne en conjonction avec l'intégration et le déploiement continus pour accélérer le processus de vérification, parallèlement aux processus de développement et de réalisation. En intégrant la vérification continue à la chaîne d'outils de conception et à l'environnement de développement, la vérification devient une partie transparente du flux de conception. Et lorsque la vérification est automatisée (y compris l'exécution des tests et des métriques, la consolidation des résultats au sein de l'équipe de développement et la création des rapports nécessaires), la conformité est considérablement simplifiée, tout en offrant une précision et une cohérence accrues.

La complexité logicielle des systèmes embarqués multicœurs RISC-V ne cesse de croître avec l'ajout de nouvelles fonctionnalités et l'évolution des normes de certification. En intégrant les tests et la vérification à chaque étape de la conception, les développeurs bénéficient de la vérification continue, ce qui accélère le développement logiciel, réduit les délais de livraison et simplifie la conformité, tout en garantissant la sécurité et la fiabilité.