On n’a pas tous les jours vingt ans…
Depuis maintenant une bonne dizaine d’années, les industriels doivent mener à bien des programmes de rénovation de systèmes développés en moyenne depuis plus de vingt ans. Ces rénovations impliquent généralement une remise à niveau aussi bien matérielle que logicielle.
Dans ce cadre, Systerel accompagne ses clients et ce dans des secteurs aussi variés que le transport, la défense ou l’avionique.
Ces développements nous ont ainsi amenés à avoir une réflexion rétrospective sur les changements opérés depuis plus de vingt ans sur la façon de développer du logiciel critique.
Introduction¶
Durant ces vingt dernières années, les technologies et les pratiques liées au développement logiciel ont profondément changé. On peut entre autres noter :
La diminution des mises en œuvre croisées au bénéfice des natives (quand cela a un sens),
La maturité et la diversité des outils disponibles,
Les performances offertes par les architectures matérielles,
L’apparition de nouvelles contraintes normatives.
La mise en œuvre¶
Il y a vingt ans, la mise en œuvre d’une application croisée 1 n’était principalement faite que sur sa cible.
De nos jours, les mises en œuvre natives 2 sont devenues aisées tout en restant représentatives.
Cela n’est cependant possible que si un grand soin est porté à la manière dont sont faites les abstractions matérielles. C’est un point crucial sur lequel Systerel porte toute son attention afin d’avoir au final des mises en œuvre natives aisées et pertinentes. Dans le cadre du code legacy, cette mise en œuvre peut impliquer un refactoring qui sera au final toujours bénéfique.
Il est important de noter qu’une mise en œuvre native améliore systématiquement la portabilité de l’application tout en bénéficiant des avantages du monde natif : mise au point des tests plus simples et mise à disposition d’un riche écosystème d’outils.
Dans le cadre d’applications critiques, une démonstration devra être faite concernant le déport de tests en natif. Par exemple, il est tout à fait possible d’envisager de ne faire des tests de couverture (statement, branch et MC/DC) qu’en natif. La cible étant alors dévolue :
À la caractérisation temps réel,
À la caractérisation de l’EOC (Executable Object Code) : ici on vérifie que le compilateur a « fait le job »,
Aux tests d’intégration et de validation.
Pour terminer, il faut souligner que les capacités offertes par les techniques de virtualisation et de conteneurisation renforcent encore l’intérêt de travailler nativement. Dans ce cadre, il est, cette fois-ci, tout à fait envisageable de mettre en œuvre un système complet qui sera donc beaucoup plus représentatif en regard du composant testé. Systerel est ainsi amenée à travailler sur la virtualisation complète de systèmes tels que des lignes de métro.
Les outils¶
Il y a vingt ans, l’offre sur les outils disponibles n’était pas pléthorique et ces outils avaient bien souvent un coût de mise en œuvre important. Aujourd’hui, l’offre est importante et elle permet de répondre à des besoins adaptés et ce dans des délais et des coûts généralement raisonnables.
Les améliorations concernent par exemple :
La performance des moyens de débogage,
La pertinence et l’acuité des messages émis par les chaines de compilation,
La puissance des outils d’analyse statique et les progrès faits sur les technologies afférentes. Par exemple les méthodes formelles pour ce qui concerne la technologie SPARK,
Des IDE évolutives et conviviales,
…
Cette boite à outils peut être aussi enrichie par ses propres outils (outillages). Pour ce qui concerne Systerel, nous utilisons majoritairement : Python, Libadalang, BASH etc…
Pour filer la métaphore, on peut dire qu’il y a vingt ans vous n’aviez qu’un seul tournevis pour plusieurs types de vis alors qu’aujourd’hui vous pouvez disposer de tous les tournevis possibles ou vous pouvez aussi fabriquer votre propre tournevis !
Une autre évolution notable concerne la systématisation de l’utilisation d’environnements de développement. Là aussi, il est plus simple de nos jours de mettre en place un environnement de développement bien adapté au projet : c’est la boite à outils pour nos tournevis !
Dans ce domaine, Systerel apporte le plus grand soin à la mise en place de ces environnements sachant qu’un environnement soigné permet toujours de garantir une bonne pérennité du projet.
Pour terminer sur les outillages, les systèmes de log des applications sont, comme pour les environnements, des points qui doivent faire l’objet de beaucoup d’attention. Soigner le système de log d’une application permet toujours de gagner à terme beaucoup de temps aussi bien dans les phases de développement que lors de l’exploitation opérationnelle.
Dans le cadre de ses développements Ada, Systerel a développé toute une suite de composants basés en grande partie sur GNATCOLL (GNAT Component Collection) ainsi qu’une console virtuelle (NCA : NetCatAda) permettant de déporter facilement des traces et des logs vers une station dédiée Linux ou Windows.
Copie d’écran de NCA
Le matériel¶
C’est probablement dans ce domaine que les progrès ont été les plus significatifs. Au travers des refontes et des migrations menées par Systerel, nous avons pu voir rétrospectivement combien les choses avaient bien changé :
Généralisation des architectures SMP et SIMD,
Passage du MHz au GHz sur les ordres de grandeur des fréquences processeurs et des bus,
Inflation de la taille et du niveau des caches ainsi que des ressources mémoires en général,
Introduction de la logique programmable, des SSD, des GPU, de nouveaux types d’interfaces, etc…
…
Même si ces évolutions sont de fait très intéressantes et ouvrent de nouveaux champs en termes d’architectures, il faut cependant rester bien vigilant sur la façon de développer sur de telles architectures et ne pas croire que la « sensation » d’avoir des ressources illimitées par rapport à ce que l’on avait il y a vingt ans est un blanc-seing pour faire des applications peu optimisées utilisant des ressources indues même si celles-ci sont disponibles.
Il faut toujours garder à l’esprit que faire des choses raisonnables et simples sera toujours payant sur le moyen et le long terme.
Les contraintes¶
Même si des contraintes et des exigences normatives existaient déjà il y a vingt ans, celles-ci sont maintenant plus systématiques, contraignantes et rigoureuses.
Ainsi donc, dans des programmes de refonte, les industriels peuvent être confrontés à de nouvelles exigences auxquelles ils ne sont pas obligatoirement habitués :
Contraintes de sécurité et cybers,
Contraintes de sureté (DAL, SIL),
Introduction de la logique programmable,
Mise à niveau ou refonte des cadres normatifs,
…
Dans ce cadre, Systerel accompagne ses clients afin de définir une démarche permettant à moindre coût de produire les artefacts requis sans pour autant sacrifier aux exigences normatives. Par exemple, si le contexte d’un projet ne permet pas de satisfaire à toutes les règles relatives aux normes devant être mises en œuvre (exemple MISRAC++) alors, Systerel proposera un subset minimum de règles à vérifier et le reste sera justifié au travers d’une ou plusieurs démonstrations.
Conclusion¶
Faire évoluer des applications basées sur de « vieilles technologies » vers des technologies issues d’une « veille technologique » et/ou de desideratas/impératifs de clients demande un savoir-faire.
De par son histoire, Systerel a su accompagner ses clients dans ces programmes de refontes et de mises à niveau technologiques en vue généralement d’adresser des gestions d’obsolescence.
La démarche et l’expérience de Systerel dans ce domaine lui permettent de satisfaire aux exigences actuelles aussi bien en matière d’évolution technologique que normative tout en veillant à impacter au minimum ce qui existait ; on n’a pas tous les jours vingt ans !
Comments