Software para operativas portuarias: integración de datos

La parte documental incluye avisos de llegada del buque, listas de carga y descarga, conocimientos de embarque, declaraciones de mercancías peligrosas, documentos aduaneros y órdenes de entrega o recogida. Parte de estas comunicaciones viajan como mensajes estructurados entre sistemas; otra parte sigue llegando en PDF, hojas de cálculo o correo.

En el ámbito de la Unión Europea, el Reglamento (UE) 2019/1239 establece un entorno europeo de ventanilla única marítima (EMSWe), con interfaces armonizadas para las obligaciones de información de los buques que llegan, permanecen o salen de los puertos de la Unión, y se aplica desde el 15 de agosto de 2025. Para un proyecto de software, esto significa que una parte de los datos de escala se canaliza por cauces definidos; la interpretación de las obligaciones concretas corresponde a cada organización y a sus asesores.

• Inventario de documentos que intervienen en vuestro proceso y quién los emite.
• Para cada uno: si llega como mensaje estructurado, como fichero tabular o como documento libre.
• Campos clave que permiten cruzarlos: escala, buque, número de contenedor, número de conocimiento de embarque, referencia aduanera.
• Documentos libres que convendría extraer automáticamente, siempre con revisión humana de los campos críticos.

El sistema operativo de la terminal (TOS) es el maestro de lo que ocurre dentro: posiciones en patio, secuencias de carga, movimientos de puerta, inspecciones y estados de cada unidad. Cualquier integración debería respetar esa autoridad y consumir sus datos en lugar de replicar decisiones fuera de él.

Para el cliente que importa o exporta, el puerto es un tramo de una cadena más larga: almacén de origen, transporte terrestre, terminal, buque, terminal de destino y entrega. El valor del software suele estar en unir esos tramos con un identificador común y en anticipar problemas: un contenedor retenido que impide cumplir una cita de entrega, una escala retrasada que obliga a replanificar camiones.

• Seguimiento por unidad y por envío, con eventos normalizados aunque procedan de fuentes distintas.
• Cálculo de fechas previstas a partir de la escala y del estado en terminal, mostrando de dónde sale cada dato.
• Avisos a la persona responsable cuando un evento esperado no llega o llega fuera de plazo.
• Conexión con el transporte terrestre: reservas, asignación de camiones o vagones y confirmación de entrega.

Grúas de muelle, grúas de patio, cabezas tractoras, apiladoras y básculas generan datos de actividad, posición y estado. Integrarlos permite registrar movimientos reales, medir tiempos de operación, preparar mantenimiento o detectar cuellos de botella. Esta información suele estar en sistemas de control de cada fabricante o en el propio TOS.

• Leer datos de equipos para registro y análisis tiene un perfil de riesgo muy distinto de enviarles órdenes; cualquier actuación sobre maquinaria se diseña con el responsable de operaciones y fuera de las funciones de seguridad del equipo.
• Los identificadores de equipo deben coincidir entre el sistema de mantenimiento, el TOS y la telemetría.
• Los datos de posición de vehículos conducidos por personas son datos personales indirectos y requieren una finalidad clara.

Con tantos emisores, el diseño gana mucho si se adopta un modelo de eventos común: cada fuente se traduce a eventos normalizados (unidad descargada, retención aplicada, retención levantada, salida por puerta) con marca de tiempo, origen y referencia a la unidad y a la escala. Sobre ese registro de eventos se construyen las vistas y los avisos.

• Tabla de equivalencias de identificadores entre sistemas, mantenida y versionada.
• Conservación del mensaje original junto al evento normalizado, para poder auditar la traducción.
• Tratamiento de eventos tardíos, duplicados o contradictorios, con reglas explícitas de prioridad por fuente.
• Permisos por actor: cada organización ve lo que le corresponde de cada unidad.
• Supervisión de cada conexión: cuándo llegó el último mensaje de cada fuente.

Ejemplo ilustrativo: un transitario quiere saber, sin llamar a la terminal, qué contenedores de sus clientes están disponibles para recoger. El sistema combina la escala (del consignatario o de la plataforma portuaria), la descarga y las retenciones (de la terminal) y el despacho (de su sistema aduanero), y muestra solo las unidades libres, con la fuente y la hora de cada dato. Si una fuente lleva horas sin informar, la vista lo indica en lugar de mostrar un estado antiguo como actual.

1. ¿Qué decisión concreta quieres mejorar (recogidas, citas, facturación, planificación de escala) y qué datos la alimentan?
2. ¿Qué sistemas son maestros de cada dato y qué acceso ofrecen: mensajes estructurados, interfaces de programación, ficheros?
3. ¿Existe una plataforma de comunidad portuaria que ya agregue parte de la información?
4. ¿Cómo se cruzan los identificadores entre actores y quién mantiene las equivalencias?
5. ¿Qué información es confidencial entre actores y cómo se segregan los permisos?
6. ¿Qué obligaciones de información aplican a vuestra organización, según vuestros asesores, y cómo debe apoyarlas el sistema?

Un buen primer paso suele ser una sola vista de valor alto, como la disponibilidad de unidades para un tipo de actor, construida sobre el modelo de eventos. Si funciona, el mismo modelo sirve para ampliar a otros procesos sin rehacer las conexiones.