Communication véhicule et IoT industriel, déclarée en fichiers de données.

Le modèle déclaratif

Quatre éléments — un seul moteur.

Chaque déploiement Multi Stacks, bus véhicule ou IoT industriel, est déclaré en quatre parties mobiles. La stratégie périodique est disponible d'emblée ; les séquences avancées émergent en composant avec MSP et MEP.

Couverture protocolaire

16 familles de protocoles dans une API unifiée.

Modbus ASCII est expérimental — non revendiqué pour la production. ISOBUS est en acquisition lecture seule ; la création d'affichage VT n'est pas prise en charge.

Exemple pratique · IoT industriel (Modbus)

Interrogation d'un automate en Modbus RTU.

Mêmes quatre éléments, protocole différent. Un contrôleur de groupe électrogène industriel expose des registres d'entrée ; une pile Modbus les interroge à 1 Hz, les décode en signaux nommés et diffuse un événement quand un seuil est dépassé.

{
  "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" }
}

Mode multi-pile

N piles · un seul ensemble d'interfaces physiques.

Chaque pile s'exécute avec un cycle de vie indépendant et un chemin d'export indépendant sur les mêmes interfaces physiques. Plusieurs piles partageant un bus ne nécessitent pas de planificateur — l'API protocole unifiée arbitre l'accès et applique l'isolation.

flowchart TD
  S1[Pile A — OBD-II JSON<br/>PIDs passager]
  S2[Pile B — J1939 JSON<br/>PGNs camion]
  S3[Pile C — Modbus JSON<br/>capteurs RS-485]
  V[API protocole unifiée<br/>arbitrage · cycles de vie]
  S1 --> V
  S2 --> V
  S3 --> V
  V --> Iface1[CAN0]
  V --> Iface2[CAN1]
  V --> Iface3[RS-485]
  S1 -->|export| MQ1[Sujet MQTT A]
  S2 -->|export| MQ2[Sujet MQTT B]
  S3 -->|export| MEP[Moteur de politique]

Capacités

Ce qui est disponible d'emblée.

22 piles par défaut validées en CI, gestion DTC de niveau production, passthrough J2534-2, et résilience par disjoncteur intégrée — disponibles sans écrire un planificateur ni gérer manuellement l'arbitrage de bus.

Identification + push de pile OE

La bonne pile pour chaque véhicule, automatiquement.

Avant tout sondage, le runtime identifie le véhicule et sélectionne la pile OE appropriée à charger. La pile OE poussée standardise les données — nommage, format, unités et fréquence — pour les DTC OE, la télémétrie tableau de bord et les autres surfaces de données OE.

Ce processus d'identification est autonome — l'appareil résout la pile correcte localement depuis le résultat d'identification, sans aller-retour cloud requis pour le fonctionnement courant. Le cloud pousse la définition de pile OE une fois ; l'appareil l'applique à chaque connexion.

Les clients peuvent étendre le catalogue de piles avec leurs propres piles — achetées, propriétaires ou issues d'ingénierie inverse — avec leur propre logique d'identification. Les piles personnalisées sont limitées à leur flotte uniquement ; elles coexistent avec les piles OE par défaut sans conflit.

Pour le diagnostic à distance piloté par le cloud — où un humain ou une IA est le maître plutôt que l'appareil — consultez notre équipe technique au sujet de la surface de diagnostic à distance.

Où cela s'inscrit

Un pilier de la couche opérations.

Le diagnostic à distance est l'un des cinq piliers de la couche opérations — avec l'observabilité, la sécurité, l'OTA et le cycle de vie. Lire l'ensemble sur /fr/platform/operations.

Support des langages

Six langages pour les extensions de pile.

Les clients peuvent étendre le comportement des piles — logique d'identification personnalisée, transformations de signaux et gestionnaires d'actions — en utilisant l'un des six langages. Lua 5.4 est l'option de scripting à plus faible barrière d'entrée : aucune chaîne d'outils Rust requise.

Voir le SDK complet et les outils développeur →

FAQ

Questions fréquentes

• Multi Stacks est-il la même chose que OBDStacks ?

  Oui. OBDStacks est le nom historique ; Multi Stacks est le nom canonique depuis le 2026-05-05. Même moteur, même DSL JSON, même catalogue default-stacks/.

• Combien de protocoles le runtime prend-il en charge simultanément ?

  Jusqu'à 16 familles de protocoles partagent une API protocole unifiée. Plusieurs piles s'exécutent en parallèle avec des cycles de vie indépendants et des chemins d'export indépendants sur les mêmes interfaces physiques.

• Qu'est-ce qu'une pile déclarative ?

  Une pile est un fichier de données JSON spécifiant ECU, commandes, actions, exports, conditions et expressions. Mettre à jour un PID, changer une période d'échantillonnage ou ajuster une politique de réponse est une édition JSON et un commit — pas une release firmware.

• Modbus ASCII fonctionne-t-il en production ?

  Modbus ASCII est une fonctionnalité expérimentale — ne pas l'utiliser pour des déploiements en production. Modbus RTU (RS-485) et Modbus TCP/MBAP sont tous deux prêts pour la production.

• Puis-je tester une pile sans matériel ECU réel ?

  Oui. mos-mes simule un ou plusieurs ECU sur une interface CAN virtuelle et répond aux commandes UDS, OBD-II et ISO-TP avec des stratégies de signal configurables. Les pipelines CI exécutent des suites de régression complètes sur vcan sans banc physique.

• Que couvre le support DTC ?

  Lecture et effacement de DTC dans les piles prises en charge — via le service OBD-II 03/04 ou les services d'information de diagnostic UDS.

• Comment Multi Stacks se compose-t-il avec MSP et MEP ?

  Une « Stratégie » Multi Stacks est périodique par défaut. Pour les séquences pilotées par signal, un graphe MSP publie un déclencheur et Multi Stacks envoie la requête correspondante. Pour les séquences pilotées par événement, une règle MEP se déclenche sur un événement nommé et exécute une action Multi Stacks. Les deux compositions restent déclaratives.