Grâce à son expérience significative sur les logiciels / systèmes embarqués critiques et à sa maîtrise des exigences sectorielles, ERASM est en mesure de réaliser des activités de développement logiciel suivant les référentiels EN50128, IEC61508 et DO178C, avec une prise en charge de la phase descendante du cycle en V (en partie ou dans son intégralité).
ERASM a vocation à vous accompagner dans toutes ces phases de conception et développement pour :
- Vous guider afin d’appliquer les bonnes pratiques en logiciel critique à chaque étape du cycle de vie de développement.
- Vous assurer d’être en conformité aux normes logiciel critique en vigueur.
- Vous assister lors de vos échanges avec l’autorité compétente en charge de l’évaluation de la sécurité logicielle critique.
- Sécuriser le projet et son avancement jusqu’à l’obtention de la certification de logiciel critique.
1. Phase préliminaire avant de développer un logiciel critique
Avant le démarrage de la phase de développement de logiciels critiques, il convient de procéder aux opérations suivantes :
- Rédaction du cahier des charges
- Conception préliminaire (choix de l’architecture logicielle / microcontrôleur). Une architecture efficace peut simplifier grandement le logiciel embarqué (et donc baisser significativement son coût).
2. Planification du projet
Le développement de logiciel sûr, fiable et conforme impose de respecter une planification stricte :
- Rédaction des plans (description des process de développement)
- Rédaction/Sélection de règles de spécification des exigences
- Rédaction/Sélection de règles de design
- Rédaction/Sélection de règles de codage (usuellement basé sur le standard MISRA).
3. Spécification des exigences du logiciel
Étape clé pour assurer la fiabilité du logiciel critique développé, cette activité consiste, entre autres, à :
- Identifier les interfaces externes et proposer un découpage fonctionnel.
- Définir des modes de fonctionnement du logiciel (initialisation, nominal, état sûr…) et leurs différentes transitions associées.
- Décrire le fonctionnement attendu du logiciel sous forme d’exigences logicielles (fonctionnelles, sécuritaires, performance…). La rédaction de ces exigences est basée sur les documentations amonts (documents système / cahier des charges, contraintes exportées), les règles de rédaction du projet et les attentes du contexte normatif.
4. Spécification de l’architecture du logiciel
Il s’agit d’établir l’architecture du logiciel :
- Organiser le logiciel en un ensemble de composants (pour les logiciels « simples ») ou en couches logicielles + composants (pour les logiciels plus complexes) avec l’utilisation d’un système d’exploitation (OS) ou non (bare metal).
- Pour chaque composant logiciel :
- Allouer les exigences logicielles que le composant doit implémenter.
- Définir des interfaces logicielles du composant.
- Identifier les possibles interactions matérielles (généralement pour les composants bas niveau, de type driver).
- Décrire les interactions entre les composants dans le temps (diagrammes de séquences).
Par ailleurs, une stratégie est mise en place vis-à-vis de certains aspects sensibles du point de vue de la sécurité (safety) :
Mécanismes de sécurité & d’autocontrôle du logiciel. Selon les enjeux sécuritaires, des procédures d’autotest doivent faire l’objet d’une implémentation dans le logiciel : contrôle de l’intégrité du programme, autotest des mémoires, watchdog, diversification des opérateurs, mise en œuvre des protections natives de cibles spécifiques (ECC, lockstep, CPU selftest, MPU/MMU…).
- Gestion des interruptions. Idéalement, l’architecture du logiciel se doit de réduire au maximum le nombre d’interruptions utilisées. Afin de garantir le caractère temps réel du logiciel, une attention particulière est apportée quant à l’attribution de la priorité des interruptions et la maîtrise de leurs fréquences de déclenchement.
- Politique de partage des données. Que le système soit simple (MCU basique & nombre limité d’interruptions) ou plus complexe (cœurs multiples, mémoire cache, DMA…), une stratégie doit être élaborée pour garantir l’intégrité et la disponibilité des données partagées entre les tâches concurrentes.
- Prise en compte des erratas. Il convient ici de prendre en compte les erreurs connues de la cible et/ou du compilateur qui pourraient avoir un impact notable plus tard dans le cycle de développement (erreurs d’arrondis sur une FPU, séquence d’accès menant à un deadlock…).
5. Dernière phase de développement logiciel critique : conception détaillée du logiciel & codage
Sur la base des exigences du logiciel et de l’architecture, la conception détaillée peut alors être rédigée :
- Pour chaque composant, l’ensemble des éléments (fonctions publiques, privées, variables, type de données…) est décrit au travers d’exigences.
- Des représentations graphiques (machine d’état, data flow, control flow…) peuvent être fournies suivant la complexité algorithmique / fonctionnelle du logiciel.
La conception détaillée est ensuite transposée en code source, principalement en langage C.
Résultat : une démarche de développement pour une bonne gestion des risques de logiciels critiques et garantir la sécurité des logiciels embarqués.
ERASM dispose d’une solide expérience sur une multitude de plateformes « grand public » (PIC18, PIC24 & PIC32 de Microchip, STM32 de STMicro, TMS320 de Texas, etc…) et « safety » (microcontrôleurs sécuritaires, type RM48 / TMS570 de Texas), conjointement à leurs IDE associés (IAR, MPLABX, STMCube, CCS…).