Solutions · Autonomous Vehicles
Ship an autonomous-vehicle stack.
A distributed component OS for autonomous-driving programmes. ROS2-class host on industrial silicon. Edge-AI ready — camera, GPU, NPU share memory. Process-isolated micro services with enforced resource limits.
Scope, stated up front
What this is, and what it is not.
What MOS4 ships
- The runtime — distributed component OS, hot-swappable containers.
- Hosted ROS2 nodes via the ROS2 bridge micro service.
- Multi-camera perception with shared GPU-to-NPU memory, no CPU pixel copying.
- Machine-bus coverage: J1939, ISOBUS, CANopen, Modbus, J1708, CAN-FD, DoIP.
- RTK GNSS, IMU, 1,000+ zone geofencing, and a sensor-fusion signal-processing pipeline.
- Telemetry uplink with signed attestation.
- Remote diagnostic, reconfigure, and signed remediation.
- Software bill of materials (SBOM) and compliance artefacts for the CRA evidence chain.
What MOS4 does not ship
- A public-road L4 (fully-autonomous) driving stack.
- HD maps or map-tile licences.
- A homologation certificate for autonomy decisions.
- Your perception, planning, or control models — we host yours.
- A functional-safety case for the integrated machine.
- An ADAS or public-road automotive-safety certification.
Building for public roads? MOS4 is not the right OS for that programme.
The buyer's problem
Off-public-road autonomy is its own world.
No road-homologation process. No L4 (fully-autonomous) stack to purchase off the shelf. You own the autonomy application, and you need an OS that hosts the ROS2 nodes you already wrote, talks to the machine's CAN and ISOBUS buses, runs your perception on AI-class silicon, streams telemetry, takes a remote reboot when something seizes, and ships CRA-compliant from day one.
How MOS4 fits
Five capabilities for an autonomous machine.
ROS2 hosted, not rewritten
A ROS2 bridge micro service connects any unmodified ROS2 node to MOS4 over a local process link. Perception, planning, and control nodes you already ship stay where they are — MOS4 hosts them on a lighter platform alongside CAN, GNSS, telemetry, and remote care.
Perception on AI-class silicon
Multi-camera capture (MIPI-CSI, GMSL2, USB UVC), region-of-interest extraction with shared GPU-to-NPU memory, and on-device neural network inference. Up to ~100 TOPS on the AI-class tier. The CPU never copies pixel data in the inference path.
Machine bus, not just CAN
J1939, ISOBUS (ISO 11783), CANopen, Modbus RTU/TCP, J1708, CAN-FD, DoIP — concurrent on one device. Stack definitions are data files; adding a new parameter group (PGN) or signal (SPN) requires no firmware change.
Sensor fusion and safety platform
Real-time kinematic (RTK) GNSS with IMU dead-reckoning, 1,000+ zone geofencing evaluated on-device, and a signal-processing pipeline for sensor fusion. Evidence-based decision patterns are available for autonomy-mode transitions where an audit trail is required.
Remote care wired in
Telemetry uplink (signed, attested). Hot-reload of signal-processing graphs, autonomy state-machine policies, and geofence maps. Signed over-the-air (OTA) updates with auto-rollback. Remote reboot, remote re-flash, remote diagnostics — built-in OS capability, not a bolt-on. One immobilization avoided pays for the device.
Platform metrics
Key numbers.
Reference architecture
An autonomous machine on MOS4.
Reference architecture — cloud fleet manager connects over a secure MQTT uplink to a MOS4 in-machine ECU. The ECU runs containerised ROS2 nodes for perception, planning, and control. Multi Stacks handles J1939, ISOBUS, CANopen, Modbus on the machine bus, feeding a signal-fusion pipeline. Camera capture feeds region-of-interest extraction, then on-device NPU inference. Signal fusion, NPU, and ROS2 feed the autonomy state-machine. The state-machine commands the actuator CAN bus. The ECU also exposes a remote-care surface for signed remediation.
flowchart LR Cloud[Cloud · fleet manager] --> Up[MD21 · MQTT secure uplink] Up --> ECU[MOS4 in-machine ECU] ECU --> MCM[MCM · containers] MCM --> ROS2[ROS2 nodes<br/>perception · planning · control] ECU --> MS[Multi Stacks<br/>J1939 · ISOBUS · CANopen · Modbus] MS --> MSP[MSP · signal fusion] ECU --> CAP[Camera capture<br/>MIPI · GMSL · UVC] CAP --> ROI[ROI shader<br/>GPU → NPU zero-copy] ROI --> NPU[mos-ai-runtime<br/>.tflite inference] NPU --> MEP[MEP · autonomy state-machine] MSP --> MEP ROS2 --> MEP MEP --> CMD[Command bus → actuator CAN] ECU --> RC[Remote care<br/>signed remediation]
Worked example
An autonomous airport tug.
An airport-ground-operations vehicle manufacturer ships an autonomous baggage tug. The autonomy stack is theirs — perception, planning, control, all written in ROS2 by a small team. The chassis and drive-by-wire interface are theirs. The runtime, the silicon abstraction, the machine bus, the multi-camera capture, the AI compute, the telemetry uplink, and the remote-care surface come from MOS4.
ROS2 preserved
Existing ROS2 nodes deploy unchanged in isolated containers. The ROS2 bridge micro service translates ROS2 messages to and from the MOS4 event bus bidirectionally.
Telemetry on day one
MD21 uplink ships with the OS. Fleet-side operators see live position, health, mode, and fault state without writing a telemetry layer.
Remote reboot proven
A stalled tug at gate 14 in the middle of a turnaround does not need a technician to drive to the apron. A signed remote action restarts the affected process; if the SoC is wedged, a signed remote reboot takes the unit back to a known-good state.
Anonymous proof
Airport-ground-operations vehicle manufacturer · global rollout.
A leading airport-ground-operations vehicle manufacturer ships MOS4 across its fleet. The autonomy and chassis software is theirs; the runtime, telemetry, and remote-care surface are MOS4. Reference under NDA — sales-mediated reference call available on request.
Reference under NDA · request a sales-mediated reference call
FAQ
Frequently asked questions
-
Does MOS4 ship a public-road autonomy stack?
No. MOS4 is designed for private-premise operation — farm, airfield, mine, quarry, port handler, golf course, yard. Public-road L4 is outside scope by design. Buyers building public-road systems need a different toolchain.
-
Who owns the autonomy decision-making?
You do. MOS4 hosts your perception, planning, and control models. We do not certify autonomy decisions, replace your perception/planning/control nodes, or provide HD maps. We provide the platform — runtime, machine bus, AI compute, uplink, remote care, audit.
-
Does it work with existing ROS2 nodes?
Yes. The ROS2 bridge micro service translates ROS2 (DDS) messages to and from the MOS4 event bus bidirectionally. Existing ROS2 nodes run in isolated containers without code changes. See the ROS2 sidecar gateway in the SDK page.
-
What hardware tier is required for AI perception?
AI-class silicon for on-device neural network inference. The region-of-interest extraction and AI runtime services require an NPU; there is no CPU fallback in production. The machine bus, telemetry, and remote-care surfaces run on compute-class. See the hardware page for the silicon-tier ladder.
-
How does the fleet survive an in-field failure?
Remote Care is the answer. Signed remote diagnostic, hot-reload of signal-processing graphs and autonomy state-machine policies, signed over-the-air (OTA) updates with auto-rollback, remote reboot at process and SoC level. The OS does not override safety interlocks; remediations are operator-mediated and audit-logged.
-
Is there CRA compliance support?
Yes. A software development lifecycle pipeline with software bill of materials (SBOM, CycloneDX format), dependency auditing, static analysis, signed updates, and per-action audit logs ship from day one. See the compliance page for the full article-by-article mapping.
-
Can I name MOS4 in my safety case?
MOS4 ships compliance artefacts, software bills of materials (SBOMs), and security pipeline evidence. Functional-safety certification (ISO 26262 / ISO 25119) of the integrated machine is the OEM responsibility — we provide the underlying evidence, you make the safety argument.
Bring your autonomous machine.
Vehicle class, sensor mix, ROS2 footprint, bus protocols, fleet topology — bring the constraints. Engineering will sketch the MOS4 fit during the call.