Platform · Hardware

Hardware tiers — one OS, Munic owns the port.

MOS4 runs on three hardware tiers — modem-class, compute-class, and AI-class. Munic ports the OS to each tier; the product team picks the tier per device. Neural processing unit (NPU) up to ~100 TOPS on the AI tier, GPU-to-NPU shared memory, GMSL2 multi-camera, eUICC Consumer + eUICC M2M across the AI family. MIPI-CSI, USB UVC, RTSP / ONVIF, 1-Wire. Munic authors the kernel branch, board support package (BSP), boot image, and OTA pipeline. The team writes application code. SKUs, datasheets, and pricing on munic.io.

Talk to engineering Browse the micro services catalog
~100 TOPS AI-class NPU ceiling for on-device inference across the AI tier
~30 MB OS RAM footprint modem-class reference, steady-state
1.6 s boot time modem-class reference, first-app-ready
<5% container overhead container engine, modem-class reference

Three silicon tiers

Pick the class that matches the product.

Modem-class

Working floor: single-core application processor at or above 800 MHz, 256 MB RAM

Cellular IoT gateway, OBD dongle, asset tracker. ~30 MB RAM OS footprint, 1.6 s boot. Full connectivity stack.

Compute-class

Multi-core application processor with on-die NPU

Heavy-duty fleet, ISOBUS / J1939, multi-protocol vehicle comms, light camera capture, MIPI-CSI. Signal-processing and mission-event engines available.

AI-class

NPU silicon up to ~100 TOPS, GMSL2-capable

AI-class platforms run the full Vision stack, AI pipeline, ADAS, multi-camera GMSL2, GPU-to-NPU shared memory, and eUICC Consumer + eUICC M2M across the family. 1 GB RAM minimum for the AI Language platform (LLM + RAG + voice) on top of the AI-class floor.

Tier names describe silicon capability. SKUs, datasheets, and volume pricing live on munic.io.

Cellular modules

Four cellular families — capability-first, vendor-neutral.

The cellular micro service loads the vendor radio driver at runtime. A new module is a driver library swap — no OS recompilation. eUICC Consumer + eUICC M2M ships across every AI-class platform.

Capability families — for full SKU list, datasheets, and pricing see munic.io.

Supported cellular module families — representative figures (see datasheet for full spec)
Family RAM Flash RAT eUICC profile
LPWA legacy module 256 MB 256 MB 2G (GPRS) · Cat-M1 · NB-IoT No
LTE Cat 4 + 2G/3G fallback 256 MB 512 MB 2G · 3G · 4G LTE Cat 4 No
Compute-capable LTE + LPWA See datasheet See datasheet 4G LTE · LPWA (Cat-M1 / NB-IoT) Yes (eUICC SGP.22)
AI-class with embedded eUICC See datasheet See datasheet 4G LTE / 5G NR · LPWA Yes (eUICC SGP.22, on every AI-class platform)

"eUICC profile" column: eUICC remote SIM provisioning (GSMA SGP.22 Consumer profile) — the modem manages SIM profiles over the air without a physical card swap. RAM and Flash figures are module-embedded memory — not the application processor. Dual APN is available on every family. Full SKU list, datasheets, and volume pricing at munic.io. Cellular radio stack detail: Connectivity.

NPU inference

What the AI tier exercises.

Compute-class — NPU via vendor acceleration plugin

The AI runtime drives the on-die NPU via the vendor acceleration plugin. Camera frames travel MIPI-CSI → GPU crop and resize → NPU as a standard tensor. The shared-memory hand-off is not part of the compute-class profile — adequate for single-model inference, not multi-cam ADAS.

AI-class — NPU + GPU-to-NPU zero-copy

On the AI tier, the AI runtime drives the NPU through the vendor acceleration plugin. The GPU region-of-interest shader allocates output tensors in shared GPU-NPU memory so the NPU does not re-import per frame. The full AI-class platform family is binary-compatible with the reference port — treat as ported.

GPU region-of-interest crop mechanism per tier
Tier Crop and resize NPU hand-off
Compute-class GPU crop and resize GPU output → NPU as standard tensor
AI-class GPU crop and resize GPU-to-NPU shared memory (zero-copy)

AI pipeline deep-dive: AI funnel · Camera capture inputs: Vision.

Camera interfaces

Five inputs. One shared-frame contract.

Camera capture interfaces by tier
Interface Tier GStreamer element Frame type
MIPI-CSI Compute-class · AI-class libcamera / V4L2 GBM / V4L2
GMSL2 AI-class only V4L2 media-subsystem driver shared GPU/NPU memory
USB UVC All tiers V4L2 UVC driver V4L2
RTSP / ONVIF All tiers GStreamer rtspsrc GStreamer
WebRTC All tiers GStreamer webrtcbin GStreamer

Every input converges on the same shared GPU memory frame at the pipeline junction — the common entry point for the AI pipeline. GMSL2 is an AI-class capability — for the long-cable, EMI-resistant, multi-camera deployments typical of advanced driver-assistance systems (ADAS) and driver monitoring. Full camera pipeline: Vision.

1-Wire bus

Dallas/Maxim sensors — one component.

The 1-Wire component polls /sys/bus/w1/devices/ via the Linux w1 kernel subsystem. Handles parasite power, DS18x20 12-bit conversion, and CRC-8 validation on every read.

Supported device families

  • · DS18B20 — temperature
  • · DS2438 — temperature + humidity
  • · DS1992 — EEPROM
  • · iButton — driver ID written to the platform database on plug/unplug

10 service methods + streaming

Typed API surface. CRC-8 validation on every read. Streaming events for plug/unplug. Browse the 1-Wire micro service in the catalog.

Form factors

From dongle to fleet-box.

Three MOS4 hardware tiers ascending diagonally on a dark blueprint backdrop — modem-class board at the base with cyan traces, compute-class in the middle with cyan and amber traces, AI-class SoM on top with an amber NPU

Reference shots of the silicon tiers. A product may adopt any of these or a derivative — Munic ports MOS4 to the chosen BSP; the form factor stays with the integrator.

OBD Dongle — Modem-class form factor

Modem-class

OBD Dongle

Vehicle Gateway — Compute-class form factor

Compute-class

Vehicle Gateway

DIN-Rail Edge — Compute-class form factor

Compute-class

DIN-Rail Edge

Fleet Box — AI-class form factor

AI-class

Fleet Box

OBD dongle — modem-class form factor on a workbench

From OBD dongle to DIN-rail edge computer — one OS, three silicon tiers. Browse micro services in the catalog.

Porting model

Munic owns the port. You own the application.

Munic owns

  • · Linux kernel branch for each supported hardware tier.
  • · Board support package (BSP) integration — board configuration, device tree, drivers.
  • · Boot image build and signing pipeline.
  • · OTA pipeline — signed package delivery, A/B partition, rollback.
  • · Compliance evidence — SBOM, risk assessment, architecture description.

Customer owns

  • · Application code and business logic.
  • · Domain-specific threat model and risk register.
  • · Application-layer test coverage and evidence.
  • · Hardware selection and form-factor design.

Additional platforms in active porting are not named until publicly announced. Talk to engineering to evaluate target hardware.

FAQ

Frequently asked questions

  • What is the minimum supported silicon for a modem-class deployment?

    The working floor for modem-class is a single-core application processor at or above 800 MHz with 256 MB RAM. Confirm with engineering before treating this as a hard constraint — per-programme configuration may affect the actual minimum.

  • Which cellular module families does MOS4 run?

    MOS4 runs all four families: legacy LPWA modules (2G fallback + Cat-M1 / NB-IoT), LTE Cat 4 modules with 2G/3G fallback, compute-capable LTE + LPWA modules, and AI-class modules with embedded eUICC across the family. The cellular micro service loads the vendor radio driver at runtime — a new module is a driver library swap with no OS recompilation. RAM and Flash figures per family are in the table above; full SKU list and datasheets on munic.io.

  • Which camera interface is available on each tier — does GMSL2 work on compute-class?

    GMSL2 is an AI-class capability — for the long-cable, EMI-resistant, multi-camera deployments typical of advanced driver-assistance systems (ADAS) and driver monitoring. Compute-class supports MIPI-CSI direct via libcamera. USB UVC, RTSP / ONVIF, and WebRTC are available across all tiers. See the Camera interfaces table above for the full breakdown.

  • Does GPU-to-NPU shared memory work on compute-class?

    GPU-to-NPU shared memory (zero-copy) is an AI-class capability. On compute-class, the GPU ROI shader outputs a standard tensor that the NPU receives without the shared-memory optimisation. Both tiers run the same GPU pipeline; the per-frame hand-off path differs.

  • Is eUICC profile management available on every tier?

    Yes on every AI-class platform — eUICC profile management (GSMA SGP.22 Consumer; GSMA SGP.02 M2M) ships embedded across the AI tier. Compute-capable LTE + LPWA modules also include eUICC profile management. Earlier modem-class families ship physical SIM only.

  • Who owns the porting work?

    Munic authors the Linux kernel branch, BSP integration, boot image, OTA pipeline, and compliance evidence for each supported tier. The team writes application code, not BSPs.

  • Are additional hardware targets in the roadmap?

    Additional platforms are in active porting. Munic does not name them until publicly announced. Talk to engineering at /contact for target hardware evaluation.

  • Where do I find hardware SKUs, datasheets, and pricing?

    SKUs, datasheets, and volume pricing are published at munic.io. This page describes hardware-tier capabilities — link to munic.io for procurement detail.

Bring the hardware target.

Engineering will confirm silicon tier fit and walk through the porting plan.

Talk to engineering Browse the micro services catalog

Building on MOS4?

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

Talk to engineering Book a 30-min slot
Talk to engineering