Comparativa

MOS4 vs AGL & Apex.OS

AGL y Apex.OS son runtimes clase SDV construidos alrededor de programas de consorcio y partners. MOS4 cubre la misma clase de problema como producto estándar — evaluación con una conversación directa con ingeniería, sin filtro de grupo de trabajo.

Puerta cerrada de consorcio AGL/Apex con una llave en la cerradura; una ruta abierta de producto estándar MOS4 al lado con una flecha ámbar que la atraviesa

Ruta de adopción

Programa de consorcio frente a producto estándar.

La ruta de consorcio requiere membresía o un acuerdo de partner, una plataforma de referencia y un programa de producción. La ruta de producto estándar ejecuta una evaluación bajo licencia, despliega un dispositivo piloto y se despliega sobre la escalera de hardware MOS4.

flowchart LR
  subgraph Cons["Ruta consorcio / partner"]
    O1[Membresía o acuerdo de partner] --> O2[Plataforma de referencia] --> O3[Programa de producción]
  end
  subgraph T2["Ruta de producto estándar"]
    T1[Evaluación bajo licencia] --> T2x[Dispositivo piloto] --> T3[Despliegue sobre la escalera de hardware]
  end

Cara a cara

Comparación de capacidades.

Audiencia objetivo AGL / Apex.OS Consorcios OEM, programas IVI Tier-1, ecosistema de partners Apex.OS. MOS4 Proveedores Tier-2, operadores de flota, fabricantes de máquinas agrícolas y off-highway.
Modelo de adopción AGL / Apex.OS Se requiere membresía en el consorcio AGL o un acuerdo de partner con Apex.OS para acceder a la pila completa. MOS4 Evaluación de producto estándar bajo licencia directa. Sin filtro de consorcio.
Contratos de servicio AGL / Apex.OS AGL: descriptores de servicio D-Bus + protobuf. Apex.OS: interfaces de ciclo de vida ROS2 en C++. MOS4 89 archivos .proto en mos-interfaces definen cada frontera de servicio, verificados con buf lint y cargo build en CI.
Autoría de componente AGL / Apex.OS AGL: descriptor de servicio D-Bus + boilerplate por servicio. Apex.OS: implementación del ciclo de vida de nodo ROS2. MOS4 Declare interfaces en proto, anote una struct Rust con #[component], implemente el trait generado. Un micro service mínimo cabe en menos de 30 líneas de Rust.
Protocolos vehiculares AGL / Apex.OS AGL apunta a pilas IVI OEM (principalmente SDV sobre Ethernet). Apex.OS no suministra pilas de protocolo OBD. MOS4 obdstacks-v2: 16 protocolos (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, KWP, J1850, GMLAN, CANopen, Modbus) vía archivos JSON declarativos de pila, cargables en caliente en tiempo de ejecución.
OTA de flota AGL / Apex.OS AGL delega la OTA a mecanismos específicos del proveedor. Apex.OS no suministra una ruta OTA de flota. MOS4 mos-update: paquetes delta firmados con Ed25519, particiones A/B, rollback automático vía bootcount. OTA por cohorte y canario vía el complemento cloud de Munic.
Rango de hardware AGL / Apex.OS Plataformas de referencia OEM — normalmente SoCs clase compute o clase IA. MOS4 Clase módem (28,4 MB de RSS estacionario, 1,6 s hasta primera aplicación lista) hasta clase compute y clase IA. Mismo flujo bundle.toml a lo largo de la escalera.
Alojamiento de ROS2 AGL / Apex.OS Apex.OS es una distribución ROS2 endurecida para programas ASIL-B+. MOS4 mos-ros2 aloja nodos rclcpp/rclpy sin modificar dentro de un contenedor MCM. El puente reenvía topics DDS como eventos EventBus tipados. Hable con ingeniería para la cualificación AGV/robótica.

Fuente — AGL desde automotivelinux.org ; Apex.OS desde apex.ai; MOS4 desde /es/architecture.

Lo que MOS4 añade

Amplitud de plataforma para programas Tier-2 y de flota.

Seis escenarios de producción, una sola base de código.

La misma plataforma MOS4 soporta los despliegues de pasarela IoT, agricultura (137 características), dashcam, dongle OBD, C4Max y Ekko Drive sin forks de código por escenario. AGL y Apex.OS están orientados a programas OEM de head-unit y autonomía; MOS4 cubre el espacio de telemática de flota, off-highway y aftermarket.

Observabilidad como propiedad del framework.

Cada componente MOS4 emite histogramas de tiempo de respuesta, contadores de error y eventos de ciclo de vida automáticamente vía ObservabilityRegistry. La exportación OTLP de OpenTelemetry y la propagación de W3C Trace Context están incluidas en el framework, no añadidas por servicio.

Alcance de seguridad — declarado con honestidad.

MOS4 no está certificado ASIL hoy. Los programas que necesitan nodos ROS2 certificados ASIL-B+ conservan Apex.OS para ese alcance; MOS4 cubre las capas circundantes de flota, OTA y protocolo vehicular. Alineación de seguridad por programa — hable con ingeniería.

FAQ

Las preguntas que más oímos.

  • ¿Está MOS4 en la misma clase de problema que AGL?

    Sí — la misma clase software-defined-vehicle. AGL apunta a programas IVI OEM a través de un modelo de consorcio. MOS4 se entrega como producto estándar para la audiencia de flota Tier-2 y off-highway, de modo que programas más pequeños pueden adoptarlo sin un grupo de trabajo multi-OEM.

  • ¿Cómo se compara MOS4 con Apex.OS para aplicaciones de autonomía?

    Apex.OS es una distribución ROS2 endurecida. MOS4 aloja nodos ROS2 existentes dentro de su supervisor — sin modificación del código rclcpp/rclpy — y añade protocolos vehiculares, OTA de flota y observabilidad alrededor. Los programas que necesitan ROS2 certificado conservan Apex.OS para ese alcance; MOS4 cubre la flota y las capas de protocolo vehicular.

  • ¿Puede MOS4 ejecutarse junto a una pila AGL o Apex.OS?

    El modelo de coexistencia está disponible para discusión con ingeniería. No hay un despliegue de referencia publicado de MOS4 junto a AGL. Hable con ingeniería para evaluar la topología de su programa.

  • ¿Y el software solo de consorcio?

    MOS4 no requiere membresía de consorcio. El producto, el SDK y la biblioteca de 63 interfaces .proto son accesibles para cualquier cliente bajo una evaluación estándar.

  • ¿Es MOS4 clase SDV?

    Sí — la misma clase de problema software-defined-vehicle. La diferencia es la ruta de adopción: evaluación bajo una licencia estándar con una conversación directa con ingeniería, no un programa de consorcio.

  • ¿Cuál es el rango de hardware?

    MOS4 corre desde procesadores de aplicación clase módem capaces de Linux (~28 MB de RSS estacionario, 1,6 s hasta primera aplicación lista) hasta hardware clase compute y clase IA. El mismo flujo bundle.toml + cargo distro generate produce binarios para cada nivel.

La misma clase SDV, ruta de producto estándar.

Una llamada de 30 minutos con ingeniería. Emparejaremos la escalera de hardware MOS4 con su programa.

¿Construyendo sobre MOS4?

Una respuesta del equipo de ingeniería, ~24 h. Sin presentación, sin NDA.

Hablar con ingeniería