Compare

MOS4 vs AGL & Apex.OS

AGL and Apex.OS are SDV-class runtimes built around consortium and partner programmes. MOS4 covers the same problem class as a standard product — evaluation under a direct engineering conversation, no working-group gate.

Closed AGL/Apex consortium gate with a key in its lock; an open MOS4 standard product path beside it with an amber arrow flowing through

Adoption path

Consortium programme vs standard product.

The consortium path requires membership or a partner agreement, a reference platform, and a production programme. The standard product path runs an evaluation under licence, ships a pilot device, and deploys on the MOS4 hardware ladder.

flowchart LR
  subgraph Cons["Consortium / partner path"]
    O1[Membership or partner agreement] --> O2[Reference platform] --> O3[Production programme]
  end
  subgraph T2["Standard product path"]
    T1[Evaluation under licence] --> T2x[Pilot device] --> T3[Deploy on hardware ladder]
  end

Side-by-side

Capability comparison.

Target audience AGL / Apex.OS OEM consortia, Tier-1 IVI programmes, Apex.OS partner ecosystem. MOS4 Tier-2 suppliers, fleet operators, agricultural and off-highway machine builders.
Adoption model AGL / Apex.OS AGL consortium membership or Apex.OS partner agreement required to access the full stack. MOS4 Standard product evaluation under a direct licence. No consortium gate.
Service contracts AGL / Apex.OS AGL: D-Bus + protobuf service descriptors. Apex.OS: ROS2 lifecycle interfaces in C++. MOS4 89 .proto files in mos-interfaces define every service boundary, checked by buf lint and cargo build in CI.
Component authoring AGL / Apex.OS AGL: D-Bus service descriptor + per-service boilerplate. Apex.OS: ROS2 node lifecycle implementation. MOS4 Declare interfaces in proto, annotate one Rust struct with #[component], implement the generated trait. A minimal micro service is under 30 lines of Rust.
Vehicle protocols AGL / Apex.OS AGL targets OEM IVI stacks (primarily Ethernet SDV). Apex.OS does not supply OBD protocol stacks. MOS4 obdstacks-v2: 16 protocols (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, KWP, J1850, GMLAN, CANopen, Modbus) via declarative JSON stack files, hot-loadable at runtime.
Fleet OTA AGL / Apex.OS AGL delegates OTA to vendor-specific mechanisms. Apex.OS does not supply a fleet OTA path. MOS4 mos-update: Ed25519-signed delta packages, A/B partitions, automatic rollback via bootcount. Cohort and canary OTA via the Munic cloud companion.
Hardware range AGL / Apex.OS OEM reference platforms — typically compute-class or AI-class SoCs. MOS4 Modem-class (28.4 MB steady-state RSS, 1.6 s first-app-ready) through compute-class and AI-class. Same bundle.toml workflow across the ladder.
ROS2 hosting AGL / Apex.OS Apex.OS is a hardened ROS2 distribution for ASIL-B+ programmes. MOS4 mos-ros2 hosts rclcpp/rclpy nodes unmodified inside a MCM container. Bridge forwards DDS topics as typed EventBus events. Talk to engineering for AGV/robotics qualification.

Source — AGL from automotivelinux.org ; Apex.OS from apex.ai; MOS4 from /architecture.

What MOS4 adds

Platform breadth for Tier-2 and fleet programmes.

Six production scenarios, one codebase.

The same MOS4 platform supports IoT gateway, agriculture (137 features), dashcam, OBD dongle, C4Max, and Ekko Drive deployments without per-scenario code forks. AGL and Apex.OS are oriented toward OEM head-unit and autonomy programmes; MOS4 covers the fleet-telematics, off-highway, and aftermarket space.

Observability as a framework property.

Every MOS4 component emits response-time histograms, error counters, and lifecycle events automatically via ObservabilityRegistry. OpenTelemetry OTLP export and W3C Trace Context propagation are included in the framework, not added per service.

Safety scope — stated honestly.

MOS4 is not ASIL-certified today. Programmes that need ASIL-B+ certified ROS2 nodes retain Apex.OS for that scope; MOS4 covers the surrounding fleet, OTA, and vehicle-protocol layers. Safety alignment per programme — talk to engineering.

FAQ

The questions we hear most.

  • Is MOS4 in the same problem class as AGL?

    Yes — same software-defined-vehicle class. AGL targets OEM IVI programmes through a consortium model. MOS4 ships as a standard product for the Tier-2 fleet and off-highway audience so smaller programmes can adopt it without a multi-OEM working group.

  • How does MOS4 compare to Apex.OS for autonomy applications?

    Apex.OS is a hardened ROS2 distribution. MOS4 hosts existing ROS2 nodes inside its supervisor — no modification to rclcpp/rclpy code — and adds vehicle protocols, fleet OTA, and observability around them. Programmes that need certified ROS2 keep Apex.OS for that scope; MOS4 covers the fleet and vehicle-protocol layers.

  • Can MOS4 run alongside an AGL or Apex.OS stack?

    The coexistence model is available for engineering discussion. There is no published reference deployment of MOS4 alongside AGL. Talk to engineering to evaluate the topology for your programme.

  • What about consortium-only software?

    MOS4 does not require consortium membership. The product, the SDK, and the 63-proto interface library are accessible to any customer under a standard evaluation.

  • Is MOS4 SDV-class?

    Yes — the same software-defined-vehicle problem class. The difference is the adoption path: evaluation under a standard licence with a direct engineering conversation, not a consortium programme.

  • What is the hardware range?

    MOS4 runs from modem-class Linux-capable application processors (~28 MB steady-state RSS, 1.6 s first-app-ready) through compute-class and AI-class hardware. The same bundle.toml + cargo distro generate workflow produces binaries for each tier.

Same SDV class, standard product path.

A 30-minute call with engineering. We will match the MOS4 hardware ladder to your programme.

Building on MOS4?

One reply from engineering, ~24h. No deck, no NDA.

Talk to engineering