Telemachus standard télématique : un format ouvert pour les données véhicules

Telemachus standard télématique : un format ouvert pour unifier les données véhicules. Inspiré de GTFS, il améliore la recherche, l’assurance et la mobilité intelligente.

Introduction : pourquoi un nouveau standard télématique est nécessaire

Les véhicules connectés génèrent une masse croissante de données : GPS, vitesse, freinages, consommation, diagnostics embarqués… Pourtant, la télématique reste fragmentée. Chaque fournisseur propose ses propres formats, ses API, ses conventions de nommage.

👉 Conséquence :

• Les chercheurs peinent à comparer les résultats, faute de reproductibilité.
• Les data scientists passent plus de temps à nettoyer les données qu’à les analyser.
• Les industriels restent enfermés dans des solutions propriétaires coûteuses et difficiles à interconnecter.

Par conséquent, une évidence s’impose : il faut un langage commun de la télématique.

C’est la mission de Telemachus standard télématique, une spécification ouverte qui vise à devenir pour la télématique ce que
GTFS a été pour les transports publics.

État de l’art : formats existants et leurs limites

1. Les formats propriétaires des plateformes télématiques

Chaque acteur définit son propre format. On retrouve des exports en CSV, JSON ou XML, mais toujours différents dans leur structure, leurs unités, leurs fréquences.

Ainsi :

• La vitesse peut être exprimée en km/h, m/s ou mph, sans métadonnée claire.
• Les événements (freinage, accélération) sont codés de manière hétérogène.
• La fréquence d’échantillonnage varie de 1 Hz à 10 secondes, rendant toute comparaison difficile.

2. Les formats de référence en mobilité

De plus, plusieurs formats sont utilisés en mobilité :

• GTFS : a révolutionné le transport public, mais ne couvre pas la télématique véhicule individuelle.
• MDS (Mobility Data Specification) : orienté micro-mobilité (trottinettes, vélos), mais limité.
• NDS (Navigation Data Standard) : centré sur la cartographie, sans granularité inertielle.

3. Les approches académiques

En effet, les chercheurs publient leurs données en CSV ou Parquet, mais chaque dataset est structuré différemment. Impossible de bâtir un corpus commun reproductible.

👉 En résumé : beaucoup de formats, aucun pivot.

Panorama des sources actuelles : une dispersion problématique

Au-delà des formats de référence (GTFS, MDS, NDS), il existe aujourd’hui une grande diversité de sources télématiques, chacune avec ses contraintes et formats. Cette dispersion rend l’intégration complexe et justifie la nécessité d’un pivot comme Telemachus standard télématique.

1. Les plateformes SaaS B2B

Des acteurs comme Geotab, Verizon Connect, Samsara ou Fleet Complete proposent des solutions complètes de gestion de flotte.

Les données sont accessibles via des API JSON/REST propriétaires, avec des schémas spécifiques à chaque fournisseur.

Les informations sont souvent limitées à des événements (démarrage, arrêt, freinage brusque), avec peu ou pas de granularité inertielle.

👉 Problème : l’interopérabilité entre fournisseurs est quasi inexistante.

2. Les OEM (constructeurs automobiles)

Les constructeurs (BMW, Stellantis, Mercedes, etc.) proposent leurs propres portails connectés.

Chaque marque définit ses variables (vitesse, consommation, diagnostic OBD-II) et son format.

L’accès est généralement restreint et soumis à certification.

👉 Problème : une absence d’harmonisation entre marques et un verrouillage fournisseur.

3. Les boîtiers télématiques “bruts” (Teltonika, Queclink…)

De nombreux opérateurs déploient des boîtiers OBD-II ou AVL comme Teltonika ou Queclink.

Ces équipements génèrent des trames binaires riches (GNSS, parfois IMU intégrée), mais au format propriétaire.

👉 Problème : un travail d’ingénierie lourd est nécessaire pour parser, interpréter et normaliser les données.

4. Les plateformes cloud

Des solutions comme AWS IoT FleetWise, Azure IoT Hub ou Google Cloud Mobility offrent des pipelines de collecte et d’analyse.

Cependant, elles laissent les clients définir leurs propres schémas JSON, sans standard global.

👉 Problème : une hétérogénéité persistante, simplement déplacée dans le cloud.

En résumé, la dispersion des sources SaaS B2B, OEM et boîtiers bruts démontre qu’il est urgent de converger vers un
standard unique et extensible : c’est précisément la vocation de Telemachus standard télématique.

Telemachus : la philosophie d’un format pivot

Telemachus s’inspire du succès du GTFS : créer une spécification ouverte, simple mais extensible, adoptable par tous.

Principes fondamentaux

1. Un format standardisé : une base commune décrivant trajectoire et contexte.
2. Extensible : modules complémentaires (ex. Fleet Premium pour les flottes).
3. Interopérable : facilite le passage d’un fournisseur à l’autre.
4. Ouvert et documenté : hébergé publiquement, versionné, utilisable par chercheurs et industriels.

Structure des données

Le cœur de Telemachus repose sur :

• Un fichier dataset.yaml décrivant le jeu de données (métadonnées, fréquence, capteurs).
• Des tables normalisées : trajectory, imu, events, context.
• Un modèle clair de timestamps unifiés, pour fusionner GNSS, IMU, météo, typologie routière.

L’importance de l’IMU

L’une des grandes innovations de Telemachus est de placer l’IMU (accéléromètres, gyroscopes) au cœur de la spécification.

Pourquoi ?

• Les capteurs GNSS seuls ne disent rien de l’inertie réelle du véhicule.
• L’IMU capture les micro-événements : freinage brusque, dos d’âne, virage serré.
• Couplée au GPS, elle permet une reconstruction fine et exploitable des trajets.

👉 Telemachus considère donc l’IMU comme pilier fondateur du format.

La continuité avec RoadSimulator3

RoadSimulator3 (RS3) avait pour ambition de simuler des trajets véhicules réalistes :

• Trajectoires GPS à 10 Hz
• Inertie (accélérations, freinages)
• Topographie et météo
• Gyroscope et bruit stochastique

Avec RS3, il est devenu possible de produire des jeux de données synthétiques complets.

Mais restait une question : comment les stocker et les partager dans un format exploitable universellement ?

👉 Telemachus est la réponse naturelle.

Il fournit le conteneur standard qui permet de diffuser, comparer et réutiliser les données RS3 — mais aussi les données réelles issues de flottes.

En clair :

• RS3 = laboratoire de génération et validation.
• Telemachus = standard d’échange et d’exploitation.

Bénéfices pour les data scientists

Avec Telemachus, un data scientist peut :

• Charger un dataset dans pandas ou Spark sans passer des heures à mapper les colonnes.
• Comparer des trajets de différentes sources car le schéma est homogène.
• Fusionner simulation (RS3) et réel (flotte) dans un même pipeline.
• Appliquer directement ses modèles de ML/IA sans réécriture fastidieuse.

👉 Résultat : plus de temps pour la science, moins pour le nettoyage.

Cas d’usage

• Assurance : détection de comportements à risque calibrée par inertie + météo.
• Smart city : référentiels de virages dangereux, zones de surconsommation énergétique.
• Constructeurs automobiles : validation d’ADAS et conduite autonome sur datasets reproductibles.
• Chercheurs : publications comparables et réplicables grâce à un format ouvert.

Conclusion

En combinant GNSS, IMU et événements de conduite, Telemachus devient la pierre angulaire de la télématique ouverte. Ce format pivot rapproche recherche, industrie et mobilité durable, tout en assurant transparence et interopérabilité.

---

Références

• Telemachus Specification
• GTFS (Google Transit Feed Specification)
• MDS (Mobility Data Specification, LADOT)
• NDS (Navigation Data Standard)

👉 À lire aussi :
– RoadSimulator3 : simulateur inertiel 10 Hz
– Telemachus v0.2 – Structurer le standard ouvert de la donnée mobilité
– Détection d’événements de conduite par IMU embarquée