Frank van den Beuken de PRQA discute du rôle que jouent la sûreté et la sécurité dans l'avenir de la conduite assistée et autonome
Fonctionnalité accrue
Les voitures évoluent d'un dispositif électromécanique sous le contrôle d'un conducteur humain à un véhicule entièrement autonome. Nous approchons actuellement du point de basculement car les nouvelles voitures intègrent principalement des systèmes avancés d'aide à la conduite, tels que l'assistance au changement de voie, le freinage d'urgence autonome, les systèmes de vision avancés et autres, et les voitures entièrement autonomes. Dans la phase expérimentale, ils accumulent des millions de kilomètres de tests.
Les systèmes qui fournissent ces fonctions sont constitués de capteurs, d'actionneurs, de radars et de systèmes lidar qui communiquent sur des réseaux et sont contrôlés par des microcontrôleurs, de sorte qu'une définition d'une voiture est un Internet sur roues. Les voitures communiquent également avec d'autres voitures (communication de véhicule à véhicule ou VV) ou avec des infrastructures telles que des feux de circulation et des feux de signalisation (VI) et avec des satellites pour la navigation et les rapports. Sous tout cela, bien sûr, le logiciel : plus de 100 millions de lignes de code. Outre le code des applications, il existe des systèmes d'exploitation, des intergiciels tels que des piles de communication réseau et des interfaces vers des capteurs, des actionneurs et même l'écran du conducteur.
vulnérabilité accrue
En raison de cette augmentation de la complexité, les questions de sûreté et de sécurité sont de plus en plus préoccupantes. L'essor de la communication VX a rendu les voitures vulnérables aux attaques extérieures : il est déjà arrivé qu'un tiers prenne le contrôle d'une Jeep en s'imposant au conducteur.
L'utilisateur de la voiture peut ajouter une plus grande vulnérabilité. Tous les constructeurs automobiles utilisent des systèmes de diagnostic embarqué (OBD) pour surveiller divers paramètres du moteur, pour le dépannage et pour les diagnostics en atelier. L'interface du connecteur (OBD II) est ouverte et Google OBD2 recherche un grand nombre de connecteurs OBD avec Bluetooth pour permettre au conducteur de surveiller l'état du moteur avec un téléphone portable, ce qui pourrait ouvrir le système de contrôle du moteur à une personne hostile. Un article récent de l'Université du Michigan décrit l'utilisation d'une connexion directe entre un ordinateur portable et un OBD pour annuler les instructions du conducteur dans un gros camion et un autobus scolaire.
Avec une telle quantité de code, la protection est également essentielle. L'affaire judiciaire d'accélération non planifiée de Toyota a démontré qu'une grande partie de l'ancien code n'était pas de haute qualité, donc un nouveau code de qualité beaucoup plus élevée doit être développé.
Standardisation
Cinq ans seulement se sont écoulés depuis l'élaboration de la première norme spécifique pour la protection des voitures. L'ISO 26262 est une adaptation de la norme de protection fonctionnelle CEI 61508, qui se concentre sur les besoins des systèmes électriques et électroniques installés dans les voitures particulières produites en série et s'applique à toutes les activités du cycle de vie de ces systèmes liées à la protection, y compris les exigences de qualité logicielle. .
La norme utilise les niveaux ASIL (niveau d'intégrité de la sécurité automobile) pour fournir une mesure du risque associé à un sous-système. Ces niveaux vont de A à D, où A est le niveau d'intégrité le plus bas et D le plus élevé, c'est-à-dire le plus exigeant avec le plus d'exigences. En plus de ces ASIL, la gestion de la qualité (DM) de la classe indique qu'elle n'est pas tenue de se conformer à la norme ISO 26262, ce qui signifie qu'il est laissé à la discrétion de l'organisme de développement d'assurer la qualité.
Les paramètres de gravité du risque, de probabilité d'exposition et de contrôlabilité déterminent l'ASIL. Le paramètre de contrôlabilité nécessite une attention particulière. Il est supposé que le conducteur est dans les conditions appropriées pour conduire, qu'il a une formation adéquate pour la conduite (permis de conduire) et qu'il respecte toutes les réglementations légales applicables, y compris les exigences correspondantes pour éviter les risques avec les autres participants au trafic : le conducteur doit respecter le code de la route. Les lois doivent être adaptées afin que lorsqu'un système de conduite automatisé est en marche, le conducteur n'ait pas à prêter attention à moins que le système ne demande l'intervention du conducteur. Le bon fonctionnement de la notification au conducteur et de la demande de contrôle humain est essentiel. Si la notification échoue, le conducteur humain peut ne pas prêter attention et ne sera pas en mesure d'éviter le danger, comme cela a pu se produire lors du récent accident de Tesla. Si la demande échoue, le système pourrait continuer à exercer le contrôle au lieu de permettre au conducteur d'intervenir et d'éviter le danger.
Ces situations doivent toujours être affectées à la classe de contrôlabilité la plus élevée (C3), ce qui signifie que moins de 90 % des conducteurs ou autres participants à la circulation sont généralement capables, ou à peine capables, d'éviter le danger. La partie 6 de la norme 26262 est dédiée au processus de développement logiciel pour produire un code suffisamment fiable pour exécuter un système et répondre au niveau ASIL requis. La norme SAE (Society of Automotive Engineers) J3016 divise l'automatisation de la conduite en six classes, de non automatique à entièrement automatique.
Les systèmes d'auto-conduite, définis par la SAE comme niveau 3 ou supérieur, s'appuient sur un logiciel pour collecter les données des capteurs afin de modéliser l'environnement puis, selon l'objectif, décider comment assister le conducteur ou contrôler le véhicule. Il a également d'autres tâches critiques, telles que déterminer si les capteurs fonctionnent correctement, quand alerter le conducteur et quand activer la demande de contrôle humain. Il est vital que ce logiciel réponde de manière fiable. D'autres tâches logicielles, telles que la modélisation des données des capteurs, peuvent être moins critiques, mais même dans ce cas, une analyse des risques sera nécessaire.
législation
Le code de la route devra être modifié pour s'adapter aux systèmes de conduite automatisés, en particulier dans le domaine de la responsabilité et de la vie privée. Chaque pays a ses propres lois sur la circulation et il existe des initiatives législatives dans de nombreuses juridictions. Aux États-Unis, la National Highway Traffic Safety Administration a proposé un système de classification formel qui définit cinq niveaux allant du contrôle complet du véhicule par le conducteur à tout moment à l'adoption par le véhicule de toutes les fonctions critiques de protection tout au long du trajet, sans que le conducteur ne soit attendu. contrôler le véhicule à tout moment.
Chaque État a fait une proposition différente : le Nevada a été le premier État à autoriser les véhicules autonomes à tester la technologie de conduite autonome sur la voie publique en 2011, suivi par la Californie, la Floride, le Michigan, le Dakota du Nord, le Tennessee et Washington DC. En janvier 2014, le projet de recherche européen appelé Automated Driving Applications & Technologies for Intelligent Vehicles a été lancé, qui développe diverses fonctions de conduite automatisée pour le trafic quotidien en adaptant dynamiquement le niveau d'automatisation à la situation et à l'état du conducteur. Le projet couvre également les aspects juridiques qui pourraient influer sur la réussite de la commercialisation.
Vehicle & Road Automation (VRA) est une initiative de soutien financée par l'Union européenne pour créer un réseau collaboratif d'experts et d'autres parties prenantes travaillant sur le déploiement de véhicules automatisés et de leur infrastructure associée. VRA collabore avec quelques fabricants d'équipement d'origine (OEM) et fournisseurs, mais les membres sont principalement des instituts de recherche et des universités. La VRA a identifié une liste de problèmes juridiques et réglementaires dans l'UE. Volkswagen a lancé un recours en justice en Europe, y compris la modification progressive du règlement ECE 79 (également règlement de l'ONU) sur la direction assistée. Cela nécessite que le conducteur puisse annuler la fonction à tout moment et conserver le contrôle principal. Le gouvernement japonais prévoit d'élaborer des lois pour réglementer l'utilisation des voitures sans conducteur.
Le gouvernement a également créé une classification de la conduite automatisée en quatre classes, dont une pour la conduite totalement autonome. En Chine, Baidu (souvent appelé le Google de Chine) travaille également sur le développement d'une voiture automatique avec BMW. La loi chinoise est assez flexible, de sorte que le gouvernement a plus de pouvoir pour introduire les changements nécessaires. Cependant, ils doivent faire face à des aspects aussi complexes que dans d'autres pays. L'Inde réfléchit également à la conduite autonome, mais fait face à de grands défis tels qu'une législation lente et des difficultés à appliquer les règles prévues en raison d'infrastructures différentes.
Approches du développement
Dans ce contexte, comment créer du code protégé et sécurisé ? Comme indiqué précédemment, la norme ISO 26262 propose un processus de développement logiciel qui inclut l'utilisation de normes de codage et d'outils de vérification de code. La sécurité du système commence par la conception de fonctions qui contribuent à offrir un résultat sécurisé, telles que : la séparation de l'application, et plus particulièrement la division par des pare-feu des applications de protection critiques (telles que la direction et les freins) vis-à-vis des moins critiques , en particulier celles qui communiquent avec le monde extérieur (comme l'infodivertissement); limitation des communications ; vérification et validation des données communiquées ; entre autres. Étant donné que la plupart des logiciels dans ce domaine sont écrits en C, un bon point de départ pour un code sûr et sécurisé est MISRA C:2012 (MISRA 3).
Il fournit un ensemble de recommandations pour l'écriture de programmes C qui, en plus d'éviter les comportements indéfinis, incluent des règles qui améliorent la maintenabilité, les tests, la portabilité et la lisibilité du code source. Il existe également un large accord entre les règles MISRA et les tableaux de conformité ISO 26262-6, ce qui fait de MISRA un choix souhaitable lorsque la conformité à ISO 26262 est requise. le développement de systèmes sécurisés. Les outils sont une partie importante du développement conforme à la norme 1. Les outils d'analyse de code statique sont une partie importante de la gestion de la qualité du code car ils fournissent un contrôle de la qualité du code et mesurent la conformité du code aux normes de codage, comme MISRA.
Les outils de test offrent une confiance encore plus grande dans le logiciel, tandis que les outils de vérification mesurent si le logiciel répond aux objectifs du concepteur. Il est possible de développer des systèmes sûrs et sécurisés pour les véhicules et les organisations qui ont réorganisé leurs processus de développement pour se conformer à la norme ISO 26262 ont constaté qu'après une phase initiale d'introduction et d'apprentissage, elles sont également en mesure d'augmenter leur productivité.
Références
