Platform · Developer Tools
Build on MOS4 with an AI-aware toolchain.
A developer pack that runs the whole way — from a simulated device on your laptop, through continuous delivery to the fleet, to hardware-in-the-loop and live observability in the field. It integrates with the AI tools your team already uses. The pack is available with engineering — use it during evaluation and through deployment.
MCP Connector for MOS4
Your coding assistant, connected to the MOS4 catalog.
A Model Context Protocol connector lets your team's coding assistant (Claude Code, Cursor, Continue, or any MCP-aware client) read the MOS4 catalog, the component interfaces, the configuration schema, and the live device logs. The connector exposes typed resources — the assistant knows where a micro service is wired, which .proto interface it provides, which configuration keys it consumes, and which log surfaces it emits.
-
Catalog-aware completion.
The assistant knows the production micro services, their interfaces, and their configuration surface.
-
Interface-typed search.
"Where is Position published?" returns the producing service, the consuming services, and the contract.
-
Configuration linting.
Configuration files validated against the live schema before deploy.
-
Live log reading.
The assistant reads device logs through the same telemetry surface the platform uses.
Architecture-aware planning
Answers planning questions about the project graph.
Multi-service projects involve dependency graphs, interface contracts, and lifecycle ordering. The toolchain reads the project graph and answers planning questions — what does this micro service depend on?, what breaks if I bump this interface?, what test would catch this regression?
-
Dependency-graph queries.
Bidirectional — "who depends on X?" and "what does X depend on?".
-
Contract-aware refactors.
Bumping an interface surfaces every consumer that needs to follow.
-
Test-aware scaffolding.
Generated tests target the gap the assistant identified.
Embedded-system-aware debugging
Logs from a constrained device, read as structure.
Logs from a constrained device are not what a cloud assistant is trained on. The developer pack includes log readers that understand the supervisor, the OTA pipeline, the modem stack, the vehicle bus, and the AI Funnel — so a MEP rule did not fire shows up as a state-machine trace, not as raw text.
-
Supervisor-aware traces.
Container lifecycle and resource pressure are read as events, not bytes.
-
Stack-aware traces.
J1939 / UDS / Modbus frames decoded to PGN / SID / address.
-
AI Funnel-aware traces.
Vision and inference paths surface as a pipeline, not as logs.
The developer platform
Beyond the assistant — the toolchain that ships the product.
The assistant accelerates how you write a micro service. The rest of the pack carries it the whole way: develop against a simulated device before silicon, deliver to the fleet from your CI, prove it on real hardware, check that your model fits the device, and watch every service in one pane. Not every surface is self-serve — the engineering conversation calibrates which are active for your programme.
Develop before hardware
Build against a simulated device, not a waiting list.
You don't wait for boards. MOS4 ships off-target runners, so your micro service runs on your laptop and in continuous integration (CI) — driven by simulated inputs — before it ever touches silicon. Model the Manufacturing Execution System (MES) handshake, the vehicle bus, and the sensor stream, then replay them deterministically.
-
Off-target runners.
Replay event policies, execute signal graphs over recorded inputs, and exercise the multi-stack runtime over a virtual vehicle bus — no device attached.
-
Model the inputs, not just the device.
Drive your code with a simulated MES exchange, scripted vehicle-bus traffic, and sensor streams. Compose the scenario; replay it the same way every run.
-
Deterministic by design.
Isolated, repeatable runs in CI. A failure reproduces on the next engineer’s machine — not only on the bench.
-
A stub for the AI path.
The AI runtime stubs inference so an AI Funnel pipeline runs in CI without a model loaded on a device.
-
A whole bundle on your laptop.
One command brings up a bundle of micro services together — the same topology you ship — so you develop against the real wiring, not a single process in isolation.
-
A bench for every bus.
Replay J1939, CANopen, ISOBUS, and Modbus traffic against your code, inject templated messages, and drill into a captured frame timeline in the browser — reproduce a field fault on the bench before it reaches a customer.
-
Drive a virtual vehicle.
A built-in motion simulator drives real routes on a map, replays GNSS and motion itineraries, and models vehicle and fuel-consumption profiles — emitting the same position, speed, and inertial signals your code sees from real hardware, with a 3-D pose preview in the browser.
From CI to the fleet
Continuous delivery from your pipeline to the field.
Every change in your CI builds a signed image; continuous delivery (CD) rolls it out to the fleet in phases — a canary group first, then a progressive wave to general availability, with pause and roll-back at any step. A dashboard gives you one view of every device, a REST application programming interface (API) drives the same actions from your own tooling, and a rule engine routes telemetry without custom glue code. The control surface is built on ThingsBoard, bound into the platform.
-
Signed builds, phased rollouts.
A canary group first, then progressive waves to the whole fleet. Pause or roll back at any phase — never a big-bang push.
-
One dashboard, one API.
Watch fleet health in a single pane and drive provisioning, update, and query through a documented REST API.
-
Rules, not glue code.
Drag-and-drop rule chains validate, transform, route, and alarm on device telemetry — and can trigger an update.
-
Your CI, unchanged.
Keep your pipeline. Delivery attaches at the artifact: the signed image you already build flows to the fleet.
Test on real silicon
Test on every hardware flavor, in a hosted rack.
Simulation gets you most of the way; the last mile runs on real devices. Hardware-in-the-loop (HIL) puts a rack of the hardware flavors you ship behind your pipeline — hosted in Munic cloud, or stood up on-premise behind your firewall. Fan your test matrix across the rack and run on every board at once, with logs, traces, and performance captured from the silicon that ran the test.
-
Every flavor you ship.
Modem-class, compute-class, and AI-class targets in one rack — test the matrix, not a single board.
-
Parallel by default.
Fan the suite across the rack and run on every board at once, instead of one target at a time.
-
Cloud or on-premise.
Hosted in Munic cloud, or stood up on-premise behind your firewall for restricted programmes.
-
Evidence from the metal.
Logs, traces, and accuracy / latency figures come from the device that ran the test — not a guess.
Know it fits before you ship
Find out if your model runs on the device — before integration.
Bring your trained model. The assessment pipeline profiles it against the target tier and returns the numbers that decide a programme: inference latency, memory footprint, and accuracy after on-device optimization. Machine-learning operations (MLOps) tooling — Kubeflow for the pipeline, MLflow for tracking and the model registry — is bound into the process, so every run is reproducible, versioned, and auditable.
-
Will it run? Get the budget.
The pipeline profiles your model against the latency and memory budget of the target tier, and reports where it lands.
-
Tracked and reproducible.
Kubeflow orchestrates the runs; MLflow tracks every experiment, metric, and model version in the registry.
-
Gated on the metal.
The hardware-in-the-loop validator rejects a candidate that misses the accuracy or latency gate on reference hardware.
-
Optimized for the edge.
On-device optimization compresses the model to the compute envelope — the assessment reports the accuracy you keep.
-
A model registry on the device.
Models are versioned, fetched once, and checked by signature before they load — one source of truth for what runs on every device, with a CLI to list, fetch, and verify.
One pane of glass
Every micro service streams to Grafana, by default.
There is no instrumentation project. Every micro service in the OS exposes a Prometheus-compatible metric set and an OpenTelemetry surface from boot — visualized in Grafana dashboards across the fleet. Point your own container at the same scrape endpoint and it appears alongside the OS services in the same pane. Metrics, logs, and traces, on open standards, no separate stack.
-
Metrics on every service.
Each micro service is scraped by Prometheus from boot — no per-service instrumentation project to run.
-
Your container, the same surface.
Expose a metrics endpoint on your own container and it streams into the same Grafana dashboards as the OS services.
-
Open standards, no lock-in.
Prometheus- and OpenTelemetry-compatible — point any compatible back end at the surface.
Compliance, continuously
The same pipeline produces the compliance evidence.
Continuous delivery is not only how software reaches the fleet — it is how the evidence is produced. Every release carries a CycloneDX Software Bill of Materials (SBOM), a CVE scan, signed binaries, and an OpenTelemetry surface. The EU Cyber Resilience Act (CRA) obligations are mapped article-by-article in the compliance pack — generated by the pipeline, not bolted on after.
In the developer pack
What ships, and what comes with engineering.
Some of the pack is in the OS today; the rest is brought up with engineering during evaluation and through deployment — no public install path, no self-serve portal. The engineering conversation calibrates which surfaces are active for your project.
Talk to engineering about the developer pack.
Engineering walks you through the simulators, the delivery pipeline, the hardware-in-the-loop rack, the model assessment, and the observability surface during the evaluation.