Embedded product-boundary experiment
Ein Quellcode-Prototyp für Fahrzeugdaten
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.
Brücke Business ↔ Technologie · Embedded product-boundary experiment
Explores the boundary from vehicle acquisition and canonical signals to operator-facing product decisions.
Dies ist eine Portfolio- und Quellinterpretation, keine Aussage über Kunden, Betrieb, Zertifizierung oder Ergebnisse.
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.
Quellcode-Evidenz
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.
Der detaillierte technische Stand wird auf Englisch gepflegt.
Repository-Evidenz ist kein Nachweis für Kunden, Betrieb, Zertifizierung oder Ergebnisse.
Architektur
Drei Quellcodegrenzen: Embedded-Erfassung, kanonisches Signal-Mapping und APIs sowie nutzerseitige Telemetrie- und Assistenten-Oberflächen.
Nur Quellübersicht: Eine Schicht kann implementierten Code, eine Adaptergrenze oder dokumentiertes Design darstellen. Sie belegt keinen konfigurierten Produktionsdienst.
Der Embedded-Quellcode bildet OBD-II/CAN-Erfassung, ausgewählte Signale, Bewegungseingaben, Pufferung und Update-Grenzen ab. Es wird weder Produktionshardware noch eine Fahrzeugvalidierung behauptet.
Mobile-, Web-, Streaming- und Ingest-Oberflächen sind im Quellcode abgebildet. Ihre End-to-End-Latenz, Zuverlässigkeit und Nutzbarkeit im Feld erfordern eine Validierung mit Zielhardware und Zielnetzen.
Der Quellcode bildet einen Mistral-basierten Assistenten ab, der Roh-CAN-Daten in verständlicher Sprache erklärt: Fahrtzusammenfassungen, Bewertung des Fahrverhaltens sowie Hypothesen zu vorausschauender Wartung und Anomalien. Seine Ausgaben erfordern eine gesonderte Datenqualitäts- und Betriebsvalidierung.
Das Problem
Warum Fahrzeugdaten ungenutzt bleiben
Moderne Fahrzeuge erzeugen umfangreiche OBD-II-Daten, doch Fahrer und Flottenmanager haben kein zugaengliches Werkzeug zur Interpretation.
Separate Apps fuer Diagnose, Fahrtenverfolgung, Kraftstoffverbrauch und Sicherheitsbewertung. Keine einheitliche Intelligence-Schicht.
Ausfaelle passieren, bevor Probleme erkannt werden. Keine vorausschauenden Warnungen, kein Gesundheits-Scoring, keine Trendanalyse.
Man kann seinem Fahrzeug keine Fragen stellen. Keine natuerlichsprachliche Schnittstelle fuer Fahrmuster oder Fahrzeugzustand.
Funktionen
Quellcode-Oberflächen von rohen OBD-II-Daten bis zur nutzerseitigen Telemetrie
Nur Quellumfang: Ein Eintrag kann Code, einen dokumentierten Adapter oder einen konfigurierten Workflow beschreiben. Er besagt nicht, dass ein Produktionsdienst aktiv ist.
01
Der Quellcode bildet ausgewählte OBD-II-PIDs und -Modi (aktuelle Daten, Freeze Frame, DTCs, VIN), GPS via NMEA, IMU-Eingaben sowie WebSocket + SSE-Streaming ab. Abdeckung und Raten sind nicht validiert.
02
Der Quellcode bildet automatische Start-/Enderkennung, Routenaufzeichnung, Fahrtstatistiken, Wiedergabe und Fahrthistorie mit Kostenanalyse ab. Nichts davon ist an Fahrzeugen validiert.
03
Der Quellcode modelliert eine Sicherheitsbewertung aus Fahrereignissen wie Vollbremsung, starker Beschleunigung, scharfem Abbiegen und Aufprall, mit Teilbewertungen für Gleichmäßigkeit, Geschwindigkeit und Öko-Fahren. Die Schwellenwerte sind nicht an Fahrzeugen validiert.
04
Der Quellcode bildet DTC-Auslesen/-Löschen, Freeze-Frame-Analyse und einen Fahrzeug-Gesundheits-Score ab. Ausgaben zur vorausschauenden Wartung erfordern eine gesonderte Validierung.
05
Der Quellcode bildet einen Assistenten für Fragen in natürlicher Sprache zu Fahrzeugdaten ab, der ein großes Sprachmodell mit Streaming-SSE-Antworten nutzt. Seine Ausgaben erfordern eine gesonderte Validierung.
06
Der Embedded-Quellcode zielt auf einen ESP32-S3 (Dual-Core 240MHz) mit CAN/TWAI, u-blox GPS, einer MPU6050-IMU, WiFi 802.11 b/g/n und BLE GATT. Kraftstofftypen (Benzin, Diesel, Hybrid, PHEV, BEV, Wasserstoff) und OTA A/B-Rollback sind im Quellcode modelliert. Es wird weder eine Hardware- noch eine Fahrzeugvalidierung behauptet.
Was der Quellcode modelliert
Der geprüfte Code modelliert ausgewählte OBD-II/CAN-Signale und eine kanonische Mapping-Schicht. Verfügbarkeit, Rate, Einheiten und Bedeutung variieren je nach Fahrzeug und erfordern eine Validierung mit Fixtures, auf dem Prüfstand und am Fahrzeug.
Nur Repository-Oberfläche: Verfügbarkeit, Vollständigkeit, Leistung und Betriebstauglichkeit erfordern eine gesonderte Validierung.
PID 0DDer Quellcode bildet die Fahrzeuggeschwindigkeit als Eingabe für Fahrten-, Schwellenwert- und Geofence-Logik ab. Rate und Genauigkeit werden nicht fahrzeugübergreifend behauptet.
PID 0CDer Quellcode bildet die Motordrehzahl als Eingabe und als Proxy für die Motorlast ab, mit Hypothesen zur Baseline-Drift für Fehlzündungen, Lambda-Drift und Getriebeverschleiß. Das ist kein validierter Frühindikator.
PID 11Der Quellcode bildet die Drosselklappenstellung (%) als Eingabe für Aggressionsbewertung, Verhaltenscoaching und eine Ereignislogik für starkes Beschleunigen zusammen mit RPM und Geschwindigkeit ab. Das ist nicht an Fahrzeugen validiert.
PID 05Der Quellcode bildet die Kühlmitteltemperatur als Eingabe sowie Anomaliehypothesen ab. Das ist weder eine Frühwarngarantie noch eine diagnostische Schlussfolgerung.
PID 0FDer Quellcode bildet den Luftdichte-Eingang für die Kraftstoffberechnung der ECU ab. Diagnostische Anwendungen wie die Analyse von Leistungsverlust oder die Prüfung von Cold-Air-Intake-Angaben erfordern eine fahrzeugspezifische Validierung.
PID 0BDer Quellcode bildet den Saugrohrdruck als Eingabe und als Motorlastmessung (NA + Turbo) ab. Ansichten zu Boost-Kurve, Last-vs.-RPM und Belastung von Zugfahrzeugen sind Entwurfsumfang, keine validierte Analyse.
PID 2FDer Quellcode bildet den Tankfüllstand (%) als Eingabe für Betankungserkennung, Diebstahlwarnungen bei plötzlichem Abfall und eine MPG-Logik pro Fahrt ab, abgeglichen mit der Strecke aus der Geschwindigkeitsintegration. Rate und Genauigkeit werden nicht behauptet.
PID 14Der Quellcode bildet das Luft-Kraftstoff-Verhältnis als Eingabe ab. Langfristige Drift ist eine Hypothese für Katalysatorverschleiß, Lambda-Sensor-Alterung oder eine unautorisierte Modifikation des Kraftstoffsystems, keine diagnostische Schlussfolgerung.
MODE 03Der Quellcode bildet Workflows für die Aufnahme von Diagnosecodes und für Erklärungen in verständlicher Sprache ab. Unterstützte Module und vorgeschlagene Ursachen erfordern eine fahrzeugspezifische und fachliche Validierung.
ONBOARDDer Quellcode bildet die IMU auf ESP32-Seite als Eingabe für eine Ereignislogik zu starkem Bremsen, scharfem Kurvenfahren, Kollisionen und Straßenrauheit ab, unabhängig von CAN-Daten. Erkennung und Einsatz an Nicht-OBD-Fahrzeugen sind nicht validiert.
GNSSDer Quellcode bildet GPS- und Mobilfunk-Positionseingaben für benutzerdefinierte Zonen (Zuhause, Depot, Kundenstandort), Warnungen bei Ein- und Austritt sowie Offline-Pufferung ab. Das Verhalten im Feld ist nicht validiert.
OTADer Quellcode bildet Entwurfsoberflächen für Firmware-Version, gestaffelte Updates und Rollback ab. Es wird weder ein signiertes Produktionsrelease noch ein Update-Nachweis für eine Geräteflotte behauptet.
Technologie-Stack
Genannte Technologien kennzeichnen Repository-Abhängigkeiten oder Adapteroberflächen; sie belegen keine aktive Integration oder Bereitstellung.
Quellcode
Der Quellcode-Prototyp von Vectis AI — Backend, Frontend, Mobile App und Firmware — ist auf Anfrage verfügbar.
Für den Zugang zum Quellcode unterzeichnen Sie bitte die Geheimhaltungsvereinbarung. Dies ist eine übliche rechtliche Formalität.
Brauchen Sie strategische KI-Beratung für Ihre Flotte oder IoT-Plattform? Meine Beratungsleistungen können helfen.
Partnerschaft
Wenn Sie als Flottenbetreiber, Automobil-OEM oder IoT-Partner KI für Fahrzeugdaten prüfen, kontaktieren Sie mich, um die Entscheidung zu besprechen.
Von der Demo zum verlässlichen Betrieb. Melden Sie sich für neue Beiträge zu Physical AI an.
Jederzeit abbestellbar. Kein Spam, niemals.