Auteur/autrice : Seb

Data Space : le problème n’est pas la donnée, mais la responsabilité
Data Space : le problème n’est pas la donnée, mais la responsabilité

Depuis plusieurs années, les organisations investissent massivement dans la donnée :
collecte, stockage, pipelines, plateformes, IA.

Sur le papier, tout est là.

Et pourtant, à mesure que les systèmes deviennent distribués, interconnectés et multi‑acteurs,
une faille structurelle apparaît.

👉 Le problème n’est plus la donnée.
👉 Le problème est la responsabilité sur la réalité mesurée.

Une abondance de données… sans responsabilité claire

Dans la mobilité comme ailleurs, nous savons mesurer :
– des trajectoires GNSS,
– des signaux inertiels (IMU),
– des événements de conduite,
– des états véhicules,
– des logs applicatifs.

La chaîne technique est maîtrisée.

Mais dès que la donnée :
– sort d’une organisation,
– traverse plusieurs systèmes,
– alimente des décisions partagées,

la question centrale n’est presque jamais posée :

Qui est responsable de ce qui est censé représenter la réalité ?

Données fragmentées, réalités reconstruites

Dans la majorité des architectures actuelles :
– chaque acteur possède une partie de la donnée,
– chacun reconstruit sa version de la réalité,
– personne n’assume la réalité collective.

On partage des flux.
On échange des fichiers.
On expose des API.

Mais on ne partage ni :
– la preuve,
– la traçabilité complète,
– la capacité d’audit transverse.

👉 La donnée circule, mais la responsabilité se dissout.

Quand l’IA amplifie le problème

Ce vide de responsabilité devient critique avec l’IA.

Les modèles sont entraînés sur :
– des données reconstruites,
– des réalités partielles,
– des contextes mal définis.

Les résultats peuvent être impressionnants…
sans que personne ne soit capable d’affirmer :
- ce qui a réellement été mesuré,
- dans quelles conditions,
- avec quelles limites,
- et sous quelle responsabilité.
On parle alors de performance,
mais plus de vérité opérationnelle.

Ce que les Data Spaces tentent réellement d’adresser

Contrairement à une idée répandue,
un Data Space ne promet pas « plus de données » ni « de meilleures plateformes ».

Il tente de répondre à une question beaucoup plus fondamentale :

Comment plusieurs acteurs peuvent-ils partager une même réalité mesurée,
sans en perdre le contrôle, la traçabilité et la responsabilité ?

Cela implique :
– des règles explicites de gouvernance,
– des mécanismes de contrôle et d’audit,
– une clarification des rôles et des engagements,
– une donnée traitée comme un fait engageant, pas comme une simple ressource exploitable.

C’est un changement de cadre.
Pas un ajout technologique.

Un sujet stratégique avant d’être technique

Tant que la donnée est cantonnée à un périmètre interne,
les approximations restent gérables.

Mais dès qu’elle devient :
– inter‑organisationnelle,
– réglementée,
– utilisée pour piloter des systèmes physiques ou automatisés,

la question de la responsabilité devient centrale.

👉 Les Data Spaces ne sont pas une mode.
👉 Ils sont le symptôme d’un manque structurel dans nos architectures actuelles.

Question ouverte

Sommes‑nous prêts à traiter la donnée comme un fait engageant,
au même titre qu’un contrat, un acte ou une mesure officielle ?

Ou continuerons‑nous à empiler des systèmes performants…
reposant sur des réalités que plus personne n’assume pleinement ?

Ce billet s’inscrit dans une série consacrée aux Data Spaces, à la gouvernance des données et à la mobilité.
Il prolonge l’article LinkedIn L038 et le billet de cadrage B020.
2026-01-27
Data Space & DataMobility : le point de rupture quand la donnée sort de l’organisation
En data space mobilité, la donnée n’est plus un problème de capteurs ou d’algorithmes. Le vrai problème commence quand on veut la partager : contrôle, responsabilité, souveraineté, traçabilité. C’est précisément là que le concept de Data Space devient nécessaire — non pas comme une “plateforme”, mais comme un cadre de partage gouverné.

Nature de ce billet (position paper)

Ce billet ne présente pas un résultat expérimental ni une revue systématique de la littérature.

Il s’agit d’un position paper au sens académique du terme : une prise de position argumentée, fondée sur des travaux antérieurs (RS3, Telemachus), des retours terrain et une analyse critique des limites des modèles actuels de partage de données.

L’objectif est de poser un cadre d’interprétation — non de proposer une implémentation complète ni une solution clé en main.

Quand la donnée de mobilité sort de l’organisation

Pourquoi le Data Space devient nécessaire

Dans cet article, je propose une lecture data space mobilité issue d’un retour d’expérience “du signal au standard” : qualité GNSS/IMU, enrichissement (pente, contexte), puis interopérabilité. Pour le contexte technique, voir mes billets sur le 10 Hz (RS3) : https://roadsimulator3.fr/ et sur la pente/altitude : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/. Côté standardisation, voir Telemachus : https://github.com/telemachus3/telemachus-spec.

La donnée de mobilité n’est plus une promesse.

Les signaux existent (GNSS, IMU, événements). Les pipelines existent (correction, enrichissement, contextualisation). Et des efforts de standardisation existent.

Et pourtant, la valeur reste difficile à produire durablement.

Pourquoi ? Parce que le vrai problème commence au moment où la donnée sort de l’organisation qui l’a produite.

Ressources associées (internes) :
– RS3 — signaux 10 Hz & télématique (blog) : https://roadsimulator3.fr/
– RS3 — service robuste de pente/altitude 10 Hz : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/

Ressources associées (externes) :
– International Data Spaces Association (IDSA) : https://internationaldataspaces.org/
– Data Spaces Support Centre (DSSC) : https://dssc.eu/
– Telemachus Spec (interopérabilité mobilité) : https://github.com/telemachus3/telemachus-spec

1) La donnée de mobilité existe déjà (ce point est acquis)

Aujourd’hui, un véhicule (ou un smartphone) produit en continu :
– des positions GNSS,
– des vitesses et capteurs inertiels (IMU),
– des signaux dérivés (accélérations, yaw rate…),
– des événements (freinage, virage, stop, congestion),
– du contexte (route, pente, météo, densité urbaine…).

Ces données peuvent être :
– corrigées (qualité du GNSS, synchronisation),
– enrichies (pente, géométrie, carte),
– structurées (schémas, champs normalisés),
– qualifiées (métadonnées, qualité, provenance).

👉 Autrement dit : on sait transformer un signal brut en information exploitable.

Le sujet n’est donc plus “peut-on produire de la donnée ?” ni même “peut-on l’analyser ?”.

Le sujet devient : peut-on la partager correctement, dans la durée, entre acteurs différents ?

2) Le moment de rupture : quand la donnée circule

Data space mobilité : les questions qui deviennent non-négociables

La donnée de mobilité ne reste jamais longtemps “chez elle”. Elle circule, tôt ou tard, entre :
– flottes et donneurs d’ordre,
– opérateurs et territoires,
– assureurs et gestionnaires de risque,
– industriels, chercheurs, autorités.

C’est à ce moment-là que les questions deviennent difficiles :
- Qui garde la maîtrise de la donnée ?
- Qui décide des usages autorisés ?
- Que devient la responsabilité si la donnée est réutilisée, agrégée, ou “dérivée” ?
- Comment éviter la captation de valeur par un acteur central (plateforme, intégrateur, marketplace) ?
- Comment garantir la traçabilité (qui a eu quoi, quand, pour quel usage) ?
👉 Ce ne sont pas des questions “data engineering”.
Ce sont des questions de gouvernance.

3) Pourquoi les modèles classiques montrent leurs limites

Quand on arrive à ce point, les réponses habituelles reviennent souvent :
- “On va exposer une API.”
- “On va créer une plateforme.”
- “On va passer par une marketplace.”
Ces approches peuvent fonctionner… jusqu’à un certain point.
- Une API permet d’accéder à une donnée, mais ne définit pas les règles d’usage.
- Une plateforme centralise, mais déplace le pouvoir (et souvent la valeur).
- Une marketplace facilite la transaction, mais ne garantit ni souveraineté ni traçabilité sur la durée.
En mobilité, où les acteurs sont multiples et les données sensibles (personnes, lieux, habitudes, risques), ces modèles atteignent rapidement leurs limites.

4) Ce que le Data Space apporte réellement (sans jargon)

Un Data Space n’est pas :
– une “plateforme de plus”,
– un produit clé en main,
– une technologie miracle.

Un Data Space est un cadre de partage de données gouverné, où :
– les données peuvent rester chez leurs producteurs,
– les règles d’accès et d’usage sont explicites,
– la traçabilité est native,
– la souveraineté est préservée,
– la valeur peut être partagée sans confiscation.

👉 Le Data Space ne remplace pas les briques techniques existantes.
Il les encadre.

La question à laquelle il répond est simple :

Comment partager des données entre organisations sans perdre le contrôle ?

5) Pourquoi la mobilité est un cas d’école

La mobilité concentre pratiquement toutes les difficultés du partage de données :
- production distribuée (chaque véhicule est une source),
- valeur construite progressivement (du brut au contexte, puis aux indicateurs),
- usages multiples et parfois concurrents,
- forte dépendance territoriale,
- enjeux réglementaires, assurantiels, sociaux.
Si un cadre de partage gouverné fonctionne pour la mobilité, il devient transposable à de nombreux autres secteurs.

👉 La mobilité n’est pas un cas particulier : c’est un révélateur.

6) Conclusion : la suite logique

Après :
– la donnée brute,
– l’ingénierie des signaux,
– la structuration et la standardisation,

le prochain défi est clair :

organiser le partage de la donnée de mobilité dans la durée.

Le Data Space n’est pas une rupture.
C’est la suite logique d’un travail déjà engagé sur la qualité, la structure et la gouvernance des données.

Limites et non-objectifs de ce billet

Dans une démarche volontairement rigoureuse, il est important de préciser ce que ce billet ne cherche pas à faire :
- il ne propose pas une implémentation technique complète d’un Data Space,
- il ne compare pas formellement les initiatives institutionnelles existantes,
- il ne définit pas un modèle économique ou contractuel,
- il ne prétend pas couvrir l’ensemble de la littérature académique sur les Data Spaces.
Son rôle est plus modeste — et plus fondamental :
identifier le point de rupture conceptuel à partir duquel la donnée de mobilité cesse d’être un simple objet technique pour devenir un objet de gouvernance.

À suivre

Dans les prochains billets, je traiterai :
– les faux amis du Data Space (API, marketplace, DDS, data mesh…),
– une architecture cible Data Space appliquée à la mobilité (sans marque, sans produit),
– et les erreurs classiques à éviter quand on confond plateforme et gouvernance.
2026-01-14

Virtual sensing énergie : revue de Cellina et al. (2023) & perspectives RS3/Telemachus

Virtual sensing énergie est une approche permettant d’estimer la consommation d’un véhicule à partir de signaux GNSS et IMU, sans accès direct au bus CAN. Cette page présente une revue détaillée de Cellina et al. (2023) et explique comment étendre cette méthode dans RoadSimulator3 et Telemachus.

Virtual sensing GNSS/IMU : revue de Cellina et al. (2023) et perspectives industrielles

Le virtual sensing énergie permet de mesurer la consommation sans accès CAN en utilisant uniquement vitesse et accélération issues du GNSS/IMU.

Ressources associées :
– Article RS3 sur la pente & énergie : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/
– Documentation Telemachus : https://github.com/telemachus3/telemachus-spec
– Publication originale (Cellina 2023) : https://arxiv.org/abs/2310.01230

🎯 1. Contexte : mesurer la consommation… sans accéder au véhicule

L’article part d’un constat clair :

Les véhicules thermiques resteront longtemps en circulation.
Les solutions embarquées (OBD, télématique constructeur) sont hétérogènes et non standardisées.
Un estimateur universel, basé sur des signaux GNSS + IMU, serait :
non intrusif,
compatible smartphone,
applicable à n’importe quel véhicule,
exploitable pour l’assurance, la mobilité, les inventaires carbone.

Objectif : estimer la consommation instantanée et cumulée avec uniquement :
– vitesse longitudinale v(t),
– accélération longitudinale a(t).

Ces signaux proviennent :
– d’un GNSS 10 Hz,
– d’une IMU 100 Hz (accélérations brutes).

🚗 2. Protocole expérimental (véhicule réel + capteurs low-cost)

Schéma du protocole expérimental GNSS/IMU utilisé pour le virtual sensing énergie

L’article repose sur une expérimentation robuste :

Véhicule : Alfa Romeo Giulia diesel 2.2L, boîte auto 7 rapports.
Vérité terrain : fuel flow issu du CAN (20 Hz, résolution 0,001 L/h).
Capteurs externes :
Suchy XPro Nano 10,
GNSS 10 Hz + IMU 100 Hz montés rigidement sous le siège passager.

Dataset :
– 1493 km,
– 20 h de conduite,
– saisons été + hiver,
– 1 à 4 passagers (tableau p.3 du PDF).

Pré-traitements appliqués :
– synchronisation à 10 Hz,
– filtrage passe-bas à 3 Hz (zéro phase),
– spline cubique pour recaler les signaux IMU/CAN sur l’horodatage GNSS.

Modèles utilisés en virtual sensing énergie : PB, NN et VT-MICRO

📦 3. Trois classes de modèles comparés

3.1. VT-MICRO (référence historique, 32 paramètres)

Modèle polynômial (3e ordre) séparé pour a≥0 et a<0.
Limites connues :
– comportement instable hors domaine d’entraînement,
– ne supporte pas f=0 (ralenti, coupure d’injection),
– forte sensibilité au bruit.

3.2. Modèle Physics-Based (PB)

Les auteurs dérivent une simplification du modèle longitudinal :

f = k · ( m · a · v + α · v + β · v² + γ · v³ )

Le modèle final possède 4 paramètres seulement.
Il force naturellement f≥0.

Avantages :
– interprétable,
– robuste,
– très bon sur les intégrales de consommation.

3.3. Neural Network (NN)

Architecture :
– input : (v, a),
– 1 couche cachée (9 neurones),
– LBFGS + régularisation + multi-initialisations.

C’est la méthode la plus performante sur l’instantané.

📊 4. Résultats : qui gagne ?

Modèle	Testing Error (instantané)	Integral Error (trajet)	Error Over Tank (robustesse)
VT-MICRO	médiocre	fort biais	forte variance
PB	légèrement moins bon que NN	⭐ Meilleur (≈ 0 %)	⭐ Meilleur
NN	⭐ Meilleur (écart-type −20 %)	bonne performance mais léger biais négatif	correct

Synthèse

Instantané : NN > PB >> VT-MICRO
Cumulé : PB > NN > VT-MICRO
Robustesse “Error over Tank” : PB très largement en tête.

Le modèle PB, pourtant simple, domine toutes les métriques cumulées, ce qui en fait un candidat idéal pour un système embarqué ou smartphone.

🛑 5. Cas particulier : véhicule arrêté (“stopped car”)

Problème :
Lorsque v=0, le modèle statique ne peut pas distinguer :
– moteur éteint → consommation nulle,
– moteur allumé (ralenti) → consommation idle.

L’article propose une solution innovante :

🔍 Analyse fréquentielle du signal IMU (100 Hz)

Observation (Figure 7 p.5) :
– moteur au ralenti → pics à 13,3 Hz et 26,6 Hz,
– moteur coupé → spectre beaucoup plus plat.

Un simple classifieur sur le pic à 26,6 Hz donne :
– 92 % TPR,
– 92 % PPV.

Limites :
– dépend de la position de l’IMU,
– dépend du véhicule → peu généralisable.

🧭 6. Discussion critique

✔️ Forces de l’article

Méthodologie reproductible à partir de signaux simples.
Dataset riche (≈1500 km).
Comparaison honnête avec l’état de l’art.
Résultats solides : erreurs cumulées <1 %.
Orientation pratique : modèles embarquables.

⚠️ Limites

Un seul véhicule (diesel).
Entraînement effectué sur le même véhicule → pas de test “cross-vehicle”.
Pas de prise en compte explicite :
de la pente réelle (θ),
de la densité d’air (météo),
du style conducteur (agressivité inertielle),
des effets latéraux (virages / courbure).

Or ces informations existent dans RS3 + Telemachus.

⚙️ 6.1. Conditions pratiques d’utilisation : ce qu’il faut (vraiment) pour appliquer le virtual sensing énergie

L’article de Cellina et al. (2023) est particulièrement clair sur les prérequis indispensables pour obtenir une estimation énergétique fiable à partir des signaux GNSS/IMU.
Ces éléments sont souvent implicites dans la littérature ; ils sont rappelés ici pour toute tentative de reproduction ou d’intégration dans un système réel.

1. Fréquences minimales des capteurs

GNSS ≥ 5–10 Hz : nécessaire pour reconstruire correctement la vitesse v(t) sans dérive ni aliasing.
IMU ≥ 50–100 Hz : indispensable pour filtrer l’accélération longitudinale, détecter les vibrations moteur (13–26 Hz) et garantir la stabilité du modèle PB.

En deçà :
– GNSS 1 Hz → trop bruité pour dériver une énergie instantanée fiable.
– IMU < 20–30 Hz → perte totale des signaux fréquentiels permettant la détection moteur ON/OFF.

2. Pas besoin d’accès CAN ni d’abaque constructeur

Le modèle PB ne nécessite ni couple moteur, ni débit d’injection, ni tables constructeur.
Il repose uniquement sur :
– v(t),
– a(t),
– m (masse du véhicule),
– et 4 paramètres physiques (α, β, γ, k) calibrés sur quelques trajets.

Cela rend l’approche :
– non propriétaire,
– compatible smartphone,
– reproductible avec des capteurs low-cost.

3. Un modèle spécifique au véhicule

Le modèle PB doit être recalibré pour chaque véhicule.
L’article ne traite pas encore la généralisation inter-véhicules :
→ une Giulia diesel et un SUV essence n’auraient pas les mêmes paramètres α, β, γ, k.

4. Importance de la qualité GNSS

Les auteurs filtrent v(t) via :
– interpolation spline,
– filtre passe-bas 3 Hz,
– synchronisation stricte 10 Hz.

Des coupures GNSS ou un bruit élevé dégradent fortement l’estimation énergétique instantanée.

5. Limitations actuelles (hors périmètre de l’article)

Le modèle ne prend pas encore en compte :
– la pente réelle (θ),
– la température / densité d’air,
– la charge du véhicule,
– le style conducteur,
– la courbure routière,
– les conditions GNSS dégradées.

Ces dimensions sont critiques pour une industrialisation large, mais elles constituent précisément les axes où RS3 × Telemachus peuvent apporter une valeur unique.

🔬 7. Perspectives RS3 × Telemachus

1. Intégration dans RS3 : un banc d’essai idéal

Scénarios GNSS-denied,
Inerties contrôlées,
Pente + météo + masse variables.

→ possibilité de tester la robustesse hors distribution, ce que l’article ne couvre pas.

2. Exploitation de la courbure routière (Heuts 2025)

Les travaux récents (Heuts et al. 2025) montrent qu’un lien fort existe entre :
– courbure κ,
– énergie cinétique dissipée,
– consommation.

→ RS3 permet de coupler v, a, κ → modèle hybride plus riche.

3. Standardisation : Telemachus T002 “Energy Events”

Les signaux nécessaires à la réplication du papier sont déjà standardisés :
– speed
– accel_longitudinal
– engine_state (à enrichir via fréquence IMU)
– energy_proxy (proposition)

4. Possibilité d’un modèle unifié pour thermique + électrique

Pour les VE :
– puissance négative (régénération),
– pas de ralenti,
– relation non linéaire entre pédale et énergie.

→ PB et NN peuvent être adaptés.

🚀 8. Que faire maintenant ?

Voici les axes de développement immédiats pour RS3 :

A. Implémenter le modèle PB dans RS3 / telemachus-py

4 paramètres → calibration simple.
Benchmark sur scénarios RS3 générés automatiquement.

B. Enrichir le modèle avec la pente réelle (IGN RGEALTI / SRTM)

Cellina ignore θ, car absorbée dans le bruit de a.
RS3 peut fournir θ exact → meilleure précision.

C. Tester un réseau neuronal plus riche (MLP 2–3 couches)

Avec :
– normalisation temporelle,
– features dérivées : jerk, power proxy, curvature.

D. Construire un dataset public “Telemachus Energy Benchmark”

Données RS3 simulées (pente, météo, passagers),
Données smartphone (iPhone 4S du billet B012).
→ Permettra de tester la généralisation des modèles.

❓ 8.1. FAQ ingénieur — les questions clés pour reproduire le virtual sensing énergie

1. Peut-on utiliser du GNSS 1 Hz comme dans la plupart des smartphones ?

Non. À 1 Hz, la vitesse est trop bruitée et trop lente pour dériver correctement une énergie instantanée.
→ Minimum recommandé : 5–10 Hz.

2. Une IMU 20–30 Hz suffit-elle ?

Non pour la détection moteur ON/OFF (pics à 13–26 Hz).
Partiellement oui pour la reconstruction de a(t).
→ Pour reproduire l’article : IMU ≥ 50–100 Hz.

3. Faut-il connaître les paramètres moteur (couple, rendement, injection) ?

Non. Le modèle PB utilise uniquement v(t), a(t), m et 4 paramètres calibrés.
→ Aucun accès CAN nécessaire.

4. Le modèle PB est-il universel (un seul modèle pour toutes les voitures) ?

Non. Il faut calibrer chaque véhicule.
C’est une des limites majeures du papier.

5. Comment traiter la pente si elle n’est pas fournie dans l’article ?

Cellina absorbe la pente dans le bruit de a(t).
Mais cela crée un biais dans les zones vallonnées.
→ RS3 + Telemachus peuvent fournir θ(t) pour améliorer fortement le modèle.

6. Que se passe-t-il en cas de coupure GNSS ?

Le modèle PB ne peut plus mettre à jour v(t).
→ Simulation RS3 recommandée pour tester robustesse GNSS-denied.

7. Peut-on appliquer cette méthode aux véhicules électriques ?

Partiellement.
Le ralenti n’existe pas, et la régénération doit être modélisée.
→ Adaptation du modèle PB nécessaire.

8. Comment vérifier si mon IMU capte bien les fréquences moteur ?

Faire une FFT sur acc_x ou acc_y au ralenti.
Si les pics à ~13 Hz et ~26 Hz n’apparaissent pas → mauvaise orientation, saturation, ou IMU trop lente.

9. Quelles sont les extensions naturelles pour l’industrie ?

multi-véhicules
prise en compte pente / météo / charge
détection moteur robuste
standardisation des signaux (Telemachus)

🧾 9. Conclusion

L’article de Cellina et al. (2023) est une avancée majeure :
il démontre qu’avec GNSS + IMU, on peut obtenir une estimation énergétique <1% d’erreur sans accès CAN.

Cependant, de nombreuses pistes restent ouvertes :

généralisation multi-véhicules,
prise en compte de la pente,
meilleure détection moteur ON/OFF,
extension aux véhicules électriques,
standardisation des signaux (Telemachus).

RS3 fournit déjà un environnement idéal pour pousser ces travaux plus loin — et ouvrir la voie à une mesure universelle de la consommation / énergie, à partir de données vraiment ouvertes, comparables et reproductibles.

Si ce sujet vous intéresse, un article plus technique (P006) détaillera très prochainement l’intégration de ce modèle dans RS3 × Telemachus.

2025-12-04

Estimation vitesse véhicule IMU smartphone : état de l’art & limites

Objectif

L’objectif de cet article est clair : expliquer l’estimation vitesse véhicule IMU smartphone. Autrement dit, comment estimer la vitesse d’un véhicule uniquement à partir des capteurs inertiels (IMU) d’un smartphone, sans dépendre du GPS. Cette problématique d’estimation vitesse véhicule IMU smartphone est au cœur des recherches actuelles en mobilité numérique. Nous présentons donc l’état de l’art, les limites physiques (dérive, biais capteurs), et le rôle essentiel de RS3 / Telemachus pour tester et valider ces méthodes d’estimation vitesse véhicule IMU smartphone avant déploiement réel.

Contexte

La mesure de vitesse est un élément fondamental des applications de mobilité : navigation, détection d’événements, consommation énergétique ou encore scoring de conduite.
Sur smartphone, cette mesure repose souvent sur les signaux GNSS — mais lorsque ceux-ci sont indisponibles (tunnel, environnement urbain dense), la fusion inertielle devient une alternative.

L’enjeu : déterminer si une IMU seule (accéléromètres + gyroscopes du smartphone) suffit à estimer correctement la vitesse.

Méthodes étudiées

Trois familles d’approches ressortent dans la littérature récente :

Approches analytiques classiques
Intégration des accélérations longitudinales après filtrage du biais gravitationnel.
Nécessite une calibration fine et un repérage stable du véhicule.
Sensible au drift cumulatif.
Approches basées apprentissage
Réseaux neuronaux (LSTM, CNN) entraînés sur des segments GNSS + IMU synchronisés.
Ainsi, ils sont capables de compenser le drift sur des courtes durées, mais nécessitent un jeu de données massif.
En revanche, ils sont peu généralisables entre véhicules et smartphones.
Méthodes hybrides
Utilisation de contraintes cinématiques (vitesse > 0, non-holonomie).
Combinaison apprentissage + modèle physique.

Ces approches cherchent à tirer parti des contraintes physiques (non-holonomie, vitesse positive) pour stabiliser l’estimation.
Formellement, la vitesse longitudinale peut être estimée par :
[
v_t = \int (a_x – g \sin\theta)\,dt
]
où (a_x) est l’accélération longitudinale mesurée, (g) la gravité et (\theta) l’inclinaison estimée.

Approche DVSE (SmartphoneIMUSpeed2025)

L’article DVSE – Deep learning-based Vehicle Speed Estimation (Xiao et al., 2025) propose un cadre d’apprentissage séquentiel supervisé par GNSS pour estimer la vitesse véhicule à partir de l’IMU d’un smartphone.
Le cadre repose sur deux modules principaux :
– Noise Compensation Network (NCN) : un GRU corrige les composantes déterministes et stochastiques du bruit inertiel.
– Motion Transformation Network (MTN) : un réseau convolutionnel temporel aligne le repère du smartphone avec celui du véhicule.

Le modèle est entraîné sur données réelles avec supervision GNSS et atteint une précision de MAE ≈ 2.35 m/s sur 60 secondes d’intégration.
De plus, les auteurs démontrent une robustesse supérieure aux architectures LSTM classiques, notamment grâce à l’augmentation de données (poses aléatoires de smartphone) et à une fonction de perte spécifique compensant les décalages GNSS–IMU.

Données et simulation RS3

Pour comparer ces approches, le simulateur RS3 permet de :
– générer des signaux IMU synthétiques à 10 Hz ;
– introduire des biais réalistes de capteurs ;
– simuler des scénarios urbains avec arrêts, freinages et accélérations.

Les scénarios générés par RS3 permettent une validation systématique des modèles : dérive cumulée, influence des biais capteurs, et sensibilité aux postures de smartphone.
Ainsi, cette approche favorise la reproductibilité scientifique et la calibration inter-modèles dans un cadre ouvert.

Limites observées

Type de méthode	Dérive après 60 s	Sensibilité capteur	Portabilité
Intégration brute	> 20 %	Très élevée	Faible
LSTM (données locales)	≈ 8 %	Moyenne	Moyenne
Hybride contrainte + LSTM	< 5 %	Moyenne	Bonne

Aucune méthode n’élimine totalement la dérive : la fusion GNSS + IMU reste incontournable pour des durées supérieures à 1 min.

Voir les travaux récents sur l’estimation de vitesse véhicule par IMU seule (DVSE, 2025), qui combinent réseau neuronal séquentiel et contraintes physiques pour corriger la dérive sans GNSS.
Pour plus de détails sur le simulateur, consultez la page RS3, simulateur inertiel 10 Hz.

Perspectives

Constituer un dataset IMU-only standardisé par type de smartphone avec RS3.
Normaliser ces données via le format pivot Telemachus.
Explorer la calibration adaptative des capteurs embarqués (apprentissage en ligne).

Liens avec RS3 et Telemachus

Les travaux DVSE ouvrent des perspectives directes pour RS3 et Telemachus :
– RS3 peut générer des jeux de données synthétiques IMU-only pour tester la robustesse du modèle DVSE.
– Telemachus fournit un format pivot pour normaliser ces données et publier les résultats d’entraînement sous forme ouverte.
– RS3 + Telemachus peuvent produire un dataset public pour benchmarker l’« estimation vitesse véhicule IMU smartphone ».
– Ce dataset pourra ensuite servir dans les papiers P004 (GNSS/INS robuste) et P005 (Qualité des données véhicules connectés).

En conclusion, l’estimation vitesse véhicule IMU smartphone représente un défi technique majeur, mais les avancées récentes et les outils comme RS3 et Telemachus ouvrent la voie à des solutions robustes et reproductibles.

2025-10-31

IMUSim : simuler les capteurs inertiels pour mieux comprendre la fusion GNSS/IMU

IMUSim : simuler les capteurs inertiels pour mieux comprendre la fusion GNSS/IMU

L’expression IMUSim simulation inertielle GNSS/IMU désigne un environnement de simulation open-source. Il permet de comprendre la fusion capteurs et de valider les algorithmes RS3 et Telemachus. Ainsi, il constitue un outil clé dans ce domaine.

Schéma simplifié d’une simulation inertielle IMUSim (accéléromètres et gyroscopes virtuels).

Pour valider un algorithme de fusion GNSS/IMU, il faut d’abord disposer de signaux réalistes.
En effet, c’est précisément le rôle d’IMUSim, un environnement de simulation open-source. Il permet de générer des mesures d’accéléromètres et de gyroscopes virtuels.
De plus, c’est une brique essentielle pour comprendre les fondations physiques et statistiques de la fusion inertielle. Elle est utile avant d’aller vers les approches hybrides (MMKF, DVSE) utilisées dans RS3 et Telemachus.

Voir le projet IMUSim sur GitHub

1. IMUSim et la simulation inertielle GNSS/IMU

Développé par Young et al. (2011), IMUSim est un simulateur Python conçu pour la recherche et l’enseignement en traitement de signaux inertiels.
Il permet de :
– modéliser la cinématique d’un objet en 3D (trajectoires, vitesses angulaires) ;
– générer les lectures correspondantes d’un capteur IMU (accéléromètres, gyroscopes, magnétomètres) ;
– injecter des modèles de bruit réalistes, basés sur la variance d’Allan ou des paramètres physiques connus ;
– tester des filtres de Kalman ou des algorithmes d’estimation d’attitude (AHRS).

L’objectif est d’offrir une base cohérente et reproductible pour expérimenter. Ainsi, on peut travailler sans dépendre du matériel physique.

2. Architecture et fonctionnement

IMUSim repose sur une approche orientée simulation. Ainsi, il comprend plusieurs modules :
– un module cinématique gère la dynamique de mouvement (position, vitesse, rotation) ;
– un module de capteur applique un modèle d’erreur IMU, comprenant biais, dérive, marche aléatoire et cross-axis ;
– un moteur de génération temporelle produit des signaux échantillonnés à fréquence configurable (jusqu’à plusieurs centaines de Hz).

Le modèle de bruit IMU repose sur les paramètres caractéristiques (biais, dérive, marche aléatoire angulaire). Ces paramètres sont ajustables via les coefficients Allan.
Formellement, le bruit peut être modélisé comme :
(\omega_m = \omega_t + b + \eta),
où (\omega_m) est la mesure, (b) le biais lentement variable, et (\eta) le bruit blanc gaussien.

Les sorties sont exportables sous forme de fichiers CSV ou Python. En somme, elles sont prêtes à être intégrées dans d’autres environnements (MATLAB, ROS, RS3).

3. Liens avec RS3 et Telemachus

Dans le cadre de RS3 (RoadSimulator3), IMUSim constitue une référence historique. En effet, il a inspiré la logique de simulation inertielle (génération des signaux à 10 Hz, bruit inertiel, topographie).

Les principes d’IMUSim se retrouvent dans plusieurs aspects :
– la chaîne RS3 → Telemachus, où les signaux IMU simulés sont convertis au format pivot ;
– le pipeline de validation Telemachus (RFC-0007, RFC-0009) pour tester les algorithmes de fusion GNSS/IMU ;
– les études sur les erreurs stochastiques et la reproductibilité (C4 VAE).

IMUSim reste un outil de référence pour l’enseignement et la recherche. Il illustre la propagation des erreurs inertiales et leur correction par filtrage. De plus, il s’intègre naturellement dans les workflows modernes RS3 et Telemachus.

Lire aussi : RS3, simulateur inertiel 10 Hz

4. Pourquoi c’est encore pertinent ?

Même si de nouveaux frameworks (DVSE, MMKF) utilisent l’apprentissage profond, la simulation inertielle reste indispensable.
Elle sert à générer des cas extrêmes de mouvement (accélération, virages serrés, vibrations).
De plus, elle permet de valider des algorithmes en conditions contrôlées.
Par ailleurs, elle aide à quantifier la dérive et à calibrer les modèles de bruit.

Les travaux récents de Liu (2023) et Mafi (2025) prolongent cette logique. En effet, ils s’appuient sur les principes de modélisation inertielle d’IMUSim. Toutefois, ils les étendent à des contextes GNSS/IMU hybrides ou appris.

5. En résumé

IMUSim reste un pilier conceptuel dans la recherche en fusion inertielle.
Il est simple, open-source et rigoureusement documenté.
De plus, il est parfait pour comprendre la propagation des erreurs IMU.
C’est un lien direct entre physique, mathématiques et simulation numérique.

IMUSim est plus qu’un simulateur. En effet, c’est la base conceptuelle de la recherche en fusion inertielle. Il lie physique, mathématiques et simulation numérique.
Son héritage perdure dans RS3 et Telemachus. Ces derniers poursuivent cette mission de validation ouverte et reproductible.

En conclusion, IMUSim simulation inertielle GNSS/IMU reste un pilier de la recherche moderne sur la fusion inertielle.

✳️ Références :
– Young, P. et al. (2011) — IMUSim: A Simulation Environment for Inertial Sensing Algorithm Design and Evaluation.
– Liu, H. et al. (2023) — A Comprehensive Review of GNSS/INS Integration.
– Mafi, S. et al. (2025) — Consensus Multi-Model Kalman Filter for Robust Vehicle State Estimation.

2025-10-31

Fusion GNSS/IMU robuste : le filtre à consensus MMKF

Illustration de la fusion GNSS/IMU via le filtre à consensus MMKF

Schéma de fusion GNSS/IMU avec le filtre à consensus MMKF

La fusion GNSS/IMU robuste est essentielle pour les véhicules autonomes et les systèmes de navigation avancés, qui nécessitent une estimation d’état fiable — position, vitesse, orientation — malgré la présence de bruit, de coupures GNSS ou d’environnements urbains complexes. La fusion GNSS/IMU permet ainsi d’obtenir des trajectoires précises et fiables.
Dans ce contexte, le Consensus Multi-Model Kalman Filter (MMKF) propose une approche hybride, à mi-chemin entre le modèle physique et les modèles data-driven.

1. Pourquoi un consensus multi-modèles ?

Les filtres de Kalman traditionnels (EKF, UKF) supposent une relation linéaire et des modèles de bruit stationnaires.
Or, dans la réalité :
– les conditions routières changent (revêtement, vibrations, braquage) ;
– les capteurs IMU et GNSS présentent des erreurs variables ;
– les dynamiques du véhicule ne sont pas toujours modélisables simplement.

Le MMKF propose de faire coopérer plusieurs modèles de filtrage, chacun optimisé pour un scénario (lignes droites, virages, pertes GNSS, accélérations brusques…), en établissant un consensus sur l’estimation finale.

2. Principe du filtre à consensus

Le filtre combine plusieurs sous-modèles :
1. Filtres spécialisés — chaque filtre représente une dynamique ou une hypothèse différente (par exemple, mouvement constant, virage, perte GNSS).
2. Mécanisme de consensus — les sorties des sous-filtres sont pondérées selon leur cohérence mutuelle et la qualité locale du signal.
3. Itération adaptative — les poids sont recalibrés à chaque pas de temps selon la divergence entre filtres (mesurée par la distance de Mahalanobis).

Formellement, le consensus combine les estimations partielles selon :
(\hat{x} = \sum_i w_i \hat{x}_i)
où (w_i) représentent les poids adaptatifs issus de la cohérence inter-modèles.

Ce consensus permet d’obtenir une estimation plus robuste sans nécessiter un seul modèle parfait.
C’est une approche multi-modèle coopérative, plus stable que les méthodes basées sur un filtre unique.

3. Comparaison avec les approches classiques

Approche	Hypothèse principale	Robustesse GNSS	Adaptation dynamique	Complexité
EKF classique	Modèle linéaire, bruit gaussien	Faible	Faible	Faible
UKF / RKF	Modèle non-linéaire	Moyenne	Moyenne	Moyenne
MMKF (Consensus)	Multi-modèles pondérés	Élevée	Forte	Modérée
DVSE (Deep Learning)	Apprentissage séquentiel	Très élevée	Très forte	Élevée

Le MMKF se situe ainsi entre la rigueur mathématique du Kalman et la souplesse des modèles d’apprentissage profond.
Il offre un compromis idéal pour les systèmes embarqués ou les pipelines hybrides RS3/Telemachus.

4. Implémentation dans RS3 / Telemachus

Dans le pipeline RS3 → Telemachus, le MMKF est intégré comme module de fusion inertielle :
– Entrées : GNSS, IMU, événements RS3, données simulées.
– Sorties : trajectoire estimée (position, vitesse, orientation) dans le format pivot Telemachus.
– Évaluation : RMSE, cohérence inertielle et dérive temporelle.

Les modules RS3 permettent de générer des séquences contrôlées de pertes GNSS (RFC-0009), tandis que Telemachus formalise les sorties au format JSON-Schema (RFC-0007).
Cette intégration garantit la reproductibilité et la comparabilité des filtres de fusion dans un cadre ouvert et documenté.

5. Liens avec les autres travaux

Liu et al. (2023) ont synthétisé les approches GNSS/INS, montrant que les modèles de fusion classique atteignent leurs limites dans les environnements dégradés.
Xiao et al. (2025) proposent DVSE, un réseau d’apprentissage profond qui vise à remplacer le filtre de Kalman.
Mafi et al. (2025) introduisent le consensus MMKF comme une solution intermédiaire, plus interprétable et calculable en temps réel.
Pour approfondir, voir également Données brutes 10 Hz et inertie véhicule.
Un article scientifique pertinent : https://arxiv.org/abs/2501.01234.

Dans ce cadre, RS3 et Telemachus constituent une plateforme d’expérimentation intégrée pour tester, comparer et documenter ces approches.

6. En résumé

Le Consensus MMKF marque une évolution majeure de la fusion multi-capteurs :
– combine le meilleur du monde physique et du monde data-driven ;
– s’intègre naturellement dans les pipelines RS3/Telemachus ;
– ouvre la voie à des validations reproductibles pour la mobilité intelligente.

Le consensus MMKF illustre la convergence entre méthodes analytiques et approches apprenantes.
Intégré dans RS3 et Telemachus, il constitue une base expérimentale solide pour la validation ouverte de filtres de fusion — un jalon vers une mobilité plus interprétable, robuste et transparente.

✳️ Références :
– Mafi, S. et al. (2025) — Consensus Multi-Model Kalman Filter for Robust Vehicle State Estimation.
– Liu, H. et al. (2023) — A Comprehensive Review of GNSS/INS Integration.
– Xiao, L. et al. (2025) — Deep learning-based Vehicle Speed Estimation via Smartphone IMU.
– RFC-0009 — Integration RS3 → Telemachus.

2025-10-31

Filtrage invariant GNSS IMU : approche robuste de localisation RS3

Filtrage invariant GNSS IMU : une approche géométrique pour la robustesse

Le filtrage invariant GNSS IMU révolutionne la fusion de capteurs pour la localisation des véhicules. Contrairement aux méthodes classiques, ce filtrage invariant s’appuie sur la géométrie des groupes de Lie, garantissant stabilité et précision dans les pipelines RS3 et Telemachus.

filtrage invariant GNSS IMU localisation RS3 — Le filtrage invariant (IEKF) applique la géométrie des groupes de Lie à la localisation véhicule.

De quoi parle le papier original ?

L’article “Invariant Filtering on the Two-Frame Group for Vehicle Localization with Unknown Parameters” (Chauchat et al., 2024) étend le cadre du Groupe à Deux Cadres (TFG) pour estimer non seulement la position et l’attitude d’un véhicule, mais aussi des paramètres inconnus comme le bras de levier GNSS et le facteur d’échelle (lié au rayon des roues ou à la pression des pneus).

Grâce à un changement de variables astucieux (X' = X / s), le système peut être reformulé sur le groupe de Similitude (Sim(2)), permettant d’obtenir des équations d’erreur autonomes — cœur de la robustesse du IEKF.

Les résultats montrent un taux de convergence supérieur à 98 %, même avec des erreurs initiales d’attitude supérieures à 200°, là où l’EKF standard échoue presque toujours.

Schéma conceptuel du filtrage invariant GNSS IMU

schéma filtrage invariant GNSS IMU RS3 — Schéma conceptuel du filtrage invariant sur groupe de Lie.

Dans ce schéma, la géométrie du mouvement est directement intégrée dans le filtre.
L’erreur évolue sur le groupe lui-même (et non dans un espace linéaire arbitraire), garantissant des propriétés de stabilité fortes.

Application du filtrage invariant GNSS IMU à RS3 et Telemachus

Ce cadre n’est pas purement théorique : il inspire directement la conception de pipelines de simulation et de validation inertielle dans RS3 et Telemachus, en offrant une base mathématique rigoureuse pour évaluer la cohérence physique des modèles.

Problème traité	Approche RS3 / Telemachus	Lien avec IEKF
Estimation de vitesse sans GNSS	Modèles inertiels simulés + apprentissage supervisé	L’IEKF fournit une référence physique stable
Gestion des erreurs de capteurs	Modélisation paramétrique RS3 + profils de bruit Telemachus	Même logique de propagation autonome
Bras de levier et échelle véhicule	Simulation topologique et inertielle	Reprend les notions de Sim(2) et d’échelle dynamique

Perspectives

L’extension du filtrage invariant vers des modèles multi-capteurs (GNSS, IMU, roues, caméras) ouvre la voie à des pipelines hybrides où la géométrie des groupes de Lie sert de colonne vertébrale pour intégrer l’apprentissage automatique.
Les travaux récents sur les Kalman invariants multi-modèles (MMKF) (Mafi et al., 2025) prolongent cette direction, et RS3 pourrait jouer un rôle clé comme banc de test ouvert pour ces architectures.

Ces approches posent les bases d’un paradigme où la géométrie remplace la linéarisation approximative du monde inertiel.
En d’autres termes, les systèmes deviennent géométriquement cohérents avant même d’être corrigés par les données.

Complément scientifique

Le filtrage invariant repose sur la définition d’un espace d’erreur autonome :

Ẋ = f(X, u)
où X désigne l’état estimé et E = χ⁻¹·ĥχ l’erreur sur le groupe de Lie.

Contrairement au filtre de Kalman étendu, la dynamique de l’erreur ne dépend plus de l’état estimé, garantissant stabilité et convergence.

Lire l’article original sur HAL

📚 Références
– Chauchat, A., Barrau, A., Bonnabel, S. (2024). Invariant Filtering on the Two-Frame Group for Vehicle Localization with Unknown Parameters.
– Boguspayev et al. (2023). A Comprehensive Review of GNSS/INS Integration.
– Mafi, F. et al. (2025). Consensus Multi-Model Kalman Filter.
– Young, A.D. et al. (2011). IMUSim: A Simulation Environment for Inertial Sensing Algorithm Design and Evaluation.

2025-10-27

Telemachus v0.2 – Structurer le standard ouvert de la donnée mobilité en France 🚀

Telemachus standard mobilité (v0.2) marque une nouvelle étape dans la gouvernance ouverte de la donnée mobilité en France. Ce format pivot garantit transparence, interopérabilité et évolution communautaire.
Ce projet vise à harmoniser l’échange des données de mobilité à travers un système collaboratif de RFCs (Request for Comments). Ainsi, il garantit une évolution transparente et communautaire du standard.

Telemachus standard mobilité v0.2 – gouvernance ouverte du format Telemachus

🚀 Pourquoi un système de RFCs ?

Un standard vivant doit s’appuyer sur une gouvernance claire et un processus transparent.
De plus, le système de RFCs permet de :

Documenter précisément chaque évolution du format ;
Ouvrir la discussion à la communauté ;
Assurer la traçabilité des décisions ;
Structurer l’évolution du standard avec rigueur.

En effet, cette approche s’inspire des meilleures pratiques de l’IETF, d’OpenTelemetry ou encore de l’OGC.

📦 Les RFCs de la version 0.2

La version 0.2 introduit plusieurs RFCs fondamentaux :

RFC	Titre	Statut	Lien
0001	Telemachus Core 0.2	Accepté	Lien
0003	Dataset Specification 0.2	Accepté	Lien
0004	Extended FieldGroups Schema	Accepté	Lien
0005	Adapter Architecture	Accepté	Lien
0007	Validation Framework & CLI Rules	Accepté	Lien
0009	RS3 Integration Pipeline	Accepté	Lien
0011	Versioning & Governance Policy	Accepté	Lien

🗂️ Retrouvez l’ensemble des documents sur GitHub :
telemachus3/telemachus-spec

🔧 Un standard modulaire, compatible et validable

RS3 génère les données brutes (IMU, GPS, vitesse…).
Adapters traduisent les données industrielles (Webfleet, Samsara, Teltonika…).
Schemas garantissent la cohérence entre jeux de données.
Validator contrôle les alignements temporels, unités et complétude.

Par conséquent, cette approche transforme Telemachus en un véritable langage pivot entre simulation, télématique industrielle et recherche scientifique.

🧠 Un projet de standard, pas une simple bibliothèque

Avec le système de RFCs, Telemachus change d’échelle. Ce n’est plus seulement une librairie Python ou un dataset. En effet, c’est une spécification documentée et gouvernée.

Le processus se déroule ainsi :
1. Proposée — la RFC est en Draft.
2. Discutée — une issue publique est ouverte sur GitHub.
3. Implémentée — dans le code ou les schémas.
4. Publiée — dans une version officielle du standard.

Ce processus garantit la pérennité, la traçabilité et la crédibilité du format dans l’écosystème mobilité.

🗓 Et maintenant ?

Renforcement de la validation sémantique (RFC-0007).
Génération automatique des schémas JSON à partir des RFCs.
Gouvernance ouverte (RFC-0011) et participation communautaire.
Extension vers les données temps réel et les futures APIs constructeurs.

📘 Une nouvelle release Telemachus Spec v0.3 regroupera ces évolutions au premier semestre 2026.

💬 Rejoignez la discussion

💬 Discussions publiques sur GitHub :
RFC Discussions – telemachus3/telemachus-spec

🌍 Documentation officielle :
telemachus3.github.io/telemachus-spec

🔗 Articles internes :
RoadSimulator3.fr |
Référentiel virages OSM vs IGN

En s’appuyant sur un système de RFCs transparent et communautaire, Telemachus établit une gouvernance solide pour la donnée mobilité. Ce modèle collaboratif garantit la compatibilité, la traçabilité et la continuité du standard dans le temps.

✍️ Auteur

Sébastien Edet — Créateur du simulateur RoadSimulator3 (RS3) et du standard Telemachus

2025-10-13

🧩 Telemachus RFC-0001 : les 10 axes d’évolution du format vers la v0.2
🧩 Telemachus RFC-0001 — Les 10 axes d’évolution du format vers la v0.2

En septembre, nous avons publié le premier jeu de données Telemachus, aligné sur la spécification v0.1-alpha.
Cette version posait les bases du format : GNSS, mouvement, IMU, moteur, qualité et contexte — pour relier les données issues de la simulation (RS3) et celles collectées sur le terrain.

Aujourd’hui, nous franchissons une nouvelle étape : la normalisation ouverte du format lui-même.
C’est tout l’objet de la RFC-0001 – Telemachus Core v0.2, désormais ouverte à commentaires sur GitHub.

🧭 Pourquoi une RFC ?

Telemachus n’est pas qu’un format de fichier : c’est un langage commun pour la donnée de mobilité haute fréquence.

Afin d’en faire évoluer la structure de façon transparente, nous adoptons un processus inspiré du web ouvert : la RFC (Request for Comments).
L’objectif :

Faire de Telemachus v0.2 un format modulaire, interopérable et analytique, capable d’unifier des données issues de simulateurs, de flottes réelles et de sources contextuelles.

⚙️ Les 10 axes d’évolution

1️⃣ Modularisation & Profils

Découper le schéma en blocs réutilisables (Position, Motion, IMU, Engine, etc.) et introduire la notion de profil :
core, fleet, simulated, contextual.
👉 Chaque fournisseur pourra ainsi ne valider que les champs pertinents à son cas d’usage.

2️⃣ Temps & Fréquence
- Support des horodatages haute précision (timestamp_ns)
- Synchronisation multi-capteurs (GNSS, IMU, CAN)
- Gestion d’un sample_idx pour les séries haute fréquence
🎯 Objectif : une cohérence temporelle robuste entre les signaux.

3️⃣ Véhicule & Chaîne de traction
```
"powertrain": {
  "engine": {"rpm": 2500, "load_pct": 70},
  "ev": {"soc_pct": 82.5, "power_kw": 45.2},
  "hybrid_mode": "charge-sustain"
}
```
🔋 Compatible thermique, électrique et hybride – pour des analyses multi-flottes.

4️⃣ Trajectoire & Géométrie

Nouveau bloc trajectory :
curvature_radm, radius_m, road_class, segment_id, lane_count…
→ un lien direct avec les travaux Road Genome sur la géométrie routière.

5️⃣ Contexte enrichi

Évolution du bloc context en enrichments :
- weather : température, vent, précipitations, visibilité
- road : surface, friction, vitesse limite
- environment : altitude, type de zone, densité urbaine
Chaque source inclut un niveau de confiance.

6️⃣ Provenance & Confiance

Renommer source → provenance et ajouter :
provider, firmware, sampling_strategy, fusion_level, confidence.
🔗 Chaque donnée devient traçable de bout en bout.

7️⃣ Données dérivées & Labels
```
"derived": {
  "jerk_ms3": "number",
  "yaw_rate_rads": "number",
  "curvature_rate": "number"
},
"labels": {
  "road_type": "string",
  "maneuver": "string",
  "driver_behavior": "string",
  "event_type": "string"
}
```
Le premier regroupe les variables calculées automatiquement,
le second les annotations sémantiques (type de route, comportement, manœuvre).
🧠 Ensemble, ils créent le lien entre physique et interprétation — indispensables pour l’IA et les analyses comportementales.

8️⃣ Métadonnées de simulation
```
"simulator": {
  "name": "RS3",
  "version": "3.2",
  "seed": 1234,
  "noise_model": "gaussian"
}
```
🎮 Permet de documenter la génération synthétique et la traçabilité scientifique.

9️⃣ Validation & Conformité
- validation_flags : indicateurs de cohérence (gps_fix_ok, imu_dropout…)
- privacy : anonymisation / hachage des identifiants
- license : obligatoire pour tout dataset public (CC-BY-4.0, ODbL…)
🔟 Interopérabilité & Manifest

Fichier compagnon manifest.json décrivant :
version du schéma, fréquence, couverture spatio-temporelle, sources et licence.
🧩 Compatible avec OGC SensorThings, OpenTelemetry et ISO 39030.

🧠 Un format pivot, entre science et industrie

Telemachus v0.2 comble le vide entre :
- les données simulées (RS3, Road Genome, études d’inertie),
- les données réelles issues de flottes connectées.
En introduisant une sémantique commune et une traçabilité claire, Telemachus vise à devenir un standard pivot pour la mobility data européenne, ouverte et vérifiable.

🤝 Appel à contribution

La RFC-0001 est ouverte à discussion publique sur GitHub 👇

➡️ Participer à la discussion officielle

Prochaines étapes
1. Validation collective des 10 axes
2. Publication du schéma telemachus-core-0.2-draft.json
3. Tests sur de nouveaux jeux de données (RS3 + réels)
4. Mise à jour du validateur Python telemachus-py
📎 Ressources
- 📘 RFC-0001 – Discussion GitHub
- 📄 Spécification Telemachus v0.1-alpha
- 📊 Jeu de données Telemachus v1.0
- 🚗 Projet RoadSimulator3
- 🧮 Article : Référentiel des virages OSM vs IGN
✍️ En résumé

Telemachus RFC-0001 marque le passage d’un format expérimental à une spécification ouverte et contributive.
C’est une étape clé pour structurer, partager et valoriser les données de mobilité à haute fréquence — au service de la recherche, de la simulation et des écosystèmes industriels.
2025-10-10
Telemachus standard télématique : un format ouvert pour les données véhicules
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
👉 À 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
2025-09-30

Auteur/autrice : Seb

Data Space : le problème n’est pas la donnée, mais la responsabilité

Une abondance de données… sans responsabilité claire

Données fragmentées, réalités reconstruites

Quand l’IA amplifie le problème

Ce que les Data Spaces tentent réellement d’adresser

Un sujet stratégique avant d’être technique

Question ouverte

Nature de ce billet (position paper)

Quand la donnée de mobilité sort de l’organisation

Pourquoi le Data Space devient nécessaire

1) La donnée de mobilité existe déjà (ce point est acquis)

2) Le moment de rupture : quand la donnée circule

Data space mobilité : les questions qui deviennent non-négociables

3) Pourquoi les modèles classiques montrent leurs limites

4) Ce que le Data Space apporte réellement (sans jargon)

5) Pourquoi la mobilité est un cas d’école

6) Conclusion : la suite logique

Limites et non-objectifs de ce billet

À suivre

Virtual sensing GNSS/IMU : revue de Cellina et al. (2023) et perspectives industrielles

🎯 1. Contexte : mesurer la consommation… sans accéder au véhicule

🚗 2. Protocole expérimental (véhicule réel + capteurs low-cost)

📦 3. Trois classes de modèles comparés

3.1. VT-MICRO (référence historique, 32 paramètres)

3.2. Modèle Physics-Based (PB)

3.3. Neural Network (NN)

📊 4. Résultats : qui gagne ?

Synthèse

🛑 5. Cas particulier : véhicule arrêté (“stopped car”)

🔍 Analyse fréquentielle du signal IMU (100 Hz)

🧭 6. Discussion critique

✔️ Forces de l’article

⚠️ Limites

⚙️ 6.1. Conditions pratiques d’utilisation : ce qu’il faut (vraiment) pour appliquer le virtual sensing énergie

1. Fréquences minimales des capteurs

2. Pas besoin d’accès CAN ni d’abaque constructeur

3. Un modèle spécifique au véhicule

4. Importance de la qualité GNSS

5. Limitations actuelles (hors périmètre de l’article)

🔬 7. Perspectives RS3 × Telemachus

1. Intégration dans RS3 : un banc d’essai idéal

2. Exploitation de la courbure routière (Heuts 2025)

3. Standardisation : Telemachus T002 “Energy Events”

4. Possibilité d’un modèle unifié pour thermique + électrique

🚀 8. Que faire maintenant ?

A. Implémenter le modèle PB dans RS3 / telemachus-py

B. Enrichir le modèle avec la pente réelle (IGN RGEALTI / SRTM)

C. Tester un réseau neuronal plus riche (MLP 2–3 couches)

D. Construire un dataset public “Telemachus Energy Benchmark”

❓ 8.1. FAQ ingénieur — les questions clés pour reproduire le virtual sensing énergie

1. Peut-on utiliser du GNSS 1 Hz comme dans la plupart des smartphones ?

2. Une IMU 20–30 Hz suffit-elle ?

3. Faut-il connaître les paramètres moteur (couple, rendement, injection) ?

4. Le modèle PB est-il universel (un seul modèle pour toutes les voitures) ?

5. Comment traiter la pente si elle n’est pas fournie dans l’article ?

6. Que se passe-t-il en cas de coupure GNSS ?

7. Peut-on appliquer cette méthode aux véhicules électriques ?

8. Comment vérifier si mon IMU capte bien les fréquences moteur ?

9. Quelles sont les extensions naturelles pour l’industrie ?

🧾 9. Conclusion

Estimation vitesse véhicule IMU smartphone : état de l’art & limites

Objectif

Contexte

Méthodes étudiées

Approche DVSE (SmartphoneIMUSpeed2025)

Données et simulation RS3

Limites observées

Perspectives

Liens avec RS3 et Telemachus

IMUSim : simuler les capteurs inertiels pour mieux comprendre la fusion GNSS/IMU

1. IMUSim et la simulation inertielle GNSS/IMU

2. Architecture et fonctionnement

3. Liens avec RS3 et Telemachus

4. Pourquoi c’est encore pertinent ?

5. En résumé

Fusion GNSS/IMU robuste : le filtre à consensus MMKF

1. Pourquoi un consensus multi-modèles ?

2. Principe du filtre à consensus

3. Comparaison avec les approches classiques