Plattform · Entwicklerwerkzeuge
Entwickeln Sie auf MOS4 mit einer KI-bewussten Toolchain.
Ein Entwicklerpaket, das den ganzen Weg mitgeht — von einem simulierten Gerät auf Ihrem Laptop über die kontinuierliche Auslieferung an die Flotte bis hin zu Hardware-in-the-loop und Live-Observability im Feld. Es integriert sich in die KI-Tools, die Ihr Team bereits verwendet. Das Paket ist mit Engineering verfügbar — nutzen Sie es während der Evaluierung und durch das Deployment hindurch.
MCP-Connector für MOS4
Ihr Coding-Assistent, verbunden mit dem MOS4-Katalog.
Ein Model Context Protocol Connector ermöglicht dem Coding-Assistenten Ihres Teams (Claude Code, Cursor, Continue oder ein beliebiger MCP-fähiger Client), den MOS4-Katalog, die Komponentenschnittstellen, das Konfigurationsschema und die Live-Gerätlogs zu lesen. Der Connector stellt typisierte Ressourcen bereit — der Assistent weiß, wo ein micro service verdrahtet ist, welche .proto-Schnittstelle er bereitstellt, welche Konfigurationsschlüssel er konsumiert und welche Log-Oberflächen er ausgibt.
-
Katalog-bewusste Vervollständigung.
Der Assistent kennt die Produktions-micro services, ihre Schnittstellen und ihre Konfigurationsoberfläche.
-
Schnittstellentypisierte Suche.
„Wo wird Position veröffentlicht?" gibt den produzierenden Service, die konsumierenden Services und den Vertrag zurück.
-
Konfigurationslinting.
Konfigurationsdateien werden vor dem Deployment gegen das Live-Schema validiert.
-
Live-Log-Lesen.
Der Assistent liest Gerätlogs über dieselbe Telemetriefläche, die die Plattform verwendet.
Architekturbewusste Planung
Beantwortet Planungsfragen über den Projektgraphen.
Multi-Service-Projekte umfassen Abhängigkeitsgraphen, Schnittstellenverträge und Lifecycle-Ordnung. Die Toolchain liest den Projektgraphen und beantwortet Planungsfragen — wovon hängt dieser micro service ab?, was bricht, wenn ich diese Schnittstelle aktualisiere?, welcher Test würde diese Regression abfangen?
-
Abhängigkeitsgraph-Abfragen.
Bidirektional — „wer hängt von X ab?" und „wovon hängt X ab?".
-
Vertragsgerechte Refactors.
Das Aktualisieren einer Schnittstelle zeigt jeden Konsumenten, der folgen muss.
-
Testgerechtes Scaffolding.
Generierte Tests zielen auf die vom Assistenten identifizierte Lücke.
Eingebettetes-System-bewusstes Debugging
Logs von einem eingeschränkten Gerät, als Struktur gelesen.
Logs von einem eingeschränkten Gerät entsprechen nicht dem, womit ein Cloud-Assistent trainiert wurde. Das Entwicklerpaket enthält Log-Reader, die den Supervisor, die OTA-Pipeline, den Modem-Stack, den Fahrzeugbus und den AI Funnel verstehen — so erscheint eine MEP-Regel hat nicht ausgelöst als State-Machine-Trace, nicht als Rohtext.
-
Supervisor-bewusste Traces.
Container-Lebenszyklus und Ressourcendruck werden als Ereignisse, nicht als Bytes gelesen.
-
Stack-bewusste Traces.
J1939 / UDS / Modbus-Frames werden zu PGN / SID / Adresse dekodiert.
-
AI-Funnel-bewusste Traces.
Vision- und Inferenzpfade erscheinen als Pipeline, nicht als Logs.
Die Entwicklerplattform
Über den Assistenten hinaus — die Toolchain, die das Produkt ausliefert.
Der Assistent beschleunigt, wie Sie einen micro service schreiben. Der Rest des Pakets trägt ihn den ganzen Weg: entwickeln Sie gegen ein simuliertes Gerät vor dem Silizium, liefern Sie aus Ihrem CI an die Flotte, beweisen Sie es auf echter Hardware, prüfen Sie, dass Ihr Modell auf das Gerät passt, und beobachten Sie jeden Service in einer einzigen Ansicht. Nicht jede Oberfläche ist Self-Service — das Engineering-Gespräch kalibriert, welche für Ihr Programm aktiv sind.
Entwickeln vor der Hardware
Bauen Sie gegen ein simuliertes Gerät, nicht gegen eine Warteliste.
Sie warten nicht auf Boards. MOS4 liefert Off-Target-Runner, sodass Ihr micro service auf Ihrem Laptop und in der kontinuierlichen Integration (CI) läuft — angetrieben von simulierten Eingaben — bevor er jemals Silizium berührt. Modellieren Sie den Handshake des Manufacturing Execution System (MES), den Fahrzeugbus und den Sensorstrom und spielen Sie sie dann deterministisch wieder ab.
-
Off-Target-Runner.
Ereignisrichtlinien wiedergeben, Signalgraphen über aufgezeichnete Eingaben ausführen und die Multi-Stack-Laufzeit über einen virtuellen Fahrzeugbus betreiben — kein Gerät angeschlossen.
-
Modellieren Sie die Eingaben, nicht nur das Gerät.
Treiben Sie Ihren Code mit einem simulierten MES-Austausch, gescriptetem Fahrzeugbus-Verkehr und Sensorströmen an. Stellen Sie das Szenario zusammen; spielen Sie es bei jedem Lauf gleich wieder ab.
-
Deterministisch von Grund auf.
Isolierte, wiederholbare Läufe in CI. Ein Fehler reproduziert sich auf der Maschine der nächsten Ingenieurin — nicht nur auf der Werkbank.
-
Ein Stub für den KI-Pfad.
Die KI-Laufzeit stubt die Inferenz, sodass eine AI-Funnel-Pipeline in CI ohne ein auf einem Gerät geladenes Modell läuft.
-
Ein ganzes Bundle auf Ihrem Laptop.
Ein einziger Befehl bringt ein Bundle von micro services gemeinsam hoch — dieselbe Topologie, die Sie ausliefern — sodass Sie gegen die echte Verdrahtung entwickeln, nicht gegen einen einzelnen Prozess in Isolation.
-
Eine Bench für jeden Bus.
J1939-, CANopen-, ISOBUS- und Modbus-Verkehr gegen Ihren Code wiedergeben, Nachrichten nach Vorlage injizieren und einen erfassten Frame-Timeline im Browser durchsehen — reproduzieren Sie einen Feldfehler auf der Bench, bevor er einen Kunden erreicht.
Vom CI zur Flotte
Kontinuierliche Auslieferung von Ihrer Pipeline ins Feld.
Jede Änderung in Ihrem CI baut ein signiertes Image; kontinuierliche Auslieferung (CD) rollt es in Phasen an die Flotte aus — zuerst eine Canary-Gruppe, dann eine progressive Welle bis zur allgemeinen Verfügbarkeit, mit Pausieren und Zurückrollen in jedem Schritt. Ein Dashboard gibt Ihnen eine einzige Ansicht jedes Geräts, eine REST-API (Application Programming Interface) treibt dieselben Aktionen aus Ihrem eigenen Tooling an, und eine Regel-Engine routet Telemetrie ohne eigenen Glue-Code. Die Steuerungsoberfläche ist auf ThingsBoard aufgebaut und in die Plattform eingebunden.
-
Signierte Builds, gestaffelte Rollouts.
Zuerst eine Canary-Gruppe, dann progressive Wellen an die gesamte Flotte. Pausieren oder rollen Sie in jeder Phase zurück — niemals ein Big-Bang-Push.
-
Ein Dashboard, eine API.
Beobachten Sie die Flottengesundheit in einer einzigen Ansicht und steuern Sie Provisionierung, Update und Abfrage über eine dokumentierte REST-API.
-
Regeln statt Glue-Code.
Drag-and-drop-Regelketten validieren, transformieren, routen und alarmieren auf Geräte-Telemetrie — und können ein Update auslösen.
-
Ihr CI, unverändert.
Behalten Sie Ihre Pipeline. Die Auslieferung setzt am Artefakt an: das signierte Image, das Sie bereits bauen, fließt zur Flotte.
Auf echtem Silizium testen
Testen Sie auf jeder Hardware-Variante, in einem gehosteten Rack.
Simulation bringt Sie fast den ganzen Weg; die letzte Meile läuft auf echten Geräten. Hardware-in-the-loop (HIL) stellt ein Rack der Hardware-Varianten, die Sie ausliefern, hinter Ihre Pipeline — gehostet in der Munic-Cloud oder On-Premise hinter Ihrer Firewall aufgesetzt. Verteilen Sie Ihre Testmatrix über das Rack und laufen Sie auf jedem Board gleichzeitig, mit Logs, Traces und Performance, erfasst vom Silizium, das den Test ausgeführt hat.
-
Jede Variante, die Sie ausliefern.
Modem-class-, compute-class- und AI-class-Targets in einem Rack — testen Sie die Matrix, nicht ein einzelnes Board.
-
Parallel von Haus aus.
Verteilen Sie die Suite über das Rack und laufen Sie auf jedem Board gleichzeitig, statt auf einem Target nach dem anderen.
-
Cloud oder On-Premise.
Gehostet in der Munic-Cloud oder On-Premise hinter Ihrer Firewall aufgesetzt für beschränkte Programme.
-
Belege vom Metall.
Logs, Traces und Genauigkeits- / Latenzwerte stammen vom Gerät, das den Test ausgeführt hat — nicht aus einer Schätzung.
Wissen, dass es passt, bevor Sie ausliefern
Finden Sie heraus, ob Ihr Modell auf dem Gerät läuft — vor der Integration.
Bringen Sie Ihr trainiertes Modell mit. Die Assessment-Pipeline profiliert es gegen das Ziel-Tier und liefert die Zahlen, die ein Programm entscheiden: Inferenzlatenz, Speicher-Footprint und Genauigkeit nach On-Device-Optimierung. Machine-Learning-Operations-(MLOps)-Tooling — Kubeflow für die Pipeline, MLflow für Nachverfolgung und die Modell-Registry — ist in den Prozess eingebunden, sodass jeder Lauf reproduzierbar, versioniert und auditierbar ist.
-
Wird es laufen? Holen Sie sich das Budget.
Die Pipeline profiliert Ihr Modell gegen das Latenz- und Speicherbudget des Ziel-Tiers und meldet, wo es landet.
-
Nachverfolgt und reproduzierbar.
Kubeflow orchestriert die Läufe; MLflow verfolgt jedes Experiment, jede Metrik und jede Modellversion in der Registry.
-
Auf dem Metall geprüft.
Der Hardware-in-the-loop-Validator weist einen Kandidaten ab, der das Genauigkeits- oder Latenz-Gate auf Referenzhardware verfehlt.
-
Für den Edge optimiert.
On-Device-Optimierung komprimiert das Modell auf die Compute-Hülle — das Assessment meldet die Genauigkeit, die Sie behalten.
-
Eine Modell-Registry auf dem Gerät.
Modelle werden versioniert, einmal abgerufen und per Signatur geprüft, bevor sie laden — eine einzige Quelle der Wahrheit darüber, was auf jedem Gerät läuft, mit einem CLI zum Auflisten, Abrufen und Verifizieren.
Eine einzige Ansicht
Jeder micro service streamt standardmäßig zu Grafana.
Es gibt kein Instrumentierungsprojekt. Jeder micro service im OS stellt ab dem Boot ein Prometheus-kompatibles Metrik-Set und eine OpenTelemetry-Oberfläche bereit — visualisiert in Grafana-Dashboards über die Flotte hinweg. Richten Sie Ihren eigenen Container auf denselben Scrape-Endpunkt, und er erscheint neben den OS-Services in derselben Ansicht. Metriken, Logs und Traces, auf offenen Standards, kein separater Stack.
-
Metriken auf jedem Service.
Jeder micro service wird ab dem Boot von Prometheus gescrapt — kein pro-Service zu betreibendes Instrumentierungsprojekt.
-
Ihr Container, dieselbe Oberfläche.
Stellen Sie einen Metrik-Endpunkt auf Ihrem eigenen Container bereit, und er streamt in dieselben Grafana-Dashboards wie die OS-Services.
-
Offene Standards, kein Lock-in.
Prometheus- und OpenTelemetry-kompatibel — richten Sie jedes kompatible Back-End auf die Oberfläche.
Compliance, kontinuierlich
Dieselbe Pipeline erzeugt die Compliance-Belege.
Kontinuierliche Auslieferung ist nicht nur, wie Software die Flotte erreicht — sie ist, wie die Belege erzeugt werden. Jedes Release trägt eine CycloneDX Software Bill of Materials (SBOM), einen CVE-Scan, signierte Binaries und eine OpenTelemetry-Oberfläche. Die Verpflichtungen des EU Cyber Resilience Act (CRA) sind im Compliance-Paket Artikel für Artikel abgebildet — erzeugt von der Pipeline, nicht nachträglich angeschraubt.
Im Entwicklerpaket
Was ausgeliefert wird und was mit Engineering kommt.
Ein Teil des Pakets ist heute im OS; der Rest wird mit Engineering während der Evaluierung und durch das Deployment hindurch hochgefahren — kein öffentlicher Installationspfad, kein Self-Service-Portal. Das Engineering-Gespräch kalibriert, welche Oberflächen für Ihr Projekt aktiv sind.
Mit Engineering über das Entwicklerpaket sprechen.
Engineering führt Sie während der Evaluierung durch die Simulatoren, die Auslieferungs-Pipeline, das Hardware-in-the-loop-Rack, das Modell-Assessment und die Observability-Oberfläche.