Défis et Besoins des PME pour la Robustesse de leurs Systèmes Cyber Physiques

Dans de nombreux domaines applicatifs tels que les systèmes ferroviaires, l’automobile, les bâtiments intelligents et l’industrie 4.0, le développement de systèmes spécifiques soulève de plus en plus de défis liés notamment à leur complexité mais aussi aux interactions entre des composantes matérielles, logicielles et réseau. Ces systèmes, appelés cyber physiques (CPS), doivent opérer de manière robuste dans des environnements ouverts, dynamiques et potentiellement exposés à des acteurs mal intentionnés. Opérer de manière robuste est une problématique importante qui a un impact sur les coûts et délais de développement, mais également la réputation de l’entreprise, et qui est souvent traitée de manière ad hoc avec des pratiques très variables. Elle touche à la fois de grandes entreprises intégrant des systèmes complexes (ex. automobile, ferroviaire) mais aussi des PME développant des produits plus spécifiques qui s’intègrent dans des solutions ou dans l’environnement de leurs clients (ex. capteurs environnementaux, instruments pour une plateforme spatiale).

Le projet Win4Collective CARAPACE, au sein duquel le CETIC collabore avec l’UCLouvain, cible les PME développant des CPS pour leur offrir en priorité un accès à des méthodes et outils visant à améliorer la robustesse de leurs produits, que ce soit lors des phases de conception, de test et d’opération.

Une des premières étapes de ce projet consistait en une étude de l’état des pratiques et des besoins dans ce domaine, au moyen d’une enquête réalisée auprès de 8 PME wallonnes développant des CPS. Les entreprises ont été interviewées pendant environ 1h30 avec un questionnaire commun, inspiré d’une enquête similaire conduite en Suède. Le formulaire est structuré selon une démarche globale couvrant la collecte des exigences de robustesse, les pratiques spécifiques de conception/développement/test de robustesse ainsi que les aspects de surveillance de robustesse en opération.

Si vous êtes intéressé par ce questionnaire et cette démarche, le formulaire est disponible en ligne et il vous permet aussi d’entrer en contact avec l’équipe du projet.

Cet article de blog présente les points marquants de cette étude, qui vont guider notre recherche au service des entreprises.

Quel est l’état des pratiques en matière de test de robustesse ?

À ce stade, un panel de 8 entreprises dont 7 PME actives dans le développement de solutions à base de CPS a été analysé. La plupart font entre 11 et 50 employés (dont une startup) plus une TPE et une entreprise de taille moyenne. Cette répartition est assez représentative du paysage wallon. La figure suivante montre que leurs domaines d’activité sont diversifiés : transport/logistique, santé, numérique, énergie, environnement,...

Au niveau des activités du cycle de vie d’un logiciel, elles sont toutes couvertes depuis l’élaboration du cahier de charges jusqu’aux tests comme l’illustre la figure suivante. La plupart des entreprises couvrent largement le cycle de vie et développent des CPS de bout en bout même si certaines sont parfois fournisseurs de solutions partielles intégrées par d’autres.

A propos de la définition de la robustesse, toutes les entreprises sont d’accord avec la définition “degré auquel un système ou un composant peut fonctionner correctement en présence d’entrées non valides ou de conditions environnementales stressantes” avec parfois certaines nuances et précisions comme l’importance d’assurer la continuité de fonctionnement malgré un environnement qui se dégrade, de surveiller le niveau de disponibilité des ressources du système ainsi que d’analyser la possibilité que les perturbations soient d’origine malicieuse. Ce dernier aspect relatif à la cybersécurité a unanimement et spontanément été rapporté comme une préoccupation importante par toutes les entreprises.

En ce qui concerne les exigences de robustesse, elles proviennent principalement des clients et des pratiques internes. Les normes sont relativement peu citées comme l’illustre la figure ci-dessous. Les clients expriment plus des exigences de type SLA (Service Level Agreement) sur des niveaux de performance, réactivité, disponibilité, charge qui in fine concernent des capacités de robustesse. Au sein de l’entreprise, une certaine culture peut être présente via la collecte plus systématique d’exigences de robustesse en même temps que d’autres exigences non-fonctionnelles au moyen d’un modèle de document. Les entreprises sujettes à des contraintes de certification en matière de sûreté de fonctionnement ont d’emblée une maturité beaucoup plus élevée sur l’ensemble du cycle de développement, et en particulier pour les exigences, en spécifiant notamment explicitement les modes de fonctionnement normaux et les modes dégradés.

Concernant les pratiques de conception et développement robuste, les principales mesures mises en place lors de la phase de conception sont les suivantes :

• utilisation d’un mécanisme de priorité pour les fonctions critiques ;
• mise en place de redondances, de mécanismes de détection et de récupération (recovery) ;
• architecture de type micro-services ou avec des taux de couplage faibles ;
• mise en place d’une surcouche compensant des dérives (ex. de capteurs) ;
• plan de backup et restauration.

Et concernant les mesures mises en place lors du développement :

• validation systématique des entrées ;
• gestion des exceptions ;
• évaluation de la robustesse de composants tiers ;
• revue de code (peer review).

Concernant les tests de robustesse, ceux-ci sont généralement réalisés en fin de développement, après qu’une validation fonctionnelle suffisante ait été atteinte au niveau composant ou système sur les cas nominaux, et avant la phase de déploiement. Une entreprise avance la mise en oeuvre de tests poussant le système dans ses limites pour s’assurer de la capacité de réaliser des diagnostics même si les tests ne sont pas encore entièrement jouables. Dans le cadre de développement agile, une pratique évoquée est d’inclure des tests de robustesse tous les 2 ou 3 sprints et en fin de projet. Des scénarios liés aux mises à jour ont aussi été mentionnés.

Les tests mis en place couvrent plusieurs catégories : tests de longue durée en labo et aussi sur le terrain, tests de charge visant à atteindre les limites du système en sollicitant un maximum de fonctionnalités en même temps, tests de simulation de défaillances matérielles, de basculement en mode dégradé, test d’interruption et de récupération.

Concernant le rôle à qui le test de robustesse (et plus largement le test) est confié, on constate qu’il s’agit dans la majorité des cas d’une responsabilité partagée au sein de l’équipe de développement (généralement selon le schéma croisé développeur/testeur indépendant) ou, pour des structures ayant des équipes plus élaborées, un testeur polyvalent. Notons qu’il n’y a pas de profil spécifique de testeur de robustesse : le rôle est à la fois trop spécialisé et demande aussi une connaissance fonctionnelle du système à tester.

Concernant l’environnement de test, il est dans la grande majorité des cas mixte avec une composante simulée et une partie comportant du matériel cible. Le but général est d’avoir la capacité de réaliser un maximum de tests dans l’environnement contrôlé du labo en simulant de manière réaliste l’environnement réel, avec un bon niveau d’automatisation et avec des coûts contrôlés. Les tests sur site sont réalisés pour valider en environnement réel mais sont beaucoup plus coûteux et donc minimisés.

Au niveau de la phase de surveillance en opération, les éléments examinés les plus fréquemment sont les traces (logs) des composants clés du système, la capacité de résilience à des entrées/sorties erronées et “l’uptime”. D’autres éléments plus spécifiques sont la résistance au bruit sur des signaux de composants matériels, des tests de pénétration (spécifiques à la sécurité) et certaines métriques de statut (occupation CPU, état courant d’un automate, etc.) Les facteurs de santé d’un système sont assez rarement définis.

Les défaillances constatées en phase d’opération peuvent être classifiées selon la terminologie CRASH (Catastrophic, Restart/redémarrage, Abort/terminaison anormale, Silent/pas observable, Hindering/entravant le système). Tous les types ont été rapportés par les entreprises avec seulement un seul cas catastrophique. Une difficulté rapportée plusieurs fois concerne la problématique de diagnostiquer des défaillances peu reproductibles ou dans le cas Silent.

Quels sont les besoins collectés auprès des entreprises ?

Les entreprises consultées ont rapporté de manière récurrente les problèmes suivants (pains points) liés à la mise en œuvre de tests de robustesse dans leurs CPS :

• la complexité de comprendre le CPS à tester, combinée avec une documentation lacunaire de certains composants du système. Cette difficulté peut être aggravée par des évolutions de l’architecture parfois introduites tardivement dans le projet et constituant un facteur de risque ;
• la lourdeur des tests de robustesse par rapport à d’autres types de tests tels que les tests unitaires ;
• la complexité de l’environnement de test à mettre en place, qui doit être proche du système réel et qui nécessite la mise en œuvre de parties simulées ;
• la difficulté de diagnostiquer les problèmes non reproductibles ;
• l’évolution importante de causes liées aux menaces de cybersécurité.

Une classification des besoins par grands domaines d’activité est résumée dans le tableau suivant qui indique aussi leur prise en charge par le projet.

Quelles sont les prochaines étapes ?

Nous vous avons présenté une synthèse des défis et besoins industriels en matière de robustesse pour des CPS. En parallèle, nous avons aussi réalisé un état de l’art des méthodes et outils permettant d’adresser ces besoins. La prochaine étape est de mettre en œuvre des solutions ciblant les besoins sélectionnés sur base de cas industriels. Au niveau du CETIC, la conduite de tests de robustesse sera ancrée sur une démarche de Chaos Engineering, popularisée pour les systèmes Cloud complexes par Netflix mais qui sera ici appliquée au domaine des CPS. Nous vous présenterons plus en détails cette approche dans un second article de blog lié au projet CARAPACE.

Comment nous rejoindre ?

Si la problématique de la robustesse vous touche et que vous désirez en savoir plus sur cette thématique, voire vous impliquer plus concrètement, le projet dispose d’un comité industriel se réunissant tous les semestres afin de présenter les progrès et collecter des retours des entreprises. Il est également possible de vous impliquer plus spécifiquement pour mettre en œuvre les techniques et outils du projet sur un cas d’étude de votre domaine.

N’hésitez pas à nous contacter en remplissant notre enquête ou par email. Notre équipe entamera un dialogue avec vous afin d’en savoir plus sur vos besoins, de les intégrer à nos travaux et de déterminer avec vous la meilleure manière de collaborer !