Vergleich

MOS4 vs. AGL & Apex.OS

AGL und Apex.OS sind SDV-Klasse-Laufzeiten, die um Konsortien- und Partnerprogramme herum aufgebaut sind. MOS4 deckt dieselbe Problemklasse als Standardprodukt ab — Evaluierung über ein direktes Engineering-Gespräch, kein Arbeitsgruppen-Gate.

Geschlossenes AGL/Apex-Konsortiums-Tor mit Schlüssel im Schloss; daneben ein offener MOS4-Standardprodukt-Pfad mit einem bernsteinfarbenen Pfeil, der hindurchfließt

Adoptionspfad

Konsortiumsprogramm vs. Standardprodukt.

Der Konsortiumspfad erfordert eine Mitgliedschaft oder Partnervereinbarung, eine Referenzplattform und ein Produktionsprogramm. Der Standardprodukt-Pfad führt eine Evaluierung unter Lizenz durch, liefert ein Pilotgerät aus und deployt auf der MOS4-Hardware-Leiter.

flowchart LR
  subgraph Cons["Konsortium-/Partner-Pfad"]
    O1[Mitgliedschaft oder Partnervereinbarung] --> O2[Referenzplattform] --> O3[Produktionsprogramm]
  end
  subgraph T2["Standardprodukt-Pfad"]
    T1[Evaluierung unter Lizenz] --> T2x[Pilotgerät] --> T3[Deployment auf Hardware-Leiter]
  end

Gegenüberstellung

Fähigkeitsvergleich.

Zielgruppe AGL / Apex.OS OEM-Konsortien, Tier-1-IVI-Programme, Apex.OS-Partner-Ökosystem. MOS4 Tier-2-Zulieferer, Flottenbetreiber, Landwirtschafts- und Off-Highway-Maschinenbauer.
Adoptionsmodell AGL / Apex.OS AGL-Konsortiumsmitgliedschaft oder Apex.OS-Partnervereinbarung erforderlich, um Zugang zum vollständigen Stack zu erhalten. MOS4 Standardprodukt-Evaluierung unter einer direkten Lizenz. Kein Konsortium-Gate.
Service-Verträge AGL / Apex.OS AGL: D-Bus + Protobuf-Service-Deskriptoren. Apex.OS: ROS2-Lifecycle-Interfaces in C++. MOS4 89 .proto-Dateien in mos-interfaces definieren jede Service-Grenze, geprüft von buf lint und cargo build in CI.
Komponentenerstellung AGL / Apex.OS AGL: D-Bus-Service-Deskriptor + Boilerplate pro Service. Apex.OS: ROS2-Knoten-Lifecycle-Implementierung. MOS4 Schnittstellen in Proto deklarieren, eine Rust-Struktur mit #[component] annotieren, das generierte Trait implementieren. Ein minimaler Micro Service ist unter 30 Zeilen Rust.
Fahrzeugprotokolle AGL / Apex.OS AGL zielt auf OEM-IVI-Stacks (primär Ethernet-SDV). Apex.OS liefert keine OBD-Protokoll-Stacks. MOS4 obdstacks-v2: 16 Protokolle (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, KWP, J1850, GMLAN, CANopen, Modbus) über deklarative JSON-Stack-Dateien, zur Laufzeit hot-loadbar.
Flotten-OTA AGL / Apex.OS AGL delegiert OTA an herstellerspezifische Mechanismen. Apex.OS liefert keinen Flotten-OTA-Pfad. MOS4 mos-update: Ed25519-signierte Delta-Pakete, A/B-Partitionen, automatischer Rollback per Bootcount. Kohorten- und Canary-OTA über den Munic-Cloud-Companion.
Hardware-Bandbreite AGL / Apex.OS OEM-Referenzplattformen — typischerweise compute-Klasse oder KI-Klasse-SoCs. MOS4 Modem-Klasse (28,4 MB stationäres RSS, 1,6 s First-App-Ready) über compute-Klasse und KI-Klasse. Derselbe bundle.toml-Workflow über die gesamte Leiter.
ROS2-Hosting AGL / Apex.OS Apex.OS ist eine gehärtete ROS2-Distribution für ASIL-B+-Programme. MOS4 mos-ros2 hostet rclcpp/rclpy-Knoten unverändert in einem MCM-Container. Eine Bridge leitet DDS-Topics als typisierte EventBus-Ereignisse weiter. Sprechen Sie mit dem Engineering zur AGV-/Robotik-Qualifizierung.

Quelle — AGL von automotivelinux.org ; Apex.OS von apex.ai; MOS4 von /de/architecture.

Was MOS4 hinzufügt

Plattform-Breite für Tier-2- und Flottenprogramme.

Sechs Produktionsszenarien, eine Codebase.

Dieselbe MOS4-Plattform unterstützt IoT-Gateway-, Landwirtschafts- (137 Features), Dashcam-, OBD-Dongle-, C4Max- und Ekko-Drive-Deployments ohne Code-Forks pro Szenario. AGL und Apex.OS sind auf OEM-Head-Unit- und Autonomie-Programme ausgerichtet; MOS4 deckt den Flotten-Telematik-, Off-Highway- und Aftermarket-Bereich ab.

Observability als Framework-Eigenschaft.

Jede MOS4-Komponente emittiert Response-Time-Histogramme, Error-Counter und Lifecycle-Ereignisse automatisch über ObservabilityRegistry. OpenTelemetry-OTLP-Export und W3C-Trace-Context-Propagation sind im Framework enthalten, nicht pro Service hinzugefügt.

Sicherheits-Geltungsbereich — ehrlich angegeben.

MOS4 ist heute nicht ASIL-zertifiziert. Programme, die ASIL-B+-zertifizierte ROS2-Knoten benötigen, behalten Apex.OS für diesen Geltungsbereich; MOS4 deckt die umgebenden Flotten-, OTA- und Fahrzeugprotokoll-Schichten ab. Sicherheitsabstimmung pro Programm — sprechen Sie mit dem Engineering.

FAQ

Die Fragen, die wir am häufigsten hören.

  • Gehört MOS4 zur selben Problemklasse wie AGL?

    Ja — dieselbe Software-defined-Vehicle-Klasse. AGL zielt auf OEM-IVI-Programme über ein Konsortiumsmodell. MOS4 wird als Standardprodukt für die Tier-2-Flotten- und Off-Highway-Zielgruppe ausgeliefert, sodass kleinere Programme es ohne Multi-OEM-Arbeitsgruppe übernehmen können.

  • Wie vergleicht sich MOS4 mit Apex.OS für Autonomie-Anwendungen?

    Apex.OS ist eine gehärtete ROS2-Distribution. MOS4 hostet bestehende ROS2-Knoten in seinem Supervisor — keine Änderung am rclcpp/rclpy-Code — und fügt Fahrzeugprotokolle, Flotten-OTA und Observability darum hinzu. Programme, die zertifiziertes ROS2 benötigen, behalten Apex.OS für diesen Geltungsbereich; MOS4 deckt die Flotten- und Fahrzeugprotokoll-Schichten ab.

  • Kann MOS4 neben einem AGL- oder Apex.OS-Stack laufen?

    Das Koexistenzmodell steht für Engineering-Diskussionen zur Verfügung. Es gibt kein veröffentlichtes Referenz-Deployment von MOS4 neben AGL. Sprechen Sie mit dem Engineering, um die Topologie für Ihr Programm zu bewerten.

  • Was ist mit konsortiums-exklusiver Software?

    MOS4 erfordert keine Konsortiumsmitgliedschaft. Das Produkt, das SDK und die 63-Proto-Schnittstellenbibliothek sind für jeden Kunden unter einer Standard-Evaluierung zugänglich.

  • Ist MOS4 SDV-Klasse?

    Ja — dieselbe Software-defined-Vehicle-Problemklasse. Der Unterschied ist der Adoptionspfad: Evaluierung unter einer Standardlizenz mit einem direkten Engineering-Gespräch, kein Konsortiumsprogramm.

  • Wie sieht die Hardware-Bandbreite aus?

    MOS4 läuft von Linux-fähigen Anwendungsprozessoren der modem-Klasse (~28 MB stationäres RSS, 1,6 s First-App-Ready) über compute-Klasse und KI-Klasse-Hardware. Derselbe bundle.toml + cargo distro generate Workflow erzeugt Binaries für jede Stufe.

Dieselbe SDV-Klasse, Standardprodukt-Pfad.

Ein 30-minütiges Gespräch mit dem Engineering. Wir passen die MOS4-Hardware-Leiter an Ihr Programm an.

Bauen Sie auf MOS4?

Eine Antwort vom Engineering-Team, ~24 h. Kein Deck, kein NDA.

Mit Engineering sprechen