Livrez votre code en six langages, sur un runtime qui détient l'appareil.

Métriques clés

Les chiffres qui dimensionnent l'intégration.

89 interfaces typées services sur 16 packages de types partagés

180 fonctionnalités plateforme surfaces de service déclarées dans l’OS

10 s hot-swap Micro service Rust, de la fin de compilation au premier appel sur device

<5% surcharge conteneur CPU/RAM ; ~10 Mo RSS. Enveloppe de budget conteneur MCM.

Installation

Ajoutez le SDK en une commande.

Deux bibliothèques clientes de référence couvrent Rust et Python. Les autres langages atteignent les services MOS4 via le pont MQTT — pas de SDK spécifique au langage requis.

cargo add mos-sdk-client

pip install mos-sdk-client

Lua, Go, C et C++ atteignent la même surface de service via le pont MQTT in-process — voir la documentation quickstart pour des exemples par langage.

Pont MQTT

Tout client. Tout langage. Sans SDK Munic.

MOS4 embarque un broker MQTT in-process. Les payloads sont acceptés en JSON simple ou en format binaire typé ; le JSON est transcodé à l'entrée. Un catalogue de services retained permet aux clients de découvrir les services disponibles à la connexion.

sequenceDiagram
  participant Py as Conteneur Python<br/>(paho-mqtt)
  participant MQ as Broker MQTT<br/>(in-process)
  participant Svc as Service MSP
  Py->>MQ: PUBLISH mos/rpc/MspService/LoadGraph<br/>payload JSON ou typé
  Note over MQ: transcode JSON vers appel typé à l'entrée
  MQ->>Svc: appel typé LoadGraph(graph)
  Svc-->>MQ: réponse
  MQ-->>Py: PUBLISH mos/rpc/MspService/LoadGraph/reply
  Note over Py,MQ: toute bibliothèque client MQTT, tout langage — sans SDK Munic requis

import json
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.connect("localhost", 1883)

# Publier vers toute interface de micro service via le pont MQTT
client.publish(
    "mos/rpc/MspService/LoadGraph",
    payload=json.dumps(graph_json),
)

Création de micro service Rust

Une annotation. Trente lignes.

Les développeurs Rust écrivant un micro service natif annotent une struct avec #[component] et ajoutent un appel build.rs. Le framework génère le dispatch de service, la création de proxy, le câblage du cycle de vie, les accesseurs de config, l'instrumentation d'observabilité et un faux pour les tests unitaires.

use mos_sdk::component;

#[component]
pub struct MyService {
    config: MyConfig,
}

#[async_trait::async_trait]
impl provided::my::MyServiceServer for MyService {
    async fn do_thing(&self, req: Request) -> Result<Response> {
        // votre logique — observabilité et cycle de vie câblés par le framework
        Ok(Response { ok: true })
    }
}

// build.rs — appel unique qui génère le trait serveur, proxy, faux, métriques
fn main() {
    build_api::generate_component_code(env!("CARGO_MANIFEST_DIR"), "src");
}

Les faux générés compilent sans daemon MOS4 en cours — les tests unitaires s'exécutent sur n'importe quel hôte.

Console

Un binaire. Shell, REST, web, série.

Flux pilotés par le cloud

Appeler tout micro service depuis le cloud via le pont RPC.

Le pont RPC achemine les appels JSON des clients externes vers tout service MOS4 enregistré — y compris les conteneurs. method ListServices() expose le catalogue live à l'exécution. Cas d'usage : debug distant, déblocage de situations terrain rares, et flux hybrides où un agent IA ou un service cloud pilote le device. Voir Micro services pour les surfaces côté cloud et les patterns d'intégration.

Le port RPC interne n'est pas exposé par défaut. L'accès externe passe par le pont MQTT ou le pont RPC — pas d'exposition directe de port pour l'outillage.

Ce que vous apportez vs ce que nous apportons

Répartition honnête.

FAQ

Questions fréquentes

• Quels langages sont livrés avec des images de base pré-construites ?

  Python, Rust, C, C++, Go et Lua — six runtimes de langage avec exemples de conteneur OCI et budgets de taille d'image imposés en CI sur 15 paires (langage, scénario).

• Comment fonctionne le pont MQTT ?

  MOS4 embarque un broker MQTT in-process — pas de broker externe requis. Les payloads sont acceptés en JSON simple ou en format binaire typé ; le JSON est transcodé à l'entrée. Un catalogue de services retained permet aux clients de découvrir les services disponibles à la connexion. Toute bibliothèque cliente MQTT, tout langage — atteint les services MOS4 sans SDK Munic requis.

• Quelle est la vitesse du hot-swap ?

  10 secondes de la fin de compilation au premier appel de service réussi sur un vrai device. Quand un nouveau processus enregistre un micro service avec un component.id existant, le master arrête l'ancienne instance, injecte l'état sérialisé et démarre le remplacement. Pas de re-flash. Le hot-swap est une fonctionnalité des micro services Rust ; les conteneurs (Python, C, C++, Go) suivent un chemin de mise à jour OTA différent.

• Quel est le budget de surcharge du conteneur ?

  L'enveloppe de budget conteneur MCM est inférieure à 5% de surcharge CPU/RAM et environ 10 Mo de RSS par conteneur. Le CLI autonome mcm est préinstallé sur les images de production.

• Le port RPC interne est-il exposé pour l'outillage direct ?

  Le port RPC interne n'est pas exposé par défaut. Le pont RPC achemine les appels JSON des clients externes vers tout service MOS4 enregistré ; utilisez le pont MQTT ou le pont RPC pour l'accès externe.

• À quoi sert le pont RPC ?

  Le pont RPC appelle tout service MOS4 — y compris les conteneurs — depuis le cloud via API. Cas d'usage : debug distant, déblocage de situations terrain rares, et flux hybrides où un agent IA pilote le device. Pas de code de protocole ou de câblage au-delà de le service et d'un endpoint côté cloud.

Outils développeur

Outillage adapté à l'IA pour les développeurs MOS4.

Le pack développeur MOS4 étend le SDK avec un connecteur MCP, un linter de configuration, des lecteurs de logs et des requêtes sur le graphe de projet — pour que les outils IA déjà utilisés par votre équipe comprennent la plateforme. Disponible avec l'ingénierie.