Reference
Glossary
Short definitions for the MOS4 vocabulary. Each entry links to the canonical page that explains it in depth.
- 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. 52 micro services ship in the production catalog.
- Micro services → 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 → Micro services →
- MSP
- Morpheus Signal Processing — a graph-based real-time signal processing engine for vehicle telemetry. Nodes are wired by edges in .msp.yml files; 226 graphs across 21 vehicle domains ship out of the box.
- Graphs run on a Tokio async runtime targeting modem-class hardware. Adding a new vehicle domain requires only a YAML file — no Rust recompile. 124 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 services (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 → Micro services →
- 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 →
- 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 the MIPI-CSI AI-class variant: Vulkan ROI portable. On the serialiser-bridge AI-class variant: dmabuf-to-NPU zero-copy via shared GPU memory.
- 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 →
- 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: single-core application processor, ~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 16-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 on the AI-class tier.
- MIPI-CSI variant: TFLite NPU inference via silicon-vendor delegate. Serialiser-bridge variant: dmabuf-to-NPU zero-copy via shared GPU memory.
- 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 → Micro services →
- 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 compliance posture →
- 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 52 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 contract between micro services. The mos-interfaces repo holds 89 .proto files covering services 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 → Micro services →
- Private-premise autonomy
- Autonomous-vehicle operation on controlled premises — farm, airfield, mine, quarry, port handler, golf course, yard. Excludes public-road operation by design. MOS4 supports the runtime, hosted ROS2 nodes, machine bus, perception silicon, telemetry, and remote care; the customer ships the autonomy app.
- No NHTSA homologation. No HD map dependency. No L4 autonomy stack provided. The OEM owns perception, planning, control, and the safety case for the integrated machine.
- Autonomous Vehicles → AI Vision →
- AI Cam (OEM box)
- Fixed-install single-optic camera box with on-device AI inference, branded by the OEM, running on the MOS4 platform. Used for industrial inspection, perimeter, retail anti-theft, and operator vision on heavy machines. Distinct from a dashcam, which is in-vehicle and dual-optic.
- AI Cameras → AI Vision →
- Dashcam (OEM)
- In-vehicle dual-optic camera with ADAS, DMS, and GDPR live anonymisation on the MOS4 runtime. One of three deployment shapes of the MOS4 video stack — alongside the OEM camera box and the multi-camera fleet network.
- AI Cameras → AI Vision →
- Remote Care
- Built-in MOS4 OS capability covering hot reconfiguration and signed remote remediation. Wired into every device. Material for any programme where one immobilisation costs more than the device.
- Two remediation tiers: reconfigure remotely (MSP / MEP / geofence hot-reload, around ten seconds end-to-end) and remediate remotely (signed A/B OTA, remote reboot, remote re-flash). Every action is signed, gated, and audit-logged. For interactive ECU sessions — read, reset, push calibrations, attest and reflash — see Remote Diagnostic. Distinct from ekkofleet, the turnkey fleet SaaS that uses MOS4 as its platform.
- Remote Care page → Remote Diagnostic page → Operations layer →
- Remote Diagnostic
- Cloud-driven interactive diagnostic session on the same engine that drives autonomous telemetry. The cloud opens a session, drives the vehicle bus, reads ECU state, resets DTCs, pushes calibrations, attests and reflashes firmware, then closes.
- Mode of operation matters: Multi Stacks is autonomous (device decides what to ask, cloud receives), Remote Diagnostic is interactive (cloud decides, device actuates). Same protocols (UDS, J1939, ISOBUS, Modbus, J2534-passthru), same physical bus. Safety interlocks are not override-able from the Remote Diagnostic surface; reflash is signed and attested; bootcount-based revert restores the previous firmware on failed reflash. Each state-changing action carries per-action signed authorisation and an audit log entry.
- Remote Diagnostic page → Multi Stacks (autonomous counterpart) →
- Telemetry uplink
- The MD21-secured device-to-cloud data path. Signed, attested, and shared across every MOS4 product. Underpins Remote Care and any fleet-SaaS layer that sits on top of MOS4.
- MD21 is Munic-patented; against MQTT5 / SOTA it ships with lower data consumption and stronger attestation guarantees. The bridge translates EventBus events to and from MQTT for customers whose back end is already MQTT-shaped.
- Connectivity → Remote Care →
- OBD-II
- On-Board Diagnostics II (SAE J1979) — the standardised diagnostic interface mandated on passenger cars sold in North America from 1996 and in the EU from 2001. Defines a 16-pin DLC connector, a set of standard PIDs (Parameter Identifiers), and the five transport protocols (ISO 9141-2, SAE J1850 VPW/PWM, CAN ISO 15765-4, KWP2000).
- Multi Stacks → Proof →
- UDS
- Unified Diagnostic Services (ISO 14229) — the international standard for ECU-level diagnostic sessions. Defines services for reading/writing data records, resetting ECUs, running routines, and flashing firmware. Used by MOS4 Remote Diagnostic and Multi Stacks.
- Multi Stacks → Remote Diagnostic →
- J1939
- SAE J1939 — the heavy-duty vehicle network protocol built on CAN. Uses Parameter Group Numbers (PGNs) and Suspect Parameter Numbers (SPNs) to address engine, transmission, and axle ECUs on trucks, buses, and off-highway machinery.
- Multi Stacks → Automotive →
- PGN
- Parameter Group Number — the J1939 addressing unit that identifies a group of related data items (e.g. engine speed, coolant temperature). Each PGN maps to one or more SPNs.
- Multi Stacks →
- SPN
- Suspect Parameter Number — the individual signal identifier within a J1939 PGN (e.g. SPN 190 = engine speed in RPM). Multi Stacks decodes SPNs via the declarative JSON stack.
- Multi Stacks →
- ISOBUS
- ISO 11783 — the agricultural machinery network protocol built on CAN. Used for implement-to-tractor communication (seeders, sprayers, harvesters). MOS4 reads ISOBUS data in read-only mode via Multi Stacks.
- Multi Stacks → Automotive →
- J2534
- SAE J2534 PassThru — the standard API that allows a PC application to communicate with vehicle ECUs through a pass-through device connected to the vehicle bus. MOS4 Remote Diagnostic implements J2534-passthru mode for cloud-driven ECU flashing and calibration.
- Remote Diagnostic →
- DTC
- Diagnostic Trouble Code — a five-character code (e.g. P0300) stored in an ECU when a fault is detected. MOS4 reads, logs, and can remotely reset DTCs via the UDS and OBD-II stacks.
- Multi Stacks → Remote Diagnostic →
- ECU
- Electronic Control Unit — an embedded controller managing a specific vehicle system (engine, transmission, brakes, body). MOS4 communicates with ECUs over CAN/UDS/J1939 and can remotely reflash them via signed OTA.
- Multi Stacks → Remote Diagnostic →
- SAE J1850
- SAE J1850 — a legacy OBD-II transport protocol (VPW at 10.4 kbps, PWM at 41.6 kbps) used on North American vehicles before CAN became mandatory. Supported in Multi Stacks for older vehicle coverage.
- Multi Stacks →
- PID
- Parameter Identifier — the OBD-II equivalent of a data address. Mode 01 PIDs report live sensor values (e.g. PID 0C = engine RPM). Multi Stacks declarative stacks reference PIDs by number and decode them into named signals.
- Multi Stacks →
- MQTT
- Message Queuing Telemetry Transport — a lightweight publish/subscribe protocol widely used in IoT. MOS4 includes an in-process MQTT broker so customer services can publish and subscribe without an external broker. The telemetry uplink uses MD21, not MQTT, for device-to-cloud transport.
- Connectivity →
- eUICC
- Embedded Universal Integrated Circuit Card — a soldered, remotely programmable SIM that enables over-the-air profile switching without a physical SIM swap. Covered by two GSMA standards: SGP.22 (Consumer) for devices with end-user interaction, and SGP.02 (M2M) for fleet and embedded deployments managed by the network operator.
- Connectivity → Hardware tiers →
- GSMA SGP.22
- The GSMA eUICC Consumer profile management standard — governs remote SIM provisioning for consumer devices where the end user controls profile selection. Also referred to as eUICC Consumer.
- Connectivity →
- GSMA SGP.02
- The GSMA eUICC M2M profile management standard — governs remote SIM provisioning for machine-to-machine and fleet deployments managed by an operator or enterprise. Also referred to as eUICC M2M.
- Connectivity →
- LPWA
- Low-Power Wide-Area network — a class of wireless technologies (NB-IoT, LTE-M, LoRaWAN) designed for battery-operated IoT devices that send small payloads infrequently over long distances. MOS4 connectivity micro services support LPWA modems alongside standard cellular.
- Connectivity →
- GNSS
- Global Navigation Satellite System — the family of satellite positioning systems (GPS, GLONASS, Galileo, BeiDou). MOS4 includes dedicated GNSS micro services for position, speed, heading, and time.
- Hardware tiers → Proof →
- ESF
- External Sensor Fusion — a GNSS receiver feature that fuses satellite measurements with data from an inertial sensor (accelerometer, gyroscope) to maintain position accuracy during satellite outages (tunnels, urban canyons). MOS4 exposes ESF data via the GNSS micro services.
- Hardware tiers →
- RTK
- Real-Time Kinematic GNSS — a differential correction technique that achieves centimetre-level positioning accuracy by comparing carrier-phase measurements with a reference station. Used in MOS4 deployments for precision agriculture and autonomous-vehicle path planning.
- Autonomous Vehicles → Hardware tiers →
- ELD
- Electronic Logging Device (FMCSA 49 CFR Part 395) — a US-federal-mandate device that records driver hours of service by reading engine data from the vehicle ECU. MOS4 includes an ELD-compliant micro service that handles hours-of-service logging over J1939/OBD-II.
- Multi Stacks → Automotive →
- OTA
- Over-The-Air firmware update — the ability to deliver signed software updates to a device without physical access. MOS4 ships a signed A/B OTA system with bootcount-based revert and remote re-flash, covered under Remote Care.
- Remote Care → Operations layer →
- LCV
- Light Commercial Vehicle — the segment covering vans, pick-ups, and small trucks (typically under 3.5 t GVW). A primary market segment for MOS4 telematics deployments.
- Automotive →
- CRA
- EU Cyber Resilience Act — horizontal EU regulation that applies mandatory cybersecurity requirements to products with digital elements, effective 2027. MOS4 ships a CRA-aligned SBOM, cargo audit/geiger/deny toolchain, semgrep static analysis, and a public PSIRT process.
- Compliance → CRA-ready →
- SBOM
- Software Bill of Materials — a machine-readable inventory of every software dependency in a release. MOS4 generates a CycloneDX SBOM on every commit across all micro services. Required by the EU CRA; downloadable from the customer portal.
- Compliance → SBOM (CycloneDX) →
- CycloneDX
- An open SBOM standard (OWASP) that defines a machine-readable XML/JSON format for software component inventories. MOS4 uses cargo cyclonedx to generate CycloneDX SBOMs on every release.
- Compliance → SBOM (CycloneDX) →
- PSIRT
- Product Security Incident Response Team — the organisational function that receives, triages, and publicly discloses security vulnerabilities. MOS4 operates a public PSIRT process as part of its CRA-aligned security posture.
- Compliance →
- SAST
- Static Application Security Testing — automated analysis of source code for security vulnerabilities without executing the program. MOS4 CI runs semgrep SAST rules on every commit, with violations blocking merge.
- Compliance →
- NPU
- Neural Processing Unit — a dedicated silicon block optimised for matrix operations used in neural-network inference. MOS4 AI-class hardware exposes the NPU to the mos-ai-runtime micro service via a zero-copy dmabuf path from the GPU ROI shader.
- AI Funnel → Hardware tiers →
- TOPS
- Tera Operations Per Second — the unit used to rate NPU inference throughput. AI-class hardware in MOS4 reaches up to approximately 100 TOPS on the top tier.
- Hardware tiers → AI Funnel →
- ADAS
- Advanced Driver-Assistance Systems — the class of in-vehicle safety features (lane departure, forward collision warning, blind-spot detection) delivered by on-device vision inference. MOS4 supports ADAS model deployment via the on-device AI pipeline.
- AI Vision → AI Cameras →
- DMS
- Driver Monitoring System — a vision-based safety system that detects driver distraction, fatigue, or absence. Deployed as an ONNX/TFLite model on MOS4 AI-class hardware via the on-device AI pipeline.
- AI Vision → AI Cameras →
- GMSL2
- Gigabit Multimedia Serial Link 2 — a serialiser/deserialiser camera interface standard capable of carrying high-resolution video over a single coaxial or shielded twisted-pair cable. Used on MOS4 AI-class hardware for multi-camera fleet installations.
- AI Vision → Hardware tiers →
- MIPI-CSI
- MIPI Camera Serial Interface — the standard short-range camera interface used on embedded SoCs. MOS4 supports MIPI-CSI camera capture on AI-class hardware, feeding frames into the GPU ROI shader and NPU inference pipeline.
- AI Vision → Hardware tiers →
- RAG
- Retrieval-Augmented Generation — an AI architecture that augments a language model with a retrieval step over a document corpus, so answers are grounded in specific retrieved content rather than model weights alone. Used in MOS4 on-device conversational interfaces.
- AI Funnel →
- STT
- Speech-To-Text — the conversion of spoken audio to a text transcript. MOS4 runs on-device STT models via the AI runtime for voice command interfaces and driver interaction.
- AI Funnel →
- TTS
- Text-To-Speech — the conversion of text to synthesised speech audio. Used in MOS4 on-device conversational interfaces for spoken operator feedback.
- AI Funnel →
- WER
- Word Error Rate — the standard metric for evaluating speech recognition accuracy, calculated as (substitutions + insertions + deletions) / reference word count. Lower is better.
- AI Funnel →
- ROS2
- Robot Operating System 2 — an open-source robotics middleware framework providing publish/subscribe communication, hardware abstraction, and tooling for autonomous systems. MOS4 hosts ROS2 nodes via mos-ros2, bridging DDS topics to the MOS4 EventBus.
- Autonomous Vehicles →
- SDLC
- Software Development Life Cycle — the structured process covering requirements, design, implementation, verification, and maintenance. MOS4 CI enforces security and quality gates at each SDLC stage via the ci-gamma shared template.
- Compliance →
- JTBD
- Jobs To Be Done — a product-thinking framework that frames user needs as the "jobs" a person is trying to accomplish in a given context. Used internally at Munic to scope platform features.
- MCP
- Model Context Protocol — an open standard that lets a coding assistant read typed resources from a system. The MOS4 MCP connector exposes the micro service catalog, the interface contracts, the configuration schema, and the device logs, so any MCP-aware client can query them at edit time.
- Developer Tools →
- MES
- Manufacturing Execution System — the factory-floor system that tracks and controls production. MOS4 developer tooling can model the MES handshake so a micro service is exercised against simulated production inputs before it runs on hardware.
- Developer Tools →
- HIL
- Hardware-in-the-loop — a test method that runs software against real target hardware instead of a simulation, gating on real performance. The MOS4 developer pack offers a hardware-in-the-loop rack of device flavors, hosted in Munic cloud or stood up on-premise.
- Developer Tools → AI Funnel →
- MLOps
- Machine-Learning Operations — the practice and tooling for building, tracking, deploying, and monitoring machine-learning models. The MOS4 model assessment pipeline binds Kubeflow and MLflow to check whether a model fits the latency and memory budget of the target device.
- Developer Tools → AI Funnel →
- CD
- Continuous Delivery — the practice of releasing every validated build through a controlled, phased rollout. In MOS4, continuous delivery rolls a signed image from your CI to the fleet in waves — a canary group first, then progressive expansion — with pause and roll-back at any phase.
- Developer Tools → Operations →
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.
| 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 |