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)

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.

---

📦 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.