10. FORMATOS DE DATOS

Definir formatos de datos es algo así como inventar un sistema de archivado: si preguntamos a doce personas cual es la manera más eficiente de organizar las categorías obtendremos una docena de soluciones diferentes. La definición de formatos de datos para el SLB tiene un nivel añadido de complejidad: existen ya miles de barcos participando en programas SLB, muchos de ellos basados en formatos de datos precedentes. El establecimiento de normas y estándares en este ámbito requiere de todos las partes implicadas una combinación de rigor técnico, flexibilidad y diplomacia.

La gran mayoría de los sistemas SLB existentes están basados en el sistema Inmarsat-C, y el formato de datos de posición utilizado por estos terminales está, a su vez, basado en las recomendaciones de la Organización Marítima Internacional, como parte de su trabajo relacionado con la convención del SOLAS y el resultante SMSSM.

Además, los datos se agrupan en bloques de bits, un proceso que asigna posiciones específicas en el mensaje a cada conjunto específico de datos, manteniendo de este modo al mínimo el tamaño del mensaje. Esta forma de trabajo puede ilustrarse, por ejemplo, en el modo en el que comunicamos que la posición en un informe determinado corresponde a latitud norte o sur y longitud este u oeste.

Si tomamos una transmisión normal de datos no especificados serían necesarios al menos cinco bits para expresar las letras N, S, E u O. Sin embargo, si predeterminamos que la información para cada hemisferio de latitud o longitud sea transmitida en dos campos específicos dentro del mensaje, solamente necesitaremos un bit para distinguir entre N y S, y un segundo bit para distinguir entre E y O. Los otros campos pueden ser comprimidos de un modo similar. El resultado es que los mensajes en bloques de bits son mucho más cortos que los expresados de forma libre, están mejor adaptados para su tratamiento automático en un sistema SLB, y mantienen los costes de comunicaciones en un valor mínimo.

A pesar de estas ventajas, debemos admitir que formato de informe de posición utilizado normalmente por Inmarsat, no esta optimizado para el SLB y utiliza varios campos que no son importantes para el funcionamiento del SLB. Por ejemplo, determina mensajes macro codificados para comunicar parámetros que requieren una introducción manual.

Sin embargo, a pesar del hecho de que este formato no está específicamente adaptado al SLB por no haber sido desarrollado pensando en dicha aplicación, desde el punto de vista del operador del SLB es razonable incluirlo como una de las opciones válidas para un sistema en fase de desarrollo. Esto se debe a que muchos de los buques que participan actualmente en el SLB ya están programados para transmitir en este formato, y si lo descartáramos, obligaríamos a reprogramar todos los equipos de los buques que participan en el SLB, y a aquellos que disponen de un equipo Inmarsat-C que podría ser utilizado en futuras operaciones de SLB.

Por el contrario, significaría una perdida de oportunidad en esta fase inicial de desarrollo del SLB, no definir un formato optimizado para suministrar los datos al sistema SLB. Además, conviene establecer un formato que ofrezca al usuario cierta flexibilidad en la organización de los datos. Los informes serían inevitablemente más largos, pero mucho menos restrictivos y por tanto aceptables para cualquier usuario que, por una u otra razón, considere que los datos organizados campos de bits no son todavía compatibles con su forma de operar.

Por todo ello parece que la solución consiste en calificar tres diferentes formatos como aceptables para los informes SLB, y para que todos los operadores de SLB programen sus sistemas de modo que acepten los tres formatos. Limitando de esta forma las posibles variables se restringirían las divergencias entre las autoridades nacionales, estableciéndose el escenario adecuado para converger en el futuro en un único formato como estándar mundial.

Sería un enorme error y totalmente contraproducente no incorporar los estándares internacionales existentes, cuando puedan ser aplicados. Se pueden incorporar con facilidad en nuestros formatos de datos los siguientes estándares: ISO 8859.1 como conjunto de caracteres; ISO 3166 como código de países; ISO 8601 para representación de fechas y horas; e ISO 9735 EDIFACT como reglas de sintaxis.

10.1. El informe de posición de Inmarsat

Los informes de datos de Inmarsat se ejecutan en series de uno a tres paquetes de 15 bytes. Al igual que en todos los sistemas de comunicaciones, el informe comienza con un encabezamiento que contiene datos de carácter administrativo que indican el tipo de mensaje, el remitente y el receptor. Por esta razón en el primer paquete queda menos espacio para los datos designados por el usuario, y además, teniendo en cuenta que el primer paquete del informe de datos marítimos estándar finaliza con casi tres bytes reservados para los mensajes microcodificados, cuando se usan los datos de rumbo y velocidad es necesario incluirlos en el segundo paquete.

A continuación del encabezamiento del primer paquete siguen 39 bits destinados para los datos de posición, organizados del siguiente modo:

Tabla 10.1 Informe de posición de Inmarsat, solo posición.

El espacio remanente del primer paquete se destina a la designación de mensajes micro codificados y su atributo o variable. El segundo paquete comienza, después de su encabezamiento, con la velocidad y el rumbo del siguiente modo:

Tabla 10.2 Informe de posición de Inmarsat, inclusión de velocidad y rumbo

Después de incluir la velocidad y el rumbo todavía quedan 8 bytes para datos definidos por el usuario, que podrían emplearse para transmitir, sin ningún coste adicional, otros datos disponibles a bordo tales como temperatura, velocidad del viento, humedad o temperatura en la superficie del agua.

10.2. Informe de posición SLB optimizado

Considerado cada campo individualmente, no es posible transmitir datos de posición de modo más económico que el establecido en el informe marítimo de posiciones de Inmarsat. Sin embargo, si es posible eliminar otros campos de datos no esenciales, reduciendo así el informe en su conjunto.

Por ejemplo, si reservamos seis bytes para la información del encabezamiento -lo que significaría seis bits más de los requeridos por Inmarsat, suficientes para adecuarse a las necesidades de cualquier sistema futuro- un solo paquete de 15 bytes podría incluir todos los campos de datos, es decir posición, velocidad y rumbo, quedando todavía los dos bytes necesarios al final del paquete para la suma de control, o un algoritmo de corrección de errores.

Tabla 10.3 Informe optimizado de posición SLB recomendado

El resultado es que la decodificación es más simple ya que, una vez identificado el encabezamiento por el sistema receptor, los datos activos continúan seguidamente, elemento por elemento hasta al final, en que se verifica su integridad mediante una suma de control. Una consecuencia muy interesante de esta solución es que los costes de transmisión de un informe de posición que contenga rumbo y velocidad se reducen entre el 20% y el 50% aproximadamente.

10.3. Formato extendido del informe de posición

En un mundo ideal, todos los informes de posición SLB estarían en bloques de bits al objeto de optimizar tanto la economía como la precisión. Aunque este enfoque podría constituir el objetivo final de la normalización del SLB, no es realista esperar que todo el mundo abandone lo que está haciendo y encuadre sus prácticas existentes en alguna norma propuesta externamente. El proceso se asemejará mas a una convergencia que a un cambio repentino.

Por esta razón, el colectivo del SLB necesita, además de una solución rígidamente diseñada bit a bit, otro formato de informe más flexible con los datos expresados en simples caracteres, estando cada conjunto de datos precedido por un indicador del contenido del campo. Los datos presentados de esta forma pueden decodificarse fácil y automáticamente, para introducirlos a continuación en la base de datos del SLB, en el formato propio del sistema en cuestión.

Reconociendo el hecho de que todos los Estados miembros habían desarrollado las propias preferencias individuales para el almacenamiento de los datos recogidos de los buques pesqueros, la Comisión Europea desarrolló, como parte de su proyecto piloto de ámbito Europeo, un formato de este tipo que puede ser fácilmente ampliado o modificado para ajustarse a los requisitos de posición que se han tratado en los apartados anteriores. La adopción de una variante de dicho formato tendría la ventaja de que el ajuste al mismo sería muy sencillo para los 13 Estados costeros de la Unión Europea, así como para aquellos Estados del pabellón que tengan buques pescando en aguas de la UE.

Los campos requeridos para componer un informe son los siguientes:

Tabla 11.4 Elementos del formato extendido de posición

El informe efectivo se compone utilizando una barra doble (//) y un código para indicar el principio de un campo, y una barra simple (/) para separar el código de los datos del campo.

Utilizando estos elementos, el informe de posición de un buque americano de nombre Ishmael en posición latitud 48 grados 16 minutos Norte, longitud 33 grados 51 minutos Oeste, navegando a 9,3 nudos de velocidad al rumbo 271 grados, a las 08:25 PM del día 19 de Diciembre de 1998, tendría la siguiente forma:

//SR//TM/POS//NA/ISHMAEL//FS/USA//TI/2025//DA/981219//LA/N4816//LO/W3351//SP/093//CO/271//ER

Aunque está muy lejos de ser un mensaje eficaz en términos de tamaño -en ASCII ocuparía aproximadamente 92 bytes, es decir tres veces el tamaño del informe de posición de Inmarsat y seis veces el informe de posición SLB mejorado- tiene las ventajas de ser flexible y universal. Aunque se altere el orden de los elementos el informe sigue siendo fácilmente descifrable. Conviene tener en cuenta que, simplemente con el acuerdo de los operadores del SLB sobre el orden de los elementos, podría conseguirse una mayor economía mediante la eliminación de los códigos de designación de los campos.

Además, es muy sencillo añadir nuevos conjuntos de datos definiendo los elementos adicionales mediante la creación de nuevos códigos de dos letras. Como veremos más adelante, esta característica será muy útil para la definición del informe de capturas. La validez de esta aproximación se hizo patente cuando la Dirección de Pesca de Noruega, en el contexto de la obligación del utilizar el SLB en la Organización de las Pesquerías del Atlántico Norte (OPANO), utilizó el formato original de la UE para cubrir prácticamente todas las áreas de comunicación con sus barcos.