Platform
Die Betriebsschicht.
Fünf Fähigkeiten, die eine Flotte nach dem ersten ausgelieferten Gerät benötigt — und was es braucht, um diese Flotte im Feld am Leben zu erhalten. In die Plattform integriert; kein Zusatzmodul, kein Anbieter-Add-on, kein Problem des Kunden.
Säule 1
Observability
Live-Metriken, Traces und Snapshots pro micro service — Prometheus- und OpenTelemetry-kompatibel, ohne Konfiguration.
Automatische Metriken pro micro service
RPC-Timing, Anfrage- und Fehlerzähler, Durchsatz, Lifecycle-Events, Status, Uptime — kein Instrumentierungscode erforderlich.
Eigene Metriken + Health-Score
Jeder micro service überträgt eigene Metriken und einen 0,0–1,0 Health-Score über die In-Process-Observer-API.
Periodischer Cloud-Snapshot
Ein dedizierter Reporter-micro service sendet pro Komponente und pro Prozess Datensätze (CPU, Speicher, Dateideskriptoren, Threads, Uptime, Health-String) sowie einen erzwungenen Flush bei Leerlauf, Stop und Notfall-Stop.
Container-Prometheus-Scrape
Der Metrik-Endpunkt jedes laufenden Containers speist die Supervision-Pipeline über die leichtgewichtige Container-Engine.
W3C Trace Context-Propagierung
Verteiltes Tracing über micro services und Prozesse hinweg — keine Änderung am Anwendungscode erforderlich.
Force-Sync Remote-Pull
Cloud oder Tooling zieht bei Bedarf einen sofortigen Snapshot, ratenbegrenzt.
Warum das wichtig ist. Ein Flottengerät mit hundert unabhängigen micro services gibt innerhalb von Minuten nach dem Boot ein kohärentes Prometheus-kompatibles Metrik-Set aus; das Cloud-Team nutzt die Dashboards, die es bereits besitzt.
Wie Registry und Observer in die Plattformarchitektur passen →
Säule 2
Safety
Vier Supervisions-Ebenen und eine deterministische Eskalationskette. Ein hängender Task, ein hängender Prozess oder ein hängender Kernel kann das Gerät nicht verlieren.
Watchdog-Supervisionsfluss. Ein micro service-Task petzt seinen In-Process-HealthMonitor-Checkpoint; Prozess-Pings fließen zusammen mit dem HealthMonitor in den Watchdog-Policy-micro service; die Policy sendet warn, restart oder emergency stop an die Registry und petzt den Linux-Hardware-Watchdog; bei Hänger erzwingt die Hardware einen System-Neustart.
graph TD
A[Micro service-Task] -->|Checkpoint petzten| B[In-Process HealthMonitor]
C[Prozess-Pings] --> D[Watchdog-Policy-micro service]
B --> D
D -->|warn / restart / emergency stop| E[Registry]
D -->|petzten| F[Linux /dev/watchdog]
F -->|Hardware-Reset bei Hänger| G[System-Neustart] Ebene 1 — In-Process HealthMonitor
Jeder micro service deklariert benannte Checkpoints und petzt diese aus seiner Task-Schleife.
Ebene 2 — Prozess-Pings
Master- und Slave-Prozesse tauschen Health-Pings aus; degradierter Zustand wird an die Policy gemeldet.
Ebene 3 — Watchdog-Policy-micro service
30-Sekunden-Autonomschleife, Verletzungszähler pro Komponente, deterministische Aktionsleiter warn → restart → emergency stop.
Ebene 4 — Linux-Hardware-Watchdog
Timer wird in festen Intervallen gepetzt; hängt der Software-Stack, erzwingt die Hardware einen Reset.
Emergency-Stop-Lifecycle-Hook
Jeder micro service erhält vor dem Neustart ein kurzes Cleanup-Fenster. Hooks werden von der Registry aufgerufen, nicht von der Anwendung.
Issue-Aggregation
Identische Issues werden zu periodisch-oder-Burst-klassifizierten Batches zusammengefasst, bevor sie hochgeladen werden — das Cloud mit Duplikaten zu überfluten ist unmöglich.
Energie-Schiedsrichter
Jeder micro service kann ein Token halten, um einen Energieübergang bis zur sicheren Abwicklung aufzuschieben; die Engine wartet bis zu einem konfigurierbaren Timeout auf das Freiwerden der Tokens.
Warum das wichtig ist. Die Eskalationskette ist auditierbar, auf dem Prüfstand testbar und läuft ohne Bedienereingriff. Ein Feldausfall bei einer Flotte im großen Maßstab kostet mehr als die Plattform selbst.
Säule 3
Over-the-air-Updates
A/B-Partitionen, signierte Delta-Pakete, automatisches Rollback. Reines Rust, kein externer Daemon, läuft auf modem-class-Hardware.
A/B-Rootfs-Slots + Bootcount
Ein fehlgeschlagener Boot kehrt ohne Bedieneingriff zum vorherigen Slot zurück.
Delta-Pakete
Content-defined Chunking, Deduplizierung über mehrere Quellbäume, zstd-Komprimierung für modem-class-Ziele.
Kryptografische Kette
Signiertes Manifest wird vor jedem Flash-Schreibvorgang verifiziert; optionale Nutzlast-Verschlüsselung; Integritätsprüfungen pro Datei und für das Gesamtimage.
Persistente Retry- + Reboot-Zähler
Retry-Limit pro Datei, pro Update und pro Reboot — übersteht Stromausfälle, verhindert endlose Reboot-Schleifen bei fehlerhaften Updates.
Zwei Transport-Einstiegspunkte
Cloud-Befehlskanal und direkter micro service-Aufruf.
Zwei Binaries aus einer Bibliothek
Ein hostseitiger Generator und ein geräteseitiger Applizierer; Formatänderungen propagieren atomar.
Warum das wichtig ist. Firmware auszuliefern ist der einfache Teil; sie ohne Serviceeinsatz zurückzurollen ist der schwierige.
Wir gehen einen OTA-Rollout mit Ihnen durch, Ende zu Ende.
Säule 4
Remote-Steuerung
Ein einziger Kanal adressiert jeden micro service auf dem Gerät. Live-Signale, Live-Logs, Live-Diagnosesitzungen.
Cloud-aufrufbare micro service-Schnittstellen
Jede registrierte micro service-Schnittstelle ist aus der Cloud oder aus Tooling aufrufbar, JSON- oder Protobuf-Durchleitung, Runtime-Katalogabfrage, JSON-RPC-2.0-Fehler, optionale Latenzstatistiken pro Aufruf.
Remote-Log-Abruf
TAI64-Zeitstempel-Bereichsfilter plus grep/sed-Muster, gestreamte komprimierte Chunks. Kein SSH, kein SCP, kein geräteseitiges Tooling.
Observability-Snapshot auf Abruf
Sofortigen Snapshot abrufen, bevor ein Befehl oder Update ausgestellt wird; ratenbegrenzt.
Fahrzeugprotokoll-Oberfläche via Multi Stacks
Live-Auslesen jedes CAN-, CAN-FD-, DoIP-, ISOBUS-, J1939-, J1708-, J1850-, J1587-, HD-OBD-, Modbus-, RS-485-Signals als micro service-Topic.
Warum das wichtig ist. Der After-Sales-Workflow ist praktikabel, weil jedes Gerät in der Flotte dieselbe Remote-Steuerungs-Oberfläche exponiert.
Säule 5
Lifecycle
Jede Zustandsänderung ist bewusst gesteuert. Neustarts werden erklärt, Leerlaufzustände sind überschreibbar, Runtime-Upgrades rollen flottenweit ohne Änderungen am Kundencode aus.
Boot-Reason + Wake-Reason-Register
Allen micro services zugänglich (HardReset, SoftReset, WatchdogReset, Ignition, Alarm, RTC, CAN). Feld-Tooling und Cloud-Oberfläche lesen diese, um jeden Neustart auf die Ursache zurückzuführen.
Override-next-idle
Die Registry kann den nächsten natürlichen Leerlauf durch einen kontrollierten Neustart oder Shutdown ersetzen — keine überraschenden Neustarts im Feld.
Max-Uptime-Wächter
Zweischwelliges Reboot-Modell für Allokator-Fragmentierung auf dauerlaufenden Geräten; Soft-Limit startet beim nächsten Leerlauf neu, Hard-Limit erzwingt Neustart, Loop-Guard bricht Reboot-Leerlauf-Zyklen auf.
System-Layer
Operator-gepinnte gemeinsame Runtime-Layer. Ein flottenweites Runtime-Upgrade ist ein einziger Digest-Bump in der Operator-Konfiguration; Kunden-Anwendungscontainer werden nicht neu gebaut oder neu eingereicht.
Wake-Event-Konfiguration
Konfigurierbares Wake-Mask (Ignition, Alarm, RTC), damit das Gerät für Strom schläft und für die richtigen Signale aufwacht, auf Plattformen, die dies unterstützen.
Warum das wichtig ist. Flottenoperationen drehen sich selten um katastrophale Ausfälle; es geht um kohärente Antworten auf „Warum hat dieses Gerät letzte Nacht neu gestartet?" und „Wie rolle ich einen Runtime-Sicherheitspatch auf zehntausend Kunden-Container aus, ohne Kundencode anzufassen?".
Übergreifende Fähigkeit
Remote Care — die Flotten-Uptime-Ansicht
Die fünf Säulen oben zeigen, wie die Operations-Schicht pro Belang strukturiert ist. Dieselbe Oberfläche — als Ende-zu-Ende-Behebung betrachtet — ist die Remote-Care-Seite, gebaut für das Flottenoperations-Publikum, das in vermiedenen Immobilisierungen denkt, nicht in Säulen.
Wenn das Gerät stockt, schicken Sie keinen LKW. Sie schicken ein Paket.
Remote Care ist die übergreifende Ansicht der Operations-Schicht — drei Behebungsstufen (Diagnostizieren, Neukonfigurieren, Beheben), eine prädiktive Schicht auf dem Gerät und ein Audit-Log für jede Aktion. Eingebaute OS-Fähigkeit, keine separate SaaS.
Katalog
Die sieben Katalogkarten hinter der Schicht
Jede obige Aussage ist einem micro service zugeordnet. Im Katalog finden Sie Schnittstellen, Quellenspezifikation und Integrationspunkte.
Plattformarchitektur — wie Registry + Lifecycle zusammenpassen →
Safety
Watchdog
Vier-Ebenen-Supervision-Policy-micro service. 30-Sekunden-Autonomschleife; deterministische Eskalation; Hardware-Watchdog-Integration.
Observability
Observer
Periodischer Cloud-Snapshot-Reporter. Pro-Komponente und Pro-Prozess-Datensätze; erzwungener Flush bei Lifecycle-Übergängen; Force-Sync-RPC.
Safety
Sentry
Issue-Aggregation über alle micro services. Kaskaden-Gate beim Start; periodisch-oder-Burst- Klassifikation; Deduplizierung vor dem Upload.
Remote-Steuerung
Logs
Remote-Log-Abruf. TAI64-Zeitstempel-Bereich + grep/sed-Filter; gestreamte komprimierte Chunks; kein SSH, kein SCP.
OTA
Update
A/B-Partition-OTA. Signierte Delta-Pakete; content-defined Chunking; kryptografische Kette; Retry- und Rollback-Zähler.
Lifecycle
Containers
Leichtgewichtige Container-Engine. System-Layer-Substitution; Prometheus-Scrape pro Container; cgroups-v2-Ressourcenisolierung.
Safety + Lifecycle
Power
Energie-Schiedsrichter; Max-Uptime-Wächter; Wake-Event-Konfiguration; Override-next-idle; Boot- und Wake-Reason-Register.
Fragen
Die fünf Fragen, die Integratoren tatsächlich stellen
Was bei jedem technischen Discovery-Call aufkommt.
-
Ist dies eine Umbenennung von Compliance, Observability und OTA?
Nein. Compliance, Observability und OTA bleiben jeweils eigene Seiten und Konzepte. Die Betriebsschicht ist das übergeordnete Konzept — was die Plattform einer Flotte ab Tag zwei bietet — und verweist auf die jeweiligen Detailseiten.
-
Muss ich jede Säule verwenden?
Nein. Jede Säule ist unabhängig. Ein Team kann am ersten Tag nur mit Safety-Supervision und der OTA-Kette ausliefern und Remote-Steuerung sowie Observability-Snapshots aktivieren, sobald das Cloud-Backend bereit ist.
-
Bindet mich das an Munic-gehostete Cloud-Dienste?
Nein. Der Observability-Snapshot ist Prometheus- und OpenTelemetry-kompatibel; die OTA-Kette läuft gegen jeden HTTP-, HTTPS- oder SFTP-Endpunkt; die Remote-Steuerungs-Oberfläche spricht ein dokumentiertes JSON-Schema. Cloud-Backends sind austauschbar.
-
Was unterscheidet das von Prometheus + Grafana + einem eigenen OTA-Dienst in Containern?
Es ist kein anderer Stack. Es sind dieselben Protokolle, vorverpackt, mit dem geräteseitigen Klebstoff bereits vorhanden: Hardware-Watchdog-Integration, A/B-Partitions-Ablauf, signierte Paketverifizierung, lifecycle-gespülte Snapshots, deterministische Eskalation. Was ausgeliefert wird, ist die Inbetriebnahme.
-
Wie halten Sie die Seite aktuell, wenn sich die Plattform weiterentwickelt?
Jede Aussage auf dieser Seite verweist auf die zugehörige micro service-Dokumentation; CI schlägt bei veralteten oder fehlenden Quellenangaben fehl. Der micro service-Katalog ist die kanonische Wahrheit; diese Seite ist ein navigierbarer Index darüber.
Betreiben Sie Ihre Flotte auf MOS4.
Ein 30-minütiger Discovery-Call mit Engineering — gehen Sie Ihre Day-2-Kostenlinie durch und sehen Sie, welche Säulen sie am stärksten reduzieren.