TSN résilient – ResTSN

Les véhicules modernes embarquent des dizaines, voire centaines de capteurs, actionneurs et calculateurs échangeant, au travers d’un ou plusieurs réseaux temps-réel, de nombreuses informations nécessaires au bon fonctionnement de l’ensemble. Ces réseaux manipulent des données ayant des caractéristiques très variées, et la technologie TSN, extension temps réel de la technologie Ethernet, standardisées par l’IEEE, se propose d’unifier les architectures grâce à la richesse de ces mécanismes. En cas de défaillance d’une partie du réseau (suite à une panne ou à une attaque), une partie des communications est perdue, compromettant potentiellement l’intégrité du système. L’objectif du projet est de travailler sur la résilience de tels réseaux, en permettant à un réseau qui tombe dans un mode de fonctionnement dégradé de se reconfigurer automatiquement, pour continuer à assurer aux mieux ses missions essentielles. Ce type de mécanisme existe déjà dans les réseaux de données informatiques, mais l’enjeu ici vient des caractéristiques temps-réel. Dans un tel contexte, il ne suffit pas de servir au mieux des capacités restantes l’ensemble des flux de manière indistinctes. En effet, il existe des flux de données plus importants que d’autres, et dans une situation dégradée, mieux vaut sacrifier complètements des flux plutôt que de partager la pénurie de ressources entre tous. On ne peut pas non plus simplement accorder plus de priorité aux flux les plus importants, pour deux raisons. D’une part, les réseaux TSN n’ont que 8 niveaux de priorité. Mais surtout, dans les réseaux temps réels, la simple allocation de priorité ne suffit pas à garantir un comportement ayant les bonnes caractéristiques temporelles (la preuve en est qu’Ethernet possédait déjà 8 niveaux de priorité, ce qui était insuffisant pour les besoins des systèmes temps-réels embarqués critiques).

L’enjeu devient donc de reconfigurer le réseau, avec les ressources restantes. Il s’agit donc de calculer une nouvelle configuration, mais ce calcul est assez différent de la problématique de configuration d’un réseau lors de la conception du système, et ce sur deux points principaux. Le premier point est que la nouvelle configuration doit être « proche » de la précédente, c’est à dire qu’il faut éviter de modifier les paramètres associés aux flux qui ne sont pas directement impactés par la panne, si on a considéré qu’ils étaient assez importants pour être conservés. Le second point est que ce calcul doit pouvoir être réalisé en opération, donc en quelques secondes en utilisant les ressources de calcul présentes dans le véhicule, alors que la configuration lors de la conception peut utiliser si besoin des heures ou des jours de calcul, éventuellement sur des machines dédiées. Ajoutons que la reconfiguration sera d’autant plus facile si la configuration initiale a été conçue en ce sens.

Mais la mise en place de nouveaux mécanismes, par nature, augmente la surface d’attaque possible. Un tiers malveillant va toujours chercher à détourner à son avantage une fonctionnalité. Dans TSN, il existe un élément central de configuration. Dans notre contexte, il faut donc veiller à éviter qu’un tiers puisse signaler cet élément une panne inexistante et forcer le réseau à passer en mode dégradé, alors que ses capacités sont nominales. Il faut aussi éviter qu’un tel tiers puisse se faire passer pour cet élément et forcer ainsi le déploiement d’une configuration inadéquate (où les messages ne seraient pas distribuées aux bons destinataires par exemple, ou en faisant passer tous les flots par un élément réseau qui deviendrait surchargé, et perdrait alors des messages).

L’objectif du projet consiste donc à rendre TSN résilient, c'est-à-dire définir des algorithmes de reconfiguration et des architectures reconfigurables sans mettre en place de vulnérabilité supplémentaire.