Plateforme · Outils développeur
Développez sur MOS4 avec une chaîne d'outils adaptée à l'IA.
Un pack développeur qui vous accompagne sur tout le parcours — d'un device simulé sur votre ordinateur portable, à travers la livraison continue vers le parc, jusqu'au matériel dans la boucle et à l'observabilité live sur le terrain. Il s'intègre aux outils IA déjà utilisés par votre équipe. Le pack est disponible avec l'ingénierie — utilisez-le pendant l'évaluation et jusqu'au déploiement.
Connecteur MCP pour MOS4
Votre assistant de code, connecté au catalogue MOS4.
Un connecteur Model Context Protocol permet à l'assistant de codage de votre équipe (Claude Code, Cursor, Continue ou tout client compatible MCP) de lire le catalogue MOS4, les interfaces de composants, le schéma de configuration et les logs du device live. Le connecteur expose des ressources typées — l'assistant sait où un micro service est câblé, quelle interface .proto il fournit, quelles clés de configuration il consomme et quelles surfaces de logs il émet.
-
Complétion adaptée au catalogue.
L'assistant connaît les micro services de production, leurs interfaces et leur surface de configuration.
-
Recherche typée par interface.
« Où est publié Position ? » retourne le service producteur, les services consommateurs et le contrat.
-
Lint de configuration.
Les fichiers de configuration sont validés contre le schéma live avant déploiement.
-
Lecture de logs live.
L'assistant lit les logs du device via la même surface de télémétrie que la plateforme.
Planification adaptée à l'architecture
Répond aux questions de planification sur le graphe de projet.
Les projets multi-services impliquent des graphes de dépendances, des contrats d'interface et un ordonnancement de cycle de vie. La chaîne d'outils lit le graphe de projet et répond aux questions de planification — de quoi dépend ce micro service ?, qu'est-ce qui casse si je modifie cette interface ?, quel test attraperait cette régression ?
-
Requêtes sur le graphe de dépendances.
Bidirectionnel — « qui dépend de X ? » et « de quoi X dépend-il ? ».
-
Refactors adaptés aux contrats.
Modifier une interface fait apparaître chaque consommateur qui doit suivre l'évolution.
-
Scaffolding adapté aux tests.
Les tests générés ciblent l'écart identifié par l'assistant.
Débogage adapté aux systèmes embarqués
Les logs d'un device contraint, lus comme une structure.
Les logs d'un device contraint ne ressemblent pas à ce sur quoi un assistant cloud est entraîné. Le pack développeur inclut des lecteurs de logs qui comprennent le superviseur, le pipeline OTA, la stack modem, le bus véhicule et l'AI Funnel — ainsi une règle MEP qui ne s'est pas déclenchée apparaît comme une trace de machine à états, pas comme du texte brut.
-
Traces adaptées au superviseur.
Le cycle de vie des conteneurs et la pression des ressources sont lus comme des événements, pas comme des octets.
-
Traces adaptées aux stacks.
Les trames J1939 / UDS / Modbus sont décodées en PGN / SID / adresse.
-
Traces adaptées à l'AI Funnel.
Les chemins vision et inférence apparaissent comme un pipeline, pas comme des logs.
La plateforme développeur
Au-delà de l'assistant — la chaîne d'outils qui livre le produit.
L'assistant accélère la façon dont vous écrivez un micro service. Le reste du pack le porte sur tout le parcours : développez face à un device simulé avant le silicium, livrez au parc depuis votre CI, prouvez-le sur du vrai matériel, vérifiez que votre modèle tient sur le device, et surveillez chaque service dans une seule vue. Toutes les surfaces ne sont pas en libre-service — la conversation d'ingénierie calibre celles qui sont actives pour votre programme.
Développer avant le matériel
Construisez face à un device simulé, pas à une liste d'attente.
Vous n'attendez pas les cartes. MOS4 est livré avec des runners hors-cible, pour que votre micro service tourne sur votre ordinateur portable et en intégration continue (CI) — piloté par des entrées simulées — avant même de toucher le silicium. Modélisez la poignée de main du Système d'exécution de fabrication (MES), le bus véhicule et le flux de capteurs, puis rejouez-les de manière déterministe.
-
Runners hors-cible.
Rejouez des politiques d’événements, exécutez des graphes de signaux sur des entrées enregistrées et faites tourner le runtime multi-stack sur un bus véhicule virtuel — sans device branché.
-
Modélisez les entrées, pas seulement le device.
Pilotez votre code avec un échange MES simulé, un trafic de bus véhicule scripté et des flux de capteurs. Composez le scénario ; rejouez-le de la même manière à chaque exécution.
-
Déterministe par conception.
Des exécutions isolées et reproductibles en CI. Une panne se reproduit sur la machine du prochain ingénieur — et pas seulement sur le banc.
-
Un stub pour le chemin IA.
Le runtime IA stubbe l'inférence pour qu'un pipeline AI Funnel s'exécute en CI sans modèle chargé sur un device.
-
Un bundle entier sur votre ordinateur portable.
Une commande démarre un bundle de micro services ensemble — la même topologie que vous livrez — pour que vous développiez contre le vrai câblage, pas un seul processus isolé.
-
Un banc pour chaque bus.
Rejouez du trafic J1939, CANopen, ISOBUS et Modbus contre votre code, injectez des messages à partir de gabarits, et explorez une timeline de trames capturées dans le navigateur — reproduisez un défaut terrain sur le banc avant qu'il n'atteigne un client.
De la CI au parc
Livraison continue de votre pipeline vers le terrain.
Chaque changement dans votre CI construit une image signée ; la livraison continue (CD) la déploie vers le parc par phases — un groupe canari d'abord, puis une vague progressive vers la disponibilité générale, avec pause et retour en arrière à chaque étape. Un tableau de bord vous donne une vue unique de chaque device, une interface de programmation (API) REST pilote les mêmes actions depuis votre propre outillage, et un moteur de règles route la télémétrie sans code de colle sur mesure. La surface de contrôle est construite sur ThingsBoard, liée à la plateforme.
-
Builds signés, déploiements par phases.
Un groupe canari d’abord, puis des vagues progressives vers tout le parc. Mettez en pause ou revenez en arrière à n’importe quelle phase — jamais de déploiement big-bang.
-
Un tableau de bord, une API.
Surveillez la santé du parc dans une vue unique et pilotez le provisionnement, la mise à jour et les requêtes via une REST API documentée.
-
Des règles, pas du code de colle.
Des chaînes de règles en glisser-déposer valident, transforment, routent et déclenchent des alarmes sur la télémétrie du device — et peuvent déclencher une mise à jour.
-
Votre CI, inchangée.
Conservez votre pipeline. La livraison s’attache à l’artefact : l’image signée que vous construisez déjà part vers le parc.
Tester sur du vrai silicium
Testez sur chaque variante matérielle, dans un rack hébergé.
La simulation vous amène presque au bout ; le dernier kilomètre tourne sur de vrais devices. Le matériel dans la boucle (HIL) place un rack des variantes matérielles que vous livrez derrière votre pipeline — hébergé dans le cloud Munic, ou déployé sur site derrière votre pare-feu. Étalez votre matrice de tests sur le rack et exécutez sur chaque carte en même temps, avec les logs, les traces et les performances capturés depuis le silicium qui a exécuté le test.
-
Chaque variante que vous livrez.
Des cibles modem-class, compute-class et AI-class dans un seul rack — testez la matrice, pas une seule carte.
-
Parallèle par défaut.
Étalez la suite sur le rack et exécutez sur chaque carte en même temps, au lieu d’une cible à la fois.
-
Cloud ou sur site.
Hébergé dans le cloud Munic, ou déployé sur site derrière votre pare-feu pour les programmes restreints.
-
Des preuves issues du métal.
Les logs, les traces et les chiffres de précision / latence proviennent du device qui a exécuté le test — pas d’une estimation.
Sachez qu'il tient avant de livrer
Découvrez si votre modèle tourne sur le device — avant l'intégration.
Apportez votre modèle entraîné. Le pipeline d'évaluation le profile face au niveau cible et retourne les chiffres qui décident d'un programme : latence d'inférence, empreinte mémoire et précision après optimisation sur device. L'outillage des opérations d'apprentissage automatique (MLOps) — Kubeflow pour le pipeline, MLflow pour le suivi et le registre de modèles — est lié au processus, pour que chaque exécution soit reproductible, versionnée et auditable.
-
Va-t-il tourner ? Obtenez le budget.
Le pipeline profile votre modèle face au budget de latence et de mémoire du niveau cible, et rapporte où il se situe.
-
Suivi et reproductible.
Kubeflow orchestre les exécutions ; MLflow suit chaque expérience, métrique et version de modèle dans le registre.
-
Validé sur le métal.
Le validateur matériel dans la boucle (HIL) rejette un candidat qui rate le seuil de précision ou de latence sur le matériel de référence.
-
Optimisé pour la périphérie.
L'optimisation sur device compresse le modèle à l'enveloppe de calcul — l'évaluation rapporte la précision que vous conservez.
-
Un registre de modèles sur le device.
Les modèles sont versionnés, téléchargés une fois et vérifiés par signature avant chargement — une source de vérité unique pour ce qui tourne sur chaque device, avec une CLI pour lister, récupérer et vérifier.
Une seule vue d'ensemble
Chaque micro service afflue vers Grafana, par défaut.
Il n'y a pas de projet d'instrumentation. Chaque micro service de l'OS expose un jeu de métriques compatible Prometheus et une surface OpenTelemetry dès le démarrage — visualisé dans des tableaux de bord Grafana à l'échelle du parc. Pointez votre propre conteneur vers le même endpoint de scrape et il apparaît aux côtés des services de l'OS dans la même vue. Métriques, logs et traces, sur des standards ouverts, sans stack séparée.
-
Des métriques sur chaque service.
Chaque micro service est scrapé par Prometheus dès le démarrage — aucun projet d’instrumentation par service à mener.
-
Votre conteneur, la même surface.
Exposez un endpoint de métriques sur votre propre conteneur et il afflue dans les mêmes tableaux de bord Grafana que les services de l’OS.
-
Standards ouverts, aucun verrouillage.
Compatible Prometheus et OpenTelemetry — pointez n’importe quel back end compatible vers la surface.
Conformité, en continu
Le même pipeline produit les preuves de conformité.
La livraison continue n'est pas seulement la façon dont le logiciel atteint le parc — c'est la façon dont les preuves sont produites. Chaque release embarque une nomenclature logicielle (SBOM) CycloneDX, une analyse CVE, des binaires signés et une surface OpenTelemetry. Les obligations du Cyber Resilience Act (CRA) de l'UE sont mappées article par article dans le pack de conformité — généré par le pipeline, pas ajouté après coup.
Dans le pack développeur
Ce qui est livré, et ce qui vient avec l'ingénierie.
Une partie du pack est dans l'OS aujourd'hui ; le reste est mis en route avec l'ingénierie pendant l'évaluation et jusqu'au déploiement — aucun chemin d'installation public, aucun portail en libre-service. La conversation d'ingénierie calibre les surfaces actives pour votre projet.
Parlez à l'ingénierie du pack développeur.
L'ingénierie vous présente les simulateurs, le pipeline de livraison, le rack matériel dans la boucle, l'évaluation de modèle et la surface d'observabilité pendant l'évaluation.