Ingénierie système, logiciel embarqué et MBSE : audit, conseil, formation et assistance technique pour le naval et le ferroviaire

Cadre normatif de l'ingénierie système et du logiciel embarqué

Des processus de cycle de vie, pas une réglementation en propre

L'ingénierie système n'est pas une activité réglementée en tant que telle. Elle s'appuie sur des normes de processus que les donneurs d'ordre et les textes sectoriels reprennent par renvoi ou par contrat. La norme ISO/IEC/IEEE 15288 définit un cadre commun pour les processus du cycle de vie des systèmes, sans imposer de modèle de cycle de vie ni de technique de modélisation. La norme ISO/IEC/IEEE 29148 détaille l'ingénierie des exigences : ce qu'est une bonne exigence, ses attributs et la façon d'appliquer les processus d'exigences de la 15288 et de la 12207, qui traite du logiciel. L'association INCOSE publie un manuel d'ingénierie système et des guides de rédaction des exigences, utiles comme référence de pratique.

Ces normes décrivent des processus, pas des preuves de sûreté. Elles servent à organiser le travail et à le rendre traçable : de quoi parle-t-on, pour qui, avec quelles exigences, quelle architecture, quelles vérifications. Le texte contractuel de chaque projet précise ce qui est applicable.

Ferroviaire : EN 50126, EN 50716 et interopérabilité

Pour le ferroviaire, les normes de la famille EN 50126 (processus RAMS, parties 1 et 2), EN 50129 (systèmes électroniques relatifs à la sécurité pour la signalisation) et EN 50716 (développement de logiciels) encadrent la démarche. La norme EN 50716 remplace EN 50128 et EN 50657, et couvre à la fois les logiciels de contrôle-commande et ceux du matériel roulant. Nous n'en détaillons pas les exigences ici : le domaine consacré à la sûreté de fonctionnement les traite, avec les règles de codage et les niveaux d'intégrité.

Côté réglementaire, le contrôle-commande est encadré par la STI (spécifications techniques d'interopérabilité) correspondante, le règlement d'exécution (UE) 2023/1695, modifié par le règlement d'exécution (UE) 2026/693 pour les essais ETCS (European Train Control System, système européen de contrôle des trains) et l'ATO (Automatic Train Operation, conduite automatique des trains). Pour les communications d'un train, la série de normes IEC 61375 décrit le réseau de communication de train (TCN) : architecture générale, bus de train et bus de rame. La communication relative à la sécurité dans les systèmes de transmission relève de la norme EN 50159. En France, l'EPSF est l'autorité de sécurité pour les autorisations qui s'appuient sur ces démonstrations.

Naval : systèmes de bord et exigences de classification

À bord des navires, les systèmes d'automatisme, de navigation, de communication et de gestion d'énergie relèvent des conventions de l'Organisation maritime internationale et des règles de la société de classification choisie par l'armateur ou le chantier. La série IEC 60092 traite des installations électriques des navires et la série IEC 61162 des interfaces numériques pour les équipements de navigation et de radiocommunication maritimes. Pour la cyber-résilience, l'IACS a adopté les exigences unifiées E26 pour le navire et E27 pour les systèmes et équipements de bord, applicables aux navires neufs contractés à partir du 1er juillet 2024.

La société de classification approuve les plans et vérifie les systèmes selon ses règles : elle décide, nous ne la remplaçons pas. Quand les systèmes touchent à des programmes de défense, les exigences d'habilitation et de contrôle des exportations sont fixées par le donneur d'ordre et s'imposent à la mission.

Ce que l'on attend d'une démarche d'ingénierie

Des exigences vérifiables, tracées de bout en bout

Une exigence utile est nécessaire, non ambiguë, vérifiable et rattachée à sa source. Le travail commence par les parties prenantes : exploitant, mainteneur, autorité, donneur d'ordre, équipage ou conducteur, intégrateur. Il se poursuit par la dérivation en exigences de système puis de sous-système, avec leur allocation, et se termine par la preuve : essai, analyse, inspection ou démonstration. La traçabilité relie le besoin, l'exigence, l'élément d'architecture, le code et le test, et permet de mesurer l'impact d'une modification.

Les outils de gestion des exigences et de gestion du cycle de développement portent cette traçabilité. Ils n'y suffisent pas : un schéma d'attributs mal pensé ou des liens entretenus à la main produisent une matrice fausse, plus dangereuse qu'une matrice absente.

La vérification et la validation se préparent dès les exigences. Chaque exigence reçoit sa méthode de preuve, puis un plan d'essais d'intégration progressif : composant, sous-système, système, avec des bancs de test et des simulations de l'environnement lorsque le matériel réel n'est pas disponible. Les écarts constatés en essais remontent à l'exigence ou à l'architecture qui les explique, ce qui évite de corriger seulement le symptôme dans le code.

Architecture et modèles : des méthodes, pas des outils

L'ingénierie système basée sur les modèles remplace des documents dispersés par un modèle partagé. Le langage SysML, maintenu par l'Object Management Group, décrit exigences, structure et comportement. La méthode Arcadia, conçue à l'origine par Thales, est outillée par Capella, projet open source de la fondation Eclipse : elle sépare l'analyse du besoin opérationnel, l'analyse fonctionnelle du système, l'architecture logique puis l'architecture physique.

Un modèle se justifie quand il évite des incohérences entre équipes, supporte des analyses d'impact ou alimente des vérifications automatiques. Il ne se justifie pas pour sa seule existence. Nous le disons quand un modèle n'apporte rien, et nous ne promettons aucun outil : le langage, la méthode et le niveau de détail se choisissent selon le projet.

Logiciel embarqué, temps réel et communications

Le logiciel embarqué se développe en C ou en C++ sur microcontrôleur, avec ou sans système d'exploitation temps réel, ou sur système sur puce. Les sujets propres sont les contraintes temporelles (ordonnancement, priorités, analyse du pire temps d'exécution), la gestion de la mémoire et des interruptions, la mise à jour du micrologiciel et l'observabilité en exploitation. Les règles de codage de sûreté, comme MISRA (Motor Industry Software Reliability Association, règles de codage logiciel sûr), relèvent du domaine sûreté de fonctionnement.

Les échanges entre équipements reposent sur des bus de terrain et des protocoles industriels : les séries IEC 61158 et IEC 61784 pour les bus de terrain, OPC UA (IEC 62541) pour l'échange de données entre machines et systèmes, les interfaces maritimes IEC 61162 et les bus de train IEC 61375. La logique programmable et les systèmes sur puce se décrivent en VHDL (IEEE 1076) puis se simulent et se vérifient avant fabrication. Dans tous ces cas, l'interface se spécifie, se teste et se versionne comme le reste du système.

Le cycle de vie est un enjeu à part entière. Un système ferroviaire ou naval reste en service pendant des décennies, alors que les composants électroniques et les outils de développement disparaissent bien plus vite. La gestion de l'obsolescence, la reprise d'un logiciel par une nouvelle équipe, la mise à jour sécurisée du micrologiciel et la gestion de configuration des versions déployées sur une flotte pèsent sur les coûts de cycle de vie autant que la conception initiale.

Rôles et responsabilités

Le concepteur, l'évaluateur indépendant et l'autorité

Le concepteur d'un système, constructeur, équipementier ou intégrateur, demande l'autorisation et en porte la démonstration. Les rapports d'évaluation indépendants exigés pour une autorisation sont établis par des organismes accrédités ou reconnus, jamais par ceux qui ont conçu ou conseillé sur la conception. Le décret n° 2019-525 du 27 mai 2019 précise que l'organisme d'évaluation de la conformité ne s'implique pas dans la conception, la fabrication ou la construction de ce qu'il évalue (article 56). Dans les normes CENELEC, le rôle d'évaluateur de sécurité indépendant relève de la même logique.

Les rôles se répartissent aussi en chaîne. Le constructeur ou le chantier spécifie le système, l'équipementier développe un sous-ensemble, l'exploitant ou l'armateur l'exploite et le fait évoluer. Chacun reçoit des exigences et en transmet. Un écart d'interprétation à une interface, par exemple sur un dictionnaire de données ou un temps de réponse, se découvre rarement avant l'intégration si les exigences d'interface ne sont pas écrites et relues par les deux parties.

Pour un prestataire d'ingénierie, la règle pratique est simple : qui a spécifié ou modélisé sur un projet ne l'évalue pas ensuite, et la séparation entre équipes, clients et dossiers est organisée et documentée.

Les publics concernés

Les ingénieurs système (MBSE), les architectes, les ingénieurs logiciel embarqué ferroviaire, les ingénieurs automatisme et systèmes embarqués, les ingénieurs télécommunications ferroviaires et navigation et communications de bord, les responsables de gestion de configuration et de documentation technique, et les chefs de projet sont les premiers concernés. Les organisations vont des constructeurs de matériel roulant et des industriels de la signalisation aux chantiers navals civils et militaires, aux équipementiers et systémiers, aux sociétés d'ingénierie et aux laboratoires d'essais.

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

Nous auditons des architectures et des processus d'ingénierie, conseillons sur les exigences, l'architecture et les méthodes de développement, produisons des exigences, des modèles et des spécifications, déployons ou migrons des outils d'exigences et de gestion du cycle de développement, et formons. Nous intervenons aussi en assistance technique, sous la responsabilité et l'encadrement d'Optédif, avec des livrables définis, au forfait ou en récurrent. Les méthodes (SysML, Arcadia, modèles exécutables) sont des moyens : nous n'avons ni partenariat d'éditeur à servir, ni outil à vendre.

Nos livrables sont traçables, argumentés et présentables à votre donneur d'ordre, à l'exploitant ou à l'organisme tiers.

Ce que nous ne faisons pas

Un audit, une revue ou un audit blanc d'Optédif ne vaut pas évaluation indépendante. Nous ne sommes ni évaluateur de sécurité indépendant, ni organisme notifié ou désigné, ni organisme d'évaluation de l'analyse des risques, ni société de classification. Nous ne délivrons aucune autorisation, aucun agrément, aucune certification ni habilitation, et nous n'attestons ni le niveau d'intégrité d'un logiciel, ni la conformité d'un système. Le choix de l'architecture, la démonstration de sécurité et la décision restent à son concepteur.

Nous ne mettons pas de personnel à disposition et nous n'affectons pas notre personnel à des tâches critiques pour la sécurité ferroviaire. Nous n'intervenons pas sur des informations classifiées de défense.

Données sensibles et propriété intellectuelle

Les spécifications, les modèles et le code d'un client sont confidentiels. Nous convenons par contrat de la titularité des livrables, de l'absence de réutilisation et des conditions d'usage des outils. Nous n'intervenons pas sur des données soumises à contrôle des exportations sans cadre contractuel et réglementaire défini au préalable avec le client.

Références officielles

Textes et autorités

• EPSF : décret n° 2019-525 du 27 mai 2019, autorisations ferroviaires.
• ERA : STI contrôle-commande et signalisation, ERTMS (European Rail Traffic Management System, système européen de gestion du trafic ferroviaire).
• OMI : conventions maritimes, dont SOLAS (Safety Of Life At Sea, convention internationale pour la sauvegarde de la vie humaine en mer).
• IACS : exigences unifiées E26 et E27.

Normes citées

ISO/IEC/IEEE 15288, 29148 et 12207 ; EN 50126, EN 50129, EN 50159 et EN 50716 ; séries IEC 61375, IEC 61158, IEC 61784, IEC 62541, IEC 60092 et IEC 61162 ; IEEE 1076 pour le VHDL. Ces documents sont privés, protégés et payants : nous ne les reproduisons pas, et nous citons l'édition applicable dans chaque livrable. Pour les niveaux d'intégrité et les règles de codage, voir le domaine sûreté de fonctionnement ; pour la cybersécurité des systèmes embarqués, voir le domaine cybersécurité.