MtoM Mag - Le journal de l'MtoM.

Non seulement la tendance est très forte en faveur des technologies ADAS (Advanced Driver Assist System, ou système d’assistance à la conduite), qui sont susceptibles d’évoluer jusqu’à la conduite 100% automatisée, mais il faut aussi satisfaire aux exigences de la norme de sécurité ISO 26262, et répondre aux attentes des acheteurs pour des tableaux de bord et des systèmes d’info-divertissement dotés du même niveau de sophistication que leurs smartphones et leurs tablettes.

La demande de systèmes plus interactifs dans l’habitacle a conduit, non seulement à s’éloigner des cadrans mécaniques traditionnels, mais aussi à augmenter la quantité d’information présentée. Plusieurs écrans proposent aux passagers un divertissement personnalisé pendant le voyage, tout en fournissant au conducteur une meilleure information sur l’état de la route autour de lui. Une visualisation 3D avancée fournit une vue à 360° de l’environnement autour du véhicule, en évitant au conducteur d’avoir à se soucier des angles morts. Une meilleure intelligence intégrée au logiciel de traitement d’images permet d’avertir le conducteur des risques survenant quand des véhicules changent de file ou si un événement se produit plus loin sur la route.

Une interaction intuitive est indispensable aux systèmes IVI (In-Vehicle Infotainment, ou info-divertissement à bord) présents dans le véhicule, pour éviter de fournir au conducteur des informations non-pertinentes, qui pourraient nuire à son attention. Les fonctions pour changer de musique ou modifier le réglage de la climatisation doivent être facilement accessible afin de ne pas obliger le conducteur à quitter trop longtemps les yeux de la route. En pratique, mettre en œuvre une telle interaction s’avère difficile car cela implique un très grand nombre de variables. Alors que la commande vocale et les interfaces gestuelles plus sophistiquées sont de plus en plus répandues, celles-ci doivent être adoptées et mises en œuvre par les concepteurs UX (User eXperience, ou expérience utilisateur).

Les tests utilisateur sont essentiels pour pouvoir assurer que l’interaction imaginée fonctionne bien dans la réalité. Les experts UX doivent pouvoir ajuster l’interface rapidement si des problèmes sont identifiés, tandis que les développeurs doivent s’assurer que le code de contrôle et de commande sous-jacent, fonctionne correctement.

Grâce à la croissance des écosystèmes d’applications en électronique grand-public, la voiture elle-même devient une plateforme IT (Information Technology, ou informatique). Les systèmes IVI exposent leurs API à des dispositifs tiers, qui permettent le développement de services supplémentaires, sans implication directe du constructeur automobile. Mais il existe des défis importants associés à cette tendance.

Les demandes pesant sur le développement IVI posent de gros problèmes au modèle traditionnel en cascade du développement logiciel. Les constructeurs, et par suite les fournisseurs de rang 1, cherchent des moyens plus agiles, pour élaborer et maintenir les logiciels IVI. Des normes comme GENIVI définissent une base commune importante pour des API qui peuvent être utilisées par une large communauté de développeurs. Mais les constructeurs doivent pouvoir innover rapidement et permettre aux architectes, aux concepteurs UX et aux développeurs, de travailler sur différentes sections de la base de code sans générer de conflit. Et ils doivent être capables de travailler avec leurs fournisseurs de rang 1, afin d’optimiser le potentiel de collaboration. L’abstraction architecturale est un élément essentiel pour répondre à cela.

La première exigence est une couche logicielle bas niveau permettant au même code source d’être exécuté sur plusieurs plateformes cibles. Cela garantit que le code source (ou basecode) puisse tourner sur les différentes générations et les différents modèles de véhicules. Mais il existe aussi un besoin de différenciation entre familles de produits, pour offrir l’expérience du luxe avec certains modèles, et un ensemble plus basique de fonctionnalités avec des modèles plus économiques.

Il y a encore une autre considération. Bien que la plupart des systèmes d’info-divertissement que les constructeurs automobiles souhaitent introduire n’aient aucune incidence directe sur la sécurité des véhicules, les développeurs ne peuvent pas ignorer les exigences ISO26262. La norme exige que les modifications apportées aux systèmes liés à la sécurité soient documentées et justifiées clairement avec des études de sécurité. Par conséquent, il est essentiel qu’une séparation claire soit faite entre les systèmes servant à la conduite et ceux destinés à l’info-divertissement, de sorte que les petites et fréquentes modifications apportées, ne perturbent pas l’architecture logicielle de systèmes critiques. Sans une architecture logicielle appropriée, il est difficile de garantir cela.

Le mode de conception MVC (Model-View-Controller, ou Modèle-Visualisation-Contrôleur) permet de donner, aussi bien aux concepteurs UX qu’aux développeurs, le contrôle de leurs zones respectives, et d’expérimenter, de tester et d’améliorer plus facilement certaines approches originales. L’approche MVC divise l’application en trois parties, interconnectées par des API. La partie Modèle gère les données et les règles de l’application noyau. La partie Visualisation construit les éléments d’interface utilisateur, et rapporte les interactions utilisateur au contrôleur. A son tour, la partie Contrôleur interprète les gestes et les requêtes utilisateur, et les convertit en commandes que le modèle peut appliquer à sa logique interne.

La séparation des fonctions dans MVC permet d’utiliser le même noyau logique pour piloter différents types d’interface utilisateur, afin de supporter les besoins de différents types d’application IVI. De cette façon, la même logique de commande de noyau peut fonctionner avec des interactions vocales ou de type GUI (Graphical User Interface, ou interface utilisateur graphique), par exemple. Cela permet également à différents éléments UI (User Interface, ou interface utilisateur) de servir à différents modèles de véhicule, sans avoir à changer le code sous-jacent.

Un modèle de programmation déclaratif pour les composants de visualisation, associé à une approche basée sur les langages de balisage offre encore plus de souplesse. Basé sur le très répandu Javascript, QML est un langage de balisage conçu pour supporter le développement facile et rapide d’interface. Une action initiée par un geste sur un dispositif donné, peut être initié en déplaçant un curseur de défilement sur un autre. En attachant différentes propriétés aux objets, les développeurs peuvent rapidement tester différentes configurations d’interface, pour s’adapter à l’environnement d’affichage individuel de chaque dispositif cible. À l’inverse de HTML5, QML rend trivial l’interfaçage du langage déclaratif au noyau C++ du code de commande, et permet ainsi de conserver la performance native.

Grâce à sa structure à base de Javascript, QML permet aux développeurs d’incorporer des bibliothèques tierce-partie, qui peuvent servir à valider des données d’entrée ou à offrir des services d’interface utilisateur additionnels, comme la reconnaissance vocale. Dans le cas où cela présente un intérêt, QML dispose aussi de puissantes fonctions logiques.

Dans la suite automobile Qt, les bibliothèques QML et C++ qui supportent les interfaces 3D interactives fluides et attrayantes, sont associées à des bibliothèques et supportent plusieurs logiciels et services axés sur l’environnement automobile. Cette suite comprend la plateforme automobile conforme GENIVI développée par Pelagicore, ainsi que l’outil GammaRay de KDAB permettant de déboguer les applications très interactives. L’outil QmlLive permet de mettre à jour en temps réel le code QML dans l’application, pour que les concepteurs puissent évaluer immédiatement l’impact de leurs modifications, et en faire plus souvent, pour produire des designs plus fiables.

Au-delà de la fluidité de l’interface et de l’accès à un large éventail d’applications additionnelles, le sujet sécurité va jouer un rôle majeur dans la définition de l’architecture IVI du futur. Un gestionnaire d’application peut supporter cet accent mis sur la sécurité, la sûreté et la résilience, en permettant la mise en œuvre de politiques au niveau des applications, pour garantir qu’elles ne soient pas en conflit les unes avec les autres, et éviter le risque de fuite de données entre les composants. En rendant un seul composant gestionnaire responsable de la bonne application de la politique, les constructeurs disposent de toute la souplesse nécessaire pour répondre aux évolutions rapides en termes d’innovations UX et de demandes du marché, tout en continuant à livrer des systèmes conformes aux plus grandes normes de sécurité.

Grâce à ces composants et outils, la suite automobile Qt permet aux constructeurs automobiles de fournir un meilleur logiciel beaucoup plus vite qu’auparavant, et qui réponde aux multiples besoins concurrents qu’ils doivent désormais satisfaire au sein des IVI actuels et à venir.