Visibilidad de embarques: normalice eventos antes de añadir un agente
Por Equipo Quantum Developers
Resumir:
Un agente de monitoreo solo puede gobernarse si cada cambio del embarque conserva identidad, tiempo del evento, fuente, vocabulario y evidencia; una ETA sin ese linaje es una opinión difícil de auditar. Antes de pedir predicciones o resúmenes, la organización debe lograr que eventos de naviera, aerolínea, almacén y sensor hablen de un mismo objeto sin borrar quién afirmó qué.
El problema no es falta de mapas
Muchas torres de control muestran un punto y una fecha estimada. La dificultad aparece cuando dos participantes reportan estados distintos, una actualización llega tarde o un evento corrige otro. Si el tablero sobrescribe el valor anterior, operaciones pierde la secuencia que permitiría decidir.
“Embarque” tampoco es una identidad suficiente. Puede referirse a reserva, documento, unidad logística, contenedor, pieza, vuelo o tramo. Una alerta debe decir qué objeto cambió y qué relación lo conecta con el resultado que el equipo controla.
Qué aportan tres estándares y qué no resuelven solos
El estándar GS1 EPCIS estructura visibilidad mediante las dimensiones qué, cuándo, dónde, por qué y cómo, con vocabulario de contexto empresarial. Es útil para eventos sobre objetos físicos o digitales y su cadena de custodia.
IATA ONE Record define para carga aérea un modelo común, una API y una especificación de seguridad; mantiene datos en la fuente y permite al propietario controlar acceso. Su “registro único” es una vista enlazada del embarque, no una orden para copiar todo a una base central.
El estándar DCSA Track & Trace ofrece procesos, estructuras de evento y APIs para seguimiento de contenedores a través de fases marítimas. Aporta vocabulario sectorial para eventos como transporte, equipo y embarque.
Los tres reducen ambigüedad dentro de sus ámbitos, pero no garantizan que una empresa vincule correctamente un evento aéreo con una orden interna o conserve la evidencia original. Esa es responsabilidad de la capa operativa.
Sobre canónico de evento logístico
No fuerce todos los mensajes a un esquema gigante. Cree un sobre pequeño y mantenga el payload original mediante referencia.
| Campo | Función |
|---|---|
| event_id | identidad del hecho recibido; soporta deduplicación |
| source_system y source_party | quién publicó y desde qué sistema |
| source_standard/version | EPCIS, ONE Record, DCSA u otro vocabulario |
| object_type/object_id | pieza, unidad logística, contenedor, envío o reserva |
| occurred_at/timezone | cuándo ocurrió en el mundo operativo |
| received_at | cuándo la plataforma lo conoció |
| event_type/business_step | qué ocurrió en vocabulario canónico y original |
| location_id | dónde ocurrió, con sistema de identificación |
| related_objects | relaciones con orden, tramo, documento y transporte |
| evidence_ref | mensaje original, documento o lectura permitida |
| supersedes_event_id | corrección explícita sin borrar historia |
| confidence/origin | dato declarado, sensor, cálculo o inferencia |
Separar occurred_at de received_at permite detectar latencia y ordenar correctamente. Un evento recibido después puede describir un hecho anterior. La línea de tiempo debe conservar ambos.
Mapeo práctico a una línea de ejecución
El siguiente mapeo no afirma equivalencia normativa; es un contrato operativo para integrar conceptos:
| Pregunta operativa | GS1 EPCIS | ONE Record | DCSA | Línea común |
|---|---|---|---|---|
| ¿Qué cambió? | objeto/evento | objeto logístico | shipment/equipment/transport event | object_id + related_objects |
| ¿Cuándo? | eventTime | evento o cambio del objeto | eventDateTime | occurred_at |
| ¿Dónde? | readPoint/businessLocation | ubicación enlazada | event location | location_id |
| ¿Por qué/contexto? | businessStep/disposition | tipo y relaciones del modelo | eventType/classifier | event_type + business_step |
| ¿Quién lo afirma? | fuente del repositorio/participante | dueño del dato | publisher | source_party |
| ¿Qué evidencia existe? | evento capturado | recurso y revisión | mensaje de API | evidence_ref + source version |
Conserve el término original junto a la traducción canónica. Así una nueva versión del estándar puede remapearse sin reescribir la historia.
De evento a excepción accionable
Un evento no debería generar una alerta solo por ser nuevo. Aplique una regla de estado:
- valide identidad, versión y duplicado;
- actualice la proyección del objeto sin borrar eventos;
- compare el nuevo estado con plan, promesa o política;
- clasifique diferencia por acción requerida;
- asigne dueño, vencimiento y evidencia;
- cierre cuando una acción o evento posterior resuelva la condición.
Una ETA calculada debe registrarse como inferencia con versión, entradas y horizonte, separada de una ETA declarada por el transportista. Si ambas difieren, el agente puede explicar el conflicto y proponer prioridad; no debe fingir una única verdad.
Ejemplo ilustrativo multimodal
Este ejemplo es ilustrativo. Una unidad sale de almacén, viaja por carretera a terminal, cruza por mar y continúa por aire. Un evento EPCIS registra despacho de la unidad; DCSA reporta carga del contenedor; ONE Record actualiza un objeto de carga aérea.
La capa común no intenta convertirlos en el mismo evento. Los enlaza mediante relaciones: la unidad está contenida en el contenedor durante un tramo y asociada a la pieza aérea en otro. Cuando DCSA publica descarga tardía, la proyección detecta que el hito aéreo planificado ya no es alcanzable. El agente prepara una excepción con eventos fuente, diferencia frente al plan y alternativas permitidas. Operaciones decide reprogramar.
El valor no viene de “seguir tres veces”. Viene de preservar el cambio causal desde la fuente hasta la decisión y el resultado.
Gobierno del linaje entre participantes
Defina qué parte puede afirmar cada evento, cómo se autentica, cuánto se retiene y quién puede verlo. Un integrador no debe convertirse silenciosamente en autor. Las correcciones usan supersedes_event_id; nunca editan el pasado. Los datos sensibles permanecen referenciados y protegidos.
Revise métricas de calidad por fuente: completitud de campos obligatorios, latencia, duplicados, correcciones y objetos sin relación. No use cantidad de eventos como sinónimo de visibilidad. Mil mensajes sin identidad común pueden empeorar la operación.
Implementación en Quantum
Quantum Automation Center puede usar el objeto de negocio como eje, la línea de tiempo para eventos normalizados, artefactos y logs para evidencia permitida, y estados para excepciones. Permisos y aprobación humana controlan acciones; analíticas muestran latencia, calidad de fuente y resolución. Consulte monitoreo de embarques y la ontología de Quantum.
El agente debe leer esa historia y producir una recomendación trazable, no sustituirla con un resumen sin referencias.
El contrapunto: otro modelo canónico añade fricción
Es cierto. Una transformación adicional puede perder semántica, retrasar datos y crear un equipo central que bloquea cambios. Si obliga a cada socio a abandonar su estándar, el diseño fracasó.
Mantenga el sobre pequeño, versionado y extensible. Preserve payload y vocabulario originales, y traduzca solo los campos necesarios para identidad, orden, contexto y gobierno. Los equipos sectoriales siguen usando EPCIS, ONE Record o DCSA en profundidad.
Cuándo no construir esta capa
No la construya cuando una sola red y un estándar ya cubren el recorrido y las decisiones necesarias; configure ese estándar directamente. Tampoco use un agente para inventar eventos ausentes o “rellenar” fuentes crónicamente tardías. Una inferencia puede apoyar planificación, pero debe etiquetarse como tal.
Si no existe acuerdo para compartir datos, resuelva derechos y responsabilidad antes de integrar. Más tecnología no crea procedencia.
Prueba de trazabilidad antes del siguiente modelo
Seleccione una excepción cerrada y recorra resultado, decisión, eventos, relaciones y mensajes fuente. Cambie luego una traducción canónica y compruebe que puede reprocesar sin perder el original. Si la cadena se rompe, invierta en identidad y procedencia antes de entrenar otra predicción de ETA.
Sources
- GS1 EPCIS and Core Business Vocabulary — gs1.org
- IATA ONE Record — iata.org
- DCSA Track and Trace Standard Documentation — dcsa.org
Temas del artículo
