Auteur : Steve McAslan, directeur technique chez NXP Semiconductors.
Il est clair, même pour le propriétaire moyen d'un véhicule, que le paysage automobile est en train de changer. Au-delà de l'essence et du diesel, il existe également des options d'électrification. Ceux-ci incluent des hybrides, entièrement alimentés par batterie et alimentés à l'hydrogène. Mais ce ne sont pas les seuls changements. L'architecture électrique et électronique (E/E) sous-jacente du véhicule évolue également. Cela implique des changements importants dans la conception de l'électronique du véhicule et dans l'expérience du conducteur et des passagers à l'intérieur.
Les microprocesseurs ont été lentement intégrés à l'automobile depuis les années 70, lorsque les fabricants d'équipement d'origine ont commencé à intégrer des systèmes d'injection électronique de carburant (EFI) et des diagnostics embarqués. Année après année, ils ont contribué à la sécurité, à l'efficacité et au confort de la voiture, avec un ou plusieurs d'entre eux intégrés dans chacune des unités de contrôle électronique (ECU) de plus en plus nombreuses. Cela a abouti à une architecture plate du point de vue du réseau et à peu de possibilités de fournir des mises à niveau de fonctionnalités après la construction du véhicule. Tout ce qui est nécessaire pour mettre en œuvre une fonction, de la détection à l'actionnement, est connecté à un seul ECU. Les calculateurs sont normalement connectés via un bus, tel que CAN, aux systèmes de commande, de programmation et de diagnostic centraux. Une fois implanté, le logiciel n'est mis à jour que si un problème est détecté et seulement après des efforts considérables, des tests et un rappel du véhicule.
L'influence du smartphone dans l'industrie automobile
Cependant, une génération d'utilisateurs de smartphones influence les attentes concernant l'expérience produit. Les consommateurs ne s'attendent plus à acheter un produit fini ; ils achètent des plateformes qui peuvent être modifiées et configurées selon leurs besoins, leurs exigences et leur mode de vie. L'approche rigide d'aujourd'hui en matière de conception de véhicules ne rentre pas dans ce moule. Cela a obligé l'industrie automobile à repenser son approche de l'électronique automobile et des logiciels qui implémentent la plupart de ses fonctionnalités.
Il existe actuellement deux écoles de pensée sur l'architecture E/E, qui réduisent le nombre d'ECU, simplifient le câblage et la mise en réseau et permettent les mises à jour en direct (OTA). Ils fournissent également la structure nécessaire pour que les fonctions, telles que les sièges chauffants, puissent être achetées en tant qu'application pour smartphone longtemps après que le véhicule a été configuré et livré à son propriétaire d'origine.
L'une d'entre elles concerne les architectures de domaine qui suivent la convention de dénomination actuelle des différents domaines du véhicule, tels que la transmission, le châssis, les freins et la carrosserie, pour n'en nommer que quelques-uns (Figure 1). Une fonction qui était auparavant implémentée sur un seul ECU est déployée avec de nombreuses autres fonctions de domaine sur un seul ECU avec un puissant processeur multicœur (Figure 2).
L'autre approche est l'architecture zonale. Ici, l'emplacement de l'ECU est plus pertinent, avec un petit nombre de boîtiers matériels situés autour du véhicule plus près des capteurs et actionneurs installés. Encore une fois, les ECU contiennent de puissants processeurs multicœurs avec des réseaux redondants à grande vitesse adaptés au contrôle en temps réel qui échangent des données avec d'autres contrôleurs de zone. Au centre se trouve un ordinateur haute performance (HPC) et une passerelle télématique qui fournit une connectivité Internet.
Alors que les architectures de domaine offrent ce qui pourrait être considéré comme une étape facile vers une plus grande intégration, les architectures zonales bouleversent l'approche du développement logiciel. En effet, des fonctions telles que le contrôle des phares et des clignotants sont réparties sur les ECU zonaux au lieu d'être dédiées à un seul boîtier. Au lieu de cela, les fonctions sont implémentées sous forme d'ECU virtuels sur de puissants processeurs multicœurs.
Dans les architectures de domaine et de zone, cela signifie également que les logiciels conformes aux différents niveaux d'intégrité de sécurité automobile (ISO 26262 ASIL) doivent fonctionner en parallèle sur le même processeur sans s'affecter en cas de panne. Ceci est connu dans l'industrie automobile sous le nom de "absence d'interférence". Ainsi, quelle que soit l'architecture utilisée, il est clair que le logiciel est au centre de la définition des capacités du véhicule et qu'un aspect central de celle-ci est la virtualisation.
Figure 2 : Sur un contrôleur de domaine, chaque fonction du véhicule est implémentée dans un calculateur virtuel, les systèmes d'exploitation partageant les performances de traitement sous l'œil attentif d'un hyperviseur.
Brève incursion dans la virtualisation
La virtualisation a été essentielle au succès du Cloud Computing, car elle permet à plusieurs installations de système d'exploitation (SE) de s'exécuter sur un seul serveur, partageant ainsi ses performances entre de nombreux utilisateurs. La virtualisation Bare Metal s'exécute sur le niveau le plus bas du matériel serveur, sans qu'aucun système d'exploitation invité installé ne sache qu'il est virtualisé, qu'il partage des ressources matérielles ou que d'autres systèmes d'exploitation s'exécutent parallèlement. Dans sa forme la plus pure, la plate-forme de virtualisation, connue sous le nom d'hyperviseur, intercepte essentiellement les appels du système d'exploitation et les traduit vers le système virtualisé, tels que les accès au disque et à la mémoire. Il en va de même pour les interfaces matérielles, telles que la connectivité Ethernet.
Comme on pouvait s'y attendre, la virtualisation entraîne une surcharge inévitable dans la gestion de ces accès matériels. Pour lutter contre cela, les développeurs peuvent adopter l'approche alternative de la paravirtualisation. Dans ce cas, les accès aux ressources matérielles sont implémentés dans un logiciel similaire à la façon dont ils se feraient s'il n'y avait qu'un seul système d'exploitation. Bien que cela améliore les performances par rapport à la virtualisation, l'avantage varie en fonction de la charge de travail et nécessite que les systèmes d'exploitation soient modifiés en conséquence. Ce niveau de variation n'est pas acceptable pour le monde en temps réel du contrôle automobile.
Processeurs temps réel pour systèmes d'exploitation virtualisés
Les processeurs dédiés aux applications automobiles doivent relever ces défis, comme c'est le cas avec une nouvelle génération de processeurs temps réel de NXP. Par exemple, un ingénieur de développement s'attend souvent à ce que les broches d'E / S à usage général (GPIO) soient configurées et contrôlées via une série de grands registres, chaque bit étant dédié à la définition de l'adresse, à l'utilisation de pull-ups, au contrôle de sortie et fournir l'état des entrées. Chacun de ces registres se voit attribuer une adresse unique en mémoire. Pour cette raison, les mécanismes de protection de la mémoire typiques ne peuvent pas allouer des bits individuels d'un registre à une instance spécifique du système d'exploitation. Il est donc de la responsabilité de l'hyperviseur de gérer cela dans le logiciel.
Les S32Z et S32E offrent une alternative intelligente qui renonce à cette exigence, permettant la prise en charge de la virtualisation cœur à broche pour des combinaisons arbitraires de broches GPIO par système d'exploitation invité. La prise en charge est assurée par du matériel supplémentaire qui attribue, au moment du démarrage, les broches GPIO requises à un système d'exploitation client ou à une partition système spécifique. Comme cela est implémenté dans le matériel, les pertes de performances généralement associées à la virtualisation disparaissent. Étant donné que chaque système d'exploitation ne voit que son propre nombre arbitraire de GPIO, grâce au partitionnement au niveau matériel, il n'y a presque pas besoin de paravirtualisation.
La certification ASIL est également simplifiée par cette prise en charge de la virtualisation au niveau matériel. Toute défaillance matérielle n'affecte que le système d'exploitation associé et son application, et une seule machine virtuelle peut choisir de se réinitialiser ou de redémarrer sans impact sur les autres systèmes d'exploitation ou les configurations matérielles des périphériques. Les processus d'emballement n'affectent pas les autres parties du système. Un autre avantage est la garantie de qualité de service qui en résulte pour la bande passante et les performances.
Adaptation aux besoins du véhicule définie par logiciel
L'accès de cœur à cœur aux ressources GPIO n'est qu'un aspect de la gamme de processeurs temps réel S32E et S32Z qui répondent aux exigences des véhicules définis par logiciel. Les 24 interfaces réseau FlexCAN FD peuvent être étiquetées avec un identifiant qui leur permet également d'être attribuées à des systèmes d'exploitation invités spécifiques, minimisant à nouveau la surcharge logicielle. Mais ce n'est pas tout. Les réseaux CAN peuvent être particulièrement gourmands en interruptions, ce qui entraîne de nombreux changements de contexte qui rendent difficile le respect des exigences en temps réel dans le reste de votre code d'application.
Pour gérer cela, les périphériques CAN font partie d'un bloc d'auto-accélération de communication dédié avec deux cœurs de verrouillage Arm Cortex-M33 dédiés et 768 Ko de SRAM (Figure 3). La nouvelle norme CAN-XL est également prise en charge par le bloc Connectivité/Interface. CAN-XL offre des débits de données allant jusqu'à 20 Mbit/s et un champ de données plus large de 2048 octets. Il reste interopérable avec les réseaux CAN-FD, mais prend également en charge la canalisation des protocoles de couche supérieure tels que le protocole Internet (IP), ce qui sera de plus en plus utilisé à mesure que l'Ethernet automobile sera déployé comme dorsale.
Il comprend également l'Ethernet automobile, avec deux interfaces 10/100/1000 Mbit et un commutateur Ethernet intégré dans un bloc d'accélération Ethernet. À l'avenir, les processus qui contrôlent les fonctions du véhicule enverront des commandes via Ethernet aux processus logiciels qui implémentent le contrôle ou fournissent des données de capteur. Cependant, cette fonction peut être exécutée sur le même matériel de processeur, mais sur un ECU virtuel différent. Pour ce faire, le commutateur Ethernet peut également faire passer des données entre des calculateurs virtuels du processeur. Cela signifie que vous pouvez créer des fonctions logicielles qui communiquent via Ethernet sans avoir besoin de savoir si le logiciel partenaire est sur le même processeur ou sur un contrôleur de zone différent ailleurs sur le réseau.
Figure 3 : Un petit échantillon de la connectivité automobile disponible, parfois avec prise en charge de l'accélération, offerte par les S32E et S32Z.
Développement de logiciels de véhicules définis par logiciel
La façon de développer des logiciels automobiles évolue également. La rupture la plus significative avec la tradition se produit chez les équipementiers automobiles. Ici la vue d'ensemble est essentielle, car elle permet de s'assurer que les fonctions nécessaires sont bien définies et que le matériel processeur choisi offre les performances nécessaires pour répondre aux attentes d'aujourd'hui et à celles des futurs conducteurs tout au long de la vie du véhicule ( Figure 4).
Figure 4 : Dans une architecture zonée, les fonctions sont réparties dans des calculateurs virtuels dans tout le véhicule, comme dans ce cas, où le système de freinage avant et arrière et l'ESC lié au système de freinage sont déployés de manière centralisée.
Les fournisseurs de rang 2 joueront également un rôle important ici, grâce à leur compréhension approfondie des différents aspects du véhicule et de la manière dont ils ont été mis en œuvre historiquement. Plus bas dans la chaîne, les fournisseurs automobiles de niveau 3/XNUMX sont plus susceptibles de voir moins de changements, mis à part le passage au développement de logiciels pour un calculateur virtuel, plutôt que de matériel. Ils auront accès à un système d'exploitation et à des périphériques avec peu d'informations sur ce qui tourne sur le même matériel. En fait, ces décisions n'ont peut-être même pas été prises. Telle est la flexibilité de l'approche définie par logiciel.
Ce qui est essentiel, c'est que les processeurs choisis offrent d'excellentes performances pour aujourd'hui et une marge de manœuvre pour l'avenir, ainsi que la possibilité de prendre en charge des mises à jour OTA sécurisées. Les S32E et S32Z fournissent huit cœurs Arm Cortex-R52 fonctionnant jusqu'à 1 GHz, construits sur un processus de 16 nm et avec une feuille de route à 5 nm. Ils peuvent être configurés de manière flexible en tant que noyaux individuels ou en blocs pour répondre aux exigences de sécurité des fonctions qui s'exécutent sur eux. Pour répondre aux exigences des systèmes avancés d'aide à la conduite (ADAS) et des fonctions de conduite autonome, il existe également un processeur 25 GFLOPS DSP/Machine Learning.
Un moteur de sécurité matériel (HSE), certifié ISO 21434, fournit des accélérateurs cryptographiques sécurisés pour une communication sécurisée et des mises à jour logicielles signées numériquement qui sont partagées à l'aide d'une infrastructure à clé publique (PKI).
L'avenir de la voiture est logiciel
Vues de l'extérieur, les voitures restent des merveilles mécaniques, de leur conception et forme à leurs sièges et moteurs. Mais tout le reste, du mouvement aux avantages qu'ils offrent à leurs occupants, sera défini par le logiciel, lié à l'électronique, à l'abri des regards. L'automobile a toujours été un marché unique, exigeant plus que les processeurs les plus rapides que l'industrie des semi-conducteurs peut offrir, mais aussi des produits exigeants qui répondent également à des exigences de fiabilité et de sécurité étendues. Une nouvelle classe de processeurs en temps réel est nécessaire car le véhicule défini par logiciel pilote des architectures système basées sur des approches généralement associées au cloud computing, telles que la virtualisation. Des appareils tels que les familles S32E et S32Z, qui prennent en charge le mappage matériel granulaire du cœur à la broche pour prendre en charge les calculateurs virtualisés, deviendront un incontournable des architectures d'E/S automobiles nouvellement déployées. Cela permettra aux équipementiers de consolider le matériel et d'offrir des fonctionnalités de smartphone en tant que service, des applications et des mises à jour OTA, sans perdre la fiabilité et la sécurité sur lesquelles reposent leurs marques.
