Plataforma · Herramientas para desarrolladores
Desarrolle en MOS4 con una cadena de herramientas con IA.
Un paquete de desarrollador que recorre todo el camino — desde un dispositivo simulado en su portátil, pasando por la entrega continua a la flota, hasta el hardware-in-the-loop y la observabilidad en vivo sobre el terreno. Se integra con las herramientas de IA que su equipo ya usa. El paquete está disponible con ingeniería — úselo durante la evaluación y a lo largo del despliegue.
Conector MCP para MOS4
Su asistente de codificación, conectado al catálogo MOS4.
Un conector Model Context Protocol permite al asistente de codificación de su equipo (Claude Code, Cursor, Continue o cualquier cliente compatible con MCP) leer el catálogo MOS4, las interfaces de componentes, el esquema de configuración y los logs del dispositivo en vivo. El conector expone recursos tipados — el asistente sabe dónde está cableado un micro service, qué interfaz .proto provee, qué claves de configuración consume y qué superficies de log emite.
-
Autocompletado con conocimiento del catálogo.
El asistente conoce los micro services de producción, sus interfaces y su superficie de configuración.
-
Búsqueda tipada por interfaz.
«¿Dónde se publica Position?» devuelve el servicio productor, los servicios consumidores y el contrato.
-
Linting de configuración.
Los archivos de configuración se validan contra el esquema live antes del despliegue.
-
Lectura de logs en vivo.
El asistente lee los logs del dispositivo a través de la misma superficie de telemetría que usa la plataforma.
Planificación con conocimiento de la arquitectura
Responde preguntas de planificación sobre el grafo de proyecto.
Los proyectos multi-servicio implican grafos de dependencias, contratos de interfaz y ordenamiento del ciclo de vida. La cadena de herramientas lee el grafo de proyecto y responde preguntas de planificación — ¿de qué depende este micro service?, ¿qué se rompe si actualizo esta interfaz?, ¿qué test detectaría esta regresión?
-
Consultas de grafo de dependencias.
Bidireccional — «¿quién depende de X?» y «¿de qué depende X?».
-
Refactors con conocimiento de contratos.
Actualizar una interfaz muestra cada consumidor que necesita seguir el cambio.
-
Scaffolding orientado a tests.
Los tests generados apuntan a la brecha identificada por el asistente.
Depuración con conocimiento de sistemas embebidos
Logs de un dispositivo restringido, leídos como estructura.
Los logs de un dispositivo restringido no son lo que un asistente cloud está entrenado para entender. El paquete de desarrollador incluye lectores de logs que comprenden el supervisor, el pipeline OTA, el stack del módem, el bus del vehículo y el AI Funnel — de modo que una regla MEP que no se disparó aparece como una traza de máquina de estados, no como texto en bruto.
-
Trazas con conocimiento del supervisor.
El ciclo de vida del contenedor y la presión de recursos se leen como eventos, no como bytes.
-
Trazas con conocimiento de los stacks.
Las tramas J1939 / UDS / Modbus se decodifican a PGN / SID / dirección.
-
Trazas con conocimiento del AI Funnel.
Los caminos de visión e inferencia aparecen como una pipeline, no como logs.
La plataforma de desarrollo
Más allá del asistente — la cadena de herramientas que entrega el producto.
El asistente acelera cómo escribe un micro service. El resto del paquete lo lleva todo el camino: desarrolle contra un dispositivo simulado antes del silicio, entregue a la flota desde su CI, demuéstrelo en hardware real, compruebe que su modelo cabe en el dispositivo y observe cada servicio en un único panel. No toda superficie es de autoservicio — la conversación de ingeniería calibra cuáles están activas para su programa.
Desarrolle antes del hardware
Construya contra un dispositivo simulado, no una lista de espera.
No espera a las placas. MOS4 incluye runners off-target, así que su micro service se ejecuta en su portátil y en la integración continua (CI) — alimentado por entradas simuladas — antes de tocar el silicio. Modele el handshake del Sistema de Ejecución de Manufactura (MES), el bus del vehículo y el flujo de sensores, y reprodúzcalos de forma determinista.
-
Runners off-target.
Reproduzca políticas de eventos, ejecute grafos de señal sobre entradas grabadas y ejercite el runtime multi-stack sobre un bus de vehículo virtual — sin dispositivo conectado.
-
Modele las entradas, no solo el dispositivo.
Alimente su código con un intercambio MES simulado, tráfico de bus de vehículo guionizado y flujos de sensores. Componga el escenario; reprodúzcalo igual en cada ejecución.
-
Determinista por diseño.
Ejecuciones aisladas y repetibles en CI. Un fallo se reproduce en la máquina del siguiente ingeniero — no solo en el banco.
-
Un stub para el camino de IA.
El runtime de IA genera un stub de la inferencia para que una pipeline de AI Funnel se ejecute en CI sin un modelo cargado en un dispositivo.
-
Un bundle completo en su portátil.
Un comando levanta un bundle de micro services juntos — la misma topología que envía — de modo que desarrolla contra el cableado real, no contra un único proceso en aislamiento.
-
Un banco para cada bus.
Reproduzca tráfico J1939, CANopen, ISOBUS y Modbus contra su código, inyecte mensajes con plantilla y examine una línea de tiempo de frames capturados en el navegador — reproduzca un fallo de campo en el banco antes de que llegue a un cliente.
De CI a la flota
Entrega continua desde su pipeline hasta el campo.
Cada cambio en su CI construye una imagen firmada; la entrega continua (CD) la despliega a la flota por fases — primero un grupo canario, luego una oleada progresiva hasta la disponibilidad general, con pausa y reversión en cualquier paso. Un panel le da una sola vista de cada dispositivo, una interfaz de programación de aplicaciones REST (API REST) dirige las mismas acciones desde sus propias herramientas, y un motor de reglas enruta la telemetría sin código pegamento a medida. La superficie de control está construida sobre ThingsBoard, integrada en la plataforma.
-
Builds firmados, despliegues por fases.
Primero un grupo canario, luego oleadas progresivas a toda la flota. Pause o revierta en cualquier fase — nunca un despliegue de golpe.
-
Un panel, una API.
Observe la salud de la flota en un único panel y dirija el aprovisionamiento, la actualización y las consultas a través de una API REST documentada.
-
Reglas, no código pegamento.
Cadenas de reglas con arrastrar y soltar validan, transforman, enrutan y alarman sobre la telemetría del dispositivo — y pueden disparar una actualización.
-
Su CI, sin cambios.
Conserve su pipeline. La entrega se engancha en el artefacto: la imagen firmada que ya construye fluye a la flota.
Pruebe en silicio real
Pruebe en cada variante de hardware, en un rack alojado.
La simulación le lleva la mayor parte del camino; la última milla se ejecuta en dispositivos reales. El hardware-in-the-loop (HIL) pone un rack de las variantes de hardware que envía detrás de su pipeline — alojado en la nube de Munic, o levantado on-premise tras su firewall. Reparta su matriz de tests por el rack y ejecútela en cada placa a la vez, con logs, trazas y rendimiento capturados del silicio que ejecutó el test.
-
Cada variante que envía.
Targets modem-class, compute-class y AI-class en un solo rack — pruebe la matriz, no una sola placa.
-
Paralelo por defecto.
Reparta la suite por el rack y ejecútela en cada placa a la vez, en lugar de un target cada vez.
-
Cloud u on-premise.
Alojado en la nube de Munic, o levantado on-premise tras su firewall para programas restringidos.
-
Evidencia desde el metal.
Los logs, las trazas y las cifras de precisión / latencia provienen del dispositivo que ejecutó el test — no de una suposición.
Sepa que cabe antes de enviar
Descubra si su modelo se ejecuta en el dispositivo — antes de la integración.
Traiga su modelo entrenado. La pipeline de evaluación lo perfila contra el tier de destino y devuelve los números que deciden un programa: latencia de inferencia, huella de memoria y precisión tras la optimización on-device. El instrumental de operaciones de aprendizaje automático (MLOps) — Kubeflow para la pipeline, MLflow para el rastreo y el registro de modelos — está integrado en el proceso, de modo que cada ejecución es reproducible, versionada y auditable.
-
¿Funcionará? Obtenga el presupuesto.
La pipeline perfila su modelo contra el presupuesto de latencia y memoria del tier de destino, y reporta dónde queda.
-
Rastreado y reproducible.
Kubeflow orquesta las ejecuciones; MLflow rastrea cada experimento, métrica y versión de modelo en el registro.
-
Validado en el metal.
El validador hardware-in-the-loop rechaza un candidato que no pasa la puerta de precisión o latencia en hardware de referencia.
-
Optimizado para el edge.
La optimización on-device comprime el modelo al envoltorio de cómputo — la evaluación reporta la precisión que conserva.
-
Un registro de modelos en el dispositivo.
Los modelos se versionan, se obtienen una sola vez y se comprueban por firma antes de cargarse — una única fuente de verdad para lo que se ejecuta en cada dispositivo, con una CLI para listar, obtener y verificar.
Un solo panel de vidrio
Cada micro service transmite a Grafana, por defecto.
No hay proyecto de instrumentación. Cada micro service del OS expone un conjunto de métricas compatible con Prometheus y una superficie OpenTelemetry desde el arranque — visualizado en dashboards de Grafana a lo largo de la flota. Apunte su propio contenedor al mismo endpoint de scrape y aparece junto a los servicios del OS en el mismo panel. Métricas, logs y trazas, sobre estándares abiertos, sin stack separado.
-
Métricas en cada servicio.
Cada micro service es recolectado por Prometheus desde el arranque — sin un proyecto de instrumentación por servicio que ejecutar.
-
Su contenedor, la misma superficie.
Exponga un endpoint de métricas en su propio contenedor y se transmite a los mismos dashboards de Grafana que los servicios del OS.
-
Estándares abiertos, sin lock-in.
Compatible con Prometheus y OpenTelemetry — apunte cualquier back end compatible a la superficie.
Cumplimiento, continuamente
La misma pipeline produce la evidencia de cumplimiento.
La entrega continua no es solo cómo el software llega a la flota — es cómo se produce la evidencia. Cada release lleva una lista de materiales de software (SBOM) CycloneDX, un escaneo de CVE, binarios firmados y una superficie OpenTelemetry. Las obligaciones del Cyber Resilience Act (CRA) de la UE están mapeadas artículo por artículo en el paquete de cumplimiento — generadas por la pipeline, no añadidas después.
En el paquete de desarrollador
Qué se entrega y qué viene con ingeniería.
Parte del paquete ya está en el OS hoy; el resto se levanta con ingeniería durante la evaluación y a lo largo del despliegue — sin ruta de instalación pública, sin portal de autoservicio. La conversación de ingeniería calibra qué superficies están activas para su proyecto.
Hablar con ingeniería sobre el paquete de desarrollador.
Ingeniería le guiará por los simuladores, la pipeline de entrega, el rack hardware-in-the-loop, la evaluación de modelos y la superficie de observabilidad durante la evaluación.