Solutions · KI-Kameras
Eine KI-Kamera-Produktlinie ausliefern.
Ein Connected-Camera-OS für KI-first-Edge-Geräte. Kamera, GPU und NPU teilen sich Speicher — keine CPU-Pixel-Kopie. Pipeline in TOML deklarieren; ein ONNX- oder TFLite-Modell ausliefern. Bis zu ~100 TOPS auf der KI-Klasse-Stufe.
Drei Produkt-Shapes
Eine Runtime. Drei Deployment-Shapes.
Dieselbe MOS4-Video-Plattform wird in drei benannten Produkt-Shapes ausgeliefert. Die sechs Funktionen unten laufen unter jedem Shape — Erfassen, Aufzeichnen, Streamen, Abrufen, Aufwecken, Cloud-KI.
OEM-Kamera-Box · Festinstallation · Single-Optic
AI Cam · OEM-Box
Fest installierte Single-Optic-Kamera mit On-Device-KI-Inferenz. Industrie-Inspektion, Perimeter, Retail-Diebstahlschutz, Bediener-Vision auf Schwermaschinen. Vom OEM gebrandet, läuft auf der MOS4-Plattform.
In-Vehicle · Dual-Optic · ADAS + DMS
Dashcam · In-Vehicle
Dual-Optic-In-Vehicle-Dashcam mit Fahrerassistenz (ADAS), Fahrerüberwachung (DMS) und DSGVO-Live-Anonymisierung. Produktions-Deployments in Performance-Fahrzeugen, Lkw, leichten Nutzfahrzeugen und Spezialflotten.
Flotte · 3–5 Kameras · Bediener-Vision
Multi-Cam-Flotten-Netzwerk
Drei- bis fünf-Kamera-Arrays für Zustellung, Ground-Handling und Off-Highway-Bediener-Vision. Frames laufen direkt von den Kameras zur KI-Inferenz und Aufzeichnung ohne CPU-Kopie. Dieselben sechs Funktionen wie bei den Single-Kamera-Shapes, ausgefächert über alle Optiken.
Auf der Suche nach dem KI-Use-Case-Katalog (DMS, ADAS, Arbeitsplatz- & Asset-Sicherheit)? Siehe KI-Use-Cases. Pipeline-Deep-Dives (ROI-Shader, DSGVO-Live-Anonymisierung) leben bei AI Vision. Auf der Suche nach der Silizium-Leiter und Hardware-SKUs? Siehe Hardware und munic.io.
Funktionsübersicht
Wählen Sie die Aufgabe. Springen Sie zum Abschnitt.
Beliebige Kameras anbinden
Fünf Transporte — MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC — hinter einem Capture-Control-Service. Zwei SoC-Familien. Hot-Plug. Backend zur Laufzeit ausgewählt.
Bei Ereignis aufzeichnen
Rotierender Speicher mit ereignisgesteuertem Clip-Schutz — markierte Segmente werden von der Aufbewahrungs-Policy nie gelöscht. Null Flash-Schreibvorgänge bei normaler Aufzeichnung. DSGVO-Live-Anonymisierung läuft innerhalb der Erfassungspipeline.
Live streamen
WebRTC (browser-kompatibel), RTSP / RTSPS und SRT für latenzarme Langstrecke über verlustbehafteten Mobilfunk. Browser-freundliche Wiedergabe. Session-Signalisierung erledigt die Plattform — kein Signalisierungscode zu schreiben.
Clip abrufen
Sieben Service-Operationen decken den vollständigen Lebenszyklus gespeicherter Medien ab. Stream-Copy-Clip-Extraktion — kein Decode, kein Re-Encode. SFTP-Upload mit Server-Key-Pinning und Pre-Upload-Payload-Trim.
Bei Ereignis aufwecken
Sieben Weckquellen — Zündung, Alarm, RTC, CAN-Frame, Bewegung, Modem, Störung. Bereitschaftszeit unter fünf Sekunden — schnell genug, um ein flüchtendes Fahrzeug einzufangen.
KI auf die Bytes anwenden
On-Device-NPU-Triage heute; Cloud-KI auf hochgeladenen Clips, zusammengeführt mit dem Lifecycle-Ereignisstrom — Fahrerverhalten, DTC, OBD-Position, GNSS-Pose. DSGVO-konform durch Blur zum Erfassungszeitpunkt.
Wie es zusammenpasst
Eine Pipeline, sechs Funktionen.
Kamera produziert Zero-Copy-Frames in den Frame-Bus; der Bus fächert auf Encoder, NPU und Stream aus; Encoder speist den Dashcam-Index, der den SFTP-Upload speist, der die Cloud-KI speist; Cloud-KI empfängt auch NPU-Detektionen.
flowchart LR C[Camera<br/>MIPI · GMSL · UVC · RTSP · WebRTC] F[Frame bus<br/>shared-memory · 1:N fanout] E[Encoder<br/>H.264 segments] N[NPU<br/>on-device triage] S[Stream<br/>WebRTC · RTSP · SRT] D[Dashcam index<br/>SQLite · zero flash writes] U[SFTP upload<br/>host-key pinned] X[Cloud AI<br/>per-clip + lifecycle merge] C --> F --> E --> D --> U --> X F --> N --> X F --> S
Multi-Kamera
Eine bis acht Kameras ab Werk.
Fünf Transporte hinter einer Service-API. Zwei Hardware-Tiers. Ein bis acht Kameras pro Gerät werden in der ausgelieferten Runtime unterstützt; höhere Fan-outs sind auf Studie verfügbar. Frames laufen im gemeinsamen Speicher durch die Pipeline — jede Quelle konvergiert auf dasselbe Format, sodass nachgelagerte Verbraucher (KI-Inferenz, Encoder, Stream) keine Aushandlung pro Quelle benötigen.
Gleichzeitig Aufnahme + Stream
Viele Kameraplattformen zwingen zur Wahl zwischen lokaler Aufnahme und Streaming oder Upload älterer Clips. MOS4 wurde für beides gleichzeitig entworfen: Live-Encode in den flash-aware Segment-Sink, RTSP/WebRTC-Stream und Verlaufs-Clip-Upload laufen auf derselben Shared-Memory-Frame-Ebene, ohne Buffer-Duplikation.
Wear-Leveling-Speicher
Der Segment-Sink ist flash-aware: Schreibzugriffe werden über Blöcke rotiert, um die Lebensdauer auf Premium-SKUs mit Langzeitaufzeichnung zu verlängern. Aufbewahrungsrichtlinien, geschützte Clips und die Cloud-Upload-Queue laufen alle gegen dieselbe Wear-Budget-Abrechnung.
| Transport | SoC-Backend | Hinweise |
|---|---|---|
| MIPI-CSI | KI-Klasse / compute-Klasse (libcamera) | Native MIPI; keine externe Bridge |
| GMSL2 | KI-Klasse (Serialiser-Bridge) | Serialiser-Bridge-Pfad |
| USB UVC | Beide | Standard V4L2 UVC-Klassentreiber |
| Ethernet RTSP / ONVIF | Beide | Netzwerkkameras; RTSPS über TLS |
| WebRTC (WHEP) | Beide | Browser-kompatible Signalisierung |
Mehrere Sensoren speisen ihre Per-Plattform-Backends; Backends konvergieren auf ein Tee-Element mit dem Zero-Copy-Frame-Bus-Vertrag; das Tee fächert zu Encoder, NPU, GPU-ROI-Shader und Pose-Tracker aus.
flowchart LR S1[Sensor 1] --> B1[Backend<br/>per platform] S2[Sensor 2] --> B2[Backend] S3[Sensor N] --> B3[Backend] B1 --> T[Frame bus<br/>shared-memory · 1:N fanout] B2 --> T B3 --> T T --> E[Encoder] T --> N[NPU] T --> G[GPU crop/resize] T --> V[Pose tracker]
mos-camera-capture GStreamer-Pipeline durchgehend über fünf Transporte und zwei SoC-Familien. Backend zur Laufzeit über Device-Tree-Probe ausgewählt.
NV12 dmabuf entry
Jedes Backend normalisiert auf video/x-raw(memory:DMABuf), format=NV12.
CPU-Pixel-Mapping ist in Produktions-Builds eine Spec-Verletzung.
mos-frame Cross-Process-SHM-Fanout via Linux-dmabuf-fd über SCM_RIGHTS. LATEST-N-Drop-Policy pro Subscriber — ein langsamer Verbraucher hält den Producer nie auf.
CaptureControlService ListDevices · ConfigureStream · StartCapture · StopCapture · GetStatus · ResetCapture — eine Oberfläche für jede Plattform.
Bei Ereignis aufzeichnen
Aufzeichnen, was zählt. Behalten, was Sie markieren.
Rotierende Segmente wechseln nach Storage-Budget. Ein Ereignis-Flag macht aus einem Segment einen geschützten Clip — von der Retention-Policy nie gelöscht. DSGVO-Anonymisierung lebt innerhalb der Erfassungspipeline, bevor ein Frame den Encoder erreicht.
Erfassungspipeline speist den flash-aware Segment-Sink; jedes geschlossene Segment feuert ein SegmentClosed-Event in den SQLite-Index; der Retention-Enforcer prüft das Protected-Flag und löscht die ältesten ungeschützten Segmente über Budget; Ereignis-Flags rufen die Protect-Service-Methode auf, um Segmente als sicher zu markieren.
flowchart LR
C[Capture pipeline<br/>encode · parse · mux] --> S[Segment sink<br/>flash-aware]
S --> X[SegmentClosed event]
X --> I[(SQLite segment index<br/>in-memory + snapshots)]
I --> R{Retention check}
R -->|protected| K[Keep]
R -->|unprotected + over budget| D[Delete oldest]
E[Event flag<br/>driver behaviour · DTC · ...] --> P[Protect service method]
P --> I | Knopf | Standard | Hinweise |
|---|---|---|
| segment_seconds | konfigurierbar | Segmentdauer; begrenzt durch GOP und Storage-Write-Batch. |
| budget_bytes | 10 GiB | Retention-Enforcer löscht oberhalb davon die ältesten ungeschützten Segmente. |
| gop_seconds | konfigurierbar | Beeinflusst Clip-Kanten-Slop bei ExtractClip (~1–2 s). |
| anonymisation.enabled | false | DSGVO-Live-Blur (Pipeline-interne Pixelung). Reboot zum Umschalten. |
| event_flag | 0 | Pro-Segment-Flag; via Protect-Service-Methode schützen, um Retention zu überspringen. |
mos-camera-capture Segment-Encoder und DSGVO-Anonymisierungs-Stage — die GStreamer-Pipeline vom Sensor zum flash-aware Segment-Sink, einschließlich der GPU-Pixelung vor dem Encoder.
mos-dashcam Segment-Index (In-Memory-SQLite), Retention-Enforcer und Protect-Service-Methode — der vollständige Lebenszyklus gespeicherter Medien ohne einen einzigen Flash-Write bei normaler Aufzeichnung.
flash-aware segment sink Atomare Umbenennung beim Segment-Schluss — power-loss-sichere Segmentgrenze. Keine partiellen Segmente im Index nach einem unerwarteten Shutdown.
mp4mux + h264parse + hw-encoder
Encoder-Pipeline zur Laufzeit ausgewählt — Hardware-H.264-Encoder auf KI-Klasse-Silizium,
V4L2-H.264-Encoder auf der anderen Variante. h264parse normalisiert den Bytestream;
mp4mux muxt in MP4.
Live streamen
Live zu einem Browser, einem Player oder einem Cloud-Relay streamen.
Drei Live-Pfade — WebRTC (browser-kompatibles WHEP), RTSP / RTSPS und SRT. SRT für latenzarme Langstrecke über verlustbehafteten Mobilfunk. Der Micro Service übernimmt das Session-Setup; die Signalisierung ist für die Integration transparent.
Kamera speist den H.264-Encoder; Encoder fächert zu einem RTSP-Server (rtsps:// mit TLS), einem WHEP-Endpoint und einem SRT-Listener aus; RTSP speist VLC/ffmpeg-Player, WHEP speist einen Browser, und SRT speist ein Cloud-Relay.
flowchart LR C[Camera] --> E[Encoder<br/>H.264] E --> R[RTSP server<br/>rtsps:// · TLS] E --> W["WHEP endpoint<br/>http(s)://.../whep"] E --> S[SRT listener] R --> P1[Player<br/>VLC · ffmpeg] W --> P2[Browser] S --> P3[Cloud relay]
| Protokoll | URI | Element | Einsatz |
|---|---|---|---|
| WebRTC (WHEP) | http(s)://…/whep | whepsrc | Browser-Wiedergabe; eingebettete Ansicht in Flotten-UI |
| WebRTC (WS-Signalisierung) | ws(s)://… | webrtcsrc | Eigener Signalisierungs-Server |
| RTSP | rtsp://… | rtspsrc | VLC · ffmpeg · NVR-Ingest |
| RTSPS (RTSP + TLS) | rtsps://… | rtspsrc protocols=tcp+srtp | TLS-validierter CA-Bundle für Produktion |
| SRT | srt://… | srtsink / srtsrc | Latenzarme Langstrecke über verlustbehafteten Mobilfunk |
whepsrc / webrtcsrc WebRTC-Quellelemente — WHEP offer/answer über HTTP, WebSocket-Signalisierung, ICE-Gathering, DTLS-Handshake. Sie liefern die URI; das Element verhandelt die Session.
rtspsrc
RTSP- und RTSPS-Quelle — einfaches rtsp:// oder TLS-validiertes
rtsps:// mit protocols=tcp+srtp. CA-Bundle in Produktion
gepinnt; Entwicklung kann tls-validation-flags=0 setzen.
SRT plumbing
SRT-Listener via srtsink / srtsrc — Paket-Recovery über verlustbehafteten
Mobilfunk ohne TCP-Head-of-Line-Blocking. Langstrecke zu einem Cloud-Relay ohne Relay-seitigen
Integrationscode.
ICE / DTLS session establishment Vollständiger WebRTC-Session-Lifecycle — Candidate-Gathering, STUN/TURN-Traversal, DTLS-SRTP-Schlüsselvereinbarung. Der Micro Service exponiert den RTP-Stream, sobald die Session live ist; die Integration berührt den Handshake nicht.
TLS validation for rtsps://
X.509-Zertifikatsketten-Validierung, CA-Bundle-Pinning und SRTP-Schlüsselableitung — alles
innerhalb von rtspsrc. Kein OpenSSL-Plumbing in der Integrationsschicht.
Clip abrufen
Auf Anforderung einen Clip ziehen. In Ihre Cloud ausliefern.
Sieben Service-Operationen decken den Lebenszyklus gespeicherter Medien ab. Stream-Copy-Clip-Extraktion — kein Decode, kein Re-Encode, ~1–2 s Kantengrenze. SFTP-Upload mit Server-Key-Pinning, Path-Traversal-Guard und Pre-Upload-Payload-Trim.
GetSegments queryt den Segment-Index nach Lens und Zeitspanne; ExtractClip führt Stream-Copy-Extraktion mit ~1–2 s Kanten-Slop durch; Upload sendet via SFTP mit Host-Key-Pinning; die Payload wird vor der Übertragung getrimmt (redundante Atoms entfernt, Chunk-Offsets gepatcht). Snapshot (Keyframe zu JPEG ~50 ms) und Protect/Unprotect sind als gestrichelte Sidepaths gezeigt.
flowchart LR G[GetSegments<br/>by lens + time range] --> X[ExtractClip<br/>no decode · ~1–2 s edge slop] X --> U[Upload<br/>SFTP · host-key pinned] U --> M[Trim payload<br/>no re-encode] S[Snapshot<br/>keyframe → JPEG ~50 ms] -.-> X P[Protect / Unprotect] -.-> G
| Operation | Eingabe | Ausgabe |
|---|---|---|
| GetSegments | lens, start_ts, end_ts | Liste von SegmentRow |
| ExtractClip | segment_id, start_offset, end_offset | Clip-Pfad auf der Disk |
| Snapshot | segment_id, keyframe_offset | JPEG-Pfad |
| Protect | segment_id | — (idempotent) |
| Unprotect | segment_id | — (idempotent) |
| Remove | segment_id | — (löscht Datei + Zeile) |
| Upload | paths, destination_uri, options | Upload-Status-Stream |
mos-dashcam Segment-Index (SQLite, In-Memory mit Snapshots), Retention-Enforcer und alle sieben Service-Operationen — GetSegments, ExtractClip, Snapshot, Protect, Unprotect, Remove, Upload. Produktionsreif auf internen Aufzeichnungspfaden.
splitmuxsrc ! qtmux ! filesink
GStreamer-Mux-Only-Pipeline für ExtractClip — splitmuxsrc liest das Quellsegment;
qtmux remuxt den Stream; filesink schreibt den Output-Clip. Kein Decode,
kein Re-Encode, kein Pixel-Round-Trip.
russh-sftp ring backend
SFTP-Upload-Transport — russh-sftp mit Ring-Backend, Host-Key-Pinning, Path-Traversal-Guard
und Context-Token-URL-Substitution. Die Integration liefert eine URI; der Micro Service übernimmt
SSH-Handshake und Stream-Transfer.
mp4-reduce
Entfernt free- und skip-Atoms aus dem MP4-Container und patcht
dann stco / co64 Chunk-Offset-Tabellen, um die Datei gültig zu halten.
Reduziert die Upload-Payload, ohne einen einzigen Frame neu zu encodieren.
dashcam-controller
White-Label-External-Dashcam-Integration über Wi-Fi-HTTP und TCP-Benachrichtigung. Eine
Pending-Request-Queue mit TTL überbrückt Konnektivitätslücken. Unterscheidet sich von
mos-dashcam — dieser Micro Service treibt eine externe Hardware-Einheit, nicht
die interne Aufzeichnungspipeline auf der MOS4-Box.
mos-dashcam vs dashcam-controller
mos-dashcam ist der interne Rekorder: Er läuft auf der MOS4-Box, besitzt die Segment-FIFO und exponiert die oben dokumentierten sieben Service-Operationen. dashcam-controller steuert eine externe White-Label-Dashcam-Einheit über Wi-Fi-HTTP und TCP-Benachrichtigung — separate Hardware, separater Lebenszyklus, dasselbe Fahrzeug. Beide können gleichzeitig laufen; sie teilen keinen State.
Bei Ereignis aufwecken
Bei Aufprall aufwecken. Bei einem CAN-Frame aufwecken. Bei einem Cloud-Befehl aufwecken.
Sieben Weckquellen decken den Lebenszyklus eines geparkten oder schlafenden Fahrzeugs ab. Die Bereitschaftszeit liegt unter fünf Sekunden — schnell genug, um ein Fahrzeug einzufangen, das gerade begonnen hat sich zu bewegen.
Sieben Weckquellen — Zündung, Alarm, RTC, CAN-Frame, Bewegung, Modem, Störung — speisen alle den Power Manager, der die Box in unter fünf Sekunden in den Bereit-Zustand bringt.
flowchart LR IG[Ignition<br/>vehicle ignition signal] --> PM[Power manager] AL[Alarm<br/>external alarm input] --> PM RT[RTC<br/>scheduled wall-clock / relative timer] --> PM CA[CAN frame<br/>CAN ID match] --> PM MV[Movement<br/>accelerometer threshold] --> PM MO[Modem<br/>cloud-issued remote wake] --> PM DI[Disturbance<br/>G-sensor impact threshold] --> PM PM --> BR[Box ready<br/>< 5 s]
| Quelle | Trigger | Einsatz | Bereitschaftszeit |
|---|---|---|---|
| Zündung | Fahrzeug-Zündsignal | Standard-Flottenbox | < 5 s |
| Alarm | Externer Alarm-Input | Einbruch / Panik-Knopf | < 5 s |
| RTC | Geplanter Wall-Clock- oder relativer Timer | Periodischer Health-Upload / Tagesabschluss | < 5 s |
| CAN-Frame | CAN-ID-Match | Wecken bei spezifischem Signal — Kabelbaumfehler / Tür offen | < 5 s |
| Bewegung | Beschleunigungssensor-Schwelle | Fahrzeug bewegt sich im Parkzustand → Wecken zur Aufnahme | < 5 s |
| Modem | Cloud-initiiertes Remote-Wecken | Operator weckt für Live-Stream / Clip-Abruf | < 5 s |
| Störung | G-Sensor-Impact-Schwelle | Crash- / Einbruchsereignis-Aufzeichnung | < 5 s |
configure_wake_events Power-Manager-Weckquellen-Bitmaske — konfiguriert, welche der sieben Quellen für den nächsten Sleep-Zyklus aktiv sind. Ein Aufruf; der Micro Service besitzt die Hardware-Register-Writes und die Quellen-Arbitration.
set_rtc_wake_time RTC-Wake-Scheduler — setzt einen Wall-Clock-Timestamp oder einen relativen Offset für das nächste geplante Wecken. Wird für periodischen Health-Upload, Tagesabschluss-Reporting oder jeden zeitgesteuerten Resume-Zyklus verwendet.
get_wake_reason / clear_wake_reason Wake-Reason lesen und löschen — einmal nach Resume aufrufen, um die Bitmaske mit der auslösenden Quelle zu lesen, dann vor dem nächsten Sleep löschen. Der Power Manager besitzt das Reason-Register und unterscheidet automatisch zwischen Boot und Wake.
boot-vs-wake discrimination Der Power Manager unterscheidet beim Startup einen Kaltstart von einem Wake-from-Sleep. Der Integrationscode sieht eine saubere Wake-Reason-Bitmaske — keine Roh-Hardware-Register-Inspektion erforderlich.
request_reboot_on_idle / request_shutdown_on_idle Override-Next-Idle-Hooks — planen einen Reboot oder Shutdown am Ende des aktuellen aktiven Fensters, ohne laufende Aufzeichnung oder Upload zu unterbrechen. Der Micro Service wartet auf die Idle-Bedingung, bevor er ausführt.
Cloud-KI
On-Device-NPU heute. Cloud-KI auf den Bytes, die Sie hochladen.
Die On-Device-KI-Triage läuft, bevor ein Byte die Box verlässt — Frames werden auf der NPU gecroppt und analysiert. Ein Munic-Cloud-Produkt führt dann schwerere Pro-Clip-KI auf hochgeladenen Segmenten aus und führt sie mit dem Lifecycle-Ereignisstrom zusammen — Fahrerverhalten, Fehlercodes (DTC), OBD-II-Position, GNSS-Pose. Der Clip ist DSGVO-konform, bevor die Cloud ihn sieht.
Erfassung mit DSGVO-Live-Blur speist die On-Device-NPU-Triage und das Rekorder-Segment. Das Segment wird via SFTP als DSGVO-saubere Bytes in die Cloud-KI hochgeladen. Fahrerverhalten, DTC/OBD-Position und GNSS-Pose speisen den Lifecycle-Ereignisstrom, der mit der Cloud-KI-Pro-Clip-Inferenz zusammengeführt wird und ins Flotten-Dashboard ausgibt.
flowchart TD CAP[Capture<br/>GDPR live blur at capture time] --> NPU[NPU triage<br/>GPU crop + on-device inference] CAP --> REC[Recorder segment<br/>anonymised clip] REC --> UPL[SFTP upload<br/>GDPR-clean bytes] UPL --> CAI[Cloud AI<br/>per-clip inference] DRV[Driver behaviour] --> LS[Lifecycle event stream] OBD[DTC / OBD position] --> LS GNS[GNSS pose] --> LS LS --> CAI CAI --> DSH[Fleet dashboard]
Die On-Device-Triage läuft, bevor ein Byte die Box verlässt — Region-of-Interest-Extraktion plus NPU-Inferenz verwerfen irrelevante Frames. Was die Cloud erreicht, ist bereits anonymisiert und bereits gefiltert. Die Cloud-KI führt schwerere Pro-Clip-Modelle aus und führt sie mit dem AI Funnel-Lifecycle-Ereignisstrom für Flotten-Skalierungs-Fahrerverhalten und Vorfall-Korrelation zusammen.
mos-roi-shader Vulkan-ROI-Extraktion mit dmabuf-zu-NPU-Zero-Copy auf unterstütztem KI-Klasse-Silizium — keine CPU-Pixel-Kopien im KI-Hot-Path. Regions of Interest werden extrahiert und an die NPU geliefert, ohne den Accelerator-Speicher-Domain zu verlassen.
mos-ai-runtime .tflite-NPU-Inferenz auf KI-Klasse-Silizium — gleichzeitige Multi-Modell-Ausführung über NPU-Slices, vom Micro Service verwaltet. Bringen Sie Ihre .tflite-Modelldatei mit; die Runtime übernimmt Scheduling, Speicher und Ergebnis-Lieferung.
AI Funnel Cloud-Retraining, Quantisierung und OTA-Modell-Lieferung — verwaltet durch die AI Funnel-Pipeline. Neu trainierte Modelle landen ohne Firmware-Update-Zyklus auf dem Gerät. Kein Integrationscode erforderlich, um den Feedback-Loop zu verdrahten.
lifecycle event correlation An jedes Lifecycle-Ereignis wird ein zeit-vertrauenswürdiges Flag angehängt — Fahrerverhalten, Fehlercodes (DTC), OBD-II-Position, GNSS-Pose. Die Cloud-KI nutzt das Flag, um mehrdeutige Timestamp-Matches abzulehnen, bevor sie mit Clip-Inferenz-Ergebnissen zusammengeführt werden. DSGVO-Postur dokumentiert unter /de/platform/compliance.
Scope-Grenze
Ein spezifisches Munic-Cloud-Produkt liefert die in diesem Abschnitt beschriebene Pro-Clip-Inferenz und Lifecycle-Merge. Produktname, Pricing und Cloud-Architektur liegen außerhalb des Scopes dieser Seite — das Gespräch dazu beginnt mit dem Engineering. Nutzen Sie den CTA unten, um Kontakt aufzunehmen.
Katalog der KI-Use-Cases
DMS, ADAS und Flottensicherheit — der vollständige Katalog.
Fahrerüberwachung, Fahrassistenz, Arbeitsplatzsicherheit und Asset-Sicherheit — jeweils ein On-Device-Modell, fusioniert mit Live-Fahrzeugtelemetrie. Bringen Sie Ihr eigenes Modell mit oder lassen Sie eines aus Ihrem Material trainieren.
Den vollständigen KI-Use-Case-Katalog ansehen →FAQ
Häufig gestellte Fragen
-
Läuft der Video-Stack auf Hardware der modem-Klasse?
Erfassung und Dashcam-Aufzeichnung laufen auf Geräten der compute-Klasse. NPU-Inferenz (GPU-Crop, On-Device-KI-Runtime) erfordert KI-Klasse-Silizium — es gibt in Produktion keinen CPU-Fallback.
-
Wo findet die DSGVO-Anonymisierung statt?
Innerhalb der Erfassungspipeline, bevor ein Frame den Encoder, die KI-Runtime oder einen Verbraucher erreicht. Aufgezeichnete Segmente sind bereits konform; nachgelagerte Verbraucher erhalten bereits anonymisierte Frames.
-
Muss ich Encoder- oder Pipeline-Code schreiben?
Nein. Der Kamera-Capture-micro service verwaltet die Video-Pipeline durchgehend — Start, Stopp, Fehler-Recovery, Hot-Plug — über fünf Transporte und zwei Hardware-Tiers.
-
Wie unterscheidet sich die externe White-Label-Dashcam von der internen Aufzeichnung?
mos-dashcam ist der interne Rekorder; dashcam-controller steuert externe White-Label-Dashcam-Hardware über Wi-Fi-HTTP und TCP-Benachrichtigung. Beide können auf demselben Fahrzeug zusammenarbeiten.
Bringen Sie zwei Kameras und einen Use-Case mit.
Erfassungstransport, Aufzeichnungsstrategie, Live-Protokoll, Weckquelle, KI-Modell, Deployment-Shape — bringen Sie mit, was Sie haben, und wir skizzieren die Pipeline während des Gesprächs. Multi-Cam-Flotten auf autonomen Fahrzeugen lassen sich auch mit Remote Care paaren.