Code in sechs Sprachen ausliefern — auf einer Laufzeit, die die Box besitzt.

Kennzahlen

Die Zahlen, die die Integration dimensionieren.

89 typisierte Schnittstellen Services über 16 gemeinsame Typ-Pakete

180 Plattform-Features deklarierte Service-Oberflächen im OS

10 s Hot-Swap Rust-micro service, Ende-Compilierung bis zum ersten Service-Aufruf auf Gerät

<5% Container-Overhead CPU/RAM; ~10 MB RSS. MCM-Container-Budget-Envelope.

Installation

SDK in einem Kommando hinzufügen.

Zwei Referenz-Client-Bibliotheken decken Rust und Python ab. Andere Sprachen erreichen MOS4-Services über die MQTT-Bridge — kein sprachspezifisches SDK erforderlich.

cargo add mos-sdk-client

pip install mos-sdk-client

Lua, Go, C und C++ erreichen dieselbe Service-Oberfläche über die In-Process-MQTT-Bridge — siehe die Quickstart-Dokumentation für sprachspezifische Beispiele.

MQTT-Bridge

Jeder Client. Jede Sprache. Kein Munic-SDK.

MOS4 bettet einen MQTT-Broker In-Prozess ein. Payloads werden als reines JSON oder als typisiertes binäres Format akzeptiert; JSON wird am Eingang transcodiert. Ein retained Service-Katalog ermöglicht Clients, verfügbare Services zur Verbindungszeit zu entdecken.

sequenceDiagram
  participant Py as Python-Container<br/>(paho-mqtt)
  participant MQ as MQTT-Broker<br/>(in-process)
  participant Svc as MSP-Service
  Py->>MQ: PUBLISH mos/rpc/MspService/LoadGraph<br/>JSON oder typisierter Payload
  Note over MQ: JSON zu typisiertem Aufruf am Eingang transcodieren
  MQ->>Svc: typisierter Aufruf LoadGraph(graph)
  Svc-->>MQ: Antwort
  MQ-->>Py: PUBLISH mos/rpc/MspService/LoadGraph/reply
  Note over Py,MQ: beliebige MQTT-Client-Bibliothek, beliebige Sprache — kein Munic-SDK erforderlich

import json
import paho.mqtt.client as mqtt

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

# Über MQTT-Bridge zu jeder micro service-Schnittstelle publizieren
client.publish(
    "mos/rpc/MspService/LoadGraph",
    payload=json.dumps(graph_json),
)

Rust-micro service-Authoring

Eine Annotation. Dreißig Zeilen.

Rust-Entwickler, die einen nativen micro service schreiben, annotieren eine Struct mit #[component] und fügen einen build.rs-Aufruf hinzu. Das Framework generiert Service-Dispatch, Proxy-Erstellung, Lifecycle-Verdrahtung, Config-Accessoren, Observability-Instrumentierung und einen Fake für Unit-Tests.

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> {
        // Ihre Logik — Observability und Lifecycle werden vom Framework verdrahtet
        Ok(Response { ok: true })
    }
}

// build.rs — einzelner Aufruf generiert Server-Trait, Proxy, Fake, Metriken
fn main() {
    build_api::generate_component_code(env!("CARGO_MANIFEST_DIR"), "src");
}

Generierte Fakes kompilieren ohne einen laufenden MOS4-Daemon — Unit-Tests laufen auf jedem Host.

Konsole

Ein Binary. Shell, REST, Web, Seriell.

Cloud-gesteuerte Flows

Jeden micro service aus der Cloud über die RPC-Bridge aufrufen.

Die RPC-Bridge leitet JSON-Aufrufe von externen Clients zu jedem registrierten MOS4-Service — einschließlich Container. method ListServices() stellt den Live-Katalog zur Laufzeit bereit. Anwendungsfälle: Remote-Debug, Entsperren seltener Feldsituationen und Hybrid-Flows, bei denen ein KI-Agent oder ein Cloud-Service das Gerät steuert. Siehe micro services für Cloud-seitige Oberflächen und Integrations-Muster.

Der interne RPC-Port ist standardmäßig nicht verfügbar. Externer Zugriff geht über die MQTT-Bridge oder die RPC-Bridge — keine direkte Port-Exposition für Tooling.

Was Sie bringen vs. was wir bringen

Ehrliche Aufteilung.

FAQ

Häufig gestellte Fragen

• Welche Sprachen werden mit vorgefertigten Basis-Images geliefert?

  Python, Rust, C, C++, Go und Lua — sechs Sprach-Laufzeiten mit OCI-Container-Beispielen und CI-erzwungenen Image-Größen-Budgets über 15 (Sprache, Szenario)-Paare.

• Wie funktioniert die MQTT-Bridge?

  MOS4 bettet einen MQTT-Broker In-Prozess ein — kein externer Broker erforderlich. Payloads werden als reines JSON oder als typisiertes binäres Format akzeptiert; JSON wird am Eingang transcodiert. Ein retained Service-Katalog ermöglicht Clients, verfügbare Services zur Verbindungszeit zu entdecken. Jede MQTT-Client-Bibliothek, jede Sprache — erreicht MOS4-Services ohne Munic-SDK.

• Wie schnell ist Hot-Swap?

  10 Sekunden vom Ende des Compilierens bis zum ersten erfolgreichen Service-Aufruf auf einem echten Gerät. Wenn ein neuer Prozess einen micro service mit einer bestehenden component.id registriert, stoppt der Master die alte Instanz, injiziert serialisierten Zustand und startet den Ersatz. Kein Reflash. Hot-Swap ist eine Rust-micro service-Funktion; Container (Python, C, C++, Go) folgen einem anderen OTA-Update-Pfad.

• Was ist das Container-Overhead-Budget?

  Das MCM-Container-Budget-Envelope liegt unter 5% CPU/RAM-Overhead und ca. 10 MB RSS pro Container. Das mcm-Standalone-CLI ist auf Produktions-Images vorinstalliert.

• Ist der interne RPC-Port für direktes Tooling verfügbar?

  Der interne RPC-Port ist standardmäßig nicht verfügbar. Die RPC-Bridge leitet JSON-Aufrufe von externen Clients zu jedem registrierten MOS4-Service weiter; MQTT-Bridge oder RPC-Bridge für externen Zugriff verwenden.

• Wofür ist die RPC-Bridge?

  Die RPC-Bridge ruft jeden MOS4-Service — einschließlich Container — aus der Cloud via API auf. Anwendungsfälle: Remote-Debug, Entsperren seltener Feldsituationen und Hybrid-Flows, bei denen ein KI-Agent das Gerät steuert. Kein Protokoll- oder Verdrahtungs-Code über die Services und einen Cloud-seitigen Endpunkt hinaus.

Entwicklerwerkzeuge

KI-bewusste Werkzeuge für MOS4-Entwickler.

Das MOS4-Entwicklerpaket erweitert das SDK um einen MCP-Connector, einen Konfigurationslinter, Log-Reader und Projektgraph-Abfragen — damit die KI-Tools, die Ihr Team bereits verwendet, die Plattform verstehen. Verfügbar mit Engineering.