Embedded product-boundary experiment
Un prototype de code source pour les données véhicule
A vehicle-data prototype spanning API, user surfaces, embedded source, and a Rust signal-normalisation core. The implemented record supports trace and fixture work; vehicle, hardware, and fleet validation remain outside it.
Pont métier ↔ technologie · Embedded product-boundary experiment
Explores the boundary from vehicle acquisition and canonical signals to operator-facing product decisions.
Il s'agit d'une interprétation du portefeuille et des sources, et non d'une affirmation de client, déploiement, certification ou résultat.
Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.
Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.
Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.
Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.
Preuves issues du code source
A vehicle-data prototype spanning API, user surfaces, embedded source, and a Rust signal-normalisation core. The implemented record supports trace and fixture work; vehicle, hardware, and fleet validation remain outside it.
Le relevé technique détaillé est maintenu en anglais.
Les preuves du dépôt ne constituent pas des preuves client, de déploiement, de certification ou de résultats.
Architecture
Trois frontières du code source : l'acquisition embarquée, la mise en correspondance canonique des signaux et les API, et les surfaces de télémétrie et d'assistant destinées à l'utilisateur.
Carte des sources uniquement : une couche peut représenter du code implémenté, une frontière d'adaptateur ou une conception documentée. Elle n'affirme pas l'existence d'un service de production configuré.
Le code source embarqué représente l'acquisition OBD-II/CAN, des signaux sélectionnés, des entrées de mouvement, la mise en tampon et les frontières de mise à jour. Aucun matériel de production ni aucune validation sur véhicule n'est affirmé.
Les surfaces mobile, web, de streaming et d'ingestion sont représentées dans le code source. Leur latence de bout en bout, leur fiabilité et leur utilisabilité sur le terrain nécessitent une validation avec le matériel et les réseaux cibles.
Le code source représente un assistant basé sur Mistral pour l'explication en langage clair des données brutes du CAN : résumés de trajets, notation du comportement de conduite, et hypothèses de maintenance prédictive et d'anomalie. Ses sorties nécessitent une validation distincte, sur la qualité des données et sur le plan opérationnel.
Le Problème
Pourquoi les données véhicule sont inexploitees
Les véhicules modernes génèrent des données OBD-II riches, mais conducteurs et gestionnaires de flotte n'ont aucun outil accessible pour les interpreter.
Des applications séparées pour le diagnostic, le suivi de trajets, la consommation et le scoring de conduite. Aucune couche d'intelligence unifiee.
Les pannes surviennent avant que les problèmes ne soient détectés. Aucune alerte predictive, aucun score de sante, aucune analyse de tendances.
Impossible d'interroger votre véhicule. Aucune interface en langage naturel pour comprendre les habitudes de conduite ou la sante du véhicule.
Fonctionnalités
Des surfaces de code source, des données OBD-II brutes à la télémétrie destinée à l'utilisateur
Périmètre source uniquement : une entrée peut décrire du code implémenté, un adaptateur documenté ou un workflow configuré. Elle n'indique pas qu'un service de production est actif.
01
Le code source représente des PIDs et des modes OBD-II sélectionnés (données courantes, freeze frame, DTCs, VIN), le GPS via NMEA, une entrée IMU et le streaming WebSocket + SSE. La couverture et les fréquences ne sont pas validées.
02
Le code source représente la détection automatique de début/fin, l'enregistrement d'itinéraires, les statistiques de trajets, le replay et l'historique des trajets avec analyse des coûts. Aucun de ces éléments n'est validé sur véhicule.
03
Le code source modélise un score de sécurité issu d'événements de conduite tels que le freinage brusque, l'accélération rapide, le virage serré et l'impact, avec des sous-scores pour la fluidité, la vitesse et l'éco-conduite. Les seuils ne sont pas validés sur véhicule.
04
Le code source représente la lecture/l'effacement des DTC, l'analyse freeze frame et un score de santé véhicule. Les sorties de maintenance prédictive nécessitent une validation distincte.
05
Le code source représente un assistant pour des questions en langage naturel sur les données véhicule, utilisant un grand modèle de langage avec des réponses en streaming SSE. Ses sorties nécessitent une validation distincte.
06
Le code source embarqué cible un ESP32-S3 (double cœur 240MHz) avec CAN/TWAI, GPS u-blox, une IMU MPU6050, WiFi 802.11 b/g/n et BLE GATT. Les types de carburant (essence, diesel, hybride, PHEV, BEV, hydrogène) et le rollback OTA A/B sont modélisés dans le code source. Aucune validation sur matériel ou sur véhicule n'est affirmée.
Ce que modélise le code source
Le code examiné modélise des signaux OBD-II/CAN sélectionnés et une couche de mise en correspondance canonique. La disponibilité, la fréquence, les unités et la signification varient selon le véhicule et nécessitent une validation sur jeux de test, sur banc et sur véhicule.
Surface du dépôt uniquement : disponibilité, exhaustivité, performance et aptitude opérationnelle exigent une validation distincte.
PID 0DReprésente l'entrée de vitesse du véhicule pour la logique de trajets, de seuils et de géorepérage. La fréquence et la précision ne sont pas affirmées pour l'ensemble des véhicules.
PID 0CReprésente l'entrée de régime moteur comme indicateur indirect de la charge du moteur, avec des hypothèses de dérive par rapport à la ligne de base pour les ratés d'allumage, la dérive lambda et l'usure de la transmission. Il ne s'agit pas d'un indicateur précoce validé.
PID 11Représente l'entrée de position de l'accélérateur (%) pour le scoring d'agressivité, le coaching comportemental et la logique d'événements de forte accélération, avec le RPM et la vitesse. Cela n'est pas validé sur véhicule.
PID 05Représente l'entrée de température du liquide de refroidissement et des hypothèses d'anomalie. Il ne s'agit ni d'une garantie d'alerte précoce ni d'une conclusion de diagnostic.
PID 0FReprésente l'entrée de densité d'air pour le calcul du carburant par l'ECU. Les usages de diagnostic, tels que l'analyse d'une perte de puissance ou la vérification des allégations relatives à une admission d'air froid, nécessitent une validation propre à chaque véhicule.
PID 0BReprésente l'entrée de pression du collecteur comme mesure de la charge du moteur (atmosphérique + turbo). Les vues de courbe de suralimentation, de charge vs RPM et de stress des véhicules de remorquage relèvent du périmètre de conception, et non d'une analyse validée.
PID 2FReprésente l'entrée de niveau du réservoir (%) pour la détection des ravitaillements, les alertes de vol sur baisse soudaine et la logique de consommation de carburant par trajet, rapportée à la distance issue de l'intégration de la vitesse. La fréquence et la précision ne sont pas affirmées.
PID 14Représente l'entrée de rapport air-carburant. Une dérive à long terme est une hypothèse de dégradation du convertisseur catalytique, de vieillissement du capteur lambda ou de modification non autorisée du système de carburant, et non une conclusion de diagnostic.
MODE 03Représente des workflows d'ingestion des codes de diagnostic et d'explication en langage clair. Les modules pris en charge et les causes suggérées nécessitent une validation propre à chaque véhicule et par un expert.
ONBOARDReprésente l'entrée IMU côté ESP32 pour la logique d'événements de freinage brusque, de virage serré, de collision et de rugosité de la route, indépendamment des données CAN. La détection et l'usage sur des véhicules non OBD ne sont pas validés.
GNSSReprésente les entrées de position GPS et cellulaire pour les zones définies par l'utilisateur (domicile, dépôt, site client), les alertes d'entrée/sortie et la mise en tampon hors ligne. Le comportement sur le terrain n'est pas validé.
OTAReprésente des surfaces de conception pour la version du firmware, la mise à jour par étapes et le retour en arrière. Aucune version de production signée ni aucun enregistrement de mise à jour d'une flotte d'appareils n'est affirmé.
Stack Technique
Les technologies citées identifient des dépendances ou des adaptateurs du dépôt ; elles n'affirment ni intégration active ni déploiement.
Code Source
Le prototype de code source Vectis AI — backend, frontend, application mobile et firmware — est disponible sur demande.
Pour accéder au code source, veuillez signer l'accord de non-divulgation. Il s'agit d'une formalité juridique standard.
Besoin d'un accompagnement stratégique IA pour votre flotte ou plateforme IoT ? Mes services de conseil peuvent vous aider.
Partenariat
Si vous êtes opérateur de flotte, constructeur automobile ou partenaire IoT et explorez l’IA pour les données véhicule, contactez-moi pour discuter de la décision.
De la démo à une exploitation fiable. Abonnez-vous pour recevoir de nouvelles lectures sur la Physical AI.
Désabonnez-vous à tout moment. Pas de spam, jamais.