Architecture de sécurité matérielle du véhicule autonome : les leçons de la SOTIF et de l'ISO 21448
La norme ISO 26262 traite des défaillances : ce qui se passe quand le matériel casse. La norme ISO 21448 (SOTIF, Safety of the Intended Functionality) traite d'un problème fondamentalement différent : ce qui se passe quand le matériel fonctionne exactement comme prévu, mais que le système se comporte malgré tout de façon dangereuse.
Pour les ingénieurs matériels du véhicule autonome, la SOTIF transforme la manière de concevoir les architectures de capteurs, de spécifier les plateformes de calcul et de construire les stratégies de redondance.
Le problème SOTIF
Prenons un capteur LIDAR qui fonctionne parfaitement dans les limites de ses spécifications. Il mesure avec précision la distance de chaque objet dans son champ de vision. Mais une combinaison particulière de pluie, de brouillard et de soleil rasant crée un scénario où le signal de retour d'un piéton devient indiscernable du bruit de fond. Le capteur fonctionne correctement (il ne signale aucun obstacle), mais la fonctionnalité voulue du système (détecter les piétons) échoue.
C'est un problème SOTIF. Le matériel n'est pas en panne. La spécification n'est pas violée. Mais le système est dangereux parce que la spécification était insuffisante pour le scénario opérationnel.
La norme ISO 21448 exige que les concepteurs de systèmes autonomes identifient systématiquement ces "conditions déclenchantes", c'est-à-dire des combinaisons de facteurs environnementaux, de conditions d'exploitation et d'états système capables de faire échouer la fonctionnalité voulue, et qu'ils conçoivent le matériel pour les gérer ou restreignent le domaine opérationnel pour les exclure.
Conséquences pour l'architecture des capteurs
La SOTIF a des implications profondes sur l'architecture des capteurs. L'approche traditionnelle de la redondance (ajouter davantage de capteurs du même type) est insuffisante pour la conformité SOTIF, car des capteurs identiques partagent les mêmes conditions déclenchantes. Deux LIDAR échoueront tous deux à détecter un piéton dans le même scénario pluie/brouillard/soleil.
La SOTIF impose la "diversité" : utiliser des modalités de détection fondamentalement différentes pour garantir que les conditions déclenchantes d'un capteur ne recoupent pas celles d'un autre. Une architecture de capteurs conforme SOTIF combine typiquement :
Le LIDAR pour une géométrie 3D précise, efficace dans l'obscurité mais dégradé par les précipitations et la poussière.
Le radar pour la mesure de vitesse et le fonctionnement par tout temps, mais avec une résolution angulaire limitée et une difficulté à distinguer les objets entre eux.
Les caméras pour la classification et la reconnaissance des panneaux, mais dépendantes des conditions d'éclairage et affectées par les éblouissements, les ombres et la contamination de l'optique.
Les capteurs à ultrasons pour la détection de proximité, efficaces par tout temps mais limités en portée et en précision.
Le défi d'ingénierie matérielle ne consiste pas seulement à installer ces capteurs, mais à les intégrer dans un système de perception cohérent. Cela exige une synchronisation temporelle précise (tous les capteurs doivent partager une référence de temps commune), un calibrage spatial (les positions et orientations relatives doivent être connues au sous-centimètre près) et une architecture de calcul capable de fusionner les données de tous les capteurs en temps réel.
Exigences de la plateforme de calcul
L'accent mis par la SOTIF sur l'identification et le traitement des conditions déclenchantes génère des besoins de calcul qui dépassent tout ce qui a été tenté auparavant dans l'automobile.
Le système de perception doit non seulement détecter et classifier les objets, mais aussi estimer la confiance de ses détections. Une détection à 99,9 % de confiance par temps clair peut tomber à 95 % sous forte pluie. Le système de planification doit adapter son comportement en fonction de cette confiance : ralentir, augmenter la distance de sécurité ou demander une intervention humaine lorsque la confiance de perception passe sous des seuils sûrs.
Cette estimation de confiance demande beaucoup plus de calcul qu'une simple détection. Les architectures de réseaux de neurones doivent être modifiées pour produire des estimations d'incertitude en plus des classifications. Les algorithmes de fusion de capteurs doivent propager l'incertitude dans tout le pipeline. Et tout cela doit se produire dans les contraintes temps réel de la boucle de commande, typiquement 50 à 100 ms pour le cycle complet perception-planification-commande.
Les implications matérielles sont considérables. Les plateformes de calcul actuelles des véhicules autonomes consomment de 500 à 2 000 W et génèrent une chaleur proportionnelle. Le seul matériel de calcul peut représenter 10 à 15 % de la consommation électrique totale du véhicule. Concevoir une plateforme de calcul qui satisfait les besoins de la SOTIF tout en restant dans les budgets thermiques et électriques du véhicule est l'un des défis matériels déterminants du développement du véhicule autonome.
Évolution des stratégies de redondance
La SOTIF fait aussi évoluer la manière dont la redondance est mise en œuvre dans les architectures de véhicules autonomes.
La sécurité automobile traditionnelle utilise une redondance en "hot standby" : un système de secours qui prend le relais immédiatement en cas de défaillance du système principal. Cette approche fonctionne bien pour les systèmes fail-operational où le secours doit maintenir la pleine fonctionnalité.
La SOTIF introduit le concept de "dégradation progressive" : le système reconnaît que sa performance est dégradée (à cause de conditions déclenchantes, non d'une panne matérielle) et bascule vers un mode de fonctionnement plus sûr. Cela peut signifier réduire la vitesse, limiter les changements de voie ou activer une "condition de risque minimal" (arrêt sécurisé du véhicule).
L'architecture matérielle doit prendre en charge ces modes de dégradation progressive. La plateforme de calcul doit disposer d'une capacité de réserve suffisante pour exécuter des algorithmes supplémentaires de diagnostic et d'estimation de confiance quand les conditions se dégradent. L'architecture de communication doit supporter le flux de données accru issu du traitement renforcé des capteurs. Et le système d'alimentation doit être conçu pour gérer les profils de charge variables que crée la dégradation progressive.
Le défi de la validation
L'aspect le plus difficile de la SOTIF pour les équipes matérielles est peut-être la validation. La validation ISO 26262 peut s'aborder par l'analyse et les tests face à des modèles de fautes définis. La validation SOTIF exige de démontrer la sécurité sur un espace pratiquement infini de scénarios d'exploitation : chaque combinaison possible de météo, de trafic, de géométrie routière et d'état des capteurs.
Cela pousse à adopter des systèmes de simulation hardware-in-the-loop (HIL) d'une complexité sans précédent. Un système HIL de niveau SOTIF doit simuler non seulement la dynamique du véhicule, mais aussi l'environnement physique : les propriétés optiques de la pluie, la surface équivalente radar des différents types de véhicules, les modes de défaillance spécifiques de chaque capteur sous chaque condition déclenchante.
Construire et maintenir ces systèmes HIL est en soi un effort d'ingénierie matérielle majeur. Le matériel de simulation des capteurs doit être calibré et validé face à des mesures réelles. La plateforme de calcul temps réel doit simuler des modèles physiques complexes dans le respect du timing de la boucle de commande. Et l'infrastructure d'automatisation des tests doit exécuter des millions de scénarios tout en journalisant et analysant les résultats.
Concevoir pour l'inconnu
La SOTIF représente un changement philosophique dans l'ingénierie de la sécurité : passer de la preuve que le système gère des modes de défaillance connus à la démonstration qu'il se comporte de façon sûre dans des scénarios inconnus. Pour les ingénieurs matériels, ce changement exige un nouveau niveau de rigueur dans la spécification des capteurs, l'architecture de calcul et l'intégration système.
L'industrie du véhicule autonome apprend, parfois douloureusement, que la sécurité ne peut pas être atteinte par la seule spécification matérielle. Elle exige une compréhension profonde de la manière dont le matériel interagit avec le monde physique, et l'humilité de reconnaître que cette interaction contiendra toujours des surprises.
Les équipes matérielles qui réussiront seront celles qui construisent des systèmes conçus non seulement pour performer, mais pour connaître les limites de leur performance et agir de façon sûre lorsque ces limites sont atteintes.
