De l’EN 50716, dernière-née des normes logicielles pour les applications ferroviaires sécuritaires

Depuis plus de 20 ans, Systerel est reconnue pour son expertise en développement de logiciels critiques, notamment dans le secteur ferroviaire où la norme EN 50128 est le standard de référence. Elle sera définitivement annulée à l’horizon 2026, au profit de la norme EN 50716, qui assure la continuité avec son aînée tout en apportant son lot d’améliorations et de nouveautés.

Dans cet article, nous proposons de revisiter le contexte, puis d’apporter et partager quelques réflexions sur l’EN 50716.

Avant l’EN 50716, l’EN 50128¶

On ne change pas un référentiel normatif tous les jours. Les cycles d’élaboration des normes, de la conception à la publication, sont eux-mêmes relativement longs.

L’arrivée d’une nouvelle version d’une norme est ainsi un événement. C’est une occasion de prendre le temps de consulter l’état de l’art des techniques, les pratiques et les recommandations actuelles, afin d’améliorer les développements et de conduire à une qualité toujours croissante des produits.

Les logiciels développés sous contraintes sécuritaires ne font pas exception à la règle.

Pour les applications ferroviaires, et plus particulièrement les systèmes de signalisation, ils sont historiquement, et encore aujourd’hui, cadrés par la norme EN 50128. La première version de cette norme fut éditée en 2001, sa première refonte majeure en 2011, et son dernier amendement (A2, à l’impact bien mineur) en 2020. Soit une décennie entre deux évolutions.

En parallèle, toujours dans le cadre des applications ferroviaires, la norme EN 50657 parut en 2017, pour une applicabilité cette fois aux logiciels du matériel roulant. Calquée sur la norme EN 50128 (2011), elle apporte un certain nombre de corrections et d’évolutions. Celles-ci ne furent toutefois pas intégralement réintégrées dans l’amendement A2:2020 de l’EN 50128.¹

Il était donc temps de faire une révision majeure de l’EN 50128, au vu des retours d’expérience, des habitudes de développement, et des nouvelles technologies et outils apparus ces dernières années.

Vers une unicité du cadre normatif logiciel pour les applications ferroviaires¶

L’EN 50716 est ainsi arrivée sur nos rayonnages au dernier trimestre 2023, trois ans après son début de conception. Elle vient suppléer l’EN 50128 ET l’EN 50657, afin d’avoir un référentiel unique et harmonisé pour les développements logiciels sécuritaires de toutes² les applications ferroviaires.

Les trois normes coexisteront jusqu’à fin octobre 2026. Tout développement démarré d’ici là peut se conformer à l’une ou l’autre des normes, mais passé cette date, l’EN 50716 sera la seule référence acceptée.

Tout comme l’EN 50657 avait calqué sa structure sur l’EN 50128, l’EN 50716 reprend l’organisation de ses devancières : découpage en sections, numérotation des exigences³, tableaux de techniques avec niveaux de recommandation, fiches descriptives des rôles et responsabilités. La transition depuis un précédent référentiel peut ainsi s’accomplir de manière fluide.

Plusieurs améliorations, et une annexe entièrement nouvelle¶

Fondamentalement, le contenu normatif⁴ a peu changé. On peut estimer, en ordre de grandeur, que 30% à 40% des exigences ont été impactées par rapport à l’EN 50128, mais les modifications sont pour beaucoup de l’ordre de la formulation ou de l’apport de précision.

Dans les changements significatifs, on pourra noter particulièrement⁵ :

• Une passe de simplification sur l’Article 5 présentant les contraintes organisationnelles, qui laisse toutefois les contraintes largement inchangées,

• Une revisite de l’Article 8 portant sur les données d’application, introduisant notamment de nouveaux documents, mais excluant désormais les « algorithmes d’application »⁶,

• Une passe de réorganisation de l’Annexe A, afin de répartir les méthodes dans les tableaux de recommandations de manière plus cohérente avec le cycle de vie, et de revisiter les techniques relatives aux langages de programmation et aux normes de codage,

• La disparition du rôle de Chargé d’intégration, dont les responsabilités vis-à-vis des activités de tests d’intégration (logiciel/logiciel ou logiciel/matériel) sont reprises par le Chargé de tests.

Dans le cadre de ce billet, nous ne détaillerons pas davantage ces modifications, pour nous focaliser plutôt sur l’Annexe C, au contenu informatif.

Cette annexe a été complètement transformée dans l’EN 50716 : anciennement un aide-mémoire sur le contrôle de la documentation (identification pour chaque document des Rédacteur, 1er Vérificateur, 2nd Vérificateur), elle propose désormais des préconisations pour le développement logiciel, autour de 3 sujets :

• Les modèles de cycle de vie

• L’emploi de la modélisation dans le cycle de vie

• L’Intelligence Artificielle, particulièrement l’Apprentissage Automatique (Machine Learning)

Revenons ensemble sur les trois sujets abordés par cette annexe.

Les cycles de vie itératifs, une démarche volontaire plutôt que subie¶

Le modèle de cycle de vie proposé par la norme est linéaire⁷ : les phases se succèdent de la spécification jusqu’à la validation, les sorties d’une phase étant les entrées de la phase suivante. La norme n’exclut pas les boucles : les activités de vérification et de tests visent notamment à détecter au plus tôt les erreurs, provoquant un retour en arrière dans le cycle pour corriger l’erreur. Ces boucles n’auraient pas lieu dans un développement parfait, et ne sont pas planifiées lors de la mise en place du cycle de vie, des phases et des livrables.

L’ouverture proposée dans l’Annexe C de l’EN 50716 est de planifier des itérations, afin de construire de manière incrémentale les produits attendus⁸. Il faut comprendre ici que les phases cadrées par la norme sont inchangées, mais qu’on peut choisir de répéter, voire paralléliser, un ensemble de phases successives. Il sera alors nécessaire de définir l’attendu en sortie de chaque itération ; les activités de vérification et validation s’appliquent normalement à chaque phase de chaque itération. On peut noter que cette pratique est déjà répandue chez les industriels.

Opérationnellement parlant, ce cycle permet de réduire les délais d’attente ou de faire travailler les équipes en parallèle, et d’obtenir un retour précoce sur les sorties des premières phases. Le traitement incrémental du périmètre du logiciel pourrait toutefois introduire des changements majeurs tardifs, si des besoins fortement dimensionnants sont traités au cours des dernières itérations. Une bonne maîtrise de la découpe de l’attendu et des risques liés à la réalisation de chaque sous-partie est nécessaire afin de construire judicieusement un cycle itératif.

La modélisation, une pratique encouragée et encadrée par la norme¶

Modèles, modélisation, méthodes formelles¶

Un modèle est une représentation logique de concepts, qui apporte un formalisme supplémentaire en comparaison d’une description en langage naturel. Il s’accompagne d’une représentation textuelle ou graphique, à la sémantique partiellement (modélisation semi-formelle, comme UML/SysML) ou complètement définie (modélisation formelle, comme la logique temporelle ou la méthode B).

Plus la sémantique est complète, plus les modèles, par leur fondement mathématique, contribuent à obtenir un niveau de rigueur élevé, une désambiguïsation des exigences, une facilitation de la vérification et une détection au plus tôt des erreurs et incohérences. Les méthodes formelles sont les techniques permettant de manipuler, analyser ou vérifier ces modèles. À titre d’exemple, les techniques de preuve permettent ainsi d’analyser et de valider un programme ou un modèle en regard de propriétés de sécurité, sans l’exécuter.

Notons que la mise en œuvre d’une modélisation peut demander une expertise, des coûts et des délais supplémentaires par rapport à des descriptions non formelles. Mais cet investissement peut s’avérer rentable au vu des possibilités offertes par l’usage de modèles (découverte au plus tôt des défauts, génération automatique de code, de documents, accélération de la vérification, réduction des besoins en tests, …)

Vers une utilisation tout au long du cycle de vie¶

La modélisation était déjà pleinement considérée en phase de spécification, en complément d’une description en langage naturel des exigences. L’Annexe C de l’EN 50716 présente comment l’usage des modèles peut s’étendre à l’ensemble des activités prévues au cycle de vie. De manière générale, un modèle est assimilable à un document. Il peut donc remplir les attendus et se substituer à un élément de sortie d’une phase. En particulier, un modèle peut servir à générer automatiquement du Code Source (en s’appuyant sur un traducteur validé). Cependant, les techniques de l’Annexe A doivent alors être adaptées pour s’appliquer au modèle. Notamment :

• Les techniques applicables aux langages de programmation doivent être transposées aux langages des modèles utilisés,

• Les normes et guides de codage sont remplacées par des normes et guides de modélisation,

• Les bonnes propriétés du Code Source (équilibre taille/complexité, lisibilité, compréhensibilité, testabilité, …) sont transposées au modèle,

• La couverture de code par les tests doit être remplacée par des critères propres à la modélisation retenue afin de couvrir toutes les parties du modèle.

Pour évoquer d’autres cas d’usage, des modèles peuvent appuyer des activités de tests (génération de scénarios, tests dos-à-dos, simulation, …), ou des activités de vérification (preuve de propriétés). Le choix d’une ligne de modélisation, et la transposition des techniques de l’Annexe A doivent être réfléchies pour chaque activité faisant appel à des modèles.

Dans tous les cas, les modèles utilisés seront soumis aux mêmes exigences que les productions documentaires attendues par la norme, à savoir la vérification, la validation, ou encore les contraintes d’indépendance lorsque pertinent. Les outils liés aux modèles sont également soumis aux exigences de la norme (notamment les générateurs de codes T3).

L’intelligence artificielle, encore de nombreux défis à relever¶

Dans l’EN 50128, l’IA est considérée dans un cas d’utilisation restreint à la prédiction et la correction de défauts, dans une orientation de maintenance. Cette technique est toutefois classée à un niveau Non Recommandé⁹.

L’explosion de l’IA ces dernières années apporte avec elle de nouvelles applications, comme la reconnaissance de la signalisation latérale ou des obstacles en voie. Ces applications se basent sur des logiciels entraînés à partir de jeux de données d’entraînement. Ainsi, l’EN 50716 se généralise aux logiciels faisant l’objet d’Apprentissage Automatique (Machine Learning). La technique reste toutefois classée à un niveau Non Recommandé !

En effet, la norme impose un ensemble d’activités de traçabilité, de vérification et de tests afin de maîtriser en profondeur le code du logiciel et d’assurer que ses actions répondent au besoin exprimé sans compromettre la sécurité. Pour un logiciel entraîné, dont la structure interne peut être méconnue ou incompréhensible pour un raisonnement humain, des activités de traçabilité, d’analyse statique du code ou d’estimation de couverture par des tests peuvent devenir irréalisables.

Quatre défis principaux sont aujourd’hui identifiés dans l’EN 50716 comme limitants pour accepter pleinement les logiciels entraînés dans des applications à contraintes sécuritaires élevées. Il n’est pas dit qu’ils soient un jour résolus.

• Comment garantir que les données d’entraînement soient représentatives de tous les cas susceptibles d’être rencontrés par le logiciel en opération ?

• Comment vérifier/tester/analyser la structure du logiciel ?

• Comment valider que le logiciel ait appris la « bonne » fonction¹⁰ ?

• Comment réduire la sensibilité à une attaque « contradictoire » ? (Elle consiste à provoquer de grandes variations des sorties du modèle par de moindres variations dans les entrées)

Conclusion et perspectives¶

La transition de l’EN 50128 vers l’EN 50716 devrait s’annoncer fluide en regard de la forte continuité entre les deux normes. Les changements majeurs apportés, qu’ils portent sur l’organisation et les rôles, les tables de techniques, ou le développement des données d’application, sont dans une perspective d’amélioration continue et de simplification. La nouvelle annexe C incite à l’usage de cycles itératifs, de modélisation tout au long de la vie, et commence à considérer (sans le recommander pour l’heure) l’usage de logiciels construits par apprentissage.

La parution de cette norme est l’occasion pour Systerel de réaffirmer son expertise dans le développement de logiciels sécuritaires, et sa capacité à accompagner ses clients dans le cadre normatif de l’EN 50716. Notamment, Systerel possède une culture bien ancrée des techniques de modélisation et méthodes formelles (langage B, techniques de preuve), et s’ouvre également aux techniques apportées par l’IA (et aux questions relatives à la sûreté de fonctionnement qu’elle soulève).

Notons pour finir que la norme EN 50716 sera réexaminée cinq ans après sa parution, soit fin 2028. Nous suivrons avec attention l’évolution des techniques d’ici là.