Comment les quatre moteurs s'articulent-ils ?

MSP produit des signaux nommés continus depuis les capteurs et les entrées bus. MEP réagit aux déclencheurs discrets (seuil signal, événement, cron) avec des politiques machine à états. Multi Stacks communique avec les bus véhicule et les appareils IoT industriel, piloté périodiquement ou composé avec MSP/MEP. AI Funnel exécute l'IA edge déclarative — un graphe TOML plus un modèle et un dataset ; le cloud Munic réentraîne et déploie via OTA. Les quatre moteurs partagent un OS, un canal OTA et une approche de validation hors cible.

MEP est-il une machine à états ou un moteur T·C·A ?

Les deux lectures sont disponibles. Le product owner lit MEP comme des politiques machine à états sur le device — le YAML de politique est la machine à états. L'ingénieur lit le même YAML comme des primitives Trigger / Condition / Action. Il n'y a pas de runtime machine à états séparé ; l'ensemble de règles composé est la machine à états.

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/.

Faut-il du matériel pour tester une politique ou un graphe ?

Non. Le runner autonome MEP rejoue les fichiers YAML de scénario hors cible ; l'outil lint MEP détecte les erreurs statiquement. Le runner MSP exécute tout .msp.yml avec des entrées CSV sur macOS. Le simulateur ECU intégré couvre Multi Stacks sur CAN virtuel. Le faux runtime IA stub l'inférence pour CI d'AI Funnel. Les quatre moteurs ont des runners hors cible de niveau CI.

Cela nécessite-t-il du Rust ?

Non. Les quatre moteurs se configurent avec YAML, JSON et TOML. Le runtime est en Rust, mais la surface de création est des fichiers de données. Un conteneur Python peut piloter n'importe lequel des moteurs via le broker MQTT in-process — voir « Prêt à l'emploi, ensemble » ci-dessous.

Quand le chemin SDK s'applique-t-il ?

Quand l'algorithme ne peut genuinement pas être exprimé comme un graphe, une politique, une pile ou un graphe IA TOML. Logique de détection inédite, inférence de modèle propriétaire, intégration matérielle personnalisée. Les quatre moteurs no-code couvrent la majeure partie de la surface de comportement du device ; les micro services Rust, les conteneurs Python et les conteneurs C++ couvrent le reste.

Plateforme · Moteurs no-code

Quatre moteurs no-code. Zéro fichier Rust.

MSP pour les graphes de traitement de signal continus. MEP pour les politiques machine à états (primitives T·C·A sous le capot). Multi Stacks pour la communication véhicule et IoT industriel. AI Funnel pour l'IA edge déclarative. Les quatre sont testables hors cible sans matériel dans la boucle.

Parler à l'équipe technique Lire le SDK

MSP — graphes de traitement de signal continus
Visualiseur complet sur la page MSP →

MEP — automatisation de politique machine à états
Designer complet sur la page MEP →

Éditeur JSON Multi Stacks — pile J1939_Truck avec sections Protocol, Q+R Actions, Broadcast et Strategy mises en évidence — Multi Stacks — piles de protocoles définies en JSON
Catalogue complet sur la page Multi Stacks →

Éditeur AI Funnel — configuration TOML live_anonymization, graphe pipeline (camera → triage → preprocess → ONNX face_detector + TFLite plate_detector → MCM anonymizer) et le triplet TOML + Modèles + Dataset — AI Funnel — IA edge déclarée en TOML
Pipeline complet sur la page AI Funnel →

Comparaison des moteurs

Quatre moteurs · une seule plateforme.

Comparaison MSP / MEP / Multi Stacks / AI Funnel
Dimension	MSP	MEP	Multi Stacks	AI Funnel
Modèle	Graphe dataflow typé nœuds-et-arêtes	Machine à états via règles T·C·A	Protocole / Q+R / Diffusion / Stratégie	Graphe TOML + ONNX/TFLite + dataset
Exécution	Continue, toujours active	Événementielle, réactive	Périodique + composée (MSP/MEP)	Caméra → GPU → NPU sur device
Création	Graphe YAML + éditeur Streamlit navigateur	Politique YAML + designer de politique visuel	Pile JSON + catalogue default-stacks/	Graphe TOML + pipeline réentraînement cloud
Validation hors cible	CLI msp-run avec entrées CSV (macOS)	Runner msp-standalone + mep-lint	Simulateur ECU sur CAN virtuel	Faux runtime IA + faux shader ROI GPU
Rechargement à chaud	Appel de service LoadGraph, sans re-flash	Politique échangée en vol, sans redémarrage	Édition JSON de pile + commit	Canal OTA — même que OTA code
Catalogue	226 graphes · 21 domaines véhicule	3 types de déclencheur · 5 types d'action	16 familles de protocoles · 22 piles par défaut	Modèle client + dataset COCO

MEP — politiques machine à états (T·C·A sous le capot)

Automatisation de politique sans code procédural.

Le product owner lit MEP comme des politiques machine à états sur le device. L'ingénieur lit le même YAML comme des primitives Trigger / Condition / Action. Le nouveau YAML de politique est validé et échangé avec vidage des règles en vol — pas de redémarrage de processus, pas de redémarrage du device.

Trois types de déclencheur

Types de déclencheur MEP
Déclencheur	Exemple	Usage typique
Changement de clé DB	vehicle.speed dépasse 90 km/h	Alertes de seuil, changements de taux d'échantillonnage
Événement nommé	sos.button.pressed	Transfert d'interruption matérielle, événements micro service
Cron / périodique / ponctuel	toutes les 15 min, UTC	Reporting planifié, heartbeats

Action call_interface

L'action action call_interface dispatche vers MSP, Multi Stacks, tout pilote personnalisé ou tout micro service via un proxy type-safe avec validation de version semver et un timeout configurable (3 000 ms par défaut). Les dépendances de micro service sont déclarées avec des plages semver et se dégradent gracieusement à l'exécution.

Un designer de politique visuel génère du YAML valide depuis un graphe de nœuds et découvre automatiquement les déclarations requires pour les ingénieurs préférant une surface de création visuelle. Le même designer rend le diagramme d'état pour la revue produit.

Page détaillée MEP →

MSP — Dataflow continu

226 graphes. 21 domaines. Budget CPU à un seul chiffre.

Éditeur navigateur 116 noyaux

Un canvas navigateur liste les 116 types de noyaux, valide la structure du graphe contre le schéma JSON en temps réel, et exporte le .msp.yml que le runtime lit directement.

Injection runtime via MQTT

Pousser de nouveaux graphes vers un device en fonctionnement via MQTT sans mise à jour firmware. Le catalogue de 21 domaines — crash, batterie EV, carburant, GNSS, flotte, route et plus — fournit un point de départ pour la télémétrie véhicule sans création depuis zéro.

Page détaillée MSP →

Multi Stacks — Communication véhicule + IoT industriel

Quatre éléments par pile. 16 familles de protocoles.

Chaque déploiement Multi Stacks, bus véhicule ou IoT Modbus, déclare quatre parties mobiles : Protocole, Question + Réponse, Diffusion, Stratégie. Les piles sont des fichiers de données JSON ; les modifications de protocole sont des éditions JSON.

22 piles par défaut livrées avec l'OS

OBD-II, UDS, J1939, ISOBUS, OBFCM, Modbus RTU/TCP, CANopen — validées à chaque push CI via des tests Python/pytest autonomes. Les nouvelles piles vivent dans le contrôle de version, pas dans les builds firmware.

Se compose avec MSP et MEP

Stratégie périodique par défaut. Séquences pilotées par signal via MSP (un graphe déclenche une requête UDS) ; séquences pilotées par événement via MEP (une règle se déclenche sur un événement nommé et exécute une action de pile). La stratégie avancée reste déclarative.

Page détaillée Multi Stacks →

AI Funnel — IA edge déclarative

Graphe TOML en entrée. OTA en sortie. Pas de toolchain sur device.

Le client livre un graphe TOML plus un modèle ONNX/TFLite et un dataset COCO. Le cloud Munic réentraîne, quantise, valide, emballe et déploie via OTA. Le runtime sur device exécute caméra → GPU → NPU avec zéro copie de pixels.

Même canal OTA que le code

Un réentraînement de modèle passe par le même canal OTA qu'une mise à jour de micro service — déploiement progressif, épinglage de version, rollback de flotte tous unifiés entre code et modèles.

Zéro lecture pixel CPU

Le GPU recadre et redimensionne la région d'intérêt ; le runtime IA pilote le NPU. La caméra, le GPU et le NPU partagent la mémoire directement — le handle se déplace, les données pixel restent en place. Le détail du runtime est la preuve que le modèle déclaratif est réel.

Page détaillée AI Funnel →

Validation hors cible

Tests de niveau CI sans device — sur les quatre moteurs.

Outils de validation hors cible
Outil	Moteur	Ce que cela détecte
msp-run	MSP	Exécution de graphe sur entrée CSV sur macOS, sans device
mep-standalone	MEP	Relecture complète de politique avec fichiers YAML de scénario
mep-lint	MEP	Erreurs de schéma, clés DB non définies, graphes de règles cycliques, erreurs de type d'expression
Simulateur ECU	Multi Stacks	Simulation ECU sur CAN virtuel — suites de régression UDS, OBD-II, ISO-TP sans banc physique
Faux runtime IA	AI Funnel	Stub d'inférence pour CI ; aucun matériel NPU requis

Chaque moteur no-code a un runner hors cible. Un format YAML/JSON/TOML correct et un contrat de données restent requis — ces outils valident la surface de configuration, pas l'intégration matérielle.

Prêt à l'emploi, ensemble

Un conteneur Python pilote les quatre moteurs.

Les quatre moteurs ne sont pas des silos. Un seul conteneur Python, communiquant avec le broker MQTT in-process, peut piloter MSP, MEP, Multi Stacks et AI Funnel depuis un seul processus — pas de toolchain Rust, pas de SDK par moteur, pas de glue personnalisée.

MSP · pousser un graphe

c.publish(
    "mos/msp/LoadGraph",
    json.dumps({"name": "harsh_brake", "yaml": yaml_str}),
)

MEP · charger une politique

c.publish(
    "mos/mep/LoadPolicy",
    json.dumps({"name": "geofence", "yaml": policy_str}),
)

Multi Stacks · charger une pile

c.publish(
    "mos/multi-stacks/LoadStack",
    json.dumps({"name": "j1939_truck", "json": stack_json}),
)

AI Funnel · s'abonner aux détections

c.subscribe("mos/ai-runtime/detections")
c.on_message = lambda _c, _u, m: handle(m.payload)

Même client MQTT, quatre moteurs, aucune limite de langage. Tout runtime compatible MQTT — C, C++, Go, Rust, JavaScript — peut faire de même.

Quand le no-code ne suffit pas

Trois niveaux de programmation · conçus pour coexister.

Un produit MOS4 typique mélange MSP pour le traitement de signal continu, MEP pour la politique machine à états, Multi Stacks pour la communication véhicule ou Modbus, AI Funnel pour l'IA edge, un micro service Rust personnalisé pour l'algorithme genuinement inédit, et un conteneur Python ou C++ pour le classifieur de l'équipe data-science.

Les quatre moteurs no-code partagent un registre et un runtime avec chaque micro service Rust et conteneur sur le device. Voir l'architecture plateforme pour la façon dont les moteurs s'articulent, et les micro services pour la couche cloud-connect et d'intégration au-delà du device.

Voir le SDK complet →

FAQ

Questions fréquentes

Comment les quatre moteurs s'articulent-ils ?

MSP produit des signaux nommés continus depuis les capteurs et les entrées bus. MEP réagit aux déclencheurs discrets (seuil signal, événement, cron) avec des politiques machine à états. Multi Stacks communique avec les bus véhicule et les appareils IoT industriel, piloté périodiquement ou composé avec MSP/MEP. AI Funnel exécute l'IA edge déclarative — un graphe TOML plus un modèle et un dataset ; le cloud Munic réentraîne et déploie via OTA. Les quatre moteurs partagent un OS, un canal OTA et une approche de validation hors cible.
MEP est-il une machine à états ou un moteur T·C·A ?

Les deux lectures sont disponibles. Le product owner lit MEP comme des politiques machine à états sur le device — le YAML de politique est la machine à états. L'ingénieur lit le même YAML comme des primitives Trigger / Condition / Action. Il n'y a pas de runtime machine à états séparé ; l'ensemble de règles composé est la machine à états.
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/.
Faut-il du matériel pour tester une politique ou un graphe ?

Non. Le runner autonome MEP rejoue les fichiers YAML de scénario hors cible ; l'outil lint MEP détecte les erreurs statiquement. Le runner MSP exécute tout .msp.yml avec des entrées CSV sur macOS. Le simulateur ECU intégré couvre Multi Stacks sur CAN virtuel. Le faux runtime IA stub l'inférence pour CI d'AI Funnel. Les quatre moteurs ont des runners hors cible de niveau CI.
Cela nécessite-t-il du Rust ?

Non. Les quatre moteurs se configurent avec YAML, JSON et TOML. Le runtime est en Rust, mais la surface de création est des fichiers de données. Un conteneur Python peut piloter n'importe lequel des moteurs via le broker MQTT in-process — voir « Prêt à l'emploi, ensemble » ci-dessous.
Quand le chemin SDK s'applique-t-il ?

Quand l'algorithme ne peut genuinement pas être exprimé comme un graphe, une politique, une pile ou un graphe IA TOML. Logique de détection inédite, inférence de modèle propriétaire, intégration matérielle personnalisée. Les quatre moteurs no-code couvrent la majeure partie de la surface de comportement du device ; les micro services Rust, les conteneurs Python et les conteneurs C++ couvrent le reste.

Apportez un YAML, un JSON ou un TOML.

Montrez-nous le comportement du device, le protocole, l'extraction de signal ou la tâche d'inférence ; nous le mapperons au bon moteur sur un appareil de développement.

Parler à l'équipe technique Lire Multi Stacks →