Toutes ces impulsions ont également une énorme influence sur la manière dont les automobiles sont conçues. Dans les véhicules modernes, les systèmes d’assistance à la conduite et les services en ligne à valeur ajoutée sont de plus en plus performants, l’électronique embarquée, les capteurs de bord et les systèmes de bus sont de plus en plus complexes et collectent de plus en plus de données. Il s’agit d’évaluer intelligemment ces données lors des essais de conduite afin de répondre aux exigences de qualité les plus élevées lors de la production en série ultérieure. Chez Mercedes-Benz AG également – qui se concentre sur les services et le développement, la production et la vente de voitures et de monospaces – les systèmes existants ont atteint leurs limites pour collecter les données des essais routiers.
Mercedes-Benz se dote ainsi d’une plateforme révolutionnaire et évolutive qui accélère considérablement le travail des ingénieurs de développement et permet d’accélérer les délais de mise sur le marché. Les ingénieurs des sites de développement ont désormais accès aux données de mesure en quelques heures. D’une part, vous pouvez travailler immédiatement avec les résultats de mesure, d’autre part, vous pouvez identifier directement les erreurs et ainsi déclencher un nouveau test. Ils sont ainsi plus proches des tests et les cycles de développement sont plus courts. La nouvelle solution présente encore un autre avantage : il n’est plus nécessaire de planifier la mesure de manière détaillée ou de fixer des objectifs précis pour les données de mesure à saisir. Les ingénieurs ont accès à tout moment à l’ensemble des données de mesure et peuvent également les évaluer ultérieurement en fonction de questions spécifiques.
Cela crée des avantages concrets en termes de coûts et contribue à la protection de l’environnement. Le nombre de tests diminue, les essais deviennent plus efficaces – et permettent désormais de prendre des décisions guidées par les données, ce qui n’était possible auparavant qu’au prix d’un immense effort et d’un délai beaucoup plus long. Les ingénieurs peuvent continuer à utiliser les systèmes auxquels ils sont familiarisés et, en outre, utiliser différents outils de la communauté Big Data, car l’API intégrée permet un couplage simple avec BDSP. Mais l’API offre encore un autre avantage : elle permet désormais de réaliser des évaluations sur l’utilisation réelle des données collectées. L’introduction de la nouvelle architecture facilite en outre la collaboration avec les fournisseurs et le contrôle des données pour les constructeurs automobiles. En effet, jusqu’à présent, les fournisseurs recevaient les données brutes pour leurs analyses et renvoyaient leurs analyses finales à l’Original Equipment Manufacturer (OEM). Il est désormais possible pour les fournisseurs de traiter ces analyses directement sur le système du constructeur automobile, de sorte que les données brutes ne doivent plus quitter l’entreprise.
Il est désormais possible de prendre des décisions guidées par les données, ce qui n’était possible auparavant qu’au prix d’un effort plus important et d’un délai beaucoup plus long.
L’une des étapes clés du développement des véhicules est la réalisation de tests d’endurance. Pour ce faire, les ingénieurs des départements de développement donnent des instructions concrètes sur les données à collecter. Les constructeurs automobiles envoient simultanément une multitude de prototypes de nouveaux modèles sur différentes pistes d’essai – dans le désert comme dans les glaces éternelles – afin d’examiner à la loupe leur comportement pendant les trois-huit. Ces véhicules fabriqués à la main contiennent entre autres une vaste technique de mesure qui enregistre le comportement des différents composants (y compris le logiciel) pendant les tests d’endurance. Au cours d’une équipe, environ 10 à 100 Go de données sont générés dans les formats de données les plus divers. Une fois le test terminé, ces données sont transférées de la voiture vers un système d’entrepôt de données et de gestion des données de mesure. Les ingénieurs des sites de développement reçoivent les données brutes via des partages de fichiers et les copient sur des systèmes de fichiers locaux. Cette procédure entraîne non seulement une redondance importante des données, mais aussi une perte de temps considérable : il arrive que plusieurs jours s’écoulent avant que les ingénieurs aient accès aux résultats des mesures. Si des erreurs sont alors constatées, les voitures et les conducteurs sont déjà partis ailleurs. La reproduction des tests devient alors extrêmement complexe et coûteuse. La situation s’aggrave avec les développements actuels vers la conduite électrique et automatisée, qui font augmenter les quantités de données collectées dans le domaine du TB. Afin de réduire à l’avenir le temps de mise à disposition des données, T-Systems a développé une nouvelle procédure.
T-Systems convainc les clients avec une solution performante de bout en bout, qui optimise l’ensemble du processus et permet l’utilisation des données « as a service ». Les composants clés de la solution sont des ressources de calcul en périphérie, une plateforme cloud centrale, le logiciel Big Data Signal Processing compatible avec Hadoop/Spark et le système Federated Spark basé sur ce logiciel. Après chaque trajet d’essai, les données de mesure (signaux) sont transférées via WLAN sur des Big Data Cluster. Ceux-ci se trouvent sur les ressources informatiques de périphérie installées en permanence sur les sites de test. Ils sont gérées et exploitées par T-Systems. Le Big Data Signal Processing (BDSP) est également installé sur les systèmes sur site. BDSP traite préalablement les données de mesure, c’est-à-dire que les différents formats de données collectées sont transcodés dans des formats de données Big Data courants.
Il est ainsi possible d’obtenir un traitement jusqu’à 40 fois plus rapide pour le décodage et l’analyse ultérieure qu’avec des outils conventionnels. En effet, BDSP permet d’interpréter en parallèle les résultats de mesure saisis dans des fichiers de trace distribués, binaires ou textuels. Dans la pratique, la taille des données est réduite jusqu’à 90 %. BDSP prend également en charge le rééchantillonnage et le marquage des signaux et dispose d’une API qui permet la connexion à d’autres systèmes. La partie Edge de la solution est complétée par un cloud central avec un système Federated Spark. Ce système permet aux ingénieurs d’accéder aux données de mesure, quel que soit l’endroit où elles se trouvent. Le système Federated Spark identifie automatiquement les données pour les développeurs. Les développeurs ne se contentent pas de trouver les données adéquates, ils déclenchent également les analyses correspondantes sur les serveurs Edge via le cloud. Cela signifie que seules les instructions et les résultats doivent être transférés entre les sites de test et les postes de travail des développeurs, et non plus les ensembles complets de données brutes. Il n’est donc pas nécessaire de procéder à une extension coûteuse du réseau MPLS.
Les données de mesure sont déjà cryptées dans le véhicule et restent à tout moment hautement cryptées et sécurisées. Cela vaut également pour les couches de transport, y compris les protocoles de transport entre le véhicule et les ressources Edge, ainsi que pour les accès aux réseaux.
