Plateforme · MSP
Traitement du signal véhicule comme graphe YAML.
MSP est le moteur de traitement du signal de MOS4. Un graphe de nœuds kernel typés s'exécute en continu sur l'appareil sur 21 domaines véhicule. Modifiez un fichier .msp.yml et poussez-le via un appel de service — sans recompilation Rust, sans flash de firmware.
Échelle
226 graphes sur 21 domaines véhicule.
| Domaine | Exemples de graphes |
|---|---|
| Choc et impact | détection de choc, déclencheur FNOL |
| Batterie VE | état de charge, indice de dégradation |
| Carburant | taux de consommation, fusion niveau de réservoir |
| GNSS et route | segmentation de trajet, classification type de route |
| Comportement conducteur | freinage brusque, score de virage |
| Vibration | indice d'usure pour maintenance prédictive |
| Flotte | détection de ralenti, compteur d'heures de marche |
| Tension et alimentation | santé batterie, réveil sur seuil |
| Bande passante CAN | mesure charge bus, décimation |
| Température | gradients thermiques, confort habitacle |
| Vitesse et cinématique | alertes sur-vitesse, enveloppes d'accélération |
| Moteur et transmission | analyse RPM, estimation couple |
| Événements géozone | génération de signaux entrée de zone |
| Chargement et poids | signaux d'estimation de charge essieu |
| Environnement | humidité, température ambiante |
| TPMS | analyse tendance pression pneus |
| Diagnostics | signal présence DTC, corrélation de pannes |
| Remorque | connexion/déconnexion, état éclairage |
| Sécurité | ceinture, événement porte ouverte |
| Maritime / off-highway | heures moteur, signaux réservoir |
Trois outils
Créer. Déboguer. Concevoir.
Le workflow de développement MSP couvre trois outils qui couvrent la boucle complète : de la création et validation d'un graphe hors ligne, au débogage en direct sur un appareil connecté, jusqu'à l'édition visuelle avec la palette de kernels.
Notebook Jupyter + harnais bench
Créez le graphe dans un environnement notebook Jupyter. Rejouez-le sur des enregistrements
de datasets, inspectez les formes d'onde et exécutez le harnais bench pour obtenir
un score F1 par seuil de détection — plus des estimations de RAM, CPU et latence — avant de
toucher un appareil.
Débogage en direct — msp-visualizer
Un outil React/TypeScript qui liste les graphes en cours, interroge la topologie des nœuds, affiche les temps de benchmark par kernel et diffuse des échantillons de signaux en direct via WebSocket. Aucun outillage supplémentaire requis sur un appareil de développement.
Designer MSP
Un canvas basé navigateur avec une palette de kernels. Glissez et connectez des nœuds kernel, validez la structure du graphe contre le schéma JSON en temps réel, puis exportez le .msp.yml consommé directement par le runtime.
Envoyez-nous votre graphe de signaux — nous le câblons.
Boucle de développement
Du notebook au graphe déployé — une boucle reproductible.
La boucle de développement MSP est un cycle en quatre étapes qui réduit la distance entre la création hors ligne et le comportement sur appareil.
Étape 1
Créer et valider
Construisez le graphe dans l'environnement Jupyter. Rejouez-le sur des enregistrements de datasets et vérifiez visuellement les formes d'onde avant de valider dans un fichier YAML.
Étape 2
Score F1 contre dataset de référence
Exécutez le harnais bench contre un dataset annoté. Obtenez un score F1 par seuil
de détection — reproductible entre exécutions et entre ingénieurs.
Étape 3
Estimation RAM / CPU / Latence
Le même harnais rapporte la consommation de ressources. L'estimation devient le contrat pour le build appareil — pas de surprise après le flash.
Étape 4
Déployer avec les résultats attendus
Poussez le graphe vers l'appareil via un appel de service. Le comportement en direct sur l'appareil correspond au score F1 hors ligne et à l'enveloppe de ressources validés aux étapes 2 et 3.
Architecture des signaux
Trois tiers, une API stable.
Une API stable de signaux nommés connecte les Tiers 2 et 3. Les entrées capteurs et bus du Tier 1 alimentent les signaux fondamentaux du Tier 2 ; les graphes de détection du Tier 3 consomment les noms, pas les flux bruts. Un nouveau capteur ou PID se propage uniquement dans le Tier 1.
Architecture de signaux MSP à trois tiers. Le Tier 1 contient les entrées capteurs et bus — Multi Stacks SubscribeData, GNSS, IMU et frames CAN bruts. Le Tier 1 alimente le Tier 2, qui contient la couche de signaux fondamentaux (vehicle.speed, gnss.latitude et autres). Le Tier 2 alimente le Tier 3, les 226 graphes de détection sur 21 domaines — choc, freinage brusque, ralenti et autres algorithmes spécifiques au domaine. Le Tier 3 publie vers trois consommateurs aval : le moteur de politique, le service de logs et le broker MQTT pour la sortie cloud.
flowchart TB T1[Tier 1 — capteurs et bus<br/>Multi Stacks SubscribeData<br/>GNSS · IMU · frames CAN] T2[Tier 2 — signaux fondamentaux<br/>vehicle.speed · gnss.latitude<br/>215+ signaux nommés] T3[Tier 3 — graphes de détection<br/>choc · freinage brusque · ralenti<br/>226 graphes, 21 domaines] T1 --> T2 --> T3 T3 -->|publie| MEP[mos-event-processor] T3 -->|publie| LG[mos-logs] T3 -->|publie| MQ[broker MQTT]
Injection à l'exécution
Poussez un graphe sans flash de firmware.
| Méthode | Description |
|---|---|
| LoadGraph | Pousse un graphe .msp.yml vers le runtime en cours ; pas de redémarrage |
| EnableGraph | Active un graphe chargé par nom |
| DisableGraph | Suspend un graphe ; l'état est préservé |
| DropGraph | Supprime un graphe et libère ses ressources |
| ListGraphs | Énumère les graphes chargés avec leur statut de cycle de vie |
| GetGraphInfo | Retourne la topologie et la liste de kernels d'un graphe |
Piloter MSP depuis un conteneur
LoadGraph depuis n'importe quel client MQTT. Rust non requis.
L'appel de service MSP est accessible depuis un conteneur Python via le broker MQTT in-process. Un ingénieur produit pousse un nouveau graphe depuis un script Python — le runtime le valide et le permute en direct.
Conteneur Python · LoadGraph via MQTT
# dans n'importe quel conteneur Python — sans chaîne Rust
import paho.mqtt.client as mqtt, pathlib, json
graph_yaml = pathlib.Path("harsh_brake.msp.yml").read_text()
c = mqtt.Client()
c.connect("localhost", 1883)
c.publish(
"mos/msp/LoadGraph",
json.dumps({"name": "harsh_brake", "yaml": graph_yaml}),
)Le même appel de service est disponible depuis C, C++, Go, Rust — ou depuis n'importe quel langage qui parle MQTT. Le runtime est à un conteneur de distance. Explorer le SDK pour le contrat de service complet.
Planificateur
Cinq catégories de cycle de vie pour le contrôle du cycle de service CPU.
| Catégorie | Comportement du planificateur |
|---|---|
| always_on | Actif dès le démarrage ; jamais arrêté par le planificateur |
| event_spawned | Démarré sur un événement nommé ; arrêt automatique à la fin |
| confidence_gated | S'exécute seulement quand la confiance d'entrée dépasse le seuil |
| condition_gated | Actif tant qu'une clé DB ou un signal remplit une condition |
| intermittent | Activation périodique avec cycle de service configurable |
Le planificateur active et arrête automatiquement les graphes selon la catégorie, gardant la charge CPU au ralenti faible sans gestion manuelle du cycle de vie dans le code applicatif.
Observabilité
Tap de signaux en direct et benchmarks par kernel.
msp-visualizer
Un outil React/TypeScript liste les graphes en cours, interroge la topologie des nœuds, affiche les temps de benchmark par kernel et diffuse des échantillons de signaux en direct via WebSocket. Aucun outillage supplémentaire requis sur un appareil de développement.
Signaux nommés comme API inter-graphes
Les signaux nommés — vehicle.speed, gnss.latitude et autres — sont
l'API stable entre les graphes. Les auteurs de graphes aval consomment des signaux nommés, pas
des flux matériels bruts ; les changements de capteurs ne se propagent pas dans le catalogue
de graphes.
Catalogue de modules noyau
124 modules noyau sur 9 catégories.
La bibliothèque de modules noyau couvre toute la gamme du traitement du signal de télémétrie véhicule — de l'arithmétique de base et des chaînes de filtres à la géométrie GNSS, la détection d'événements et la gestion de l'énergie. Échantillon affiché ci-dessous ; l'ensemble complet est navigable depuis le designer MSP.
Math/arithmetic
18Opérateurs scalaires et accumulateurs temporels.
- Valeur absolue
- Accumulateur
- Dérivée
- Intégrateur
- Médiane
- · et 13 de plus
Filters/DSP
23Filtres IIR/FIR, ondelettes, ré-échantillonneurs, hystérésis.
- Filtre Chebyshev type-II
- Convolution
- Suppresseur de composante DC
- Sous-échantillonneur
- Hystérésis
- · et 18 de plus
Event detection
9Primitives de seuil et de porte pour événements discrets.
- Anti-rebond asymétrique
- Porte d'événement
- Détecteur de pic
- Stabilité dans la bande
- Seuil
- · et 4 de plus
Vehicle/sensor
10Interfaces GNSS, IMU, OBD et autres côté capteurs.
- Source GNSS
- Déplacement GNSS
- Distance GNSS
- Estimateur de gravité
- Flux IMU
- · et 5 de plus
Codec/IO
19Compression, sérialisation, CSV et codeurs de trames.
- Compression bzip2
- Assemblage trame CAN
- Compression trame CAN
- Parseur CSV
- Écrivain CSV
- · et 14 de plus
Time/control
10Bases de temps, planificateurs, machines à états.
- Source d'horloge murale
- Découpeur temporel
- Lecture/écriture base de données
- Tic périodique
- Générateur de signal
- · et 5 de plus
Geometry/algebra
4Rotation 3-D, atan2, constructeurs de matrices.
- atan2
- Constructeur de matrice
- Rotation 3-D
- Transformation de rotation
Graph plumbing
26Pub/sub entre graphes, compteurs, sondes.
- Compteur
- Écrivain DB
- Drop
- Fusion de flux
- Sonde
- · et 21 de plus
Energy/power
5Ratios d'énergie, classifieurs de puissance, intégrateurs persistants.
- Profil de distance
- Ratio d'énergie
- Intégrateur persistant
- Classifieur de puissance
- Publieur événement de puissance
Besoin d'un module noyau absent du catalogue ? Munic en ajoute par programme — parlez à l'ingénierie.
En contexte
MSP dans la chaîne de signaux MOS4.
MSP se situe entre le bus véhicule et le cloud. Multi Stacks livre les frames bruts ; MSP les transforme en signaux nommés ; le processeur d'événements et le broker MQTT les acheminent vers le cloud.
Plateforme no-code
MSP est l'un des moteurs no-code de MOS4. Explorez la surface no-code complète aux côtés du processeur d'événements et de la couche de configuration flotte.
Multi Stacks — entrée Tier 1
Multi Stacks décode les frames CAN bruts et les PIDs OBD et les publie comme entrées Tier 1 que les graphes MSP consomment.
OBDStacks — source de signaux OBD
OBDStacks alimente le flux de PIDs OBD dans les signaux Tier 1 de MSP sur les domaines diagnostics et groupe motopropulseur.
SDK — poussez des graphes par programmation
Le SDK expose le contrat de service MSP complet. Poussez, activez et désactivez des graphes depuis n'importe quel conteneur ou intégration cloud.
Apportez le signal que vous voulez extraire.
Montrez-nous le domaine véhicule et l'algorithme ; nous créerons le graphe avec vous sur l'appareil cible de votre choix.