Referencia
Glosario
Definiciones cortas para el vocabulario MOS4. Cada entrada enlaza a la página canónica que la explica en profundidad.
- Micro service
- La unidad de despliegue en MOS4. Un crate Rust autocontenido anotado con #[component], que declara las interfaces protobuf que proporciona y requiere, con un esquema de configuración (mos.toml) y su propia pipeline de CI. Cada repo supervisado del ecosistema MOS4 es un micro service.
- En este sitio, los micro services también se denominan componentes dentro de un sistema operativo distribuido basado en componentes. 52 micro services se entregan en el catálogo de producción.
- Micro services → Catálogo →
- MCM
- MOS Container Manager — el motor ligero de contenedores OCI que ejecuta código del cliente junto a los micro services. El runtime de producción es crun con cgroups v2 para el control de recursos. Cuatro perfiles de montaje: SHELL, PYTHON, NATIVE, STATIC.
- Sustitución a nivel de sistema: una actualización de CPython 3.12 se propaga a todos los contenedores Python del cliente mediante un único bump de digest en system-layers.toml. Envolvente de presupuesto por contenedor: menos del 5 % de CPU/RAM y ~10 MB de RSS.
- SDK → Micro services →
- MSP
- Morpheus Signal Processing — un motor de procesado de señal en tiempo real basado en grafos para telemetría de vehículo. Los nodos se cablean mediante aristas en archivos .msp.yml; 226 grafos a través de 21 dominios de vehículo se entregan de fábrica.
- Los grafos se ejecutan sobre un runtime asíncrono Tokio enfocado a hardware de clase módem. Añadir un nuevo dominio de vehículo solo requiere un archivo YAML — sin recompilar Rust. 124 kernels en el editor visual.
- Motores no-code → Automoción →
- MEP
- MOS Event Processor — un motor Trigger → Condition → Action configurado en YAML. Los disparadores son cambios de clave en la base de datos, eventos con nombre del EventBus o programaciones cron (UTC). Las condiciones se evalúan antes de que se dispare la acción.
- Las acciones pueden invocar cualquier micro service de MOS4 (escribir clave, emitir evento, hacer una llamada de servicio). Recarga en caliente: las nuevas políticas se validan y se intercambian con drenaje de reglas en vuelo — no se requiere reinicio de proceso. Pool paralelo de workers de reglas con detección de conflictos. Lectura producto: desde el punto de vista del responsable de producto, MEP ejecuta políticas de máquina de estados en el dispositivo. La máquina de estados *es* el YAML de política — no hay un runtime separado de máquina de estados. La primitiva T·C·A es la vista de ingeniería del mismo artefacto.
- Motores no-code → Página de MEP →
- EventBus
- El canal interno de distribución de eventos con nombre de MOS4. Los componentes publican eventos por nombre; los disparadores de MEP y el reenvío de tópicos DDS de mos-ros2 consumen del EventBus. Se escribe como una sola palabra con E mayúscula y B mayúscula.
- No es una cola de mensajes — los eventos son efímeros y con nombre. Sin retención, sin replay.
- Motores no-code → Micro services →
- Multi Stacks
- El motor canónico no-code de comunicación para vehículos e IoT industrial. Cubre CAN, CAN-FD, ISO-TP, DoIP, K-Line, UDS, J1939, J1587/J1708, J1850 VPW/PWM, ISOBUS, Modbus RTU/TCP y CANopen — el mismo motor, el mismo DSL JSON, el mismo catálogo de stacks por defecto.
- Modelo declarativo — cuatro puntos: (1) Protocolo — qué transporte y entramado (CAN, J1939, UDS, ISOBUS, Modbus, …). (2) Pregunta + Respuesta — qué comando/PID/PGN/registro enviar y cómo descodificar la respuesta. (3) Difusión — manejo de mensajes de solo lectura y no solicitados (escucha pasiva, descodificación al estilo evento sin petición). (4) Estrategia — qué secuencias ejecutar y cuándo; periódica de fábrica, avanzada vía composición con MSP (disparadores guiados por señal) o MEP (secuencias guiadas por evento). 22 stacks por defecto listos para producción validados en cada push de CI.
- Página de Multi Stacks → Automoción →
- AI pipeline
- El pipeline de IA en el dispositivo usa mos-roi-shader y mos-ai-runtime. Los clientes declaran un modelo ONNX/TFLite y configuran el pipeline en TOML. mos-roi-shader extrae regiones de interés a través de la GPU (wgpu/Vulkan) y produce dmabufs de tensores listos para la NPU. mos-ai-runtime conduce la inferencia en la NPU. Ningún byte de píxel cruza la CPU en la ruta de inferencia — el invariante de dma-buf se mantiene de extremo a extremo.
- La conversión automática ONNX a TFLite está disponible. Se configura en TOML; se despliega por OTA. El silicio clase IA alcanza hasta ~100 TOPS (familia QCS).
- Página de AI Funnel → Vision →
- ROI Shader
- Un proceso GPU (wgpu/Vulkan) que extrae regiones de interés de las tramas de cámara y produce dmabufs de tensores listos para la NPU. Importa tramas dmabuf desde mos-camera-capture, exporta tópicos de tensores consumidos por mos-ai-runtime.
- Ningún dato de píxel cruza la CPU: la CPU dirige el buffer de comandos de la GPU, no el pipeline de píxeles. En la variante clase IA MIPI-CSI: ROI Vulkan portable. En la variante clase IA con puente serializador: dmabuf-a-NPU cero-copia a través de memoria GPU compartida.
- Vision → AI Funnel →
- MD21
- Protocolo de telemetría patentado por Munic. Protocolo binario codificado en ASN.1 UPER sobre TCP/TLS para comunicación bidireccional dispositivo-servidor en IoT. Usado por mos-communication-gateway y mos-update (como canal de comandos OTA).
- Más eficiente en ancho de banda que los protocolos alternativos para telemetría densa sobre enlaces celulares con cuota — gracias a multiplexación, piggyback, compresión y codificación basada en ASN.1.
- Conectividad → Catálogo →
- clase módem
- Nivel más bajo de la escalera de silicio MOS4 — típicamente un SoC monocore con módem celular. Ejecuta MOS4 con un único grafo de procesado de señal con 28,4 MB de RSS en régimen permanente y 1,6 s hasta primera app lista.
- Mínimo: procesador de aplicación monocore, ~800 MHz, 256 MB de RAM.
- Niveles de hardware → munic.io →
- clase compute
- Nivel medio de la escalera de silicio MOS4 — añade captura multi-cámara, el motor de políticas de máquina de estados MEP (T·C·A por debajo) y el motor de comunicación Multi Stacks de 16 protocolos por encima de la base clase módem.
- Un solo OS — sin rama por nivel. Munic porta; el OEM elige el nivel por producto.
- Niveles de hardware → Multi Stacks →
- clase IA
- Nivel superior de la escalera de silicio MOS4 — añade inferencia NPU, ROI shader (Vulkan) y el pipeline completo de IA en el dispositivo. Cifra de referencia: hasta ~100 TOPS en el nivel clase IA.
- Variante MIPI-CSI: inferencia NPU TFLite vía delegado del proveedor de silicio. Variante con puente serializador: dmabuf-a-NPU cero-copia a través de memoria GPU compartida.
- Niveles de hardware → AI Funnel →
- start_level
- Prioridad de registro — un valor numérico de 0 a 10 que determina el orden en que los micro services son iniciados por el supervisor MOS4. Valores más bajos arrancan antes. No confundir con las capas L0–L7 del diagrama de arquitectura, que son un modelo mental para la estructura de la plataforma.
- L0–L7 es la convención del diagrama de arquitectura (hardware en L0, aplicación en L7). start_level 0–10 es el campo de ordenamiento del registro en runtime. Son dos conceptos separados.
- Arquitectura → Micro services →
- CRA-listo
- Conformidad alineada con el Reglamento Europeo de Ciberresiliencia (aplicable desde 2027). MOS4 entrega mapeo CRA artículo por artículo (Anexo I §1, §2, Art. 13, Art. 14), SBOM CycloneDX, cargo audit / geiger / deny, semgrep y un proceso PSIRT público en cada versión.
- UNECE R155/R156: autoalineado. Evaluación formal por programa. El OEM solo documenta su capa de aplicación.
- Conformidad → Para postura de cumplimiento →
- SBOM (CycloneDX)
- Software Bill of Materials en formato CycloneDX — un inventario legible por máquina de cada dependencia en una versión. Requerido por la CRA de la UE y entregado con cada versión de MOS4. Descargable desde el portal del cliente.
- Generado por cargo cyclonedx en cada commit a través de los 52 micro services. El control de CVEs vía cargo audit es bloqueante; la publicación de SBOM es informativa.
- Conformidad → Whitepapers →
- proto interface
- Un archivo .proto que define el contrato tipado de llamada de servicio entre micro services. El repo mos-interfaces alberga 89 archivos .proto que cubren servicios a través de los dominios de conectividad, posicionamiento, visión, energía y datos.
- Cada micro service importa desde este único registro compartido. Sin negociación de formato de cable por repo. mos-codegen genera stubs tipados para cada SDK de lenguaje a partir de estos archivos .proto.
- Arquitectura → Micro services →
- Autonomía en recinto privado
- Operación de vehículo autónomo en recintos controlados — granja, aeródromo, mina, cantera, terminal portuaria, campo de golf, recinto industrial. Excluye la operación en vía pública por diseño. MOS4 da soporte al runtime, los nodos ROS2 hospedados, el bus de máquina, el silicio de percepción, la telemetría y los cuidados remotos; el cliente entrega la aplicación de autonomía.
- Sin homologación NHTSA. Sin dependencia de mapa HD. Sin pila de autonomía L4 proporcionada. El OEM es dueño de la percepción, planificación, control y del caso de seguridad para la máquina integrada.
- Vehículos autónomos → AI Vision →
- AI Cam (caja OEM)
- Caja de cámara de óptica única e instalación fija con inferencia de IA en el dispositivo, marca del OEM, ejecutándose sobre la plataforma MOS4. Usada para inspección industrial, perímetro, antirrobo en retail y visión del operador en maquinaria pesada. Distinto de una dashcam, que es interior al vehículo y de doble óptica.
- Cámaras de IA → AI Vision →
- Dashcam (OEM)
- Cámara interior al vehículo de doble óptica con ADAS, DMS y anonimización en directo conforme al RGPD sobre el runtime MOS4. Una de las tres formas de despliegue del stack de video MOS4 — junto con la caja de cámara OEM y la red multi-cámara de flota.
- Cámaras de IA → AI Vision →
- Remote Care
- Capacidad incorporada del SO MOS4 que cubre la reconfiguración en caliente y la remediación remota firmada. Cableada en cada dispositivo. Material para cualquier programa en el que una inmovilización cueste más que el propio dispositivo.
- Dos niveles de remediación: reconfigurar remotamente (recarga en caliente de MSP / MEP / geocercas, alrededor de diez segundos de extremo a extremo) y remediar remotamente (OTA A/B firmada, reinicio remoto, reflasheo remoto). Cada acción se firma, controla y registra en auditoría. Para sesiones interactivas de ECU — leer, resetear, empujar calibraciones, atestar y reflashee — ver Remote Diagnostic. Distinto de ekkofleet, el SaaS de flota llave en mano que usa MOS4 como plataforma.
- Página de Remote Care → Página de Remote Diagnostic → Capa de operaciones →
- Remote Diagnostic
- Sesión de diagnóstico interactiva dirigida desde la nube sobre el mismo motor que mueve la telemetría autónoma. La nube abre una sesión, pilota el bus del vehículo, lee el estado de las ECU, resetea DTCs, empuja calibraciones, atesta y reflashee firmware, y luego cierra.
- El modo de operación importa: Multi Stacks es autónomo (el dispositivo decide qué preguntar, la nube recibe), Remote Diagnostic es interactivo (la nube decide, el dispositivo actúa). Mismos protocolos (UDS, J1939, ISOBUS, Modbus, J2534-passthru), mismo bus físico. Los enclavamientos de seguridad no se pueden anular desde la superficie de Remote Diagnostic; el reflasheo está firmado y atestado; la reversión basada en bootcount restaura el firmware previo en caso de reflasheo fallido. Cada acción que cambia estado lleva una autorización firmada por acción y una entrada de log de auditoría.
- Página de Remote Diagnostic → Multi Stacks (contraparte autónoma) →
- Subida de telemetría
- La ruta de datos dispositivo-a-nube asegurada por MD21. Firmada, atestada y compartida a través de cada producto MOS4. Sustenta Remote Care y cualquier capa de SaaS de flota que se asiente sobre MOS4.
- MD21 está patentado por Munic; frente a MQTT5 / SOTA, se entrega con menor consumo de datos y mayores garantías de atestación. El puente traduce eventos del EventBus desde y hacia MQTT para los clientes cuyo back end ya está orientado a MQTT.
- Conectividad → Remote Care →
- OBD-II
- On-Board Diagnostics II (SAE J1979) — la interfaz de diagnóstico estandarizada y obligatoria en turismos vendidos en Norteamérica desde 1996 y en la UE desde 2001. Define un conector DLC de 16 pines, un conjunto de PIDs estándar (identificadores de parámetro) y los cinco protocolos de transporte (ISO 9141-2, SAE J1850 VPW/PWM, CAN ISO 15765-4, KWP2000).
- Multi Stacks → Prueba →
- UDS
- Unified Diagnostic Services (ISO 14229) — el estándar internacional para sesiones de diagnóstico a nivel de ECU. Define servicios para leer/escribir registros de datos, resetear ECUs, ejecutar rutinas y flashear firmware. Usado por MOS4 Remote Diagnostic y Multi Stacks.
- Multi Stacks → Remote Diagnostic →
- J1939
- SAE J1939 — el protocolo de red para vehículos de servicio pesado construido sobre CAN. Usa Parameter Group Numbers (PGNs) y Suspect Parameter Numbers (SPNs) para direccionar ECUs de motor, transmisión y eje en camiones, autobuses y maquinaria off-highway.
- Multi Stacks → Automoción →
- PGN
- Parameter Group Number — la unidad de direccionamiento J1939 que identifica un grupo de datos relacionados (p. ej. velocidad del motor, temperatura del refrigerante). Cada PGN mapea a uno o más SPNs.
- Multi Stacks →
- SPN
- Suspect Parameter Number — el identificador de señal individual dentro de un PGN J1939 (p. ej. SPN 190 = velocidad del motor en RPM). Multi Stacks decodifica SPNs a través del stack JSON declarativo.
- Multi Stacks →
- ISOBUS
- ISO 11783 — el protocolo de red para maquinaria agrícola construido sobre CAN. Usado para comunicación implemento-tractor (sembradoras, pulverizadoras, cosechadoras). MOS4 lee datos ISOBUS en modo solo lectura a través de Multi Stacks.
- Multi Stacks → Automoción →
- J2534
- SAE J2534 PassThru — la API estándar que permite a una aplicación PC comunicarse con las ECUs del vehículo a través de un dispositivo pass-through conectado al bus del vehículo. MOS4 Remote Diagnostic implementa el modo J2534-passthru para flasheo y calibración de ECUs dirigidos desde la nube.
- Remote Diagnostic →
- DTC
- Diagnostic Trouble Code — un código de cinco caracteres (p. ej. P0300) almacenado en una ECU cuando se detecta un fallo. MOS4 lee, registra y puede resetear remotamente DTCs a través de los stacks UDS y OBD-II.
- Multi Stacks → Remote Diagnostic →
- ECU
- Electronic Control Unit — un controlador embebido que gestiona un sistema específico del vehículo (motor, transmisión, frenos, carrocería). MOS4 se comunica con ECUs sobre CAN/UDS/J1939 y puede reflashearlas remotamente mediante OTA firmado.
- Multi Stacks → Remote Diagnostic →
- SAE J1850
- SAE J1850 — un protocolo de transporte OBD-II heredado (VPW a 10,4 kbps, PWM a 41,6 kbps) usado en vehículos norteamericanos antes de que CAN fuera obligatorio. Soportado en Multi Stacks para la cobertura de vehículos más antiguos.
- Multi Stacks →
- PID
- Parameter Identifier — el equivalente OBD-II de una dirección de datos. Los PIDs Modo 01 reportan valores de sensores en directo (p. ej. PID 0C = RPM del motor). Los stacks declarativos de Multi Stacks referencian PIDs por número y los decodifican en señales nombradas.
- Multi Stacks →
- MQTT
- Message Queuing Telemetry Transport — un protocolo ligero de publicación/suscripción ampliamente usado en IoT. MOS4 incluye un bróker MQTT en proceso para que los servicios del cliente puedan publicar y suscribirse sin un bróker externo. La subida de telemetría usa MD21, no MQTT, para el transporte dispositivo-a-nube.
- Conectividad →
- eUICC
- Embedded Universal Integrated Circuit Card — una SIM soldada y reprogramable remotamente que permite el cambio de perfil por aire sin un cambio físico de SIM. Cubierto por dos estándares GSMA: SGP.22 (Consumer) para dispositivos con interacción de usuario final, y SGP.02 (M2M) para despliegues de flota y embebidos gestionados por el operador.
- Conectividad → Niveles de hardware →
- GSMA SGP.22
- El estándar GSMA de gestión de perfiles eUICC Consumer — rige el aprovisionamiento remoto de SIM para dispositivos de consumo donde el usuario final controla la selección del perfil. También llamado eUICC Consumer.
- Conectividad →
- GSMA SGP.02
- El estándar GSMA de gestión de perfiles eUICC M2M — rige el aprovisionamiento remoto de SIM para despliegues máquina a máquina y de flota gestionados por un operador o empresa. También llamado eUICC M2M.
- Conectividad →
- LPWA
- Low-Power Wide-Area network — una clase de tecnologías inalámbricas (NB-IoT, LTE-M, LoRaWAN) diseñadas para dispositivos IoT alimentados por batería que envían pequeños payloads de forma poco frecuente a grandes distancias. Los micro services de conectividad MOS4 soportan módems LPWA junto al celular estándar.
- Conectividad →
- GNSS
- Global Navigation Satellite System — la familia de sistemas de posicionamiento por satélite (GPS, GLONASS, Galileo, BeiDou). MOS4 incluye micro services GNSS dedicados para posición, velocidad, rumbo y tiempo.
- Niveles de hardware → Prueba →
- ESF
- External Sensor Fusion — una característica del receptor GNSS que fusiona medidas de satélite con datos de un sensor inercial (acelerómetro, giroscopio) para mantener la precisión de posición durante las interrupciones de satélite (túneles, cañones urbanos). MOS4 expone datos ESF a través de los micro services GNSS.
- Niveles de hardware →
- RTK
- Real-Time Kinematic GNSS — una técnica de corrección diferencial que logra precisión centimétrica al comparar medidas de fase de portadora con una estación de referencia. Usado en despliegues MOS4 para agricultura de precisión y planificación de trayectorias en vehículos autónomos.
- Vehículos autónomos → Niveles de hardware →
- ELD
- Electronic Logging Device (FMCSA 49 CFR Part 395) — un dispositivo de mandato federal en EE. UU. que registra las horas de servicio del conductor leyendo datos del motor desde la ECU del vehículo. MOS4 incluye un micro service conforme a ELD que gestiona el registro de horas de servicio sobre J1939/OBD-II.
- Multi Stacks → Automoción →
- OTA
- Actualización de firmware por aire — la capacidad de entregar actualizaciones de software firmadas a un dispositivo sin acceso físico. MOS4 entrega un sistema OTA A/B firmado con reversión basada en bootcount y reflasheo remoto, cubierto bajo Remote Care.
- Remote Care → Capa de operaciones →
- LCV
- Light Commercial Vehicle — el segmento que cubre furgonetas, pick-ups y camiones pequeños (típicamente por debajo de 3,5 t de MMA). Un segmento de mercado principal para los despliegues de telemática MOS4.
- Automoción →
- CRA
- Reglamento Europeo de Ciberresiliencia — regulación horizontal de la UE que aplica requisitos obligatorios de ciberseguridad a productos con elementos digitales, vigente desde 2027. MOS4 entrega un SBOM alineado con CRA, la cadena de utillaje cargo audit/geiger/deny, análisis estático con semgrep y un proceso PSIRT público.
- Conformidad → CRA-listo →
- SBOM
- Software Bill of Materials — un inventario legible por máquina de cada dependencia de software en una versión. MOS4 genera un SBOM CycloneDX en cada commit a través de todos los micro services. Requerido por la CRA de la UE; descargable desde el portal del cliente.
- Conformidad → SBOM (CycloneDX) →
- CycloneDX
- Un estándar abierto de SBOM (OWASP) que define un formato XML/JSON legible por máquina para inventarios de componentes de software. MOS4 usa cargo cyclonedx para generar SBOMs CycloneDX en cada versión.
- Conformidad → SBOM (CycloneDX) →
- PSIRT
- Product Security Incident Response Team — la función organizacional que recibe, prioriza y divulga públicamente vulnerabilidades de seguridad. MOS4 opera un proceso PSIRT público como parte de su postura de seguridad alineada con CRA.
- Conformidad →
- SAST
- Static Application Security Testing — análisis automatizado del código fuente en busca de vulnerabilidades de seguridad sin ejecutar el programa. La CI de MOS4 ejecuta reglas SAST de semgrep en cada commit, con violaciones que bloquean el merge.
- Conformidad →
- NPU
- Neural Processing Unit — un bloque de silicio dedicado optimizado para las operaciones matriciales usadas en inferencia de redes neuronales. El hardware clase IA de MOS4 expone la NPU al micro service mos-ai-runtime a través de una ruta dmabuf cero-copia desde el shader ROI en GPU.
- AI Funnel → Niveles de hardware →
- TOPS
- Tera Operations Per Second — la unidad usada para calificar el rendimiento de inferencia de NPU. El hardware clase IA en MOS4 alcanza hasta aproximadamente 100 TOPS en el nivel superior.
- Niveles de hardware → AI Funnel →
- ADAS
- Advanced Driver-Assistance Systems — la clase de funciones de seguridad interior al vehículo (alerta de cambio de carril, alerta de colisión frontal, detección de ángulo muerto) entregadas mediante inferencia de visión en el dispositivo. MOS4 soporta el despliegue de modelos ADAS a través del pipeline de IA en el dispositivo.
- AI Vision → Cámaras de IA →
- DMS
- Driver Monitoring System — un sistema de seguridad basado en visión que detecta distracción, fatiga o ausencia del conductor. Desplegado como modelo ONNX/TFLite sobre hardware clase IA de MOS4 a través del pipeline de IA en el dispositivo.
- AI Vision → Cámaras de IA →
- GMSL2
- Gigabit Multimedia Serial Link 2 — un estándar de interfaz de cámara serializador/deserializador capaz de transportar video de alta resolución sobre un único cable coaxial o de par trenzado apantallado. Usado en hardware clase IA de MOS4 para instalaciones multi-cámara de flota.
- AI Vision → Niveles de hardware →
- MIPI-CSI
- MIPI Camera Serial Interface — la interfaz estándar de cámara de corto alcance usada en SoCs embebidos. MOS4 soporta captura de cámara MIPI-CSI en hardware clase IA, alimentando tramas al shader ROI en GPU y al pipeline de inferencia NPU.
- AI Vision → Niveles de hardware →
- RAG
- Retrieval-Augmented Generation — una arquitectura de IA que aumenta un modelo de lenguaje con un paso de recuperación sobre un corpus de documentos, de modo que las respuestas se asientan en contenido recuperado específico en lugar de solo en los pesos del modelo. Usado en interfaces conversacionales de MOS4 en el dispositivo.
- AI Funnel →
- STT
- Speech-To-Text — la conversión de audio hablado a una transcripción de texto. MOS4 ejecuta modelos STT en el dispositivo a través del runtime de IA para interfaces de comandos por voz e interacción con el conductor.
- AI Funnel →
- TTS
- Text-To-Speech — la conversión de texto a audio de voz sintetizada. Usado en interfaces conversacionales de MOS4 en el dispositivo para la retroalimentación hablada al operador.
- AI Funnel →
- WER
- Word Error Rate — la métrica estándar para evaluar la precisión del reconocimiento de voz, calculada como (sustituciones + inserciones + supresiones) / cuenta de palabras de referencia. Menor es mejor.
- AI Funnel →
- ROS2
- Robot Operating System 2 — un framework de middleware de robótica de código abierto que proporciona comunicación publicación/suscripción, abstracción de hardware y utillaje para sistemas autónomos. MOS4 hospeda nodos ROS2 a través de mos-ros2, puenteando tópicos DDS al EventBus de MOS4.
- Vehículos autónomos →
- SDLC
- Software Development Life Cycle — el proceso estructurado que cubre requisitos, diseño, implementación, verificación y mantenimiento. La CI de MOS4 aplica controles de seguridad y calidad en cada etapa del SDLC a través de la plantilla compartida ci-gamma.
- Conformidad →
- JTBD
- Jobs To Be Done — un marco de pensamiento de producto que enmarca las necesidades del usuario como los "trabajos" que una persona intenta realizar en un contexto dado. Usado internamente en Munic para acotar funcionalidades de plataforma.
- MCP
- Model Context Protocol — un estándar abierto que permite a un asistente de codificación leer recursos tipados de un sistema. El conector MCP de MOS4 expone el catálogo de micro services, los contratos de interfaz, el esquema de configuración y los logs del dispositivo, de modo que cualquier cliente compatible con MCP puede consultarlos en tiempo de edición.
- Herramientas para desarrolladores →
- MES
- Manufacturing Execution System — el sistema de planta que rastrea y controla la producción. Las herramientas de desarrollador de MOS4 pueden modelar el handshake del MES para que un micro service se ejercite contra entradas de producción simuladas antes de ejecutarse en hardware.
- Herramientas para desarrolladores →
- HIL
- Hardware-in-the-loop — un método de prueba que ejecuta software contra hardware real de destino en lugar de una simulación, validando el rendimiento real. El paquete de desarrollador de MOS4 ofrece un rack hardware-in-the-loop con las variantes de dispositivo que envía, alojado en la nube de Munic o levantado on-premise.
- Herramientas para desarrolladores → AI Funnel →
- MLOps
- Machine-Learning Operations — la práctica y las herramientas para construir, rastrear, desplegar y monitorizar modelos de aprendizaje automático. La pipeline de evaluación de modelos de MOS4 vincula Kubeflow y MLflow para comprobar si un modelo se ajusta al presupuesto de latencia y memoria del dispositivo de destino.
- Herramientas para desarrolladores → AI Funnel →
- CD
- Entrega Continua (Continuous Delivery) — la práctica de publicar cada build validado mediante un despliegue controlado por fases. En MOS4, la entrega continua despliega una imagen firmada desde su CI a la flota en oleadas — primero un grupo canario, luego una expansión progresiva — con pausa y reversión en cualquier fase.
- Herramientas para desarrolladores → Operaciones →
Referencia de prioridad del registro
start_level 0–10: orden de arranque en el registro.
start_level es un campo de prioridad de registro, no una etiqueta de capa de arquitectura. El stack de arquitectura usa L0–L7 como modelo mental — son convenciones separadas.
| Rango de nivel | Rol | Ejemplos de micro services |
|---|---|---|
| 0–2 | Abstracción de hardware y BSP | módem, energía, sensores |
| 3–4 | Servicios de plataforma | OTA, configuración, observabilidad |
| 5–6 | Motores de dominio | Multi Stacks, MSP, MEP, runtime de IA |
| 7–8 | Capa de aplicación | micro services del cliente, contenedores |
| 9–10 | Servicios de enlace tardío | complementos opcionales |