獳NEXO II

Especificaciones t閏nicas de los equipos de seguimiento por sat閘ite

I

Introducci髇

1.1. General.

1. El Reglamento (CEE) 2847/93 del Consejo, de 12 de octubre de 1993, por el que se establece un r間imen de control aplicable a la pol韙ica pesquera com鷑, establece un sistema de seguimiento de buques pesqueros v韆 sat閘ite. El Reglamento (CE) 2371/2002, de 20 de diciembre del Consejo, Sobre la Conservaci髇 y Explotaci髇 de los Recursos Pesqueros en virtud de la pol韙ica pesquera com鷑 extiende el sistema a todos los buques pesqueros de eslora superior a 15 metros. Igualmente, el Reglamento (CE)/2003 de la Comisi髇 establece reglas detalladas en relaci髇 con los sistemas de localizaci髇 por sat閘ite.

2. La Direcci髇 General de Recursos Pesqueros y Acuicultura (DGRPYA en adelante) de la Secretar韆 General del Mar, del Ministerio de Medio Ambiente, y Medio Rural y Marino, tiene la responsabilidad en este asunto, sobre los buques pesqueros espa駉les.

3. El Instituto Nacional de T閏nica Aeroespacial (INTA), Organismo Aut髇omo del Ministerio de Defensa ha firmado un convenio de colaboraci髇 con la DGRPYA, mediante el cual edita este pliego de especificaciones t閏nicas que deber醤 cumplir los equipos a instalar en los buques pesqueros espa駉les.

1.2. Prop髎ito.

1. Este documento describe los requisitos del Equipo de Localizaci髇 de Buques (ELB), el cual forma parte de un Sistema de Localizaci髇 de Buques (SLB) completo formado por dichos ELBs en n鷐ero variable y un Centro de Seguimiento de Pesca (CSP) situado en Madrid.

2. Los ELBs comunicar醤 su posici髇 geogr醘ica de manera fiable y segura, manteniendo la confidencialidad de los mensajes frente a terceros.

3. Estos requisitos podr醤 cambiar para adecuarse a nuevas tecnolog韆s y necesidades.

1.3. Acr髇imos y abreviaturas.

Los siguientes acr髇imos y abreviaturas han sido utilizados en este documento:

a: actividad requerida.

ca: valor de corriente de la antena requerido.

CIR: C骴igo de Identificaci髇 de Red.

CN: Notas de Cambio (Change Notice).

CSP: Centro de Seguimiento de Pesca.

DGRPYA: Direcci髇 General de Recursos Pesqueros y Acuicultura.

DNID: Identificaci髇 de la red de datos (Data Network Identification).

dow: fecha de retirada (date of withdrawal).

ea: estado de la antena requerido.

ELB: Equipo de Localizaci髇 de Buques.

GPS: Sistema de posicionamiento global (Global Positioning System).

GW: Estaci髇 de Tierra (Gateway).

hex: hexadecimal.

IMEI: identificador del equipo (Internacional Mobile Equipment Identifier).

INTA: Instituto Nacional de T閏nica Aeroespacial.

Kbps: Kilobits por segundo.

LES: Estaci髇 costera (Land Earth Station).

LSB: Bit Menos Significativo.

MC: Mensaje Codificado.

MEM: Mensaje Macrocodificado.

MCI: Mensaje Codificado de Interrogaci髇.

MO: Mobile Originated.

MSB: Bit M醩 Significativo.

MT: Mobile Terminated.

p: posici髇 requerida.

r: rumbo requerido.

RMS: Valor eficaz (Root Mean Square).

ROM: Memoria solamente de lectura (Read Only Memory).

SBD: Short Burst Data.

SDM: Manual de definici髇 del sistema Inmarsat (System Definition Manual).

SGDM: Secretar韆 General del Mar.

SLB: Sistema de Localizaci髇 de Buques.

t: per韔do activo de emisi髇 de informes de posici髇.

ti: tiempo inicial del volcado de memoria solicitado.

tf: tiempo final del volcado de memoria solicitado.

Ti: tiempo del dato m醩 antiguo conservado en memoria.

Tf: tiempo del dato m醩 reciente conservado en memoria.

tm: per韔do de muestreo en el volcado de memoria.

tmr: per韔do de muestreo redondeado al m鷏tiplo de 10 minutos m醩 cercano.

UTC: Tiempo Universal Coordinado (Universal Time Coordinated).

v: velocidad requerida.

vn: tensi髇 nominal de alimentaci髇 en corriente alterna.

2. Documentos aplicables.

1. Reglamento (CE). 2371/2002 del Consejo de 20 de diciembre de 2002 sobre la conservaci髇 y explotaci髇 sostenible de los recursos pesqueros en virtud de la pol韙ica pesquera com鷑.

2. Normativa comunitaria aplicable en relaci髇 con las disposiciones de aplicaci髇 en lo que respecta a los sistemas de localizaci髇 de buques v韆 sat閘ite.

3. Inmarsat-C System Definition Manual (SDM), versi髇 3.0, CD003, marzo 2002.

4. Iridium SBD DirectIP Socket Connectivity White Paper. Versi髇 1.02, 23/10/2006.

5. Iridium Satellite Data Services White Paper. Versi髇 1.0, 02/06/2003.

6. UNE EN 60068-2-6. Ensayos ambientales. Parte 2: Ensayos. Ensayo Fc.: Vibraci髇 sinusoidal.

7. UNE EN 60068-2-27. Procedimiento de ensayos ambientales b醩icos. Parte 2: Ensayos. Ensayo Ea y gu韆: Choque.

8. UNE EN 60529 Grados de protecci髇 proporcionadas por las envolventes (c骴igo IP).

8a. UNE EN 60068-2-1 Ensayos ambientales. Parte 2: Ensayos. Ensayo A: Fr韔.

8b. UNE EN 60068-2-2 Ensayos ambientales. Parte 2: Ensayos. Ensayo B: calor seco.

9. UNE EN 60068-2-1/A1 y UNE EN 60068-2-1/A2. Ensayos ambientales. Parte 2: Ensayos. Ensayo A: Fr韔.

10. UNE EN 60068-2-2/A1 y UNE EN 60068-2-2/A2. Ensayos ambientales. Parte 2: Ensayos. Ensayo B: Calor seco.

11. UNE EN 60068-2-78. Ensayos ambientales. Parte 2: Ensayos. Ensayo Cb: Calor h鷐edo, ensayo continuo, recomendado principalmente para los equipos.

12. UNE EN 60068-2-11. Ensayos ambientales. Parte 2: Ensayos. Ensayo Ka: Niebla salina.

13. UNE EN 60945. Equipos de navegaci髇 mar韙ima. Requisitos generales. M閠odos de ensayo y resultados requeridos.

14. ANSI X3.92 "American National Standard for Data Encryption Algorithm (DEA)", American National Standards Institute, 1981.

15. ANSI X3.106 "American National Standard for Information Systems -Data Encryption Algorithm -Modes of Operation", American National Standards Institute, 1983.

16. ISO IEC 9594 8/ITU T X.509, "Information Technology Open Systems Interconnection The Directory: Authentication Framework".

17. FIPS PUB 140 1 "Security Requirements for Cryptographic Modules", 1993.

18. "Randomness Recommendations for Security", RFC 1750, Donald Eastlake, Stephen Crocker, Jeffrey Schiller, 1994.

19. "Cryptographic Random Numbers", IEEE P1363 Appendix E, Draft version 1.0, 11, 1995.

20. RFC 1321, "The MD5 Message Digest Algorithm", Ronald Rivest, 1992.

21. UNE-EN 60950-1. Equipos de tecnolog韆 de la informaci髇. Seguridad. Parte 1: Requisitos generales.

22. EN 60990. Methods of measurement of touch current and protective conductor current.

Nota: Para las referencias normativas que se citan en esta especificaci髇 t閏nica, en las que no se indica la fecha, se aplicar� la 鷏tima edici髇 de dicha publicaci髇 (incluyendo sus modificaciones) a partir de la fecha "dow".

3. Requisitos.

• 1. En el apartado 3.1 se definen los requisitos generales que deber醤 cumplir todos los ELBs, mientras que en el apartado 3.2 se definen los requisitos para ELBs basados en Inmarsat-C y en el 3.3 se definen los requisitos para ELBs basados en Iridium.
• 2. Si el ELB no es del tipo inmarsat-C ni del tipo Iridium, pero cumple los requisitos del punto 3.1, la DGRPYA podr� desarrollar para el tipo propuesto, una serie de requisitos equivalentes a los descritos en 3.2 y en 3.3.

3.1. Requisitos generales para ELBs.

A continuaci髇 se describen los requisitos mandatorios m韓imos a cumplir por los ELBs que utilicen un sistema de localizaci髇 v韆 sat閘ite para determinar la posici髇 de los buques.

3.1.1. Mensajes de posici髇.

• 1. El ELB debe ser capaz de transmitir autom醫icamente mensajes o informes de posici髇 (a petici髇 o peri骴icos) que incluyan la siguiente informaci髇:
  • a. Identidad del ELB.
  • b. Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • c. Latitud.
  • d. Longitud.
  • e. Rumbo actual.
  • f. Velocidad actual.
  • g. Actividad (pesca/no pesca).
• 2. La posici髇 geogr醘ica dentro del informe de posici髇 debe ser suministrada con un error que no supere los 100 metros.
• 3. Un mensaje o informe de posici髇 debe ser recibido por el CSP dentro de los 10 minutos siguientes a la transmisi髇 del mismo por el ELB en condiciones normales de operaci髇.
• 4. El ELB debe llevar implementada la capacidad de que se le programen los intervalos de env韔 de mensajes de posici髇 peri骴icos entre 15 minutos y 24 horas, mediante un comando para programar intervalos de env韔 de mensajes de posici髇 peri骴icos enviado por el CSP.
• 5. El ELB debe ser capaz de enviar todas las posiciones almacenadas durante un intervalo de tiempo determinado a petici髇 del CSP.
• 6. El ELB debe ser capaz de transmitir autom醫icamente al CSP (sin ser necesaria acci髇 alguna por parte del capit醤 o patr髇) un informe de posici髇 como respuesta a un comando enviado por el CSP en un tiempo m醲imo de 2 minutos desde que el ELB recibi� dicho comando, en condiciones normales de operaci髇.
• 7. El ELB debe enviar un informe de posici髇 junto con una identificaci髇 del evento Actividad de pesca al pulsar el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra PESCA: ACTIVO.
• 8. El ELB debe enviar un informe de posici髇 junto con una identificaci髇 del evento No actividad de pesca al pulsar otra vez el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra PESCA: PASIVO.
• 9. El ELB debe enviar un informe de posici髇 actual al pulsar el capit醤 o patr髇 el pulsador nombrado con la palabra CRUCE.

3.1.2. Mensaje de encendido.

El ELB debe ser capaz de enviar autom醫icamente un informe de posici髇 actual inmediatamente despu閟 de ser encendido o haber recuperado la alimentaci髇 el閏trica, incluyendo una identificaci髇 para indicar que es un informe de posici髇 de encendido.

3.1.3. Mensajes de apagado.

• 1. El ELB debe ser capaz de enviar un informe de posici髇 junto con una identificaci髇 del evento apagado normal cuando el capit醤 o patr髇 lo apaga deliberadamente pulsando el pulsador nombrado con la palabra APAGADO.
• 2. El ELB debe ser capaz de enviar un mensaje cuando se apaga anormalmente sin previo aviso (por ejemplo, se ha perdido la potencia el閏trica por alg鷑 motivo). Dicho mensaje debe contener la informaci髇 del buque en el momento del apagado y debe enviarse en el momento en que se recupere la alimentaci髇, debiendo identificar dicho evento de apagado anormal.

3.1.4. Mensajes de antena.

• 1. Cuando la funcionalidad del ELB lo permita, debe ser capaz de enviar autom醫icamente un informe de posici髇 junto con una identificaci髇 del evento desconexi髇 de antena (corriente de antena nula).
• 2. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la corriente de la antena.
• 3. El ELB debe ser capaz de enviar autom醫icamente un informe de posici髇 junto con una identificaci髇 del evento bloqueo de antena (conexi髇 con el sat閘ite defectuosa).
• 4. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la calidad de la se馻l de la antena.

3.1.5. Mensaje de reconocimiento.

El ELB puede ser requerido para que env韊 un mensaje independiente de reconocimiento de haber recibido correctamente el comando enviado por el CSP.

3.1.6. Mensajes de datos.

Opcionalmente, el ELB puede ser capaz mediante la conexi髇 de un terminal externo adecuado, de enviar al CSP y recibir del CSP mensajes de datos (por ejemplo texto) en un tiempo m醲imo de 15 minutos, en condiciones normales de operaci髇.

3.1.7. Interface con terminal externo.

El ELB deber� contar con un conector externo que permita la extracci髇 en puerto de los datos de posici髇 almacenados en memoria y opcionalmente pueda ser utilizado para mantener otras comunicaciones que no interfieran en su funcionalidad.

3.1.8. Cobertura.

• 1. El sistema satelital utilizado por el ELB debe ofrecer cobertura total y permanente para la zona en que se autorice.
• 2. No deben existir lagunas en la cobertura ofrecida por el sistema satelital durante un per韔do normal de funcionamiento de 24 horas al d韆.

3.1.9. Seguridad.

• 1. El ELB constar� de una caja cerrada y con un sistema de sellado adecuado para evitar su manipulaci髇, as� como de la antena correspondiente, cumpliendo las caracter韘ticas m韓imas para su adecuado funcionamiento en condiciones mar韙imas.
• 2. Como caracter韘tica opcional, los informes de posici髇 y mensajes de datos enviados por el ELB podr醤 ser encriptados con el fin de evitar la interceptaci髇 y lectura de los mismos por nadie que no sea el CSP.
• 3. No debe ser posible detectar, en el propio equipo, el intervalo de env韔 de mensajes de posici髇 peri骴icos o determinar visualmente en qu� momento se va a generar un informe de posici髇 por nadie que no sea el CSP.
• 4. No debe ser posible modificar o inhabilitar el env韔 de mensajes de posici髇 peri骴icos por nadie que no sea el CSP.
• 5. En ning鷑 caso ser� posible la modificaci髇 de los datos de identificaci髇 o posici髇 del buque por otros falsos.

3.1.10. Etiquetado.

• 1. El ELB llevar� un identificador 鷑ico o n鷐ero de serie en el exterior de la caja que no pueda ser borrado y que lo identifique de forma un韛oca.
• 2. Dicho n鷐ero tendr� la siguiente estructura:
  • a) Dos primeros caracteres num閞icos, o c骴igo del fabricante, que asignar� la DGRPYA.
  • b) Un tercer car醕ter num閞ico, o identificador del modelo.
  • c) Seis caracteres num閞icos adicionales.
• 3. Ser� responsabilidad del fabricante la asignaci髇 del identificador del modelo y de los 鷏timos seis caracteres del n鷐ero de serie, de manera que se garantice la unicidad de c骴igos dentro de los modelos por 閘 producidos.

3.2. Requisitos para ELBs basados en Inmarsat-C.

• 1. Este apartado define los requisitos que deben cumplir los ELBs que utilicen el sistema Inmarsat-C.
• 2. Dichos ELBs deben cumplir 閟tos requisitos adem醩 de los generales definidos en el apartado 3.1 de esta especificaci髇 t閏nica.

3.2.1. Descripci髇 del ELB.

• 1. El ELB estar� formado por las dos unidades descritas a continuaci髇:
  • a. Una antena que ser� de uso com鷑 para las funciones del GPS y de Inmarsat-C, homologada por Inmarsat. Tanto el receptor de GPS como el transceptor de Inmarsat C, ambos homologados por Inmarsat, podr醤 estar integrados en el bloque de la antena.
  • b. Una caja cerrada y sellada para evitar su manipulaci髇, que llamaremos caja azul, la cual podr� contener el receptor de GPS y el transceptor de Inmarsat-C, ambos homologados por Inmarsat; as� como la electr髇ica necesaria para cumplir los requisitos de esta especificaci髇 t閏nica.
• 2. Opcionalmente se podr� a馻dir un terminal externo.

3.2.2. Requisitos funcionales.

3.2.2.1. General.

• 1. La posici髇 del buque, el rumbo y la velocidad se obtendr� 鷑icamente de la se馻l recibida de la constelaci髇 satelital GPS por la antena y el receptor GPS.
• 2. La posici髇 del buque ser� transmitida al sistema satelital por un transceptor Inmarsat-C homologado por Inmarsat, a trav閟 de un proveedor de servicios autorizado por la DGRPYA.
• 3. La antena ser� com鷑 para las funciones a realizar por el receptor GPS y por el transceptor Inmarsat-C y estar�, asimismo, homologada por Inmarsat.
• 4. Cuando el receptor GPS y el transceptor Inmarsat-C est閚 integrados en el bloque de la antena, el fabricante de los ELBs deber� incorporar un sistema de seguridad adecuado para que cada caja azul solamente pueda funcionar con el bloque transceptor-antena que le sea espec韋icamente asignado, de tal forma que si este bloque es sustituido por otro diferente, el ELB no funcione.

3.2.2.2. Receptor GPS y transceptor Inmarsat-C.

3.2.2.2.1. Receptor GPS.

• 1. El receptor GPS ser� el encargado de enviar al Transceptor Inmarsat-C la posici髇 del buque, el rumbo y la velocidad.
• 2. Dicha informaci髇 ser� obtenida de la se馻l de la constelaci髇 satelital GPS recibida por dicho receptor a trav閟 de la antena GPS.
• 3. El receptor GPS debe ser, al menos, de seis canales.

3.2.2.2.1.1. Error de precisi髇 en la posici髇.

• 1. El error de precisi髇 en la posici髇 permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) est� habilitada, debe ser inferior a 100 m RMS.
• 2. El error de precisi髇 en la posici髇 permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) no est� habilitada, debe ser inferior a 25 m RMS.

3.2.2.2.1.2. Error en la velocidad.

• 1. El error de velocidad permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) est� habilitada, debe ser inferior a 1 nudo RMS.
• 2. El error de velocidad permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) no est� habilitada, debe ser inferior a 0.5 nudos RMS.

3.2.2.2.1.3. Tiempo de adquisici髇.

El tiempo de adquisici髇 del GPS debe ser inferior a los siguientes valores:

• a) 4 minutos en el caso de un encendido en fr韔.
• b) 2 minutos en el caso de un encendido despu閟 de haberse apagado durante menos de 1 hora.
• c) 1 minuto en el caso de un bloqueo o p閞dida de enganche.

3.2.2.2.1.4. Frecuencia de actualizaci髇.

La frecuencia de actualizaci髇 debe ser inferior a 10 segundos, en condiciones normales y habiendo suficientes sat閘ites enganchados.

3.2.2.2.2. Transceptor Inmarsat-C.

• 1. El transceptor ser� homologado por Inmarsat, con tal de que su funcionalidad sea correcta en ambiente mar韙imo e instalado en un buque.
• 2. El transceptor podr� ser del tipo homologado por Inmarsat para su operaci髇 como Clase II o Clase III de Inmarsat.
• 3. El transceptor procesar� las se馻les recibidas de los sat閘ites Inmarsat y GPS a trav閟 de la antena, y enviar� se馻les a la antena para su transmisi髇.

3.2.2.3. Antena.

• 1. La antena ser� com鷑 para las funciones a realizar por el receptor GPS y por el transceptor Inmarsat-C y estar�, asimismo, homologada por Inmarsat.
• 2. Ser� capaz de recibir las se馻les transmitidas por los sat閘ites Inmarsat y GPS. Asimismo, ser� capaz de transmitir las se馻les generadas por el transceptor Inmarsat-C al sat閘ite Inmarsat.

3.2.2.4. Puerto de comunicaciones local.

• 1. Adem醩 de las funciones de comunicaci髇 remotas a trav閟 de la constelaci髇 Inmarsat, demandadas por la presente especificaci髇, se requiere la capacidad de comunicaci髇 local con la caja azul a trav閟 de un puerto de comunicaciones serie RS232C.
• 2. Las capacidades y funciones a prestar a trav閟 de este puerto de comunicaciones local se dividen en dos categor韆s:
  • a) Las detalladas en esta especificaci髇, con la indicaci髇 de los mensajes de identificaci髇, interrogaci髇 y respuesta oportunos.
    
    Los mensajes y funcionalidades se indican a nivel de aplicaci髇, dejando al criterio del fabricante el encapsulado de los paquetes de entrada/salida en el nivel de enlace y aplicaci髇 correspondiente.
    
    Son aplicables al puerto de comunicaciones local los siguientes mensajes:
    
    (3.2.6.3.2) Mensaje de interrogaci髇 de memoria.
    
    (3.2.6.4.1) Mensajes de volcado de memoria.
    
    (3.2.7) Protocolo de identificaci髇 del inspector para el volcado de posiciones de memoria.
    
    (3.2.6.5.1) Formato del mensaje de error en interrogaci髇 de memoria.
  • b) Toda otra funci髇 o capacidad que desee incluir el fabricante, aqu� no indicada o anticipada.
• 3. Ambos tipos de funciones deber醤 cumplir las restricciones de seguridad y ausencias de efectos funcionales secundarios indicados a continuaci髇.
• 4. Estas restricciones se aplican sobre el canal de comunicaciones Inmarsat del equipo, con independencia del n鷐ero de c骴igos de DNID activos que tuviera el mismo.
• 5. El fabricante de los ELBs deber� entregar a la DGRPYA el software adecuado para cada equipo que permita la extracci髇 de los datos por el puerto de comunicaciones local, as� como la realizaci髇 de las capacidades y funciones anteriormente descritas.

3.2.2.4.1. Perturbaciones a las funciones requeridas del equipo.

• 1. La recepci髇 de mensajes procedentes del CSP se realiza de forma as韓crona, sin que se pueda determinar el momento ni frecuencia de recepci髇 de los mismos. La emisi髇 de mensajes del ELB al CSP se realiza de dos formas:
  • a. De forma as韓crona, por respuesta inmediata y 鷑ica a un mensaje del CSP.
  • b. De forma s韓crona y peri骴ica, en los mensajes de informaci髇 de estado del buque.
• 2. Sea t el per韔do activo de emisi髇 de los mensajes de situaci髇. El ELB s髄o permitir� realizar otras funciones de comunicaci髇 distintas de las incluidas en esta especificaci髇 cuando:
  
  Si to es el instante inicial de la transmisi髇/recepci髇, kt el tiempo de la 鷏tima comunicaci髇 de posici髇 emitido por el ELB, y ts el tiempo estimado de transmisi髇/recepci髇 del servicio requerido, se cumple (to-kt) + ts<t.
• 3. Igualmente, y ante la recepci髇 de cualquiera de los mensajes de interrogaci髇 definidos en esta especificaci髇, el ELB atender� de forma prioritaria el servicio del mismo, garantizando la asignaci髇 exclusiva del canal de comunicaciones remoto a la emisi髇 del mensaje de respuesta correspondiente, cuando se encuentre definido.
• 4. Ante la ausencia de otras restricciones, cualquier servicio o funcionalidad a馻dida al ELB por el fabricante del mismo nunca podr� impedir la recepci髇 de mensajes del CSP durante m醩 de 6 minutos.

3.2.2.4.2. Transmisi髇 de informaci髇 distinta de la requerida en esta especificaci髇.

• 1. Esta especificaci髇 no limita la inclusi髇 de otros servicios o funcionalidades que pudieran resultar de utilidad a la flota pesquera usuaria del sistema.
• 2. Dicha funcionalidad ser� completamente ajena a todos los datos que el ELB requiere, produce o almacena en relaci髇 a las funciones, mensajes y requisitos aplicables al fin principal del sistema de seguimiento de pesqueros. En particular, los usuarios del mismo nunca podr醤 tener acceso, ni de lectura ni de modificaci髇 ni de borrado, de lo siguiente:
  • a. Claves internas e identificadores de acceso.
  • b. Mensajes recibidos y emitidos al CSP, ni su contenido ni ocurrencia (salvo mensajes de texto intercambiados con el CSP).
  • c. Memoria de registro de la actividad del buque.
  • d. Estado o actividad del ELB.
• 3. La utilizaci髇 del canal de informe de datos y de todos los servicios de data reporting y polling se reservan en exclusiva para las funciones de control de la DGRPYA.

3.2.3. Requisitos f韘icos.

3.2.3.1. General.

• 1. La caja azul deber� estar conectada con la antena mediante un cable no manipulable.
• 2. La comunicaci髇 entre el transceptor Inmarsat-C y el receptor GPS no podr� ser accesible de manera no autorizada, de forma que no pueda comprometer la integridad de los datos de posici髇 del GPS.
• 3. Se permitir� una conexi髇 externa al ELB, para la conexi髇 de un terminal de usuario, utilizable en la transmisi髇 de otros datos del buque.

3.2.3.2. Requisitos ambientales.

Todas las unidades del ELB y sus componentes, deber醤 ser dise馻das para uso mar韙imo, no vi閚dose degradadas sus condiciones de funcionamiento en dicho ambiente.

3.2.3.2.1. Vibraci髇.-

El equipo podr� soportar vibraci髇 con amplitud de aceleraci髇 de 1 g en el rango de frecuencia de 10 a 150 Hz durante un tiempo de 20 ciclos, seg鷑 tabla C.1 de la norma UNE EN 60068-2-6.

3.2.3.2.2. Choque.-

El equipo podr� soportar sin deformaci髇 o rotura golpes de 15 g de amplitud de aceleraci髇 con una forma de onda simisinusoidal durante 11 ms, seg鷑 la norma UNE EN 60068-2-27.

3.2.3.2.3. Estanqueidad.-

Deber� resistir los efectos del polvo y del agua, comprob醤dose que no penetren en el interior del ELB y puedan producir da駉s, para lo cual deber� tener el grado de protecci髇 IP65 seg鷑 la norma UNE-20-324-93.

3.2.3.2.4. Temperatura.-

El rango de temperatura de almacenamiento ser� de -40 篊 a 70 篊. El rango de temperatura de funcionamiento ser� de -20 篊 a 50 篊. Seg鷑 las normas UNE EN 60068-2-1 para fr韔 y la UNE EN 60068-2-2 para calor seco.

3.2.3.2.5. Humedad.-

El equipo soportar� exposiciones en ambientes con una humedad relativa de hasta el 95%, seg鷑 la norma UNE EN 60068-2-56.

3.2.3.2.6. Niebla salina.-

El equipo soportar� un ambiente de niebla salina como el descrito en la norma UNE EN 60068-2-11.

3.2.3.3. Compatibilidad electromagn閠ica.

Ser� aplicable la norma UNE EN 60945, con los siguientes criterios:

• c. Interferencia conducida: En la banda de frecuencias de 10 KHz a 30 MHz la tensi髇 de radiofrecuencia en los terminales de alimentaci髇 no exceder� los l韒ites descritos en la Figura 2 o Figura 3 de la norma.
• d. Interferencia radiada: El l韒ite de nivel de radiaci髇 emitida en el margen de frecuencias de 30 MHZ a 300 MHz no exceder� de 500 V/m excepto en la banda de frecuencias de 156 MHz a 165 MHz donde el nivel no exceder� de 15 V/m.
• e. Inmunidad a las se馻les de audiofrecuencia conducidas, con una se馻l interferente de 3 V eficaz en el rango de 50 Hz a 10 KHz en l韓eas de alimentaci髇; y de 1 V eficaz en el rango de 10 KHz a 50 KHz en el conductor de tierra.
• f. Inmunidad a las se馻les de radiofrecuencia conducidas, con una se馻l interferente de 1 V eficaz en el rango de 10 KHz a 50 KHz en l韓eas de alimentaci髇.
• g. Inmunidad radiada en el rango de 0.4 MHz a 300 MHz con una amplitud de campo de 1 V/m para el equipo instalado dentro de la estructura del buque.
• h. Inmunidad a transitorios de 100 ns de tiempo de subida, duraciones de 10 s y frecuencia de repetici髇 de 50 � 60 Hz en l韓eas de alimentaci髇.
• i. Inmunidad frente a descargas electrost醫icas.
• j. La norma UNE EN 60945 da la presunci髇 de conformidad de los requisitos esenciales enunciados en el art韈ulo 4 de la directiva 89/336/EEC.

3.2.3.4. Interfaces el閏tricos.

• 1. El equipo admitir� una alimentaci髇 el閏trica de 24 V, con variaci髇 desde 11 V a 30 V, en corriente continua. Siendo opcional que se pueda alimentar tambi閚 en corriente alterna a 220 V, con variaci髇 de 10 % y frecuencia entre 49 Hz y 51 Hz.
• 2. La caja azul dispondr� de una conexi髇 serie tipo RS-232C (38.4 Kbps, 8 bits de datos, bit de parada, sin paridad) accesible, mediante un conector hembra tipo SubD de 9 pines, que cumpla especificaciones mar韙imas, para permitir la descarga de los datos almacenados en la memoria. Esta misma conexi髇 se podr� utilizar para conectar el terminal externo opcional.
• 3. La conexi髇 entre la caja azul y la antena ser� mediante un cable del tipo RG-213 o similar pero sin conector en el extremo de la caja azul, esto es, mediante prensaestopas para evitar su f醕il desconexi髇.

3.2.3.4.1. Condiciones normales de alimentaci髇.-

El ELB podr� ser conectado a una tensi髇 continua de 24 V, con variaci髇 desde 11 V a 30 V o cualquier otro voltaje que est� dentro del rango anterior para el cual el equipo fue dise馻do. Opcionalmente el ELB podr� ser conectado a una tensi髇 alterna de 220 V con una tolerancia del 10 % y una frecuencia entre 49 Hz y 51 Hz.

3.2.3.4.2. Condiciones extremas de alimentaci髇.-

El ELB no debe ver degradadas sus condiciones de funcionamiento en condiciones extremas de alimentaci髇, esto es, 11 V y 30 V en corriente continua y opcionalmente, 198 V y 242 V en corriente alterna.

3.2.3.4.3. Conmutaci髇 entre alimentaciones.-

El equipo deber� ser capaz de conmutar entre la alimentaci髇 de 24 V en continua y de 220 V en alterna (si est� en opci髇) sin producirse p閞dida de alimentaci髇.

3.2.3.4.4. Condiciones normales de temperatura y humedad.-

El equipo ELB encontrar� sus condiciones de funcionamiento en cualquier combinaci髇 conveniente que est� dentro de los siguientes rangos:

• a) Temperatura: 15 篊 a 35 篊.
• b) Humedad relativa: Entre el 20% y el 75%.

3.2.3.4.5. Condiciones extremas de temperatura.

• 1. El ELB encontrar� sus condiciones de funcionamiento a las temperaturas extremas de operaci髇, que ser� de -20 篊 y 50 篊.
• 2. En el caso de la temperatura superior de 50 篊, una vez que 閟ta es alcanzada y est� estabilizada, el ELB ser� capaz de transmitir/recibir durante un tiempo de 30 minutos, sin que se degraden sus condiciones de funcionamiento.
• 3. En el caso de la temperatura inferior de -20 篊, una vez que 閟ta es alcanzada y est� estabilizada, el ELB podr� ser alimentado durante un tiempo de 5 minutos, sin que se degraden sus condiciones de funcionamiento.

3.2.3.5. Interfaces del operador.

• 1. La caja azul en su lado frontal dispondr� de los siguientes pulsadores o interruptores, etiquetados como se indica:
  • a) Encendido/Apagado: Un interruptor o pulsadores etiquetados con las palabras ENCENDIDO/APAGADO, que deber� enviar el mensaje descrito en 3.2.5.1.2.5 cuando se act鷈 el encendido, y el mensaje descrito en 3.2.5.1.2.4 cuando se act鷈 el apagado.
  • b) Pesca: Un interruptor o pulsadores etiquetados con la palabra PESCA: ACTIVO, que deber� enviar el mensaje descrito en 3.2.5.1.2.1 cuando se act鷈 comienzo de actividad de pesca, y con la palabra PESCA: PASIVO, el mensaje descrito en 3.2.5.1.2.2 cuando se act鷈 fin de actividad de pesca.
  • c) Cruce: Un pulsador etiquetado con la palabra CRUCE, que deber� enviar el mensaje descrito en 3.2.5.1.2.3 cada vez que sea pulsado por el capit醤 o patr髇.
• 2. La caja azul dispondr� de una indicaci髇 luminosa cuando la actividad de pesca est� habilitada.
• 3. La caja azul dispondr� de una indicaci髇 luminosa cuando el equipo est� funcionando.

3.2.4. Requisitos de instalaci髇.

3.2.4.1. General.

• 1. Los ELBs deber醤 ser instalados solamente por personal formalmente designado por el fabricante del equipo y autorizado por la DGRPYA. Todas las operaciones de instalaci髇 podr醤 ser supervisadas por inspectores de la DGRPYA. La sujeci髇 del ELB al buque ser� la adecuada para uso mar韙imo, teniendo en cuenta condiciones de vibraci髇 propias de un buque.
• 2. En el caso de que no se pueda cumplir alguno de estos requisitos de instalaci髇, se pedir� autorizaci髇 a la DGRPYA para realizar una instalaci髇 diferente.
• 3. La instalaci髇 se har� de acuerdo con el documento de instalaci髇 proporcionado por el fabricante para la autorizaci髇 del ELB.

3.2.4.2. Caja azul.

• 1. La caja azul deber� ser instalada en zona protegida del puente o derrota, de manera que: sea directamente visible por el personal de guardia, est� protegida de los elementos atmosf閞icos, no sufra interferencias de la operaci髇 de otros equipos embarcados y no interfiera con las operaciones de seguridad del buque.
• 2. La sujeci髇 de la caja azul podr� ser tanto a una superficie horizontal como vertical, mediante tornillos pasantes en n鷐ero y m閠rica adecuados al peso de la caja. La superficie de sujeci髇 deber� ser estructural del buque, de manera que no sea f醕il su separaci髇.
• 3. Se deber� prever la instalaci髇 de al menos dos precintos de alambre pl醩tico u otro material adecuado para denotar su separaci髇 fraudulenta del buque. Igualmente, se deber� prever la instalaci髇 del mismo tipo de precintos para evitar la apertura fraudulenta de la caja azul o antena.

3.2.4.3. Antena.

• 1. La antena deber� ser fijada a una parte estructural del buque y su posici髇 debe ser tal que: tenga acceso a cielo abierto sin ser obstruido sus diagrama de radiaci髇 por ninguna parte del buque, no sufra interferencias de la operaci髇 de otros equipos embarcados y no interfiera con las operaciones de seguridad del buque.
• 2. La antena deber� ser instalada en un lugar donde las personas no puedan recibir niveles de radiaci髇 electromagn閠ica peligrosos, mientras desarrollan las normales actividades del buque.
• 3. En el caso de que est閚 integrados en el bloque de la antena el receptor de GPS y el transceptor de Inmarsat C, se deber� prever un sistema adecuado para evitar la apertura fraudulenta del bloque de la antena.

3.2.4.4. Cableado.

• 1. El cable que une la antena con la caja azul deber� ser el definido por el fabricante, no pudiendo exceder la longitud m醲ima establecida en el manual de instalaci髇. Deber� ser colocado de forma que no sea da馻do durante la normal actividad del buque.
• 2. Se deber醤 permitir todos los requisitos de puesta a tierra de la antena como especifique el fabricante.
• 3. La conexi髇 del cable con la caja azul deber� ser a trav閟 de pasamuros con prensaestopas para asegurar la estanqueidad y la desconexi髇 fraudulenta.

3.2.4.5. Instalaci髇 el閏trica.

• 1. El ELB se deber� conectar a una alimentaci髇 el閏trica que no se vea sujeta a fluctuaciones en voltaje que puedan causar condiciones de reset o da駉s al ELB.
• 2. El ELB deber� ser conectado a dos fuentes de potencia, siendo una de ellas, las bater韆s de emergencia.

3.2.5. Mensajes.

3.2.5.1. Mensajes del ELB al CSP.

En este apartado se definen los mensajes autom醫icos y manuales que debe ser capaz de enviar el ELB al CSP.

3.2.5.1.1. Mensajes autom醫icos.-

Los mensajes autom醫icos son aquellos que para ser generados por el ELB no necesitan acci髇 alguna por parte del capit醤 o patr髇.

A continuaci髇 se describen dichos mensajes:

3.2.5.1.1.1. Mensaje de posici髇 peri骴ico.

• 1. El ELB debe ser capaz de enviar informes de posici髇 a intervalos prefijados por el CSP, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. La periodicidad estar� comprendida entre 15 minutos y 24 horas, con intervalos que se ajusten a los definidos en el SDM de Inmarsat.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para fijar los intervalos, ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.3 de esta especificaci髇 t閏nica.
• 4. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en el apartado 3.2.6.2 de esta especificaci髇 t閏nica.
• 5. El formato del comando de interrogaci髇 enviado por el CSP para fijar los intervalos, ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.3 de esta especificaci髇 t閏nica.
• 6. El formato del comando de interrogaci髇 enviado por el CSP para comenzar el env韔 de mensajes de posici髇 peri骴icos, ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.4 de esta especificaci髇 t閏nica.
• 7. El formato del comando de interrogaci髇 enviado por el CSP para parar el env韔 de mensajes de posici髇 peri骴icos, ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.5 de esta especificaci髇 t閏nica.

3.2.5.1.1.2. Mensaje de 鷏tima posici髇.

• 1. El ELB debe ser capaz de enviar informes de posici髇 a petici髇 del CSP, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en el apartado 3.2.6.2 de esta especificaci髇 t閏nica.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un informe de posici髇 ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.1 de esta especificaci髇 t閏nica.

3.2.5.1.1.3. Volcado de posiciones.

• 1. El ELB debe ser capaz de enviar todas las posiciones almacenadas durante un intervalo de tiempo determinado a petici髇 del CSP.
• 2. Para ello, el ELB debe ser capaz de almacenar en una memoria interna las posiciones con una periodicidad de 10 minutos durante 6 meses.
• 3. La informaci髇 a almacenar en memoria y a enviar al CSP ser� la siguiente:
  • a. Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • b. Latitud.
  • c. Longitud.
  • d. Rumbo actual.
  • e. Velocidad actual.
  • f. Actividad (pesca/no pesca).
  • g. Se馻l de antena.
  • h. Corriente de antena.
• 4. El formato de este mensaje ser� el formato tipo almacenamiento y retransmisi髇 (store and forward) definido en el apartado 3.2.6.4 de esta especificaci髇 t閏nica.
• 5. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un volcado de posiciones ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.2 de esta especificaci髇 t閏nica.

3.2.5.1.1.4. Reconocimiento de haber recibido un mensaje del CSP.

• 1. Bajo determinadas circunstancias, el ELB puede ser requerido para que env韊 un mensaje independiente de reconocimiento de haber recibido correctamente el comando enviado por el CSP, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El formato de este mensaje ser� el formato tipo informe de posici髇 de reconocimiento (acknowledgement data report) definido en el apartado 3.2.6.2.1 de esta especificaci髇 t閏nica.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un informe de posici髇 de reconocimiento, ser� el formato tipo interrogaci髇 (polling packet format) definido en el apartado 3.2.6.3.9 de esta especificaci髇 t閏nica.

3.2.5.1.1.5. Apagado anormal del ELB.

• 1. El ELB debe ser capaz de enviar solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un mensaje cuando se apaga anormalmente, sin previo aviso, esto es, sin haberse pulsado el pulsador ENCENDIDO/APAGADO, (por ejemplo, se ha perdido la potencia el閏trica por alg鷑 motivo), utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. Dicho mensaje debe enviarse en el momento en que se recupere la alimentaci髇, debiendo identificar dicho evento, mediante un mensaje de apagado anormal.
• 3. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en el apartado 3.2.6.2 de esta especificaci髇 t閏nica, incluyendo el mensaje macrocodificado (MEM) 41 (hex) para indicar que es un informe de apagado anormal, incluyendo la informaci髇 del buque en el momento que se produjo el apagado.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.2.5.1.1.6. Desconexi髇 de la antena.

• 1. Cuando la funcionalidad del ELB lo permita, debe ser capaz de enviar autom醫icamente solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 junto con una identificaci髇 del evento desconexi髇 de antena (corriente de antena nula), utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la corriente de la antena.
• 3. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 42 (hex) para indicar que es un informe de posici髇 por desconexi髇 de antena, incluyendo la informaci髇 del buque en el momento en que se produjo la desconexi髇.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.2.5.1.1.7. Bloqueo de la antena.

• 1. El ELB debe ser capaz de enviar autom醫icamente solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 junto con una identificaci髇 del evento bloqueo de antena (conexi髇 con el sat閘ite defectuosa), utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la calidad de la se馻l de la antena.
• 3. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 43 (hex) para indicar que es un informe de posici髇 por bloqueo de la antena, incluyendo la informaci髇 del buque en el momento en que se produjo el bloqueo.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.2.5.1.1.8. Mensajes de respuesta a interrogaciones incorrectas.

• 1. El equipo llevar� registro interno de los tiempos final, T_f, e inicial, T_i, de los l韒ites de los registros en la memoria c韈lica interna.
• 2. Se considera correcto un mensaje de interrogaci髇 de memoria cuando se cumple:

  

• 3. Si el 鷏timo mensaje de interrogaci髇 de memoria no es correcto bajo el criterio anterior, el equipo emitir� por el puerto de comunicaciones local un mensaje de respuesta, con el formato que se indica en el apartado 3.2.6.5.1.

3.2.5.1.2. Mensajes por accionamiento de pulsadores.

• 1. Los mensajes manuales deben ser transmitidos por el ELB al actuar el capit醤 o patr髇 sobre uno o varios de los pulsadores localizados en su frontal.
• 2. A continuaci髇 se describen dichos mensajes.

3.2.5.1.2.1. Comienzo de pesca.

• 1. El ELB debe enviar solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 junto con una identificaci髇 del evento actividad de pesca al pulsar el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra PESCA: ACTIVO, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 45 (hex) para indicar que es un informe de posici髇 de comienzo de pesca, junto con la activaci髇 (nivel l骻ico 1) a partir de ese momento en los sucesivos informes de posici髇 del bit actividad de pesca para indicar que el buque se encuentra en actividad de pesca.

3.2.5.1.2.2. Fin de pesca.

• 1. El ELB debe enviar solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 junto con una identificaci髇 del evento no actividad de pesca al pulsar el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra PESCA: PASIVO, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 46 (hex) para indicar que es un informe de posici髇 de fin de pesca, junto con la desactivaci髇 (nivel l骻ico 0) a partir de ese momento en los sucesivos informes de posici髇 del bit actividad de pesca para indicar que el buque no se encuentra en actividad de pesca.

3.2.5.1.2.3. Cruce.

• 1. El ELB debe enviar solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 actual al pulsar el capit醤 o patr髇 el pulsador nombrado con la palabra CRUCE, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 47 (hex) para indicar que es un informe de posici髇 de cruce.

3.2.5.1.2.4. Apagado normal.

• 1. El ELB debe ser capaz de enviar solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de posici髇 junto con una identificaci髇 del evento apagado normal cuando el capit醤 o patr髇 lo apaga pulsando el bot髇, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. Para ello deber� pulsar el pulsador nombrado con las palabras ENCENDIDO/APAGADO. Esta acci髇 del operador debe producir el env韔 al CSP del informe de posici髇 junto con una identificaci髇 del evento apagado normal y apagar de forma autom醫ica el ELB.
• 3. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en la secci髇 3.2.6.2 de esta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Macrocodificado (MEM) 44 (hex) para indicar que es un informe de apagado normal.

3.2.5.1.2.5. Encendido del ELB.

• 1. El ELB debe ser capaz de enviar autom醫icamente solamente al DNID principal de la regi髇 oce醤ica en la que se encuentre un informe de la posici髇 actual inmediatamente despu閟 de ser encendido, utilizando el acceso no reservado sobre el canal de informes de datos.
• 2. Para ello, el capit醤 o patr髇 deber� pulsar el pulsador nombrado con las palabras ENCENDIDO/APAGADO.
• 3. El formato de este mensaje ser� el formato tipo informe de posici髇 (position report) definido en el apartado 3.2.6.2 de esta especificaci髇 t閏nica, incluyendo el mensaje macrocodificado (MEM) 40 (hex) para indicar que es un informe de posici髇 de encendido.

3.2.5.1.3. Uso de cifrado en el ELB.

• 1. La protecci髇 de la informaci髇 a transmitir del ELB al CSP mediante el uso de cifrado no es una caracter韘tica requerida por esta especificaci髇.
• 2. Sin embargo, si alg鷑 fabricante determinara incluir esta funcionalidad en sus equipos, deber� atenerse a los siguientes requisitos, impuestos por la necesidad de utilizar un m閠odo 鷑ico en toda la red de ELB.
• 3. Se distinguir醤 con un n鷐ero de modelo propio aquellos equipos que cifren sus comunicaciones, sin que esta funcionalidad sea reversible en los mismos.
• 4. Se podr醤 cifrar 鷑icamente los campos de datos o definidos por el usuario de los correspondientes mensajes en el SDM y en esta especificaci髇, manteniendo compatible e inalterada la cabecera y c骴igos de chequeo de los mensajes data report y store and forward.
• 5. El m閠odo de cifrado ser� de clave sim閠rica, y en particular se utilizar� el algoritmo DES (Data Encryption Standard), combinado en modo triple, DES3, y output feedback, con la cabecera no cifrada de cada mensaje a modo de vector de inicializaci髇, en sus 64 bits menos significativos.
• 6. Se llevar� a cabo respetando lo contenido en los siguientes documentos:
  • i. ANSI X3.92 American National Standard for Data Encryption Algorithm (DEA), American National Standards Institute, 1981.
  • j. ANSI X3.106 American National Standard for Information Systems-Data Encryption Algorithm Modes of Operation, American National Standards Institute, 1983.
  • k. ISO IEC 9594-8/ITU-T X.509, Information Technology-Open Systems Interconnection-The Directory: Authentication Framework.
  • l. FIPS PUB 140-1, Security Requirements for Cryptographic Modules, 1993.
• 7. Generaci髇 de claves:
  • m. Randomness Recommendations for Security, RFC 1750, Donald Eastlake, Stephen Crocker, Jeffrey Schiller, 1994.
  • n. Cryptographic Random Numbers, IEEE P1363 Appendix E, Draft version 1.0, 11, 1995.
• 8. La clave privada de cada ELB ser� registrada en el mismo de forma electr髇ica, no vol醫il, y de manera inaccesible bajo ninguna operaci髇 de despiece, lectura de memorias en banco de ensayo, o interrogaci髇 por comunicaciones remotas o locales. El equipo no facilitar� mecanismo alguno para el cambio del valor de esta clave.
• 9. Cada fabricante deber� entregar a la DGRPYA la relaci髇 de claves y n鷐eros de serie de los equipos con anterioridad a su entrada en servicio.
• 10. Los mensajes salientes del ELB, en los equipos que incorporen cifrado, se encriptar醤 utilizando el m閠odo anteriormente descrito, y con la clave privada del mismo.
• 11. Aquellos equipos que no incorporen el cifrado de las comunicaciones, deber醤 llevar registrado en el mismo un n鷐ero aleatorio de 1024 bits, de forma electr髇ica, no vol醫il, y de manera inaccesible bajo ninguna operaci髇 de despiece, lectura de memorias en banco de ensayo, o interrogaci髇 por comunicaciones remotas o locales. El equipo no facilitar� mecanismo alguno para el cambio del valor de este n鷐ero.
• 12. La generaci髇 de este n鷐ero deber� respetar lo contenido en los siguientes documentos:
  • a) Randomness Recommendations for Security, RFC 1750, Donald Eastlake, Stephen Crocker, Jeffrey Schiller, 1994.
  • b) Cryptographic Random Numbers, IEEE P1363 Appendix E, Draft version 1.0, 11, 1995.
• 13. Cada fabricante deber� entregar a la DGRPYA la relaci髇 de n鷐eros aleatorios internos y n鷐eros de serie de los equipos con anterioridad a su entrada en servicio.

3.2.5.2. Mensajes del CSP al ELB.

En este apartado se definen los mensajes que deben ser capaces de ser aceptados por el ELB. Dichos mensajes ser醤 generados por el CSP.

3.2.5.2.1. Petici髇 de 鷏tima posici髇.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de 鷏tima posici髇.
• 2. El formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇 ser� el definido en el apartado 3.2.6.3.1 de esta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un informe de 鷏tima posici髇, definido en el apartado 3.2.5.1.1.2 de esta especificaci髇 t閏nica.

3.2.5.2.2. Petici髇 de volcado de posiciones.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de volcado de posiciones entre dos tiempos determinados.
• 2. El formato del comando de interrogaci髇 de petici髇 de volcado de posiciones ser� el definido en el apartado 3.2.6.3.2 de esta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un mensaje del tipo almacenamiento y retransmisi髇 (store and forward) definido en el apartado 3.2.6.4 de esta especificaci髇 t閏nica, que contenga la informaci髇 de posici髇 de todas las posiciones almacenadas entre dichos tiempos.
• 4. La informaci髇 a almacenar en memoria y a enviar al CSP ser� la siguiente:
  • a) Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • b) Latitud.
  • c) Longitud.
  • d) Rumbo.
  • e) Velocidad.
  • f) Actividad (pesca/no pesca).
  • g) Se馻l de antena.
  • h) Corriente de antena.

3.2.5.2.3. Petici髇 de cambio de intervalos de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de cambio del intervalo de env韔 de informes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 de petici髇 de cambio de intervalos de env韔 de informes de posici髇 peri骴icos ser� el definido en el apartado 3.2.6.3.3 de esta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un mensaje de reconocimiento de haber recibido correctamente el comando enviado por el CSP.
• 4. El formato de este mensaje de reconocimiento ser� el formato tipo informe de posici髇 de reconocimiento (acknowledgement data report) definido en el SDM.

3.2.5.2.4. Petici髇 de comienzo de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de comenzar el env韔 de mensajes de posici髇 peri骴icos al recibir un comando para comenzar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para comenzar el env韔 de mensajes de posici髇 peri骴icos ser� el definido en el apartado 3.2.6.3.4 de esta especificaci髇 t閏nica.

3.2.5.2.5. Petici髇 de parar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de parar el env韔 de mensajes de posici髇 peri骴icos al recibir un comando para parar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para parar el env韔 de mensajes de posici髇 peri骴icos ser� el definido en el apartado 3.2.6.3.5 de esta especificaci髇 t閏nica.

3.2.5.2.6. Petici髇 de carga de DNID.

• 1. El ELB debe llevar implementada la capacidad de que le sea cargado un DNID al recibir un comando para cargar DNID.
• 2. La DGRPYA asignar� un DNID principal de entre todos aquellos cargados en el ELB por cada regi髇 oce醤ica en la que vaya a encontrarse el buque. Solamente a 閟te DNID principal deber醤 ir los informes de posici髇 generados por el ELB definidos en los apartados 3.2.5.1.1.5, 3.2.5.1.1.6, 3.2.5.1.1.7, 3.2.5.1.2.1, 3.2.5.1.2.2, 3.2.5.1.2.3, 3.2.5.1.2.4 y 3.2.5.1.2.5 de esta especificaci髇 t閏nica.
• 3. El formato del comando de interrogaci髇 para cargar DNID ser� el definido en el apartado 3.2.6.3.6 de esta especificaci髇 t閏nica.

3.2.5.2.7. Petici髇 de borrar DNID.

• 1. El ELB debe llevar implementada la capacidad de que le sea borrado un DNID al recibir un comando para borrar DNID.
• 2. El formato del comando de interrogaci髇 para borrar DNID ser� el definido en el apartado 3.2.6.3.7 de esta especificaci髇 t閏nica.

3.2.5.2.8. Petici髇 de recepci髇 de datos.

• 1. Opcionalmente, el ELB puede llevar implementada la capacidad de recibir datos al recibir un comando para transmitir datos al ELB.
• 2. El formato del comando de interrogaci髇 para transmitir datos a un ELB ser� el definido en el apartado 3.2.6.3.8 de esta especificaci髇 t閏nica.

3.2.5.2.9. Petici髇 de reconocimiento.

• 1. El ELB debe llevar implementada la capacidad de enviar un mensaje independiente de reconocimiento al recibir un comando que solicite reconocimiento.
• 2. El formato del comando de interrogaci髇 para solicitar reconocimiento ser� el definido en el apartado 3.2.6.3.9 de esta especificaci髇 t閏nica.

3.2.6. Formato de los mensajes.

3.2.6.1. General.

• 1. En esta secci髇 se definen los diferentes formatos de los mensajes que el ELB debe generar o recibir.
• 2. Dichos mensajes son los de posici髇, los de comando de interrogaci髇 y los de almacenamiento y retransmisi髇.
• 3. Para ello, a la hora de definir los formatos se hace referencia a diferentes secciones del Inmarsat-C System Definition Manual (SDM), versi髇 3.0, CD003, Marzo 2002.

3.2.6.2. Formato de los mensajes de posici髇.

• 1. El formato de los mensajes o informes de posici髇 a enviar sobre el canal de informes de datos (signalling channel) utilizando el acceso no reservado, ser� el definido en el SDM con el nombre de Data Report/Maritime Position Report.
• 2. La informaci髇 m韓ima que debe contener cada mensaje o informe de posici髇 debe ser la siguiente:
  • a. Identidad del ELB.
  • b. Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • c. Latitud (hemisferio, grados, minutos y fracci髇 de minutos en unidades de 0.04 de minuto).
  • d. Longitud (hemisferio, grados, minutos y fracci髇 de minutos en unidades de 0.04 de minuto).
  • e. Rumbo (resoluci髇 de 1 grado).
  • f. Velocidad (resoluci髇 de 0.2 nudos y rango de 0 a 51.2 nudos).
  • g. Actividad (pesca/no pesca).
    
    El bit de actividad estar� posicionado dentro del Maritime Position Report en el bit n.� 8 del byte 6 del First Continuation Packet.
• 3. La fecha y la hora se posicionar� dentro del Maritime Position Report de la siguiente forma:
  • a) A駉 (valores posibles del 0 al 4095): 12 bits, posicionados del bit n.� 7 (MSB) del byte 6 al bit n.� 4 (LSB) del byte 7 del First Continuation Packet.
  • b) Mes (valores del 1 al 12): 4 bits, posicionados del bit n.� 3 (MSB) del byte 7 al bit n.� 8 (LSB) del byte 8 del First Continuation Packet.
  • c) D韆 (valores del 1 al 31): 5 bits, posicionados del bit n.� 7 (MSB) al bit n.� 3 (LSB) del byte 8 del First Continuation Packet.
  • d) Hora (valores del 0 al 23): 5 bits, posicionados del bit n.� 2 (MSB) del byte 8 al bit n.� 6 (LSB) del byte 9 del First Continuation Packet.
  • e) Minutos (valores del 0 al 59): 6 bits, posicionados del bit n.� 5 (MSB) del byte 9 al bit n.� 8 (LSB) del byte 10 del First Continuation Packet.
• 4. La posici髇 del resto de los campos de informaci髇 dentro del Maritime Position Report est� espec韋icamente definida en el SDM.

3.2.6.2.1. Formato de los informes de posici髇 de reconocimiento.

El formato de los informes de posici髇 de reconocimiento ser� el definido en el SDM con el nombre de acknowlegment Data Report.

3.2.6.3. Formatos de los mensajes de comando de interrogaci髇 (Polling Commands).

A continuaci髇 se definen los formatos de los diferentes mensajes de comando de interrogaci髇 generados por el CSP.

3.2.6.3.1. Formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de 鷏tima posici髇.
• 2. El formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇 ser� el Polling Packet Format definido para el comando tipo 00H, tal y como se define en el SDM.

3.2.6.3.2. Formato del comando de interrogaci髇 de petici髇 de volcado de posiciones.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de volcado de posiciones.
• 2. El formato del comando de interrogaci髇 de petici髇 de volcado de posiciones entre dos tiempos ser� el Polling Packet Format definido para el comando tipo 40H, tal y como se define en el SDM, con la codificaci髇 10B en el campo Response para indicar que el tipo de respuesta esperada es un mensaje del tipo almacenamiento y retransmisi髇 (store and forward), y con los datos descritos a continuaci髇 dentro del campo Command Specific Parameters, que indican el tiempo inicial, el tiempo final, per韔do de muestreo y los campos que se quieren volcar.
• 3. Fecha y hora inicial de la consulta; t_i.
  
  32 bits, posicionados desde el bit n.8 (MSB) del byte n.1 al bit n.1 (MSB) del byte n.4 del campo Command Specific Parameters.
  
  La estructura y subcampos de fecha y hora, tal y como se definen en el apartado 3.2.6.2.
• 4. Fecha y hora final de la consulta; t_f.
  
  32 bits, posicionados desde el bit n.8 (MSB) del byte n.5 al bit n.1 (MSB) del byte n.8 del campo Command Specific Parameters.
  
  La estructura y subcampos de fecha y hora, tal y como se definen en el apartado 3.2.6.2.
• 5. Per韔do de la consulta; t_m.
  
  Meses (valores de 0 a 6): 3 bits, posicionados desde el bit n.8 (MSB) del byte n.9 al bit n.6 (MSB) del byte n.9 del campo Command Specific Parameters.
  
  D韆s (valores de 0 a 7): 3 bits posicionados desde el bit n.5 (MSB) del byte n.9 al bit n.3 (MSB) del byte n.9 del campo Command Specific Parameters.
  
  Horas (valores de 0 a 24): 5 bits posicionados desde el bit n.2 (MSB) del byte n.9 al bit n.6 (MSB) del byte n.10 del campo Command Specific Parameters.
  
  Minutos (valores de 0 a 60): 6 bits posicionados desde el bit n.5 (MSB) del byte n.10 al bit n.8 (MSB) del byte n.11 del campo Command Specific Parameters.
• 6. Formato de la consulta:
  • a) Posici髇 requerida; p.
    
    1 bit, posicionado en el bit n.7 del byte n.11 del campo Command Specific Parameters.
  • b) Rumbo requerido; r.
    
    1 bit, posicionado en el bit n.6 del byte n.11 del campo Command Specific Parameters.
  • c) Velocidad requerida; v.
    
    1 bit, posicionado en el bit n.5 del byte n.11 del campo Command Specific Parameters.
  • d) Actividad requerida; a
    
    1 bit, posicionado en el bit n.4 del byte n.11 del campo Command Specific Parameters.
  • e) Estado de la antena requerido; ea.
    
    1 bit, posicionado en el bit n.3 del byte n.11 del campo Command Specific Parameters.
  • f) Valor de corriente de la antena requerido; ca.
    
    1 bit, posicionado en el bit n.2 del byte n.11 del campo Command Specific Parameters.

  Un valor de 1 en cualquiera de los bits de este campo indicar� la necesidad de incluir la informaci髇 a que hace referencia en el resultado de la consulta requerida. Un valor de 0 en cualquiera de los bits de este campo indicar� que se debe excluir del resultado de la consulta requerida la informaci髇 a que hace referencia el bit de formato.

3.2.6.3.3. Formato del comando de interrogaci髇 para programar intervalos de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de que se le programen los intervalos de env韔 de mensajes de posici髇 peri骴icos mediante un comando para programar intervalos de env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para programar el intervalo de env韔 de mensajes de posici髇 peri骴icos ser� el Polling Packet Format definido para el comando tipo 04H, tal y como se define en el SDM.
• 3. Este comando de interrogaci髇 debe solicitar tambi閚 reconocimiento al ELB, por lo que el bit de reconocimiento (Ack) debe estar siempre activado.

3.2.6.3.4. Formato del comando de interrogaci髇 para comenzar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de comenzar el env韔 de mensajes de posici髇 peri骴icos mediante un comando para comenzar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para que el ELB comience a enviar mensajes de posici髇 peri骴icos con el intervalo programado ser� el Polling Packet Format definido para el comando tipo 05H, tal y como se define en el SDM.

3.2.6.3.5. Formato del comando de interrogaci髇 para parar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de parar el env韔 de mensajes de posici髇 peri骴icos mediante un comando para parar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para que el ELB pare de enviar mensajes de posici髇 peri骴icos con el intervalo programado ser� el Polling Packet Format definido para el comando tipo 06H, tal y como se define en el SDM.

3.2.6.3.6. Formato del comando de interrogaci髇 para cargar DNID.

• 1. El ELB debe llevar implementada la capacidad de que le sea cargado un DNID mediante un comando para cargar DNID.
• 2. El formato del comando de interrogaci髇 para cargar un DNID a un ELB ser� el Polling Packet Format definido para el comando tipo 0AH, tal y como se define en el SDM.
• 3. Al cargar en el ELB el DNID principal, y para que el ELB pueda identificarlo como tal, se a馻dir� el car醕ter ^aA^o en la posici髇 25 del campo ^aFree Fieldo del polling utilizando el formato indicado en el SDM.

3.2.6.3.7. Formato del comando de interrogaci髇 para borrar DNID.

• 1. El ELB debe llevar implementada la capacidad de que le sea borrado un DNID mediante un comando para borrar DNID.
• 2. El formato del comando de interrogaci髇 para borrar un DNID a un ELB ser� el Polling Packet Format definido para el comando tipo 0BH, tal y como se define en el SDM.

3.2.6.3.8. Formato del comando para transmitir datos.

• 1. Opcionalmente el ELB puede llevar implementada la capacidad de recibir datos a trav閟 de un comando para transmitir datos.
• 2. El formato del comando de interrogaci髇 para enviar datos a un ELB ser� el Polling Packet Format definido para el comando tipo 09H, tal y como se define en el SDM.

3.2.6.3.9. Formato del comando de interrogaci髇 para solicitar reconocimiento.

• 1. El ELB debe llevar implementada la capacidad de enviar un mensaje independiente de reconocimiento de haber recibido correctamente el comando para solicitar reconocimiento.
• 2. El formato del comando de interrogaci髇 para solicitar reconocimiento ser� el Polling Packet Format con el bit de reconocimiento (Ack) activado, tal y como se define en el SDM.
• 3. Todos los pollings, pueden llevar implementada esta capacidad.

3.2.6.4. Formato de los mensajes del tipo almacenamiento y retransmisi髇 (store and forward).

El ELB debe ser capaz de enviar mensajes conteniendo informaci髇 al CSP, sobre el canal de mensajes (message channel) utilizando los paquetes de mensajes, tal y como se define en el SDM.

3.2.6.4.1. Formato de los mensajes de volcado de memoria.

• 1. El ELB responder� con este mensaje a una petici髇 de volcado de posiciones, tal y como se define en (6.2.6.3.2).
• 2. La direcci髇 de destino ser� el mismo DNID del comando que hace la petici髇 de volcado.
• 3. Si el tama駉 del volcado requerido excediera el tama駉 m醲imo que el ELB, o el sistema de comunicaciones en su conjunto, sea capaz de transmitir, el ELB generar� cuantos mensajes store and forward del tipo aqu� definido sean necesarios para remitir la totalidad del resultado del volcado.
• 4. La siguiente informaci髇, de tama駉 variable en funci髇 de los par醡etros de la consulta, formar� el campo data del mensaje store and forward.
• 5. Se define un paquete singular de volcado como la concatenaci髇 de los siguientes campos:
  
  [CPS1] Posici髇 del buque, si p=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  39 bits, tal y como se definen en el apartado 2.4.2 del SDM.
  
  [CPS2] Rumbo del buque, si r=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  9 bits, tal y como se definen en el apartado 2.4.3 del SDM.
  
  [CPS3] Velocidad del buque, si v=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  8 bits, tal y como se definen en el apartado 2.4.3 del SDM.
  
  [CPS4] Actividad del buque, si a=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  1 bit, seg鷑 se define en (3.2.5.2.2).
  
  [CPS5] Estado de la antena, si ea=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  3 bits, que definen 8 valores cualitativos de la calidad de la se馻l de la antena, variando de 000 Sin se馻l a 111 Se馻l m醲ima.
  
  [CPS6] Corriente de la antena, si ca=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (6.2.6.3.2).
  
  1 bit, indicando 0 sin corriente y 1 con corriente.
  
  [CPS7] Fecha y hora de la grabaci髇 en memoria de los datos anteriores.
  
  32 bits, seg鷑 se define en (3.2.6.3.2).
• 6. Si el formato de volcado requerido omite alguno de los datos anteriores, el paquete singular se reducir� en el tama駉 de los campos omitidos. En cualquier caso, el orden de empaquetamiento se mantendr� seg鷑

  

  
  
  donde P(ps) denota el 韓dice de la palabra que almacena el campo singular ps.
• 7. Un mensaje de volcado de memoria contendr� la siguiente informaci髇:
  
  Fecha y hora inicial de los datos del volcado. 32 bits, seg鷑 se define en (3.2.6.3.2).
  
  Fecha y hora final de los datos del volcado. 32 bits, seg鷑 se define en (3.2.6.3.2).
  
  Per韔do del volcado. 17 bits, seg鷑 se define en (3.2.6.3.2).
  
  Formato de la informaci髇 volcada. 6 bits, seg鷑 se define en (3.2.6.3.2).
• 8. Aquellos paquetes cuya secuencia de tiempos garantiza el mayor ajuste posible a la frecuencia de muestreo requerida. Si tr es la fecha de un dato en memoria, se incluir� la secuencia de posiciones cuyos tiempos vienen dados por:
  • a. Primera posici髇, aquella cuyo tiempo de registro, tr0, es el m醩 pr髕imo a t_i.
  • b. Siguientes posiciones, aquellas cuyo tiempo de registro tr_k cumple:

    

  b) tr_k < = t_f

  
  
  y donde tr^(k-1) es el tiempo de registro de la posici髇 anterior en la secuencia.a

3.2.6.5. Formato de los mensajes de error.

3.2.6.5.1. Formato del mensaje de error en interrogaci髇 de memoria.

Ante una solicitud de volcado de posiciones, y en el caso de no ser correcta seg鷑 los criterios indicados en (3.2.5.1.1.8), el ELB emitir� por el puerto de comunicaciones local el siguiente mensaje:

153 bits formados por:

Copia del mensaje de interrogaci髇 recibido, seg鷑 se define en (3.2.6.3.2): 87 bits.

Indicaci髇 del error: 2 bits, indicando

00 si no se cumple T_i. ≤ t_i < t_f ≤ T_f

01 si no se cumple t_m. ≤ (t_f -t_i)

11 si no se cumple p + r + v + a + ea + ca ≠ 0

T_i 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.2.6.2).

T_f 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.2.6.2).

3.2.7. Protocolo de identificaci髇 del inspector para el volcado de posiciones de memoria.

El proceso de identificaci髇 del terminal del inspector se regir� por el siguiente protocolo:

• a) Equipos sin cifrado. El ELB generar� un n鷐ero aleatorio, de 1024 bits, que transmitir� por el puerto de comunicaciones local.
  
  El equipo del inspector realizar� el c醠culo de la funci髇 de 鷑ico sentido al resultado de concatenar los 1024 bits definidos en (3.2.5.1.3) al n鷐ero anterior, definida por el algoritmo MD5, tal y como se detalla en: RFC 1321, The MD5 Message Digest Algorithm, Ronald Rivest, 1992.
  
  El resultado de dicho c醠culo, de 128 bits, es recibido por el ELB, que deber� comprobar su validez:
  
  Si resultara correcto, proceder� a la aceptaci髇 de un mensaje de formato (3.2.6.3.2) Mensaje de interrogaci髇 de memoria, y a la transmisi髇 por el puerto de comunicaciones local de la informaci髇 requerida.
  
  Si resultara incorrecto, se bloquear醤 las comunicaciones por el puerto de comunicaciones local por tres minutos, transcurridos los cuales se restituir� el modo de operaci髇 normal.
• b) Equipos con cifrado. El ELB generar� un n鷐ero aleatorio, de 1024 bits, que transmitir� por el puerto de comunicaciones local.
  
  El equipo del inspector cifrar� este mensaje utilizando la clave privada del equipo.
  
  El resultado de dicho c醠culo, de 1024 bits, es recibido por el ELB, que deber� comprobar su validez, descifrando el mensaje y verificando que obtiene de vuelta el n鷐ero aleatorio original:
  
  Si resultara correcto, proceder� a la aceptaci髇 de un mensaje de formato (3.2.6.3.2) Mensaje de interrogaci髇 de memoria, y a la transmisi髇 por el puerto de comunicaciones local de la informaci髇 requerida.
  
  Si resultara incorrecto, se bloquear醤 las comunicaciones por el puerto de comunicaciones local por tres minutos, transcurridos los cuales se restituir� el modo de operaci髇 normal.

3.2.8. Limitaci髇 del n鷐ero de c骴igos DNID.

• 1. El n鷐ero de c骴igos DNID que cada caja azul puede recibir y cargar seg鷑 el est醤dar Inmarsat se limitar� a un valor de entre uno a diecis閕s, determinado por la DGRPYA para cada buque antes de la entrada en servicio del equipo.
• 2. La configuraci髇 particular de cada caja azul se realizar� mediante interruptores o conectores internos al equipo y no accesibles desde su exterior sin violar los precintos indicados en el apartado 3.2.4.2 de 閟ta especificaci髇 t閏nica.
• 3. El sistema de limitaci髇 deber� cumplir lo siguiente:
  • a) La codificaci髇 de los interruptores o conectores estar� indicada mediante un esquema o croquis, visible 鷑icamente al abrir la caja azul.
  • b) La limitaci髇 del n鷐ero de c骴igos DNID estar� configurada de serie a dos c骴igos.
  • c) No se podr� modificar el n鷐ero l韒ite de c骴igos DNID cargables por ning鷑 medio f韘ico o electr髇ico distinto de los interruptores o conectores internos requeridos.

3.3. Requisitos para ELBs basados en Iridium.

• 1. Este apartado define los requisitos que deben cumplir los ELBs que utilicen el sistema Iridium.
• 2. Dichos ELBs deben cumplir 閟tos requisitos adem醩 de los generales definidos en el apartado 3.1 de 閟ta especificaci髇 t閏nica.

3.3.1. Descripci髇 del ELB.

• 1. El ELB estar� formado por las dos unidades descritas a continuaci髇:
  • a) Una antena que ser� de uso com鷑 para las funciones del GPS y de Iridium homologada por Iridium, o dos antenas independientes, la primera de ellas para las funciones de Iridium homologada por Iridium, y la segunda para las funciones de GPS homologada por el fabricante de acuerdo a las especificaciones del sistema GPS y verificada por el INTA. Tanto el receptor de GPS como el transceptor de Iridium homologado por Iridium, as� como la electr髇ica necesaria para cumplir los requisitos de esta especificaci髇 t閏nica, podr醤 estar integrados en el bloque de la antena.
  • b) Una caja cerrada y sellada para evitar su manipulaci髇, que llamaremos caja azul, la cual podr� contener el receptor de GPS y el transceptor de Iridium homologado por Iridium; as� como la electr髇ica necesaria para cumplir los requisitos de esta especificaci髇 t閏nica.
• 2. Opcionalmente se podr� a馻dir un terminal externo.

3.3.2. Requisitos funcionales.

3.3.2.1. General.

• 1. La posici髇 del buque, el rumbo y la velocidad se obtendr� 鷑icamente de la se馻l recibida de la constelaci髇 satelital GPS por la antena y el receptor GPS.
• 2. La posici髇 del buque ser� transmitida al sistema satelital a trav閟 de un proveedor de servicios autorizado por la DGRPYA.
• 3. La antena ser� com鷑 para las funciones a realizar por el receptor GPS y por el transceptor Iridium y estar� homologada por Iridium, o ser醤 dos antenas independientes, la primera de ellas para las funciones de Iridium homologada por Iridium, y la segunda para las funciones de GPS homologada por el fabricante de acuerdo a las especificaciones del sistema GPS y verificada por el INTA.
• 4. Cuando el receptor GPS y el transceptor Iridium est閚 integrados en el bloque de la antena, el fabricante de los ELBs deber� incorporar un sistema de seguridad adecuado para que cada caja azul solamente pueda funcionar con el bloque transceptor-antena que le sea espec韋icamente asignado, de tal forma que si este bloque es sustituido por otro diferente, el ELB no funcione.

3.3.2.2. Receptor GPS y transceptor Iridium.

3.3.2.2.1. Receptor GPS.

• 1. El receptor GPS ser� el encargado de enviar al procesador la posici髇 del buque, el rumbo y la velocidad.
• 2. Dicha informaci髇 ser� obtenida de la se馻l de la constelaci髇 satelital GPS recibida por dicho receptor a trav閟 de la antena GPS.
• 3. El receptor GPS debe ser al menos de seis canales.

3.3.2.2.1.1. Error de precisi髇 en la posici髇.

• 1. El error de precisi髇 en la posici髇 permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) est� habilitada, debe ser inferior a 100 m RMS.
• 2. El error de precisi髇 en la posici髇 permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) no est� habilitada, debe ser inferior a 25 m RMS.

3.3.2.2.1.2. Error en la velocidad.

• 1. El error de velocidad permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) est� habilitada, debe ser inferior a 1 nudo RMS.
• 2. El error de velocidad permitido cuando la disponibilidad selectiva (Selective Availability impuesta por el Departamento de Defensa de EEUU) no est� habilitada, debe ser inferior a 0.5 nudos RMS.

3.3.2.2.1.3. Tiempo de adquisici髇.

El tiempo de adquisici髇 del GPS debe ser inferior a los siguientes valores:

• a) 4 minutos en el caso de un encendido en fr韔.
• b) 2 minutos en el caso de un encendido despu閟 de haberse apagado durante menos de 1 hora.
• c) 1 minuto en el caso de un bloqueo o p閞dida de enganche.

3.3.2.2.1.4. Frecuencia de actualizaci髇.

La frecuencia de actualizaci髇 debe ser inferior a 10 segundos, en condiciones normales y habiendo suficientes sat閘ites enganchados.

3.3.2.2.2. Transceptor Iridium.

• 1. El transceptor ser� homologado por Iridium, con tal de que su funcionalidad sea correcta en ambiente mar韙imo e instalado en un buque.
• 2. El transceptor procesar� las se馻les recibidas de los sat閘ites Iridium a trav閟 de la antena, y enviar� los datos al procesador, que integrar� estos datos con los recibidos del receptor GPS, enviando se馻les a la antena para su transmisi髇.

3.3.2.3. Antena.

• 1. La antena ser� com鷑 para las funciones a realizar por el receptor GPS y por el transceptor Iridium y estar� homologada por Iridium, o ser醤 dos antenas independientes, la primera de ellas para las funciones de Iridium homologada por Iridium, y la segunda para las funciones de GPS homologada por el fabricante de acuerdo a las especificaciones del sistema GPS y verificada por el INTA.
• 2. Ser� capaz de recibir las se馻les transmitidas por los sat閘ites Iridium y GPS. Asimismo, ser� capaz de transmitir las se馻les generadas al sat閘ite Iridium.

3.3.2.4. Puerto de comunicaciones local.

• 1. Adem醩 de las funciones de comunicaci髇 remotas a trav閟 de la constelaci髇 Iridium, demandadas por la presente especificaci髇, se requiere la capacidad de comunicaci髇 local con la caja azul a trav閟 de un puerto de comunicaciones serie RS232C o un puerto USB.
• 2. Las capacidades y funciones a prestar a trav閟 de este puerto de comunicaciones local se dividen en dos categor韆s:
  • a) Las detalladas en esta especificaci髇, con la indicaci髇 de los mensajes de identificaci髇, interrogaci髇 y respuesta oportunos.
    
    Los mensajes y funcionalidades se indican a nivel de aplicaci髇, dejando al criterio del fabricante el encapsulado de los paquetes de entrada/salida en el nivel de enlace y aplicaci髇 correspondiente.
    
    Son aplicables al puerto de comunicaciones local los siguientes mensajes:
    
    (3.3.6.3.2) Mensaje de interrogaci髇 de memoria.
    
    (3.3.6.4.1) Mensajes de volcado de memoria.
    
    (3.3.7) Protocolo de identificaci髇 del inspector para el volcado de posiciones de memoria.
    
    (3.3.6.5.1) Formato del mensaje de error en interrogaci髇 de memoria.
  • b) Toda otra funci髇 o capacidad que desee incluir el fabricante, aqu� no indicada o anticipada.
• 3. Ambos tipos de funciones deber醤 cumplir las restricciones de seguridad y ausencias de efectos funcionales secundarios indicados a continuaci髇.
• 4. Estas restricciones se aplican sobre el canal de comunicaciones Iridium del equipo.
• 5. El fabricante de los ELBs deber� entregar a la DGRPYA el software adecuado para cada equipo que permita la extracci髇 de los datos por el puerto de comunicaciones local, as� como la realizaci髇 de las capacidades y funciones anteriormente descritas.

3.3.2.4.1. Perturbaciones a las funciones requeridas del equipo.

• 1. La recepci髇 de mensajes procedentes del CSP se realiza de forma as韓crona, sin que se pueda determinar el momento ni frecuencia de recepci髇 de los mismos. La emisi髇 de mensajes del ELB al CSP se realiza de dos formas:
  • a) De forma as韓crona, por respuesta inmediata y 鷑ica a un mensaje del CSP.
  • b) De forma s韓crona y peri骴ica, en los mensajes de informaci髇 de estado del buque.
• 2. Sea t el per韔do activo de emisi髇 de los mensajes de situaci髇. El ELB s髄o permitir� realizar otras funciones de comunicaci髇 distintas de las incluidas en esta especificaci髇 cuando:
  
  Si to es el instante inicial de la transmisi髇/recepci髇, kt el tiempo de la 鷏tima comunicaci髇 de posici髇 emitido por el ELB, y ts el tiempo estimado de transmisi髇/recepci髇 del servicio requerido, se cumple (to-kt)+ts<t.
• 3. Igualmente, y ante la recepci髇 de cualquiera de los mensajes de interrogaci髇 definidos en esta especificaci髇, el ELB atender� de forma prioritaria el servicio del mismo, garantizando la asignaci髇 exclusiva del canal de comunicaciones remoto a la emisi髇 del mensaje de respuesta correspondiente, cuando se encuentre definido.
• 4. Ante la ausencia de otras restricciones, cualquier servicio o funcionalidad a馻dida al ELB por el fabricante del mismo nunca podr� impedir la recepci髇 de mensajes del CSP durante m醩 de 6 minutos.

3.3.2.4.2. Transmisi髇 de informaci髇 distinta de la requerida en esta especificaci髇.

• 1. Esta especificaci髇 no limita la inclusi髇 de otros servicios o funcionalidades que pudieran resultar de utilidad a la flota pesquera usuaria del sistema.
• 2. Dicha funcionalidad ser� completamente ajena a todos los datos que el ELB requiere, produce o almacena en relaci髇 a las funciones, mensajes y requisitos aplicables al fin principal del sistema de seguimiento de pesqueros. En particular, los usuarios del mismo nunca podr醤 tener acceso, ni de lectura ni de modificaci髇 ni de borrado, de lo siguiente:
  • a) Claves internas e identificadores de acceso.
  • b) Mensajes recibidos y emitidos al CSP, ni su contenido ni ocurrencia (salvo mensajes de texto intercambiados con el CSP).
  • c) Memoria de registro de la actividad del buque.
  • d) Estado o actividad del ELB.
• 3. La utilizaci髇 del servicio de datos y de todos los servicios de mensajes de posici髇 e interrogaci髇 se reservan en exclusiva para las funciones de control de la DGRPYA.

3.3.3. Requisitos f韘icos.

3.3.3.1. General.

• 1. La caja azul deber� estar conectada con la antena mediante un cable no manipulable.
• 2. La comunicaci髇 entre el transceptor Iridium, el receptor GPS y el procesador no podr� ser accesible de manera no autorizada, de forma que no pueda comprometer la integridad de los datos de posici髇 del GPS.
• 3. Se permitir� una conexi髇 externa al ELB, para la conexi髇 de un terminal de usuario, utilizable en la transmisi髇 de otros datos del buque.

3.3.3.2. Requisitos ambientales.

Todas las unidades del ELB y sus componentes, deber醤 ser dise馻das para uso mar韙imo, no vi閚dose degradadas sus condiciones de funcionamiento en dicho ambiente.

3.3.3.2.1. Vibraci髇.

El equipo podr� soportar vibraci髇 con amplitud de aceleraci髇 de g en el rango de frecuencia de 10 a 150 Hz durante un tiempo de 20 ciclos, seg鷑 tabla C.1 de la norma UNE EN 60068-2-6.

3.3.3.2.2. Choque.

El equipo podr� soportar sin deformaci髇 o rotura golpes de 15 g de amplitud de aceleraci髇 con una forma de onda simisinusoidal durante 11 ms, seg鷑 la norma UNE EN 60068-2-27.

3.3.3.2.3. Estanqueidad.

Deber� resistir los efectos del polvo y del agua, comprob醤dose que no penetren en el interior del ELB y puedan producir da駉s, para lo cual deber� tener el grado de protecci髇 IP65 seg鷑 la norma CEI 60529.

3.3.3.2.4. Temperatura.

El rango de temperatura de almacenamiento ser� de -40 篊 a 70 篊. El rango de temperatura de funcionamiento ser� de -20 篊 a 50 篊. Seg鷑 las normas UNE EN 60068-2-1/A1 y UNE EN 60068-2-1/A2 para fr韔, y las normas UNE EN 60068-2-2/A1 y UNE EN 60068-2-2/A2 para calor seco.

3.3.3.2.5. Humedad.

El equipo soportar� exposiciones en ambientes con una humedad relativa de hasta el 95 %, seg鷑 la norma UNE EN 60068-2-78.

3.3.3.2.6. Niebla salina.

El equipo soportar� un ambiente de niebla salina como el descrito en la norma UNE EN 60068-2-11.

3.3.3.2.7. Seguridad el閏trica.

El equipo deber� construirse de forma que el operador no pueda tocar o acercarse peligrosamente a las partes activas como medida de protecci髇 contra tensiones peligrosas.

Las partes met醠icas descubiertas del equipo no destinados a estar sometidas a tensi髇 pero que a causa de un defecto puedan estarlo, deber醤 tener prevista su puesta a masa.

3.3.3.2.7.1. Equipos alimentados a tensi髇 alterna Vn.

En el caso de la opci髇 de que el equipo se pueda alimentar tambi閚 en corriente alterna, se deber� cumplir lo siguiente:

Las partes met醠icas descubiertas, del equipo, deber醤 tener prevista su puesta a masa (por ejemplo al casco del buque), salvo que est閚 alimentadas a una tensi髇 que no exceda de 250 voltios por transformadores aisladores de seguridad que alimenten un solo equipo, o que est閚 construidas de conformidad con el principio de aislamiento doble o reforzado.

3.3.3.2.7.1.1. Ensayos de seguridad el閏trica.

Para este caso se realizar醤 los siguientes ensayos antes y despu閟 de los ensayos de los apartados 3.3.3.2.5 y 3.3.3.2.6 seg鷑 la norma UNE-EN 60950-1. Equipos de tecnolog韆 de la informaci髇. Seguridad. Parte 1: Requisitos generales.

Ensayo de corriente de contacto. (Apartado 5.1 de la norma UNE-EN 60950-1 teniendo como referencia la norma EN 60990. Methods of measurement of touch current and protective conductor current).

El criterio de aceptaci髇 ser� el siguiente seg鷑 los limites descritos en la tabla 5A del apartado citado:

Con el terminal A del instrumento de medida conectado a partes accesibles y circuitos no conectados a tierra de protecci髇, la m醲ima corriente de contacto ser� de 0,25mA de valor eficaz.

Con el terminal A del instrumento de medida conectado al terminal principal de puesta a tierra de protecci髇 del equipo (si existe), la m醲ima corriente de contacto ser� de 3,5mA de valor eficaz.

Ensayo de rigidez diel閏trica (Apartado 5.2 de la norma UNE-EN 60950-1). Se realizar醤 ensayos de rigidez diel閏trica de 1500V 50Hz eficaces de tensi髇 de ensayo incrementada gradualmente desde 0 V hasta la tensi髇 prescrita y manteniendo ese valor durante 60 segundos entre partes del circuito primario.

3.3.3.3. Compatibilidad electromagn閠ica.

Ser� aplicable la norma UNE EN 60945, con los siguientes criterios:

• a) Interferencia conducida: En la banda de frecuencias de 10 KHz a 30 MHz la tensi髇 de radiofrecuencia en los terminales de alimentaci髇 no exceder� los l韒ites descritos en la Figura 2 de la norma.
• b) Interferencia radiada: En la banda de frecuencias de 150 Khz. a 2 Ghz. el nivel de intensidad de campo no exceder� los l韒ites descritos en la Figura 4 de la norma.
• c) Inmunidad a las se馻les de radiofrecuencia conducidas, con una se馻l interferente en l韓eas de alimentaci髇 y se馻l de 3 V r.m.s. en el rango de 150 KHz a 80 Mhz. y de 10 V r.m.s. en las frecuencias siguientes: 2 Mhz., 3 Mhz., 4 Mhz., 6.2 Mhz., 8.2 Mhz., 12.6 Mhz., 16.5 Mhz., 18.8 Mhz., 22 Mhz. y 25 Mhz.
• d) Inmunidad radiada en el rango de 80 MHz a 2 GHz con una amplitud de campo de 10 V/m para el equipo instalado dentro de la estructura del buque.
• e) Inmunidad a transitorios en l韓eas de alimentaci髇, se馻l y control de 5 ns de tiempo de subida, 50 ns de anchura, 2KV de amplitud en l韓eas de alimentaci髇 y 1KV en l韓eas de se馻l y control, y frecuencia de repetici髇 de 5 KHz (1 KV) y 2.5 KHz (2KV).
• f) Inmunidad frente a onda de choque de 1.2 microsegundos. de tiempo de subida, 50 microsegundos de anchura, 1KV de amplitud en l韓ea/tierra y 0.5 KV en l韓ea/l韓ea, y frecuencia de repetici髇 de 1 pulso/min.
• g) Inmunidad frente a descargas electrost醫icas de 6 KV de descarga de contacto y 8 KV de descarga aire.
• h) La norma UNE EN 60945 da la presunci髇 de conformidad de los requisitos esenciales establecidos en el anexo I de la directiva 2004/108/EC.

3.3.3.4. Interfaces el閏tricos.

• 1. El equipo admitir� una alimentaci髇 el閏trica de 24 V, con variaci髇 desde 11 V a 30 V, en corriente continua. Siendo opcional que se pueda alimentar tambi閚 en corriente alterna Vn, con variaci髇 de �10 % y frecuencia entre 49 Hz y 51 Hz.
• 2. La caja azul dispondr� de una conexi髇 serie tipo RS-232C acorde al est醤dar RS-232 accesible, mediante un conector hembra tipo SubD de 9 pines, o de una conexi髇 del tipo USB, para permitir la descarga de los datos almacenados en la memoria. La conexi髇 debe cumplir especificaciones mar韙imas. Esta misma conexi髇 se podr� utilizar para conectar el terminal externo opcional.
• 3. La conexi髇 entre la caja azul y la antena ser� mediante un cable del tipo RG-213 o similar, o de un cable de datos y alimentaci髇 definido por el fabricante y aceptado por el INTA, dependiendo de la configuraci髇 de la antena, pero sin conector en el extremo de la caja azul, esto es, mediante prensaestopas para evitar su f醕il desconexi髇.

3.3.3.4.1. Condiciones normales de alimentaci髇.

El ELB podr� ser conectado a una tensi髇 continua de 24 V, con variaci髇 desde 11 V a 30 V o cualquier otro voltaje que est� dentro del rango anterior para el cual el equipo fue dise馻do. Opcionalmente el ELB podr� ser conectado a una tensi髇 alterna Vn con una tolerancia del �10 % y una frecuencia entre 49 Hz y 51 Hz.

3.3.3.4.2. Condiciones extremas de alimentaci髇.

El ELB no debe ver degradadas sus condiciones de funcionamiento en condiciones extremas de alimentaci髇, esto es, 11 V y 30 V en corriente continua y opcionalmente, Vn � 10% en corriente alterna.

3.3.3.4.3. Conmutaci髇 entre alimentaciones.

El equipo deber� ser capaz de conmutar entre la alimentaci髇 de 24 V en continua y de Vn en alterna (si est� en opci髇) sin producirse p閞dida de alimentaci髇.

3.3.3.4.4. Condiciones normales de temperatura y humedad.

El equipo ELB encontrar� sus condiciones de funcionamiento en cualquier combinaci髇 conveniente que est� dentro de los siguientes rangos:

• a) Temperatura: 15 篊 a 35 篊.
• b) Humedad relativa: entre el 20 % y el 75 %.

3.3.3.4.5. Condiciones extremas de temperatura.

• 1. El ELB encontrar� sus condiciones de funcionamiento a las temperaturas extremas de operaci髇, que ser� de -20 篊 y 50 篊.
• 2. En el caso de la temperatura superior de 50 篊, una vez que 閟ta es alcanzada y est� estabilizada, el ELB ser� capaz de transmitir/recibir durante un tiempo de 30 minutos, sin que se degraden sus condiciones de funcionamiento.
• 3. En el caso de la temperatura inferior de -20 篊, una vez que 閟ta es alcanzada y est� estabilizada, el ELB podr� ser alimentado durante un tiempo de 5 minutos, sin que se degraden sus condiciones de funcionamiento.

3.3.3.5. Interfaces del operador.

• 1. La caja azul en su lado frontal dispondr� de los siguientes pulsadores o interruptores, etiquetados como se indica:
  • a) Encendido/Apagado. Un interruptor o pulsadores etiquetados con las palabras "ENCENDIDO/APAGADO", que deber� enviar el mensaje descrito en 3.3.5.1.2.5 cuando se act鷈 el encendido, y el mensaje descrito en 3.3.5.1.2.4 cuando se act鷈 el apagado.
  • b) Pesca. Un interruptor o pulsadores etiquetados con la palabra "PESCA: ACTIVO", que deber� enviar el mensaje descrito en 3.3.5.1.2.1 cuando se act鷈 comienzo de actividad de pesca, y con la palabra "PESCA: PASIVO", el mensaje descrito en 3.3.5.1.2.2 cuando se act鷈 fin de actividad de pesca.
  • c) Cruce. Un pulsador etiquetado con la palabra "CRUCE", que deber� enviar el mensaje descrito en 3.3.5.1.2.3 cada vez que sea pulsado por el capit醤 o patr髇.
• 2. La caja azul dispondr� de una indicaci髇 luminosa cuando la actividad de pesca est� habilitada.
• 3. La caja azul dispondr� de una indicaci髇 luminosa cuando el equipo est� funcionando.

3.3.4. Requisitos de instalaci髇.

3.3.4.1. General.

• 1. Los ELBs deber醤 ser instalados solamente por personal formalmente designados por el fabricante del equipo y autorizados por la DGRPYA. Todas las operaciones de instalaci髇 podr醤 ser supervisadas por inspectores de la DGRPYA. La sujeci髇 del ELB al buque ser� la adecuada para uso mar韙imo, teniendo en cuenta condiciones de vibraci髇 propias de un buque.
• 2. En el caso de que no se pueda cumplir alguno de estos requisitos de instalaci髇, se pedir� autorizaci髇 a la DGRPYA para realizar una instalaci髇 diferente.
• 3. La instalaci髇 se har� de acuerdo con el documento de instalaci髇 proporcionado por el fabricante para la autorizaci髇 del ELB.

3.3.4.2. Caja azul.

• 1. La caja azul deber� ser instalada en zona protegida del puente o derrota, de manera que sea directamente visible por el personal de guardia, est� protegida de los elementos atmosf閞icos, no sufra interferencias de la operaci髇 de otros equipos embarcados y no interfiera con las operaciones de seguridad del buque.
• 2. La sujeci髇 de la caja azul podr� ser tanto a una superficie horizontal como vertical, mediante tornillos pasantes en n鷐ero y m閠rica adecuados al peso de la caja. La superficie de sujeci髇 deber� ser estructural del buque, de manera que no sea f醕il su separaci髇.
• 3. Se deber� prever la instalaci髇 de al menos dos precintos de alambre pl醩tico u otro material adecuado para denotar su separaci髇 fraudulenta del buque. Igualmente se deber� prever la instalaci髇 del mismo tipo de precintos para evitar la apertura fraudulenta de la caja azul o antena.

3.3.4.3. Antena.

• 1. La antena deber� ser fijada a una parte estructural del buque y su posici髇 debe ser tal que: tenga acceso a cielo abierto sin ser obstruido sus diagramas de radiaci髇 por ninguna parte del buque, no sufra interferencias de la operaci髇 de otros equipos embarcados y no interfiera con las operaciones de seguridad del buque.
• 2. La antena deber� ser instalada en un lugar donde las personas no puedan recibir niveles de radiaci髇 electromagn閠ica peligrosos, mientras desarrollan las normales actividades del buque.
• 3. En el caso de que est閚 integrados en el bloque de la antena el receptor de GPS y el transceptor de Iridium, se deber� prever un sistema adecuado para evitar la apertura fraudulenta del bloque de la antena.

3.3.4.4. Cableado.

• 1. El cable que une la antena con la caja azul deber� ser el definido por el fabricante, no pudiendo exceder la longitud m醲ima establecida en el manual de instalaci髇. Deber� ser colocado de forma que no sea da馻do durante la normal actividad del buque.
• 2. Se deber醤 permitir todos los requisitos de puesta a tierra de la antena como especifique el fabricante.
• 3. La conexi髇 del cable con la caja azul deber� ser a trav閟 de pasamuros con prensaestopas para asegurar la estanqueidad y la desconexi髇 fraudulenta.

3.3.4.5. Instalaci髇 el閏trica.

• 1. El ELB se deber� conectar a una alimentaci髇 el閏trica que no se vea sujeta a fluctuaciones en voltaje que puedan causar condiciones de reset o da駉s al ELB.
• 2. El ELB deber� ser conectado a dos fuentes de potencia del buque externas al ELB, siendo una de ellas, las bater韆s de emergencia.
• 3. Si opcionalmente se utilizan bater韆s internas, estas no deber醤 afectar al funcionamiento normal del ELB.

3.3.5. Mensajes.

3.3.5.1. Mensajes del ELB al CSP.

En 閟te apartado se definen los mensajes autom醫icos y manuales que debe ser capaz de enviar el ELB al CSP.

Todos estos mensajes los enviar� el ELB solamente a la direcci髇 IP del CSP.

El fabricante de los ELBs deber� incorporar un sistema de seguridad adecuado para que solamente pueda validarse una direcci髇 IP (la del CSP) por cada IMEI (una por ELB), estando este proceso controlado por la DGRPYA.

3.3.5.1.1. Mensajes autom醫icos.

Los mensajes autom醫icos son aquellos que para ser generados por el ELB no necesitan acci髇 alguna por parte del capit醤 o patr髇.

A continuaci髇 se describen dichos mensajes.

3.3.5.1.1.1. Mensaje de posici髇 peri骴ico.

• 1. El ELB debe ser capaz de enviar mensajes de posici髇 a intervalos prefijados por el CSP, utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. La periodicidad estar� comprendida entre 15 minutos y 24 horas, con intervalos de un m韓imo de 15 minutos.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para fijar los intervalos, ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.3 de esta especificaci髇 t閏nica.
• 4. El formato de 閟te mensaje ser� el formato tipo mensaje de posici髇 definido en el apartado 3.3.6.2 de 閟ta especificaci髇 t閏nica.
• 5. El formato del comando de interrogaci髇 enviado por el CSP para comenzar el env韔 de mensajes de posici髇 peri骴icos, ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.4 de 閟ta especificaci髇 t閏nica.
• 6. El formato del comando de interrogaci髇 enviado por el CSP para parar el env韔 de mensajes de posici髇 peri骴icos, ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.5 de 閟ta especificaci髇 t閏nica.

3.3.5.1.1.2. Mensaje de 鷏tima posici髇.

• 1. El ELB debe ser capaz de enviar mensajes de posici髇 a petici髇 del CSP, utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El formato de 閟te mensaje ser� el formato tipo mensaje de posici髇 definido en el apartado 3.3.6.2 de 閟ta especificaci髇 t閏nica.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un informe de posici髇 ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.1 de 閟ta especificaci髇 t閏nica.

3.3.5.1.1.3. Volcado de posiciones.

• 1. El ELB debe ser capaz de enviar todas las posiciones almacenadas durante un intervalo de tiempo determinado a petici髇 del CSP.
• 2. Para ello, el ELB debe ser capaz de almacenar en una memoria interna las posiciones con una periodicidad de 10 minutos durante 6 meses.
• 3. La informaci髇 a almacenar en memoria y a enviar al CSP ser� la siguiente:
  • a) Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • b) Latitud.
  • c) Longitud.
  • d) Rumbo actual.
  • e) Velocidad actual.
  • f) Actividad (pesca/no pesca).
  • g) Se馻l de antena.
  • h) Corriente de antena.
• 4. El formato de 閟te mensaje ser� el formato tipo volcado de posiciones definido en el apartado 3.3.6.4 de 閟ta especificaci髇 t閏nica.
• 5. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un volcado de posiciones ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.2 de 閟ta especificaci髇 t閏nica.

3.3.5.1.1.4. Reconocimiento de haber recibido un mensaje del CSP.

• 1. Bajo determinadas circunstancias, el ELB puede ser requerido para que env韊 un mensaje independiente de reconocimiento de haber recibido correctamente el comando enviado por el CSP, utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El formato de 閟te mensaje ser� el formato tipo mensaje de posici髇 de reconocimiento definido en el apartado 3.3.6.2.1 de 閟ta especificaci髇 t閏nica.
• 3. El formato del comando de interrogaci髇 enviado por el CSP para solicitar un mensaje de posici髇 de reconocimiento, ser� el formato tipo interrogaci髇 definido en el apartado 3.3.6.3.9 de 閟ta especificaci髇 t閏nica.

3.3.5.1.1.5. Apagado anormal del ELB.

• 1. El ELB debe ser capaz de enviar un mensaje cuando se apaga anormalmente, sin previo aviso, esto es, sin haberse pulsado el pulsador "ENCENDIDO/APAGADO", (por ejemplo, se ha perdido la potencia el閏trica por alg鷑 motivo), utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. Dicho mensaje debe enviarse en el momento en que se recupere la alimentaci髇, debiendo identificar dicho evento, mediante un mensaje de "apagado anormal".
• 3. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en el apartado 3.3.6.2 de 閟ta especificaci髇 t閏nica, incluyendo el Mensaje Codificado (MC) 41 (hex) para indicar que es un mensaje de apagado anormal, incluyendo la informaci髇 del buque en el momento que se produjo el apagado.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.3.5.1.1.6. Desconexi髇 de la antena.

• 1. Cuando la funcionalidad del ELB lo permita, debe ser capaz de enviar autom醫icamente un mensaje junto con una identificaci髇 del evento "desconexi髇 de antena" (corriente de antena nula), utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la corriente de la antena.
• 3. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 42 (hex) para indicar que es un mensaje de posici髇 por desconexi髇 de antena, incluyendo la informaci髇 del buque en el momento en que se produjo la desconexi髇.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.3.5.1.1.7. Bloqueo de la antena.

• 1. El ELB debe ser capaz de enviar autom醫icamente un mensaje junto con una identificaci髇 del evento "bloqueo de antena" (conexi髇 con el sat閘ite defectuosa), utilizando el servicio SBD (Short Burst Data) de Iridium, cuando la antena est� bloqueada durante m醩 de 15 minutos.
• 2. El mensaje debe ser enviado inmediatamente despu閟 de haberse recuperado la calidad de la se馻l de la antena.
• 3. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 43 (hex) para indicar que es un mensaje de posici髇 por bloqueo de la antena, incluyendo la informaci髇 del buque en el momento en que se produjo el bloqueo.
• 4. El ELB debe tambi閚 enviar un segundo mensaje del formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, incluyendo la informaci髇 actual del buque.

3.3.5.1.1.8. Mensajes de respuesta a interrogaciones incorrectas.

• 1. El equipo llevar� registro interno de los tiempos final, T_f, e inicial, T_i, de los l韒ites de los registros en la memoria c韈lica interna.
• 2. Se considera correcto un mensaje de interrogaci髇 de memoria cuando se cumple:

  

• 3. Si el 鷏timo mensaje de interrogaci髇 de memoria no es correcto bajo el criterio anterior, el equipo emitir� un mensaje de respuesta al CSP de error en interrogaci髇 de memoria con el formato que se indica en el apartado 3.3.6.5.1. Adem醩 emitir� por el puerto de comunicaciones local un mensaje de respuesta, con el formato que se indica en el apartado 3.3.6.5.2.

3.3.5.1.2. Mensajes por accionamiento de pulsadores.

• 1. Los mensajes manuales deben ser transmitidos por el ELB al actuar el capit醤 o patr髇 sobre uno o varios de los pulsadores localizados en su frontal.
• 2. A continuaci髇 se describen dichos mensajes.

3.3.5.1.2.1. Comienzo de pesca.

• 1. El ELB debe enviar un mensaje junto con una identificaci髇 del evento "actividad de pesca" al pulsar el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra "PESCA: ACTIVO", utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 45 (hex) para indicar que es un mensaje de posici髇 de comienzo de pesca, junto con la activaci髇 (nivel l骻ico 1) a partir de ese momento en los sucesivos mensajes de posici髇 del bit "actividad de pesca" para indicar que el buque se encuentra en actividad de pesca.

3.3.5.1.2.2. Fin de pesca.

• 1. El ELB debe enviar un mensaje junto con una identificaci髇 del evento "no actividad de pesca" al pulsar el capit醤 o patr髇 el pulsador o pulsadores nombrados con la palabra "PESCA: PASIVO", utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 46 (hex) para indicar que es un mensaje de posici髇 de fin de pesca, junto con la desactivaci髇 (nivel l骻ico 0) a partir de ese momento en los sucesivos mensajes de posici髇 del bit "actividad de pesca" para indicar que el buque no se encuentra en actividad de pesca.

3.3.5.1.2.3. Cruce.

• 1. El ELB debe enviar un mensaje de posici髇 actual al pulsar el capit醤 o patr髇 el pulsador nombrado con la palabra "CRUCE", utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 47 (hex) para indicar que es un mensaje de posici髇 de cruce.

3.3.5.1.2.4. Apagado normal.

• 1. El ELB debe ser capaz de enviar un mensaje de posici髇 junto con una identificaci髇 del evento "apagado normal" cuando el capit醤 o patr髇 lo apaga pulsando el bot髇, utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. Para ello deber� pulsar el pulsador nombrado con las palabras "ENCENDIDO/APAGADO". Esta acci髇 del operador debe producir el env韔 al CSP del mensaje de posici髇 junto con una identificaci髇 del evento "apagado normal" y apagar de forma autom醫ica el ELB.
• 3. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 44 (hex) para indicar que es un mensaje de apagado normal.

3.3.5.1.2.5. Encendido del ELB.

• 1. El ELB debe ser capaz de enviar autom醫icamente un mensaje de la posici髇 actual inmediatamente despu閟 de ser encendido, utilizando el servicio SBD (Short Burst Data) de Iridium.
• 2. Para ello, el capit醤 o patr髇 deber� pulsar el pulsador nombrado con las palabras "ENCENDIDO/APAGADO".
• 3. El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated) definido en el apartado 3.3.6.2 de 閟ta especificaci髇 t閏nica, incluyendo el Mensaje Codificado (MC) 40 (hex) para indicar que es un mensaje de posici髇 de encendido.

3.3.5.1.3. Uso de cifrado en el ELB.

• 1. La protecci髇 de la informaci髇 a transmitir del ELB al CSP mediante el uso de cifrado no es una caracter韘tica requerida por esta especificaci髇.
• 2. Sin embargo, si alg鷑 fabricante determinara incluir esta funcionalidad en sus equipos, deber� atenerse a los siguientes requisitos, impuestos por la necesidad de utilizar un m閠odo 鷑ico en toda la red de ELB.
• 3. Se distinguir醤 con un n鷐ero de modelo propio aquellos equipos que cifren sus comunicaciones, sin que esta funcionalidad sea reversible en los mismos.
• 4. Se podr醤 cifrar 鷑icamente los campos de datos o definidos por el usuario de los correspondientes mensajes definidos en esta especificaci髇, manteniendo compatible e inalterada la cabecera y c骴igos de chequeo de los mensajes.
• 5. El m閠odo de cifrado ser� de clave sim閠rica, y en particular se utilizar� el algoritmo DES (Data Encryption Standard), combinado en modo triple, DES3, y "output feedback", con la cabecera no cifrada de cada mensaje a modo de vector de inicializaci髇, en sus 64 bits menos significativos.
• 6. Se llevar� a cabo respetando lo contenido en los siguientes documentos:
  • a) ANSI X3.92 "American National Standard for Data Encryption Algorithm (DEA)", American National Standards Institute, 1981.
  • b) ANSI X3.106 "American National Standard for Information Systems -Data Encryption Algorithm -Modes of Operation", American National Standards Institute, 1983.
  • c) ISO IEC 9594 8/ITU T X.509, "Information Technology Open Systems Interconnection The Directory: Authentication Framework".
  • d) FIPS PUB 140 1, "Security Requirements for Cryptographic Modules", 1993.
• 7. Generaci髇 de claves:
  • a) "Randomness Recommendations for Security", RFC 1750, Donald Eastlake, Stephen Crocker, Jeffrey Schiller, 1994.
  • b) "Cryptographic Random Numbers", IEEE P1363 Appendix E, Draft version 1.0, 11, 1995.
• 8. La clave privada de cada ELB ser� registrada en el mismo de forma electr髇ica, no vol醫il, y de manera inaccesible bajo ninguna operaci髇 de despiece, lectura de memorias en banco de ensayo, o interrogaci髇 por comunicaciones remotas o locales. El equipo no facilitar� mecanismo alguno para el cambio del valor de esta clave.
• 9. Cada fabricante deber� entregar a la DGRPYA la relaci髇 de claves y n鷐eros de serie de los equipos con anterioridad a su entrada en servicio.
• 10. Los mensajes salientes del ELB, en los equipos que incorporen cifrado, se encriptar醤 utilizando el m閠odo anteriormente descrito, y con la clave privada del mismo.
• 11. Aquellos equipos que no incorporen el cifrado de las comunicaciones, deber醤 llevar registrado en el mismo un n鷐ero aleatorio de 1024 bits, de forma electr髇ica, no vol醫il, y de manera inaccesible bajo ninguna operaci髇 de despiece, lectura de memorias en banco de ensayo, o interrogaci髇 por comunicaciones remotas o locales. El equipo no facilitar� mecanismo alguno para el cambio del valor de este n鷐ero.
• 12. La generaci髇 de este n鷐ero deber� respetar lo contenido en los siguientes documentos:
  • a) "Randomness Recommendations for Security", RFC 1750, Donald Eastlake, Stephen Crocker, Jeffrey Schiller, 1994.
  • b) "Cryptographic Random Numbers", IEEE P1363 Appendix E, Draft version 1.0, 11, 1995.
• 13. Cada fabricante deber� entregar a la DGRPYA la relaci髇 de n鷐eros aleatorios internos y n鷐eros de serie de los equipos con anterioridad a su entrada en servicio.

3.3.5.2. Mensajes del CSP al ELB.

En 閟te apartado se definen los mensajes que deben ser capaces de ser aceptados por el ELB. Dichos mensajes ser醤 generados por el CSP.

El ELB solamente aceptar� mensajes desde la direcci髇 IP asignada al ELB (la IP del CSP), la 鷑ica validada para cada IMEI.

3.3.5.2.1. Petici髇 de 鷏tima posici髇.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de 鷏tima posici髇.
• 2. El formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇 ser� el definido en el apartado 3.3.6.3.1 de 閟ta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un mensaje de 鷏tima posici髇, definido en el apartado 3.3.5.1.1.2 de 閟ta especificaci髇 t閏nica.

3.3.5.2.2. Petici髇 de volcado de posiciones.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de volcado de posiciones entre dos tiempos determinados.
• 2. El formato del comando de interrogaci髇 de petici髇 de volcado de posiciones ser� el definido en el apartado 3.3.6.3.2 de 閟ta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un mensaje del tipo MO (Mobile Originated) definido en el apartado 3.3.6.4 de 閟ta especificaci髇 t閏nica, que contenga la informaci髇 de posici髇 de todas las posiciones almacenadas entre dichos tiempos.
• 4. La informaci髇 a almacenar en memoria y a enviar al CSP ser� la siguiente:
  • a) Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • b) Latitud.
  • c) Longitud.
  • d) Rumbo.
  • e) Velocidad.
  • f) Actividad (pesca/no pesca).
  • g) Se馻l de antena.
  • h) Corriente de antena.

3.3.5.2.3. Petici髇 de cambio de intervalos de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de cambio del intervalo de env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 de petici髇 de cambio de intervalos de env韔 de mensajes de posici髇 peri骴icos ser� el definido en el apartado 3.3.6.3.3 de 閟ta especificaci髇 t閏nica.
• 3. El ELB responder� a dicho comando enviando un mensaje de reconocimiento de haber recibido correctamente el comando enviado por el CSP.
• 4. El formato de 閟te mensaje ser� el formato tipo mensaje de posici髇 de reconocimiento definido en el apartado 3.3.6.2.1 de 閟ta especificaci髇 t閏nica.

3.3.5.2.4. Petici髇 de comienzo de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de comenzar el env韔 de mensajes de posici髇 peri骴icos al recibir un comando para comenzar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para comenzar el env韔 de mensajes de posici髇 peri骴icos ser� el definido en el apartado 3.3.6.3.4 de 閟ta especificaci髇 t閏nica.

3.3.5.2.5. Petici髇 de parar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de parar el env韔 de mensajes de posici髇 peri骴icos al recibir un comando para parar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para parar el env韔 de mensajes de posici髇 peri骴icos ser� el definido en el apartado 3.3.6.3.5 de 閟ta especificaci髇 t閏nica.

3.3.5.2.6. Petici髇 de carga de CIR (C骴igo de Identificaci髇 de Red).

• 1. El ELB debe llevar implementada la capacidad de que le sea cargado un CIR al recibir un comando para cargar CIR.
• 2. El formato del comando de interrogaci髇 para cargar CIR ser� el definido en el apartado 3.3.6.3.6 de 閟ta especificaci髇 t閏nica.
• 3. El ELB al recibir esta petici髇 con el dato del CIR a cargar, lo procesar� y lo grabar� en memoria no vol醫il junto con el IMEI del ELB, quedando ligados un韛ocamente los dos n鷐eros.
• 4. Despu閟 del proceso anterior, el ELB enviar� al CSP un mensaje de posici髇 de reconocimiento definido en el apartado 3.3.6.2.1 de 閟ta especificaci髇 t閏nica, incluyendo la informaci髇 del n鷐ero de CIR grabado.
• 5. El fabricante de los ELBs deber� incorporar un sistema de seguridad adecuado para que el ELB solamente acepte la carga de un CIR por IMEI.
  
  En el caso de que el ELB tenga asignado un CIR y se quiera cargar otro, el ELB generar� un mensaje de error de carga de segundo CIR definido en el apartado 3.3.6.5.2 de estas especificaciones t閏nicas.

3.3.5.2.7. Petici髇 de borrar CIR (C骴igo de Identificaci髇 de Red).

• 1. El ELB debe llevar implementada la capacidad de que le sea borrado un CIR al recibir un comando para borrar CIR.
• 2. El formato del comando de interrogaci髇 para borrar CIR ser� el definido en el apartado 3.3.6.3.7 de 閟ta especificaci髇 t閏nica.
• 3. El ELB al recibir esta petici髇 con el dato del CIR a borrar, lo procesar� y lo borrar� de la memoria no vol醫il deslig醤dolo del IMEI del ELB.
• 4. Despu閟 del proceso anterior, el ELB enviar� al CSP un mensaje de posici髇 de reconocimiento definido en el apartado 3.3.6.2.1 de 閟ta especificaci髇 t閏nica, incluyendo la informaci髇 del n鷐ero de CIR borrado.

3.3.5.2.8. Petici髇 de recepci髇 de datos.

• 1. Opcionalmente, el ELB puede llevar implementada la capacidad de recibir datos al recibir un comando para transmitir datos al ELB.
• 2. El formato del comando de interrogaci髇 para transmitir datos a un ELB ser� el definido en el apartado 3.3.6.3.8 de 閟ta especificaci髇 t閏nica.

3.3.5.2.9. Petici髇 de reconocimiento.

• 1. El ELB debe llevar implementada la capacidad de enviar un mensaje independiente de reconocimiento al recibir un comando que solicite reconocimiento.
• 2. El formato del comando de interrogaci髇 para solicitar reconocimiento ser� el definido en el apartado 3.3.6.3.9 de 閟ta especificaci髇 t閏nica.

3.3.6. Formato de los mensajes.

3.3.6.1. General.

• 1. En esta secci髇 se definen los diferentes formatos de los mensajes que el ELB debe generar o recibir.
• 2. Dichos mensajes son los de posici髇, los de comando de interrogaci髇 y los de volcado de posiciones.
• 3. Para ello, a la hora de definir los formatos se hace referencia a diferentes secciones del documento "Iridium SBD DirectIP Socket Connectivity White Paper. Versi髇 1.02, 23/10/2006".

3.3.6.2. Formato de los mensajes de posici髇.

• 1. El formato de los mensajes de posici髇, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MO (Mobile Originated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 2. El encabezado del mensaje de posici髇 ser� del formato definido en el apartado 5.2 (MO DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. La informaci髇 m韓ima que debe contener cada mensaje de posici髇 debe ser la siguiente:
  • a) Identidad del ELB.
  • b) Latitud (hemisferio, grados, minutos y fracci髇 de minutos en unidades de 0.04 de minuto).
  • c) Longitud (hemisferio, grados, minutos y fracci髇 de minutos en unidades de 0.04 de minuto).
  • d) MC.
  • e) Velocidad (resoluci髇 de 0.2 nudos y rango de 0 a 51.2 nudos).
  • f) Rumbo (resoluci髇 de 1 grado).
  • g) Actividad (pesca/no pesca).
  • h) Fecha (a駉, mes y d韆) y hora (hora y minutos) UTC en la que se haya determinado la posici髇 del buque.
  • i) Reconocimiento.
  • j) CIR (solamente para reconocimiento de carga y borrado de CIR, y para error de carga de segundo CIR).
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 requerida anteriormente ir� incluida en el elemento MO Payload del mensaje MO (Mobile Originated), tal y como se define en el apartado 5.3 (MO Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  Identidad del ELB.-32 bits. CIR (32 bits).
  
  Latitud.-19 bits. Hemisferio (1 bit). Grados (7 bits). Minutos (6 bits). Fracci髇 de minutos (5 bits).
  
  Longitud.-20 bits. Hemisferio (1 bit). Grados (8 bits). Minutos (6 bits). Fracci髇 de minutos (5 bits).
  
  MC (Mensaje Codificado).-7 bits.
  
  Velocidad.-8 bits.
  
  Rumbo.-9 bits.
  
  Actividad.-1 bit.
  
  Fecha y hora UTC.-32 bits. A駉 (valores posibles del 0 al 4095): 12 bits. Mes (valores del 1 al 12): 4 bits. D韆 (valores del 1 al 31: 5 bits. Hora (valores del 0 al 23: 5 bits. Minutos (valores del 0 al 59): 6 bits.
  
  Reconocimiento.-1 bit.
  
  CIR (solamente para reconocimiento de carga y borrado de CIR, y para error de carga de segundo CIR).-32 bits.

3.3.6.2.1. Formato de los mensajes de posici髇 de reconocimiento.

El formato de los mensajes de posici髇 de reconocimiento, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el formato de los mensajes de posici髇, definido en el apartado 3.3.6.2, con el bit de reconocimiento activado (nivel l骻ico 1), para indicar que es un mensaje de posici髇 de reconocimiento.

El formato de los mensajes de posici髇 de reconocimiento de carga o borrado de CIR, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el formato de los mensajes de posici髇, definido en el apartado 3.3.6.2, con el bit de reconocimiento activado (nivel l骻ico 1), para indicar que es un mensaje de posici髇 de reconocimiento, seguido del n鷐ero CIR cargado o borrado.

En los mensajes de posici髇 de reconocimiento de carga de CIR, el campo Identidad del ELB de 32 bits, tendr� el valor del CIR cargado, indicando que el CIR ha sido cargado.

En los mensajes de posici髇 de reconocimiento de borrado de CIR, el campo Identidad del ELB de 32 bits, tendr� todos los bits a valor 0, indicando que el CIR ha sido borrado.

3.3.6.3. Formatos de los mensajes de comando de interrogaci髇.

A continuaci髇 se definen los formatos de los diferentes mensajes de comando de interrogaci髇 generados por el CSP.

3.3.6.3.1. Formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de 鷏tima posici髇.
• 2. El formato del comando de interrogaci髇 de petici髇 de 鷏tima posici髇, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. (Valor 1 = petici髇 de reconocimiento; Valor 0 = no se pide reconocimiento)
  
  MCI: 7 bits. Valor 00 (hex).

3.3.6.3.2. Formato del comando de interrogaci髇 de petici髇 de volcado de posiciones.

• 1. El ELB debe llevar implementada la capacidad de respuesta a un comando de petici髇 de volcado de posiciones.
• 2. El formato del comando de interrogaci髇 de petici髇 de volcado de posiciones, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado de este comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, y con los datos descritos a continuaci髇. Estos datos indican el tiempo inicial, el tiempo final, per韔do de muestreo y los campos que se quieren volcar, y estar醤 posicionados en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. (Valor 1 = petici髇 de reconocimiento; Valor 0 = no se pide reconocimiento)
  
  MCI: 7 bits. Valor 01 (hex).
  
  Fecha y hora inicial de la consulta; t_i.-32 bits.
  
  La estructura y subcampos de fecha y hora, tal y como se definen en el apartado 3.3.6.2.
  
  Fecha y hora final de la consulta; t_f.-32 bits.
  
  La estructura y subcampos de fecha y hora, tal y como se definen en el apartado 3.3.6.2.
  
  Per韔do de la consulta; t_m.-19 bits.
  
  Meses (valores de 0 a 6): 3 bits.
  
  D韆s (valores de 0 a 31): 5 bits.
  
  Horas (valores de 0 a 24): 5 bits.
  
  Minutos (valores de 0 a 60): 6 bits.

  Formato de la consulta: 6 bits.

  • a) Posici髇 requerida; p
    
    1 bit, posicionado a continuaci髇 de los 6 bits de los minutos del periodo de la consulta.
  • b) Rumbo requerido; r
    
    1 bit, posicionado a continuaci髇 del bit anterior.
  • c) Velocidad requerida; v
    
    1 bit, posicionado a continuaci髇 del bit anterior.
  • d) Actividad requerida; a
    
    1 bit, posicionado a continuaci髇 del bit anterior.
  • e) Estado de la antena requerido; ea
    
    1 bit, posicionado a continuaci髇 del bit anterior.
  • f) Valor de corriente de la antena requerido; ca
    
    1 bit, posicionado a continuaci髇 del bit anterior.
    
    Un valor de "1" en cualquiera de los bits de este campo indicar� la necesidad de incluir la informaci髇 a que hace referencia en el resultado de la consulta requerida. Un valor de "0" en cualquiera de los bits de este campo indicar� que se debe excluir del resultado de la consulta requerida la informaci髇 a que hace referencia el bit de formato.

3.3.6.3.3. Formato del comando de interrogaci髇 para programar intervalos de env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de que se le programen los intervalos de env韔 de mensajes de posici髇 peri骴icos mediante un comando para programar intervalos de env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para programar el intervalo de env韔 de mensajes utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. Valor = 1 (petici髇 de reconocimiento).
  
  MCI: 7 bits. Valor 02 (hex).
  
  Pperiodicidad: 11bits. (Entre 15 y 1440 minutos, con intervalos de un m韓imo de 15 minutos).

3.3.6.3.4. Formato del comando de interrogaci髇 para comenzar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de comenzar el env韔 de mensajes de posici髇 peri骴icos mediante un comando para comenzar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para que el ELB comience a enviar mensajes de posici髇 peri骴icos con el intervalo programado, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. (Valor 1 = petici髇 de reconocimiento; Valor 0 = no se pide reconocimiento)
  
  MCI: 7 bits. Valor 03 (hex).

3.3.6.3.5. Formato del comando de interrogaci髇 para parar el env韔 de mensajes de posici髇 peri骴icos.

• 1. El ELB debe llevar implementada la capacidad de parar el env韔 de mensajes de posici髇 peri骴icos mediante un comando para parar el env韔 de mensajes de posici髇 peri骴icos.
• 2. El formato del comando de interrogaci髇 para que el ELB pare de enviar mensajes de posici髇 peri骴icos con el intervalo programado, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. (Valor 1 = petici髇 de reconocimiento; Valor 0 = no se pide reconocimiento)
  
  MCI: 7 bits. Valor 04 (hex).

3.3.6.3.6. Formato del comando de interrogaci髇 para cargar CIR.

• 1. El ELB debe llevar implementada la capacidad de que le sea cargado un CIR mediante un comando para cargar CIR.
• 2. El formato del comando de interrogaci髇 para cargar un CIR al ELB, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR a cargar).
  
  Reconocimiento: 1 bit. Valor = 1 (petici髇 de reconocimiento).
  
  MCI: 7 bits. Valor 05 (hex).

3.3.6.3.7. Formato del comando de interrogaci髇 para borrar CIR.

• 1. El ELB debe llevar implementada la capacidad de que le sea borrado un CIR mediante un comando para borrar CIR.
• 2. El formato del comando de interrogaci髇 para borrar un CIR al ELB, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de la interrogaci髇 requerida ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR a borrar).
  
  Reconocimiento: 1 bit. Valor = 1 (petici髇 de reconocimiento).
  
  MCI: 7 bits. Valor 06 (hex).

3.3.6.3.8. Formato del comando para transmitir datos.

• 1. Opcionalmente el ELB puede llevar implementada la capacidad de recibir datos a trav閟 de un comando para transmitir datos.
• 2. El formato del comando de interrogaci髇 para enviar datos a un ELB, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.
• 3. El encabezado del comando de interrogaci髇 ser� del formato definido en el apartado 5.5 (MT DirectIP Header) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 4. El alineamiento de los bytes dentro del mensaje seguir� el formato especificado en el apartado 4.1.2 (Byte Alignment) del Iridium SBD DirectIP Socket Connectivity White Paper.
• 5. La informaci髇 de los datos transmitidos ir� incluida en el elemento MT Payload del mensaje MT (Mobile Terminated), tal y como se define en el apartado 5.6 (MT Payload) del Iridium SBD DirectIP Socket Connectivity White Paper, posicionada en el siguiente orden:
  
  CIR: 32 bits. (N鷐ero CIR al que va dirigido el comando).
  
  Reconocimiento: 1 bit. (Valor 1 = petici髇 de reconocimiento; Valor 0 = no se pide reconocimiento)
  
  MCI: 7 bits. Valor 07 (hex).
  
  Bytes de Datos.

3.3.6.3.9. Formato del comando de interrogaci髇 para solicitar reconocimiento.

• 1. El ELB debe llevar implementada la capacidad de enviar un mensaje independiente de reconocimiento de haber recibido correctamente el comando para solicitar reconocimiento.
• 2. El formato del comando de interrogaci髇 para solicitar reconocimiento, utilizando el servicio SBD (Short Burst Data) de Iridium, ser� el definido como MT (Mobile Terminated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper, con el bit de reconocimiento activado.
• 3. Todos los comandos de interrogaci髇 pueden llevar implementada esta capacidad.

3.3.6.4. Formato de los mensajes del tipo volcado de posiciones.

El ELB debe ser capaz de enviar mensajes conteniendo informaci髇 al CSP, utilizando el servicio SBD (Short Burst Data) de Iridium. El formato ser� el definido como MO (Mobile Originated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper.

3.3.6.4.1. Formato de los mensajes de volcado de memoria.

• 1. El ELB responder� con este mensaje a una petici髇 de volcado de posiciones, tal y como se define en (3.3.6.3.2).
• 2. Si el tama駉 del volcado requerido excediera el tama駉 m醲imo que el ELB, o el sistema de comunicaciones en su conjunto, sea capaz de transmitir, el ELB generar� cuantos mensajes MO (Mobile Originated) del tipo aqu� definido sean necesarios para remitir la totalidad del resultado del volcado.
• 3. La siguiente informaci髇, de tama駉 variable en funci髇 de los par醡etros de la consulta, formar� el elemento MO Payload del mensaje de volcado.
• 4. Se define un paquete singular de volcado como la concatenaci髇 de los siguientes campos:
  
  [CPS1] Posici髇 del buque (latitud y longitud), si p=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 39 bits, tal y como se definen en el apartado 3.3.6.2 de estas especificaciones t閏nicas.
  
  [CPS2] Rumbo del buque, si r=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 9 bits, tal y como se definen en el apartado 3.3.6.2 de estas especificaciones t閏nicas.
  
  [CPS3] Velocidad del buque, si v=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 8 bits, tal y como se definen en el apartado 3.3.6.2 de estas especificaciones t閏nicas.
  
  [CPS4] Actividad del buque, si a=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 1 bit, tal y como se define en el apartado 3.3.6.2 de estas especificaciones t閏nicas.
  
  [CPS5] Estado de la antena, si ea=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 3 bits, que definen 8 valores cualitativos de la calidad de la se馻l de la antena, variando de 000 Sin se馻l a 111 Se馻l m醲ima.
  
  [CPS6] Corriente de la antena, si ca=1 en el mensaje de interrogaci髇 de petici髇 de volcado de memoria (3.3.6.3.2). 1 bit, indicando 0 sin corriente y 1 con corriente.
  
  [CPS7] Fecha y hora de la grabaci髇 en memoria de los datos anteriores. 32 bits, tal y como se definen en el apartado 3.3.6.2 de estas especificaciones t閏nicas.
• 5. Si el formato de volcado requerido omite alguno de los datos anteriores, el paquete singular se reducir� en el tama駉 de los campos omitidos. En cualquier caso, el orden de empaquetamiento se mantendr� seg鷑

  

  
  
  Donde P (ps) denota el 韓dice de la palabra que almacena el campo singular ps.
• 6. Un mensaje de volcado de memoria contendr� la siguiente informaci髇:
  
  En primer lugar, se incluir� la informaci髇 actual del buque, con el formato definido en el apartado 3.3.6.2 punto 5 de 閟ta especificaci髇 t閏nica, incluyendo el Mensaje Codificado (MC) 50 (hex) para indicar que es un mensaje de volcado de memoria.
  
  Fecha y hora inicial de los datos del volcado. 32 bits, seg鷑 se define en (3.3.6.3.2).
  
  Fecha y hora final de los datos del volcado. 32 bits, seg鷑 se define en (3.3.6.3.2).
  
  Per韔do del volcado. 19 bits, seg鷑 se define en (3.3.6.3.2).
  
  Formato de la informaci髇 volcada. 6 bits, seg鷑 se define en (3.3.6.3.2).

  Aquellos paquetes cuya secuencia de tiempos garantiza el mayor ajuste posible a la frecuencia de muestreo requerida. Si tr es la fecha de un dato en memoria, se incluir� la secuencia de posiciones cuyos tiempos vienen dados por:

  • a) Primera posici髇, aquella cuyo tiempo de registro, tr₀, es el m醩 pr髕imo a t_i.
  • b) Siguientes posiciones, aquellas cuyo tiempo de registro tr_k cumple:

    

    
    
    y donde tr_{(k - 1)} es el tiempo de registro de la posici髇 anterior en la secuencia.�

3.3.6.5. Formato de los mensajes de error.

3.3.6.5.1. Formato del mensaje de respuesta al CSP de error en interrogaci髇 de memoria.

Ante una solicitud de volcado de posiciones, y en el caso de no ser correcta seg鷑 los criterios indicados en (3.3.5.1.1.8), el ELB responder� al CSP, utilizando el servicio SBD (Short Burst Data) de Iridium. El formato ser� definido como MO (Mobile Originated) en los apartados 4 y 5 del Iridium SBD DirectIP Socket Connectivity White Paper, con el siguiente mensaje:

En primer lugar, se incluir� la informaci髇 actual del buque, con el formato definido en el apartado 3.3.6.2 punto 5 de 閟ta especificaci髇 t閏nica, incluyendo el Mensaje Codificado (MC) 51 (hex) para indicar que es un mensaje de error en interrogaci髇 de memoria.

195 bits formados por copia del mensaje de interrogaci髇 recibido, seg鷑 se define en (3.3.6.3.2): 129 bits.

Indicaci髇 del error: 2 bits, indicando:

T_i 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.3.6.2).

T_f 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.3.6.2).

3.3.6.5.2. Formato del mensaje de respuesta de error en interrogaci髇 de memoria por el puerto de comunicaciones local.

Ante una solicitud de volcado de posiciones, y en el caso de no ser correcta seg鷑 los criterios indicados en (3.3.5.1.1.8), el ELB emitir� por el puerto de comunicaciones local el siguiente mensaje:

195 bits formados por copia del mensaje de interrogaci髇 recibido, seg鷑 se define en (3.3.6.3.2): 129 bits.

Indicaci髇 del error: 2 bits, indicando

T_i 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.3.6.2).

T_f 32 bits seg鷑 el formato completo de fecha y hora indicado en (3.3.6.2).

3.3.6.5.2. Formato del mensaje de error de carga de segundo CIR3.

En el caso de que el ELB tenga asignado un CIR y se quiera cargar otro, el ELB generar� un mensaje de error de carga de segundo CIR que incluya el CIR que estaba cargado, el CIR que se ha intentado cargar y el c骴igo de error correspondiente.

El formato de 閟te mensaje ser� el formato tipo MO (Mobile Originated), mensaje de posici髇, definido en la secci髇 3.3.6.2 de 閟ta especificaci髇 t閏nica, con la inclusi髇 del Mensaje Codificado (MC) 48 (hex) para indicar que es un mensaje de error de carga de segundo CIR.

El campo "Identidad del ELB" incluir� el CIR que estaba cargado.

El campo "CIR" incluir� el CIR que se ha intentado cargar.

3.3.7. Protocolo de identificaci髇 del inspector para el volcado de posiciones de memoria

El proceso de identificaci髇 del terminal del inspector se regir� por el siguiente protocolo:

• a) Equipos sin cifrado. El ELB generar� un n鷐ero aleatorio, de 1024 bits, que transmitir� por el puerto de comunicaciones local.
  
  El equipo del inspector realizar� el c醠culo de la funci髇 de 鷑ico sentido al resultado de concatenar los 1024 bits definidos en (3.3.5.1.3) al n鷐ero anterior, definida por el algoritmo MD5, tal y como se detalla en: RFC 1321, "The MD5 Message Digest Algorithm", Ronald Rivest, 1992.
  
  El resultado de dicho c醠culo, de 128 bits, es recibido por el ELB, que deber� comprobar su validez:
  
  Si resultara correcto, proceder� a la aceptaci髇 de un mensaje de formato (3.3.6.3.2) "Mensaje de interrogaci髇 de memoria", y a la transmisi髇 por el puerto de comunicaciones local de la informaci髇 requerida.
  
  Si resultara incorrecto, se bloquear醤 las comunicaciones por el puerto de comunicaciones local por tres minutos, transcurridos los cuales se restituir� el modo de operaci髇 normal.
• b) Equipos con cifrado. El ELB generar� un n鷐ero aleatorio, de 1024 bits, que transmitir� por el puerto de comunicaciones local.
  
  El equipo del inspector cifrar� este mensaje utilizando la clave privada del equipo
  
  El resultado de dicho c醠culo, de 1024 bits, es recibido por el ELB, que deber� comprobar su validez, descifrando el mensaje y verificando que obtiene de vuelta el n鷐ero aleatorio original:
  
  Si resultara correcto, proceder� a la aceptaci髇 de un mensaje de formato (3.3.6.3.2) "Mensaje de interrogaci髇 de memoria", y a la transmisi髇 por el puerto de comunicaciones local de la informaci髇 requerida.
  
  Si resultara incorrecto, se bloquear醤 las comunicaciones por el puerto de comunicaciones local por tres minutos, transcurridos los cuales se restituir� el modo de operaci髇 normal.�

獳NEXO III

Documentaci髇

El armador suministrar� a la Secretar韆 General del Mar la siguiente documentaci髇 para cada equipo:

• 1. Identificaci髇 del armador:
  • a) Nombre o raz髇 social
  • b) N鷐ero D.N.I.
  • c) N鷐ero C.I.F.
  • d) Domicilio
  • e) Poblaci髇
  • f) C骴igo postal
  • g) Tel閒ono fijo Tel閒ono m髒il
  • h) Fax para notificaciones en caso de fallos del equipo
• 2. Identificaci髇 del buque:
  • a) Nombre
  • b) Matr韈ula/folio
  • c) C骴igo CFPO
  • d) TRB/GT
  • e) Eslora/pp
  • f) Eslora total
  • g) Tipo de buque
  • h) Puerto Base
  • i) Modalidad de pesca
  • j) Caladero
  • k) Cofrad韆/Asociaci髇
• 3. Identificaci髇 del equipo:
  • a) Tipo de equipo: Inmarsat-C, Iridium
  • b) Empresa fabricante
  • c) Modelo
  • d) N鷐ero de serie exterior de la caja
  • e) N鷐ero de serie del transceptor Iridium (exclusivamente para equipos basados en Iridium)
  • f) Identificador Internacional Equipo Mobil (IMEI) (exclusivamente para equipos basados en Iridium)
  • g) N鷐ero de serie de Inmarsat (ISN) (exclusivamente para equipos basados en Inmarsat-C)
  • h) Tipo de terminal de comunicaciones
• 4. Instalaci髇:
  • a) Empresa instaladora
  • b) Fecha de instalaci髇
  • c) N鷐ero de m髒il de Inmarsat (IMN) (exclusivamente para equipos basados en Inmarsat-C)
  • d) Fecha de entrada en servicio
• 5. Certificados:
  • l) Certificaciones del Instituto Nacional de T閏nica Aeroespacial (INTA) y del fabricante del equipo acreditando la conformidad del mismo con las especificaciones t閏nicas establecidas en el anexo II
  • m) Certificaci髇 de la empresa instaladora de conformidad con los requisitos de instalaci髇 establecidos en el anexo II.
  • n) Certificado de alta del equipo en el servicio de comunicaciones.�