Die geschäftlichen Zusammenfassungen sind in dieser Sprache verfügbar. Produktabläufe und technische Belege werden auf Englisch gepflegt.
Physical AI & Robotik
Vectis AI
Verteilte Fahrzeugsignale in einem zusammenhängenden Produktumfang verbinden.
Erfassung, Signaldefinitionen, APIs und Bedienerlebnis sind nicht miteinander verbunden. Eine nützliche Funktion braucht einen nachvollziehbaren Weg durch diese Elemente.
Produktverantwortliche für Mobilität und Leiter der Embedded-Entwicklung
Softwareprototyp mit ausgewiesenen Software- und Firmwaregrenzen
A signal interpretation trace
Input
Authorised CAN trace and DBC definition
Meaning
Normalised signal and unit
Consumer
An API and operator workflow
Validation
Trace fixtures; vehicle evidence still needed
Decision logic and control flow
Explore the reasoning
Select one signal and the operator decision it should support.
Engage now
A signal-to-workflow map and the evidence needed to evaluate the connected-product boundary.
Inspect
Source prototype with software and firmware boundaries
Backend unit and integration tests for the application and telemetry boundaries.
Still to validate
Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
Complete hardware-in-the-loop, vehicle-in-the-loop, field-fleet, update-safety, data-quality, and operational validation.
Quellen geprüft
The decision behind the system
How does a vehicle signal become a useful product?
A vehicle-data prototype connecting embedded acquisition, CAN/DBC signal normalisation, APIs and user-facing telemetry workflows.
Vectis explores the signal-to-product boundary for connected vehicles. Its job differs from cross-machine coordination or learned robot behaviour.
Signals with meaning
The Rust UVAL core parses DBC, decodes CAN frames and maps VSS identifiers into canonical signals. Node and WebAssembly build targets support evaluation.
Connected workflows
API and mobile surfaces explore trips, telemetry, diagnostics, geofencing and assistant interactions.
Software meets firmware
Embedded source and trace-replay fixtures expose acquisition, connectivity and update boundaries for evaluation.
Read the complete system walkthrough
Choose
Select one signal and the operator decision it should support.
Normalise
Replay an authorised trace and follow CAN/DBC interpretation into a canonical signal.
Connect
Inspect how the API and user-facing workflow consume the signal and handle missing information.
Validate
Identify data-quality, connectivity and hardware evidence required before vehicle or fleet use.
Inspect the source, test conditions and operating limits in the technical record.
Technische Unterlagen und Evidenz
Brücke Business ↔ Technologie · Embedded product-boundary experiment
Turn raw vehicle signals into a bounded, testable product system.
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.
01
Geschäftlicher Druck
Vehicle telemetry is only useful when acquisition, signal semantics, connectivity, diagnostics, user experience, and operational responsibility form one product boundary.
02
Produktentscheidung
Separate embedded acquisition, canonical signal mapping, application APIs, and user surfaces before adding assistant or predictive behaviour.
03
Technischer Nachweis
Embedded source, API and user surfaces, a Rust normalisation core, and a trace-replay fixture for DBC, CAN, and canonical mapping.
04
Evidenzrückfluss
Signal quality, offline behaviour, update safety, hardware limits, and user validation return to feature scope, architecture, support, and release criteria.
Repository-/Laufzeitgrenze
Diese Seite interpretiert Quellen aus einem getrennten Venture-Repository. Quellcode dort bedeutet nicht, dass das Venture als Dienst in hyperion-consulting.io läuft.
Die KI-Verarbeitung von Besucher- und Kundendaten ist auf Mistral über den kontrollierten EU-Endpunkt beschränkt. Die vom Inhaber freigegebenen Pfade Helio, Suche und Product Council sind aktiviert. Ein getrenntes Redaktionsverfahren mit öffentlichen Quellen nutzt Anthropic mit kontrolliertem Mistral-Ersatz; es erhält keine Website-Anfragen, Kundendokumente oder Besuchergespräche. Deterministische Werkzeuge bleiben ohne Remote-KI verfügbar.
Quellcode-Evidenz
Was der Quellcode tatsächlich belegt
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.
Reifegrad
Source prototype with software and firmware boundaries
Evidenzprüfung
Quellstand bis
Produkt- und Architekturentscheidungen
Separate device acquisition, canonical signal mapping, APIs, and operator-facing product surfaces.
Normalise DBC/CAN inputs into a canonical signal layer before product logic consumes them.
Treat offline behaviour, update safety, and hardware abstraction as explicit architecture boundaries.
Prüfbare Evidenz
Backend unit and integration tests for the application and telemetry boundaries.
Embedded source with C-level tests for selected firmware logic.
Rust UVAL source for DBC parsing, CAN decoding and VSS mapping, with Node and WebAssembly build targets and a trace-replay integration fixture.
Aussagegrenze
Advanced multiplexing and firmware C code generation remain incomplete; build targets do not establish deployed Node, mobile or browser integrations.
No hardware-in-the-loop, vehicle-in-the-loop, OEM, safety-certification, or field-fleet record is asserted.
Predictive-maintenance and assistant outputs require separate data-quality and operational validation.
Repository-Evidenz ist kein Nachweis für Kunden, Betrieb, Zertifizierung oder Ergebnisse.
Architektur
Vom OBD-II-Port zu verständlichen Einblicken in Klartext
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.
01
Layer 1 — ESP32-Quellcode für die OBD-II-Erfassung
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.
02
Schicht 2 — Rust UVAL und Anwendungsoberflächen
Der Rust-UVAL-Kern parst DBC, dekodiert CAN und ordnet VSS-Kennungen kanonischen Signalen zu. Build-Ziele für Node und WebAssembly sowie Trace-Replay-Fixtures sind vorhanden; das Ende-zu-Ende-Verhalten auf Mobilgeräten, im Browser und im Fahrzeug muss separat validiert werden.
03
Layer 3 — AI Insight Engine
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.
Was der Quellcode modelliert
Im Quellcode abgebildete Fahrzeugsignalpfade
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 0D
Fahrzeuggeschwindigkeit
01
Der Quellcode bildet die Fahrzeuggeschwindigkeit als Eingabe für Fahrten-, Schwellenwert- und Geofence-Logik ab. Rate und Genauigkeit werden nicht fahrzeugübergreifend behauptet.
PID 0C
Motordrehzahl
02
Der 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 11
Drosselklappenstellung
03
Der 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 05
Kühlmitteltemperatur
04
Der Quellcode bildet die Kühlmitteltemperatur als Eingabe sowie Anomaliehypothesen ab. Das ist weder eine Frühwarngarantie noch eine diagnostische Schlussfolgerung.
PID 0F
Ansauglufttemperatur
05
Der 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 0B
Saugrohrdruck
06
Der 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 2F
Kraftstoffstand
07
Der 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 14
O₂-Sensor (Lambda)
08
Der 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 03
ECU-Fehlercodes (DTCs)
09
Der 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.
ONBOARD
IMU (Beschleunigung + Gyroskop)
10
Der 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.
GNSS
Geofence-Grenze
11
Der 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.
OTA
Firmware-Status
12
Der 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
Technologie-Stack
Genannte Technologien kennzeichnen Repository-Abhängigkeiten oder Adapteroberflächen; sie belegen keine aktive Integration oder Bereitstellung.
Der Quellcode-Prototyp von Vectis AI — Backend, Frontend, Mobile App und Firmware — ist auf Anfrage verfügbar.
NDA erforderlich
Für den Zugang zum Quellcode unterzeichnen Sie bitte die Geheimhaltungsvereinbarung. Dies ist eine übliche rechtliche Formalität.
Mit Hyperion arbeiten
Ein Signal bis zum Arbeitsablauf verfolgen
Eine Abbildung vom Signal zum Arbeitsablauf und der Belege, die zur Evaluierung der Grenzen des vernetzten Produkts nötig sind.
Bringen Sie eine kurze Beschreibung Ihrer Situation, Rahmenbedingungen und Entscheidung mit. Umfang, Verantwortlichkeiten und Angebot werden vor Arbeitsbeginn vereinbart.