Referenz
Glossar
Kurze Definitionen für das MOS4-Vokabular. Jeder Eintrag verlinkt auf die kanonische Seite, die ihn ausführlich erklärt.
- Micro service
- Die Deployment-Einheit in MOS4. Eine eigenständige Rust-Crate, annotiert mit #[component], die die bereitgestellten und benötigten Protobuf-Schnittstellen deklariert, mit einem Konfigurationsschema (mos.toml) und einer eigenen CI-Pipeline. Jedes betreute Repo im MOS4-Ökosystem ist ein Micro Service.
- Auf der Website werden Micro Services auch als Bausteine eines verteilten komponentenbasierten Betriebssystems bezeichnet. 52 Micro Services werden im produktiven Katalog ausgeliefert.
- Micro Services → Katalog →
- MCM
- MOS Container Manager — die leichtgewichtige OCI-Container-Engine, die Kundencode neben den Micro Services ausführt. Produktive Laufzeit ist crun mit cgroups v2 für die Ressourcendurchsetzung. Vier Mount-Profile: SHELL, PYTHON, NATIVE, STATIC.
- Substitution auf Systemebene: ein CPython-3.12-Update propagiert sich über einen einzigen system-layers.toml-Digest-Bump in alle Kunden-Python-Container. Container-Budget-Envelope: unter 5 % CPU/RAM und ~10 MB RSS.
- SDK → Micro Services →
- MSP
- Morpheus Signal Processing — eine graphbasierte Echtzeit-Signalverarbeitungs-Engine für Fahrzeugtelemetrie. Knoten werden durch Kanten in .msp.yml-Dateien verdrahtet; 226 Graphen über 21 Fahrzeugdomänen werden out of the box ausgeliefert.
- Die Graphen laufen auf einer Tokio-Async-Laufzeit, ausgerichtet auf Hardware der modem-Klasse. Eine neue Fahrzeugdomäne hinzuzufügen erfordert nur eine YAML-Datei — kein Rust-Recompile. 124 Kernels im visuellen Editor.
- No-Code-Engines → Automotive →
- MEP
- MOS Event Processor — eine YAML-konfigurierte Trigger → Bedingung → Aktion-Engine. Trigger sind Datenbank-Key-Änderungen, benannte Events vom EventBus oder Cron-Zeitpläne (UTC). Bedingungen werden vor der Aktion ausgewertet.
- Aktionen können beliebige MOS4-micro services aufrufen (Key schreiben, Event auslösen, Service-Call). Hot Reload: neue Policies werden validiert und unter Beibehaltung laufender Regeln eingewechselt — kein Prozess-Neustart erforderlich. Paralleler Regel-Worker-Pool mit Konflikterkennung. Produkt-Framing: aus Sicht des Product Owners führt MEP Zustandsmaschinen-Policies auf dem Gerät aus. Die Zustandsmaschine *ist* die Policy-YAML — es gibt keine separate Zustandsmaschinen-Laufzeit. Die T·C·A-Primitive ist die Engineering-Sicht desselben Artefakts.
- No-Code-Engines → MEP-Seite →
- EventBus
- Der MOS4-interne Kanal für die Verteilung benannter Events. Services veröffentlichen Events nach Namen; MEP-Trigger und mos-ros2-DDS-Topic-Forwarding konsumieren vom EventBus. Geschrieben als ein Wort mit großem E und großem B.
- Keine Message Queue — Events sind flüchtig und benannt. Keine Aufbewahrung, kein Replay.
- No-Code-Engines → Micro Services →
- Multi Stacks
- Die kanonische No-Code-Kommunikations-Engine für Fahrzeug- und Industrie-IoT. Deckt CAN, CAN-FD, ISO-TP, DoIP, K-Line, UDS, J1939, J1587/J1708, J1850 VPW/PWM, ISOBUS, Modbus RTU/TCP und CANopen ab — dieselbe Engine, dieselbe JSON-DSL, derselbe Katalog an Standard-Stacks.
- Deklaratives Modell — vier Punkte: (1) Protokoll — welcher Transport und welches Framing (CAN, J1939, UDS, ISOBUS, Modbus, …). (2) Frage + Antwort — welcher Befehl/PID/PGN/Register zu senden ist und wie die Antwort dekodiert wird. (3) Broadcast — Behandlung von nur-lesenden und unaufgeforderten Nachrichten (passives Mithören, ereignisartige Dekodierung ohne Anfrage). (4) Strategie — welche Sequenzen wann ausgeführt werden; periodisch out of the box, fortgeschritten via Komposition mit MSP (signalgetriebene Trigger) oder MEP (ereignisgetriebene Sequenzen). 22 produktionsreife Standard-Stacks, bei jedem CI-Push validiert.
- Multi-Stacks-Seite → Automotive →
- AI pipeline
- Die On-Device-KI-Pipeline nutzt mos-roi-shader und mos-ai-runtime. Kunden deklarieren ein ONNX/TFLite-Modell und konfigurieren die Pipeline in TOML. mos-roi-shader extrahiert Regions of Interest über GPU (wgpu/Vulkan) und erzeugt NPU-fertige Tensor-dmabufs. mos-ai-runtime steuert die NPU-Inferenz. Im Inferenzpfad überqueren keine Pixel-Bytes die CPU — die dma-buf-Invariante hält durchgehend.
- ONNX-zu-TFLite-Autokonvertierung ist verfügbar. Konfiguriert in TOML; via OTA ausgerollt. KI-Klasse-Silizium erreicht bis zu ~100 TOPS.
- AI-Funnel-Seite → Vision →
- ROI Shader
- Ein GPU-Prozess (wgpu/Vulkan), der Regions of Interest aus Kamera-Frames extrahiert und NPU-fertige Tensor-dmabufs erzeugt. Importiert dmabuf-Frames von mos-camera-capture, exportiert Tensor-Topics, die von mos-ai-runtime konsumiert werden.
- Keine Pixeldaten überqueren die CPU: die CPU steuert den GPU-Command-Buffer, nicht die Pixel-Pipeline. Auf der MIPI-CSI-KI-Klasse-Variante: Vulkan-ROI portabel. Auf der Serialiser-Bridge-KI-Klasse-Variante: dmabuf-zu-NPU Zero-Copy über gemeinsamen GPU-Speicher.
- Vision → AI Funnel →
- MD21
- Munic-patentiertes Telemetrieprotokoll. ASN.1-UPER-kodiertes Binärprotokoll über TCP/TLS für bidirektionale IoT-Gerät-zu-Server-Kommunikation. Verwendet von mos-communication-gateway und mos-update (als OTA-Befehlskanal).
- Bandbreiteneffizienter als alternative Protokolle für dichte Telemetrie über messbeschränkte Mobilfunkverbindungen — durch Multiplexing, Piggyback, Kompression und ASN.1-basierte Kodierung.
- Konnektivität → Katalog →
- modem-Klasse
- Unterste Stufe der MOS4-Silizium-Leiter — typischerweise ein Single-Core-SoC mit Mobilfunkmodem. Führt MOS4 mit einem einzigen Signalverarbeitungs-Graphen aus, bei 28,4 MB stationärem RSS und 1,6 s First-App-Ready-Boot.
- Minimum: Single-Core-Anwendungsprozessor, ~800 MHz, 256 MB RAM.
- Hardware-Stufen → munic.io →
- compute-Klasse
- Mittlere Stufe der MOS4-Silizium-Leiter — fügt Multi-Kamera-Capture, die MEP-Zustandsmaschinen-Policy-Engine (T·C·A unter der Haube) und die 16-Protokoll-Multi-Stacks-Kommunikations-Engine oberhalb der modem-Klasse-Basis hinzu.
- Ein OS — kein Branch pro Stufe. Munic portiert; der OEM wählt die Stufe pro Produkt.
- Hardware-Stufen → Multi Stacks →
- KI-Klasse
- Oberste Stufe der MOS4-Silizium-Leiter — fügt NPU-Inferenz, ROI-Shader (Vulkan) und die vollständige On-Device-KI-Pipeline hinzu. Referenzwert: bis zu ~100 TOPS auf der KI-Klasse-Stufe.
- MIPI-CSI-Variante: TFLite-NPU-Inferenz via Silizium-Hersteller-Delegate. Serialiser-Bridge-Variante: dmabuf-zu-NPU Zero-Copy über gemeinsamen GPU-Speicher.
- Hardware-Stufen → AI Funnel →
- start_level
- Registry-Priorität — ein numerischer Wert von 0 bis 10, der die Reihenfolge bestimmt, in der Micro Services vom MOS4-Supervisor gestartet werden. Niedrigere Werte starten früher. Nicht zu verwechseln mit den Architekturstapel-Diagrammschichten L0–L7, die ein mentales Modell für die Plattformstruktur sind.
- L0–L7 ist die Konvention des Architekturstapel-Diagramms (Hardware auf L0, Anwendung auf L7). start_level 0–10 ist das Reihenfolge-Feld im Laufzeit-Register. Dies sind zwei separate Konzepte.
- Architektur → Micro Services →
- CRA-ready
- Konformität mit dem EU Cyber Resilience Act (gilt ab 2027). MOS4 liefert ein artikelweises CRA-Mapping (Anhang I §1, §2, Art. 13, Art. 14), CycloneDX-SBOM, cargo audit / geiger / deny, semgrep und einen öffentlichen PSIRT-Prozess bei jedem Release.
- UNECE R155/R156: selbst ausgerichtet. Formale Bewertung pro Programm. Der OEM dokumentiert nur seine Anwendungsschicht.
- Compliance → Für das Compliance-Profil →
- SBOM (CycloneDX)
- Software Bill of Materials im CycloneDX-Format — ein maschinenlesbares Inventar jeder Abhängigkeit in einem Release. Erforderlich durch den EU CRA und mit jedem MOS4-Release ausgeliefert. Vom Kundenportal herunterladbar.
- Erzeugt von cargo cyclonedx bei jedem Commit über alle 52 Micro Services. CVE-Gate via cargo audit ist blockierend; SBOM-Veröffentlichung ist informativ.
- Compliance → Whitepapers →
- proto interface
- Eine .proto-Datei, die den typisierten Service-Call-Vertrag zwischen Micro Services definiert. Das mos-interfaces-Repo enthält 89 .proto-Dateien, die Services über Konnektivität, Positionierung, Vision, Energie und Daten-Domänen abdecken.
- Jeder Micro Service importiert aus diesem einzigen gemeinsamen Register. Keine Wire-Format-Verhandlung pro Repo. mos-codegen generiert aus diesen .proto-Dateien typisierte Stubs für jedes Sprach-SDK.
- Architektur → Micro Services →
- Private-premise autonomy
- Autonomer Fahrzeugbetrieb auf kontrolliertem Gelände — Bauernhof, Flugfeld, Mine, Steinbruch, Hafen-Umschlag, Golfplatz, Werksgelände. Schließt den Betrieb auf öffentlichen Straßen per Design aus. MOS4 unterstützt die Laufzeit, gehostete ROS2-Knoten, Maschinenbus, Wahrnehmungs-Silizium, Telemetrie und Remote Care; der Kunde liefert die Autonomie-Anwendung.
- Keine NHTSA-Homologation. Keine HD-Karten-Abhängigkeit. Kein L4-Autonomie-Stack mitgeliefert. Der OEM verantwortet Wahrnehmung, Planung, Steuerung und den Sicherheitsnachweis für die integrierte Maschine.
- Autonome Fahrzeuge → AI Vision →
- AI Cam (OEM-Box)
- Fest installierte Einzeloptik-Kamera-Box mit On-Device-KI-Inferenz, vom OEM gebrandet, auf der MOS4-Plattform betrieben. Eingesetzt für Industrieinspektion, Perimeter, Einzelhandels-Diebstahlschutz und Bedienersicht auf Schwerlastmaschinen. Abgegrenzt von der Dashcam, die fahrzeugintern und mit zwei Optiken ausgestattet ist.
- AI-Kameras → AI Vision →
- Dashcam (OEM)
- Fahrzeuginterne Dual-Optik-Kamera mit ADAS, DMS und DSGVO-Live-Anonymisierung auf der MOS4-Laufzeit. Eine von drei Einsatzformen des MOS4-Video-Stacks — neben der OEM-Kamera-Box und dem Multi-Kamera-Flottennetzwerk.
- AI-Kameras → AI Vision →
- Remote Care
- Eingebaute MOS4-OS-Fähigkeit, die Hot-Rekonfiguration und signierte Fernbehebung abdeckt. In jedes Gerät eingebaut. Material für jedes Programm, in dem eine Stilllegung mehr kostet als das Gerät.
- Zwei Behebungsstufen: aus der Ferne neu konfigurieren (MSP / MEP / Geofence-Hot-Reload, etwa zehn Sekunden Ende-zu-Ende) und aus der Ferne beheben (signiertes A/B-OTA, Remote-Reboot, Remote-Reflash). Jede Aktion wird signiert, gegated und im Audit-Log protokolliert. Für interaktive Steuergerät-Sitzungen — Lesen, Zurücksetzen, Kalibrierungen pushen, Attestieren und Reflashen — siehe Remote Diagnostic. Abgegrenzt von ekkofleet, der schlüsselfertigen Flotten-SaaS, die MOS4 als Plattform verwendet.
- Remote-Care-Seite → Remote-Diagnostic-Seite → Operations-Schicht →
- Remote Diagnostic
- Cloud-gesteuerte interaktive Diagnose-Sitzung auf derselben Engine, die auch die autonome Telemetrie antreibt. Die Cloud öffnet eine Sitzung, steuert den Fahrzeugbus, liest Steuergerät-Zustand, setzt DTCs zurück, pusht Kalibrierungen, attestiert und reflasht Firmware, dann schließt sie.
- Der Betriebsmodus zählt: Multi Stacks ist autonom (das Gerät entscheidet, was zu fragen ist, die Cloud empfängt), Remote Diagnostic ist interaktiv (die Cloud entscheidet, das Gerät handelt). Dieselben Protokolle (UDS, J1939, ISOBUS, Modbus, J2534-Passthrough), derselbe physische Bus. Sicherheits-Verriegelungen lassen sich von der Remote-Diagnostic-Oberfläche aus nicht überschreiben; Reflash ist signiert und attestiert; bootcount-basiertes Revert stellt bei fehlgeschlagenem Reflash die vorherige Firmware wieder her. Jede zustandsverändernde Aktion trägt eine pro-Aktion signierte Autorisierung und einen Audit-Log-Eintrag.
- Remote-Diagnostic-Seite → Multi Stacks (autonomes Pendant) →
- Telemetry uplink
- Der MD21-gesicherte Gerät-zu-Cloud-Datenpfad. Signiert, attestiert und über jedes MOS4-Produkt hinweg geteilt. Untermauert Remote Care und jede Flotten-SaaS-Schicht, die auf MOS4 aufsitzt.
- MD21 ist Munic-patentiert; gegenüber MQTT5 / SOTA liefert es geringeren Datenverbrauch und stärkere Attestierungs-Garantien. Die Bridge übersetzt EventBus-Events von und nach MQTT für Kunden, deren Backend bereits MQTT-förmig ist.
- Konnektivität → Remote Care →
- OBD-II
- On-Board Diagnostics II (SAE J1979) — die standardisierte Diagnoseschnittstelle, die ab 1996 für in Nordamerika und ab 2001 für in der EU verkaufte Personenkraftwagen vorgeschrieben ist. Definiert einen 16-poligen DLC-Stecker, einen Satz Standard-PIDs (Parameter Identifiers) und die fünf Transportprotokolle (ISO 9141-2, SAE J1850 VPW/PWM, CAN ISO 15765-4, KWP2000).
- Multi Stacks → Belege →
- UDS
- Unified Diagnostic Services (ISO 14229) — der internationale Standard für Diagnose-Sitzungen auf Steuergerät-Ebene. Definiert Services zum Lesen/Schreiben von Datensätzen, Zurücksetzen von Steuergeräten, Ausführen von Routinen und Flashen von Firmware. Wird von MOS4 Remote Diagnostic und Multi Stacks verwendet.
- Multi Stacks → Remote Diagnostic →
- J1939
- SAE J1939 — das Netzwerkprotokoll für Nutzfahrzeuge, aufgebaut auf CAN. Verwendet Parameter Group Numbers (PGNs) und Suspect Parameter Numbers (SPNs), um Motor-, Getriebe- und Achs-Steuergeräte in Lkw, Bussen und Off-Highway-Maschinen anzusprechen.
- Multi Stacks → Automotive →
- PGN
- Parameter Group Number — die J1939-Adressierungseinheit, die eine Gruppe verwandter Datenelemente identifiziert (z. B. Motordrehzahl, Kühlmitteltemperatur). Jede PGN wird auf eine oder mehrere SPNs abgebildet.
- Multi Stacks →
- SPN
- Suspect Parameter Number — der individuelle Signalbezeichner innerhalb einer J1939-PGN (z. B. SPN 190 = Motordrehzahl in U/min). Multi Stacks dekodiert SPNs über den deklarativen JSON-Stack.
- Multi Stacks →
- ISOBUS
- ISO 11783 — das Netzwerkprotokoll für landwirtschaftliche Maschinen, aufgebaut auf CAN. Verwendet für die Anbaugerät-zu-Traktor-Kommunikation (Sämaschinen, Spritzen, Erntemaschinen). MOS4 liest ISOBUS-Daten im Read-only-Modus über Multi Stacks.
- Multi Stacks → Automotive →
- J2534
- SAE J2534 PassThru — die Standard-API, die einer PC-Anwendung ermöglicht, über ein an den Fahrzeugbus angeschlossenes Pass-Through-Gerät mit Fahrzeug-Steuergeräten zu kommunizieren. MOS4 Remote Diagnostic implementiert den J2534-Passthru-Modus für cloud-gesteuertes Steuergerät-Flashen und -Kalibrieren.
- Remote Diagnostic →
- DTC
- Diagnostic Trouble Code — ein fünfstelliger Code (z. B. P0300), der in einem Steuergerät bei Erkennung einer Störung gespeichert wird. MOS4 liest, protokolliert und kann DTCs über die UDS- und OBD-II-Stacks aus der Ferne zurücksetzen.
- Multi Stacks → Remote Diagnostic →
- ECU
- Electronic Control Unit (Steuergerät) — ein eingebetteter Controller, der ein bestimmtes Fahrzeugsystem verwaltet (Motor, Getriebe, Bremsen, Karosserie). MOS4 kommuniziert mit Steuergeräten über CAN/UDS/J1939 und kann sie über signiertes OTA aus der Ferne reflashen.
- Multi Stacks → Remote Diagnostic →
- SAE J1850
- SAE J1850 — ein Legacy-OBD-II-Transportprotokoll (VPW bei 10,4 kbps, PWM bei 41,6 kbps), das auf nordamerikanischen Fahrzeugen verwendet wurde, bevor CAN obligatorisch wurde. In Multi Stacks für die Abdeckung älterer Fahrzeuge unterstützt.
- Multi Stacks →
- PID
- Parameter Identifier — das OBD-II-Äquivalent einer Datenadresse. Mode-01-PIDs melden Live-Sensorwerte (z. B. PID 0C = Motordrehzahl). Deklarative Multi-Stacks-Stacks referenzieren PIDs per Nummer und dekodieren sie in benannte Signale.
- Multi Stacks →
- MQTT
- Message Queuing Telemetry Transport — ein leichtgewichtiges Publish/Subscribe-Protokoll, das im IoT weit verbreitet ist. MOS4 enthält einen In-Process-MQTT-Broker, damit Kunden-Services ohne externen Broker publishen und subscriben können. Der Telemetrie-Uplink verwendet MD21, nicht MQTT, für den Gerät-zu-Cloud-Transport.
- Konnektivität →
- eUICC
- Embedded Universal Integrated Circuit Card — eine eingelötete, fernprogrammierbare SIM, die Profilwechsel über die Luft ohne physischen SIM-Tausch ermöglicht. Abgedeckt durch zwei GSMA-Standards: SGP.22 (Consumer) für Geräte mit Endanwender-Interaktion und SGP.02 (M2M) für Flotten- und Embedded-Deployments, die vom Netzbetreiber verwaltet werden.
- Konnektivität → Hardware-Stufen →
- GSMA SGP.22
- Der GSMA-Standard zur eUICC-Profilverwaltung für Consumer-Geräte — regelt die ferngesteuerte SIM-Bereitstellung für Endkundengeräte, bei denen der Endanwender die Profilauswahl steuert. Auch als eUICC Consumer bezeichnet.
- Konnektivität →
- GSMA SGP.02
- Der GSMA-Standard zur eUICC-M2M-Profilverwaltung — regelt die ferngesteuerte SIM-Bereitstellung für Maschine-zu-Maschine- und Flotten-Deployments, die von einem Betreiber oder Unternehmen verwaltet werden. Auch als eUICC M2M bezeichnet.
- Konnektivität →
- LPWA
- Low-Power Wide-Area Network — eine Klasse von Funktechnologien (NB-IoT, LTE-M, LoRaWAN), die für batteriebetriebene IoT-Geräte ausgelegt sind, die kleine Nutzlasten selten über große Entfernungen senden. MOS4-Konnektivitäts-micro services unterstützen LPWA-Modems neben Standard-Mobilfunk.
- Konnektivität →
- GNSS
- Global Navigation Satellite System — die Familie der Satellitenpositionierungssysteme (GPS, GLONASS, Galileo, BeiDou). MOS4 enthält dedizierte GNSS-micro services für Position, Geschwindigkeit, Kurs und Zeit.
- Hardware-Stufen → Belege →
- ESF
- External Sensor Fusion — eine Funktion des GNSS-Empfängers, die Satellitenmessungen mit Daten eines inertialen Sensors (Beschleunigungssensor, Gyroskop) fusioniert, um die Positionsgenauigkeit bei Satellitenausfällen (Tunnel, Häuserschluchten) aufrechtzuerhalten. MOS4 stellt ESF-Daten über die GNSS-micro services bereit.
- Hardware-Stufen →
- RTK
- Real-Time Kinematic GNSS — eine differentielle Korrekturtechnik, die durch den Vergleich von Trägerphasenmessungen mit einer Referenzstation Positionsgenauigkeit im Zentimeterbereich erreicht. In MOS4-Deployments für Präzisionslandwirtschaft und Bahnplanung autonomer Fahrzeuge eingesetzt.
- Autonome Fahrzeuge → Hardware-Stufen →
- ELD
- Electronic Logging Device (FMCSA 49 CFR Part 395) — ein US-bundesweit vorgeschriebenes Gerät, das die Lenkzeiten der Fahrer durch Lesen von Motordaten aus dem Fahrzeug-Steuergerät aufzeichnet. MOS4 enthält einen ELD-konformen Micro Service, der die Lenkzeitenprotokollierung über J1939/OBD-II abwickelt.
- Multi Stacks → Automotive →
- OTA
- Over-The-Air-Firmware-Update — die Fähigkeit, signierte Software-Updates ohne physischen Zugriff an ein Gerät zu liefern. MOS4 liefert ein signiertes A/B-OTA-System mit bootcount-basiertem Revert und Remote-Reflash, abgedeckt unter Remote Care.
- Remote Care → Operations-Schicht →
- LCV
- Light Commercial Vehicle (leichtes Nutzfahrzeug) — das Segment, das Transporter, Pick-ups und kleine Lkw abdeckt (typischerweise unter 3,5 t zulässiges Gesamtgewicht). Ein primäres Marktsegment für MOS4-Telematik-Deployments.
- Automotive →
- CRA
- EU Cyber Resilience Act — horizontale EU-Verordnung, die verpflichtende Cybersicherheitsanforderungen an Produkte mit digitalen Elementen stellt, wirksam ab 2027. MOS4 liefert ein CRA-konformes SBOM, eine cargo-audit/geiger/deny-Toolchain, semgrep-Statik-Analyse und einen öffentlichen PSIRT-Prozess.
- Compliance → CRA-ready →
- SBOM
- Software Bill of Materials — ein maschinenlesbares Inventar jeder Software-Abhängigkeit in einem Release. MOS4 erzeugt bei jedem Commit ein CycloneDX-SBOM über alle Micro Services. Erforderlich durch den EU CRA; vom Kundenportal herunterladbar.
- Compliance → SBOM (CycloneDX) →
- CycloneDX
- Ein offener SBOM-Standard (OWASP), der ein maschinenlesbares XML/JSON-Format für Software-Komponenten-Inventare definiert. MOS4 nutzt cargo cyclonedx, um bei jedem Release CycloneDX-SBOMs zu erzeugen.
- Compliance → SBOM (CycloneDX) →
- PSIRT
- Product Security Incident Response Team — die organisatorische Funktion, die Sicherheitsschwachstellen empfängt, priorisiert und öffentlich offenlegt. MOS4 betreibt im Rahmen seines CRA-konformen Sicherheitsprofils einen öffentlichen PSIRT-Prozess.
- Compliance →
- SAST
- Static Application Security Testing — automatisierte Analyse des Quellcodes auf Sicherheitsschwachstellen, ohne das Programm auszuführen. Die MOS4-CI führt bei jedem Commit semgrep-SAST-Regeln aus, Verstöße blockieren den Merge.
- Compliance →
- NPU
- Neural Processing Unit — ein dediziertes Silizium-Modul, optimiert für Matrixoperationen, die bei neuronaler Netz-Inferenz verwendet werden. MOS4-KI-Klasse-Hardware stellt die NPU dem mos-ai-runtime micro service über einen Zero-Copy-dmabuf-Pfad vom GPU-ROI-Shader bereit.
- AI Funnel → Hardware-Stufen →
- TOPS
- Tera Operations Per Second — die Einheit zur Bewertung des NPU-Inferenz-Durchsatzes. KI-Klasse-Hardware in MOS4 erreicht in der obersten Stufe bis zu etwa 100 TOPS.
- Hardware-Stufen → AI Funnel →
- ADAS
- Advanced Driver-Assistance Systems — die Klasse fahrzeuginterner Sicherheitsfunktionen (Spurverlassenswarnung, Frontalkollisionswarnung, Toter-Winkel-Erkennung), die durch On-Device-Vision-Inferenz geliefert werden. MOS4 unterstützt ADAS-Modell-Deployment über die On-Device-KI-Pipeline.
- AI Vision → AI-Kameras →
- DMS
- Driver Monitoring System — ein visionsbasiertes Sicherheitssystem, das Ablenkung, Müdigkeit oder Abwesenheit des Fahrers erkennt. Als ONNX/TFLite-Modell auf MOS4-KI-Klasse-Hardware über die On-Device-KI-Pipeline deployt.
- AI Vision → AI-Kameras →
- GMSL2
- Gigabit Multimedia Serial Link 2 — ein Serialiser-/Deserialiser-Kamera-Schnittstellenstandard, der hochauflösendes Video über ein einzelnes Koaxial- oder geschirmtes Twisted-Pair-Kabel übertragen kann. Auf MOS4-KI-Klasse-Hardware für Multi-Kamera-Flotteninstallationen verwendet.
- AI Vision → Hardware-Stufen →
- MIPI-CSI
- MIPI Camera Serial Interface — die Standard-Kurzstrecken-Kamera-Schnittstelle, die auf eingebetteten SoCs verwendet wird. MOS4 unterstützt MIPI-CSI-Kamera-Capture auf KI-Klasse-Hardware und führt Frames in den GPU-ROI-Shader und die NPU-Inferenz-Pipeline.
- AI Vision → Hardware-Stufen →
- RAG
- Retrieval-Augmented Generation — eine KI-Architektur, die ein Sprachmodell um einen Retrieval-Schritt über einen Dokumentkorpus erweitert, sodass Antworten in spezifisch abgerufenen Inhalten verankert sind, nicht allein in den Modellgewichten. In MOS4-On-Device-Konversationsschnittstellen verwendet.
- AI Funnel →
- STT
- Speech-To-Text — die Umwandlung gesprochener Audio in ein Texttranskript. MOS4 führt On-Device-STT-Modelle über die KI-Laufzeit für Sprachbefehlsschnittstellen und Fahrerinteraktion aus.
- AI Funnel →
- TTS
- Text-To-Speech — die Umwandlung von Text in synthetisierte Sprachaudio. In MOS4-On-Device-Konversationsschnittstellen für gesprochene Bedienerrückmeldung verwendet.
- AI Funnel →
- WER
- Word Error Rate — die Standardmetrik zur Bewertung der Spracherkennungsgenauigkeit, berechnet als (Substitutionen + Einfügungen + Löschungen) / Anzahl Referenzwörter. Niedriger ist besser.
- AI Funnel →
- ROS2
- Robot Operating System 2 — ein Open-Source-Robotik-Middleware-Framework, das Publish/Subscribe-Kommunikation, Hardware-Abstraktion und Tooling für autonome Systeme bereitstellt. MOS4 hostet ROS2-Knoten über mos-ros2 und überbrückt DDS-Topics zum MOS4-EventBus.
- Autonome Fahrzeuge →
- SDLC
- Software Development Life Cycle — der strukturierte Prozess, der Anforderungen, Entwurf, Implementierung, Verifikation und Wartung abdeckt. Die MOS4-CI erzwingt Sicherheits- und Qualitäts-Gates in jeder SDLC-Phase über das gemeinsame ci-gamma-Template.
- Compliance →
- JTBD
- Jobs To Be Done — ein Produkt-Denkrahmen, der Anwenderbedürfnisse als die "Jobs" rahmt, die eine Person in einem gegebenen Kontext zu erledigen versucht. Wird intern bei Munic verwendet, um Plattform-Features zu skopieren.
Referenz zur Registry-Priorität
start_level 0–10: Reihenfolge des Registry-Starts.
start_level ist ein Registry-Prioritätsfeld, kein Architekturschicht-Label. Der Architekturstapel nutzt L0–L7 als mentales Modell — das sind getrennte Konventionen.
| Level-Bereich | Rolle | Beispiel-micro services |
|---|---|---|
| 0–2 | Hardware-Abstraktion und BSP | Modem, Energie, Sensoren |
| 3–4 | Plattform-Services | OTA, Konfiguration, Observability |
| 5–6 | Domänen-Engines | Multi Stacks, MSP, MEP, KI-Laufzeit |
| 7–8 | Anwendungsschicht | Kunden-micro services, Container |
| 9–10 | Spät bindende Services | optionale Erweiterungen |