Fahrzeug- und Industrial-IoT-Kommunikation, deklariert als Datendateien.

Das deklarative Modell

Vier Bausteine — eine Engine.

Jedes Multi-Stacks-Deployment, Fahrzeugbus oder Industrial IoT, wird als vier bewegliche Teile deklariert. Periodische Strategie wird out of the box geliefert; erweiterte Sequenzen entstehen durch Kombination mit MSP und MEP.

Protokoll-Abdeckung

16 Protokoll-Familien in einer einheitlichen API.

Modbus ASCII ist experimentell — nicht für Produktionseinsatz angegeben. ISOBUS ist schreibgeschützte Erfassung; VT-Display-Authoring wird nicht unterstützt.

Praxisbeispiel · Industrial IoT (Modbus)

Abfragen einer SPS über Modbus RTU.

Gleiche vier Bausteine, anderes Protokoll. Ein Fabrik-Generatorregler stellt Eingangsregister bereit; ein Modbus-Stack pollt sie mit 1 Hz, dekodiert sie als benannte Signale und sendet ein Ereignis, wenn ein Schwellwert überschritten wird.

{
  "device_id": "Genset-01",
  "transport": "modbus_rtu",
  "slave_id": 7,
  "commands": [
    {
      "name": "coolant_temp_c",
      "function": "read_input_registers",
      "address": 30001,
      "count": 1,
      "period_ms": 1000,
      "decode": "A / 10"
    },
    {
      "name": "fuel_level_pct",
      "function": "read_input_registers",
      "address": 30002,
      "count": 1,
      "period_ms": 1000,
      "decode": "A"
    }
  ],
  "broadcast": { "on_threshold": "fuel_level_pct < 10", "emit": "low_fuel" }
}

Multi-Stack-Modus

N Stacks · ein Satz physischer Schnittstellen.

Jeder Stack läuft mit einem unabhängigen Lifecycle und Export-Pfad auf denselben physischen Schnittstellen. Mehrere Stacks, die einen Bus teilen, benötigen keinen Scheduler — die einheitliche Protokoll-API arbitriert den Zugriff und erzwingt Isolation.

flowchart TD
  S1[Stack A — OBD-II JSON<br/>Fahrgast-PIDs]
  S2[Stack B — J1939 JSON<br/>LKW-PGNs]
  S3[Stack C — Modbus JSON<br/>RS-485-Sensoren]
  V[Einheitliche Protokoll-API<br/>Arbitrierung · Lifecycles]
  S1 --> V
  S2 --> V
  S3 --> V
  V --> Iface1[CAN0]
  V --> Iface2[CAN1]
  V --> Iface3[RS-485]
  S1 -->|Export| MQ1[MQTT-Topic A]
  S2 -->|Export| MQ2[MQTT-Topic B]
  S3 -->|Export| MEP[Policy-Engine]

Fähigkeiten

Was out of the box geliefert wird.

22 CI-validierte Standard-Stacks, produktionsgradige DTC-Behandlung, J2534-2-Passthrough und eingebaute Circuit-Breaker-Resilienz — alles verfügbar ohne einen Scheduler zu schreiben oder Bus-Arbitrierung manuell zu verwalten.

Identifikation + OE-Stack-Push

Der richtige Stack für jedes Fahrzeug, automatisch.

Bevor ein Polling beginnt, identifiziert die Laufzeit das Fahrzeug und wählt den passenden OE-Stack zum Laden aus. Der gepushte OE-Stack standardisiert die Daten — Benennung, Format, Einheiten und Frequenz — über OE-DTCs, Dashboard-Telemetrie und andere OE-Datenoberflächen.

Dieser Identifikationsprozess ist autonom — das Gerät löst den richtigen Stack lokal aus dem Identifikationsergebnis auf, ohne Cloud-Round-Trip für den normalen Betrieb. Die Cloud pusht die OE-Stack-Definition einmal; das Gerät wendet sie bei jeder Verbindung an.

Kunden können den Stack-Katalog mit eigenen Stacks erweitern — gekauft, IP-eigentum oder reverse-engineered — mit eigener Identifikations-Logik. Benutzerdefinierte Stacks sind auf ihre Flotte beschränkt; sie koexistieren neben den Standard-OE-Stacks ohne Konflikt.

Für Cloud-gesteuerte Remote-Diagnose — wo ein Mensch oder eine KI der Master ist statt des Geräts — wenden Sie sich an unser Engineering-Team bezüglich der Remote-Diagnose-Oberfläche.

Einordnung

Eine Säule der Operations-Schicht.

Remote-Diagnose ist eine von fünf Säulen in der Operations-Schicht — zusammen mit Observability, Safety, OTA und Lifecycle. Den vollständigen Satz lesen unter /de/platform/operations.

Sprachunterstützung

Sechs Sprachen für Stack-Erweiterungen.

Kunden können Stack-Verhalten erweitern — benutzerdefinierte Identifikationslogik, Signaltransformationen und Action-Handler — mit einer von sechs Sprachen. Lua 5.4 ist die Scripting-Option mit der niedrigsten Einstiegshürde: keine Rust-Toolchain erforderlich.

Vollständiges SDK und Entwicklerwerkzeuge ansehen →

FAQ

Häufig gestellte Fragen

• Ist Multi Stacks dasselbe wie OBDStacks?

  Ja. OBDStacks ist der Legacy-Name; Multi Stacks ist der kanonische Name seit 2026-05-05. Gleiche Engine, gleiche JSON-DSL, gleicher default-stacks/-Katalog.

• Wie viele Protokolle unterstützt die Laufzeit gleichzeitig?

  Bis zu 16 Protokoll-Familien teilen eine einheitliche Protokoll-API. Mehrere Stacks laufen gleichzeitig mit unabhängigen Lifecycles und Export-Pfaden auf denselben physischen Schnittstellen.

• Was ist ein deklarativer Stack?

  Ein Stack ist eine JSON-Datendatei, die ECUs, Commands, Actions, Exports, Conditions und Expressions spezifiziert. Eine PID aktualisieren, einen Sampling-Zeitraum ändern oder eine Antwort-Richtlinie anpassen ist ein JSON-Edit und ein Commit — keine Firmware-Release.

• Funktioniert Modbus ASCII in der Produktion?

  Modbus ASCII ist ein experimentelles Feature — verlassen Sie sich nicht darauf für Produktions-Deployments. Modbus RTU (RS-485) und Modbus TCP/MBAP sind beide produktionsreif.

• Kann ich einen Stack ohne echte ECU-Hardware testen?

  Ja. mos-mes simuliert eine oder mehrere ECUs auf einer virtuellen CAN-Schnittstelle und antwortet auf UDS, OBD-II und ISO-TP mit konfigurierbaren Signal-Strategien. CI-Pipelines führen vollständige Regressions-Suiten auf vcan ohne physische Bench aus.

• Was deckt DTC-Unterstützung ab?

  DTC-Lesen und -Löschen über den unterstützten Stack — via OBD-II-Service 03/04 oder UDS-Diagnoseinformations-Services.

• Wie kombiniert Multi Stacks mit MSP und MEP?

  Eine Multi-Stacks-"Strategy" ist standardmäßig periodisch. Für signalgesteuerte Sequenzen publiziert ein MSP-Graph einen Trigger und Multi Stacks sendet die entsprechende Anfrage. Für ereignisgesteuerte Sequenzen feuert eine MEP-Regel bei einem benannten Ereignis und führt eine Multi-Stacks-Aktion aus. Beide Kompositionen bleiben deklarativ.