Reference

Glossary

Short definitions for the MOS4 vocabulary. Each entry links to the canonical page that explains it in depth.

Open technical dictionary with schematic diagrams on the right page and indexed alphabet tabs on the right edge — amber on a single highlighted term

Micro service: The unit of deployment in MOS4. A self-contained Rust crate annotated with #[component], declaring the protobuf interfaces it provides and requires, with a config schema (mos.toml) and its own CI pipeline. Every supervised repo in the MOS4 ecosystem is a micro service.; On the website, micro services are also referred to as components within a distributed component OS. 35 micro services ship in the production catalog.; Microservices → Catalog →
MCM: MOS Container Manager — the lightweight OCI container engine that runs customer code alongside micro services. Production runtime is crun with cgroups v2 resource enforcement. Four mount profiles: SHELL, PYTHON, NATIVE, STATIC.; System-layer substitution: a CPython 3.12 update propagates to all customer Python containers via a single system-layers.toml digest bump. Container budget envelope: under 5% CPU/RAM and ~10 MB RSS.; SDK → Microservices →
MSP: Morpheus Signal Processing — a graph-based real-time signal processing engine for vehicle telemetry. Nodes are wired by edges in .msp.yml files; 225 graphs across 20 vehicle domains ship out of the box.; Graphs run on a Tokio async runtime targeting Cortex-A7. Adding a new vehicle domain requires only a YAML file — no Rust recompile. 116 kernels in the visual editor.; No-code engines → Automotive →
MEP: MOS Event Processor — a YAML-configured Trigger → Condition → Action engine. Triggers are database key changes, named events from the EventBus, or cron schedules (UTC). Conditions are evaluated before the action fires.; Actions can call any MOS4 micro service interface (write key, emit event, call service call). Hot reload: new policies are validated and swapped in with in-flight rule draining — no process restart required. Parallel rule worker pool with conflict detection. Product framing: from the product owner’s point of view, MEP runs state-machine policies on the device. The state machine *is* the policy YAML — there is no separate state-machine runtime. The T·C·A primitive is the engineering view of the same artefact.; No-code engines → MEP page →
EventBus: The MOS4 internal named-event distribution channel. Components publish events by name; MEP triggers and mos-ros2 DDS topic forwarding consume from the EventBus. Written as one word with capital E and capital B.; Not a message queue — events are ephemeral and named. No retention, no replay.; No-code engines → Microservices →
Multi Stacks: The canonical no-code vehicle and industrial-IoT communication engine. Covers CAN, CAN-FD, ISO-TP, DoIP, K-Line, UDS, J1939, J1587/J1708, J1850 VPW/PWM, ISOBUS, Modbus RTU/TCP, and CANopen — the same engine, the same JSON DSL, the same default-stacks catalogue.; Declarative model — four bullets: (1) Protocol — what transport and framing (CAN, J1939, UDS, ISOBUS, Modbus, …). (2) Question + Response — what command/PID/PGN/register to send and how to decode the answer. (3) Broadcast — read-only and unsolicited message handling (passive sniffing, event-style decoding without a request). (4) Strategy — what sequences to run and when; periodic out of the box, advanced via composition with MSP (signal-driven triggers) or MEP (event-driven sequences). 22 production-ready default stacks validated on every CI push.; Multi Stacks page → Automotive →
OBDStacks: Legacy name for Multi Stacks. See Multi Stacks.; Multi Stacks →
AI pipeline: The on-device AI pipeline uses mos-roi-shader and mos-ai-runtime. Customers declare an ONNX/TFLite model and configure the pipeline in TOML. mos-roi-shader extracts regions of interest via GPU (wgpu/Vulkan) and produces NPU-ready tensor dmabufs. mos-ai-runtime drives the NPU inference. No pixel bytes cross the CPU in the inference path — the dma-buf invariant holds end-to-end.; ONNX to TFLite auto-conversion is available. Configured in TOML; OTA-deployed. AI-class silicon reaches up to ~100 TOPS (QCS family).; AI Funnel page → Vision →
ROI Shader: A GPU process (wgpu/Vulkan) that extracts regions of interest from camera frames and produces NPU-ready tensor dmabufs. Imports dmabuf frames from mos-camera-capture, exports tensor topics consumed by mos-ai-runtime.; No pixel data crosses the CPU: the CPU drives the GPU command buffer, not the pixel pipeline. On iMX8M Plus: Vulkan ROI portable. On Qualcomm platforms: dmabuf-to-NPU zero-copy via ION/rpcmem.; Vision → AI Funnel →
MD21: Munic patented telemetry protocol. ASN.1 UPER-encoded binary protocol over TCP/TLS for bidirectional IoT device-to-server communication. Used by mos-communication-gateway and mos-update (as the OTA command channel).; More bandwidth-efficient than alternative protocols for dense telemetry on metered cellular links — via multiplexing, piggyback, compression, and ASN.1-based encoding.; Connectivity → Catalog →
LTEE: Long Term Extended Ephemeris — a satellite almanac pre-loaded into the GNSS receiver to reduce cold-start time-to-first-fix from minutes to seconds without a live internet connection at power-on.; Used by mos-gnss on u-blox M10 class receivers. Relevant for autonomy and precision agriculture deployments where vehicles start in cellular-dark areas.; Hardware tiers → Machinery →
1-Wire: A single-wire serial bus (Dallas/Maxim) used to attach low-speed sensors and identification tokens. The one-wire micro service covers driver identification (iButton), temperature, hygrometry, door sensing, and tank debimetry from a single physical wire.; Relevant for IoT gateway and agriculture programmes.; IoT Gateway → Machinery →
modem-class: Lowest tier of the MOS4 silicon ladder — typically a single-core SoC with cellular modem. Runs MOS4 with a single signal-processing graph at 28.4 MB steady-state RSS and 1.6 s first-app-ready boot.; Minimum SoC: Cortex-A7 single-core class, ~800 MHz, 256 MB RAM.; Hardware tiers → munic.io →
compute-class: Mid tier of the MOS4 silicon ladder — adds multi-camera capture, the MEP state-machine policy engine (T·C·A under the hood), and the 12-protocol Multi Stacks communication engine on top of the modem-class baseline.; One OS — no per-tier branch. Munic ports; the OEM picks the tier per product.; Hardware tiers → Multi Stacks →
AI-class: Top tier of the MOS4 silicon ladder — adds NPU inference, ROI shader (Vulkan), and the full on-device AI pipeline. Reference figure: up to ~100 TOPS (QCS family, binary-compatible with QCS6490).; iMX8M Plus: TFLite eIQ delegate NPU. Qualcomm QCS family: dmabuf-to-NPU zero-copy via ION/rpcmem.; Hardware tiers → AI Funnel →
start_level: Registry priority — a numeric value from 0 to 10 that determines the order in which micro services are started by the MOS4 supervisor. Lower values start earlier. Not to be confused with the architecture stack diagram layers L0–L7, which are a mental model for the platform structure.; L0–L7 is the architecture stack diagram convention (hardware at L0, application at L7). start_level 0–10 is the runtime registry ordering field. These are two separate concepts.; Architecture → Microservices →
CRA-ready: Conformance-aligned with the EU Cyber Resilience Act (applies from 2027). MOS4 ships article-by-article CRA mapping (Annex I §1, §2, Art. 13, Art. 14), CycloneDX SBOM, cargo audit / geiger / deny, semgrep, and a public PSIRT process on every release.; UNECE R155/R156: self-aligned. Formal assessment per programme. The OEM documents its application layer only.; Compliance → For CEO and board →
SBOM (CycloneDX): Software Bill of Materials in CycloneDX format — a machine-readable inventory of every dependency in a release. Required by the EU CRA and ships with every MOS4 release. Downloadable from the customer portal.; Generated by cargo cyclonedx on every commit across all 35 micro services. CVE gating via cargo audit is blocking; SBOM publication is informational.; Compliance → Whitepapers →
proto interface: A .proto file defining the typed service call service interface contract between micro services. The mos-interfaces repo holds 63 .proto files covering 46 service interfaces across connectivity, positioning, vision, power, and data domains.; Every micro service imports from this single shared registry. No per-repo wire format negotiation. mos-codegen generates typed stubs for each language SDK from these .proto files.; Architecture → Microservices →
mos-codegen: The MOS4 code-generation tool that produces typed stubs from .proto interface definitions for each supported language SDK (Rust, Python, C, C++). Run at build time via build.rs.; Ensures every micro service and every container SDK uses the same interface contract derived from the single mos-interfaces registry.; SDK → Microservices →

Registry priority reference

start_level 0–10: registry startup order.

start_level is a registry priority field, not an architecture layer label. The architecture stack uses L0–L7 as a mental model — these are separate conventions.

Eight-layer MOS4 architecture stack L0–L7 with the AI layer highlighted in amber — distinct from the start_level registry priority field — L0–L7 architecture layers (diagram model) — not the same as start_level 0–10 (runtime registry order).

start_level registry priority — approximate band groupings
Level range	Role	Example micro services
0–2	Hardware abstraction and BSP	modem, power, sensors
3–4	Platform services	OTA, config, observability
5–6	Domain engines	Multi Stacks, MSP, MEP, AI runtime
7–8	Application layer	customer micro services, containers
9–10	Late-binding services	optional add-ons