Informe CientificoTecnico Finalwebaux.cedex.es/.../INFORME_TECNICO_CIENTIFICO.pdf · 2010-11-02 ·...

INFORME CIENTÍFICO-TÉCNICO FINAL Fecha: 23-noviembre-2009

Entidad Solicitante: Portel Servicios Telemáticos S.A.

Proyecto: “Herramienta de seguridad para análisis de riesgo en instalaciones portuarias”

Nº Ref: PT-2007-023-12IEME

Informe: Informe Científico-Técnico Final

Coordinador del CEDEX D. Antonio Ruiz Mateo

Investigador Principal D. Fernando Fernández Melle

Informe Científico Técnico Final

Ref: PT-2007-023-12IEME 2


Ref: PT-2007-023-12IEME 3

ÍNDICE

1 INTRODUCCIÓN ......................................................................................... 10

1.1 Cambios................................................................................................... 11

2 DESCRIPCIÓN DEL PROYECTO ............................................................... 13

2.1 Tarea 1 – Adecuación legal, funcional y operativa................................... 13

2.1.1 Conclusiones del análisis del marco legal ........................................... 15

2.1.2 Presentación y debate con las Autoridades Portuarias ....................... 16

2.2 Tarea 2 – Requisitos, Modelo de Datos y Análisis de Casos de Uso ...... 19

2.2.1 Requisitos............................................................................................ 19

2.2.2 Modelo de Datos.................................................................................. 53

2.2.3 Análisis de casos de uso ..................................................................... 86

2.3 Tarea 3 – Modelo de Sistema................................................................ 155

2.3.1 Introducción ....................................................................................... 155

2.3.2 Elaboración del modelo de sistema................................................... 156

2.4 Tareas 4 y 5 - Desarrollo SW e Integración de sistemas ....................... 166

2.4.1 Objetivos a cumplir ............................................................................ 168

2.4.2 Grado de desarrollo ........................................................................... 173

2.4.3 Descripción científico técnica del desarrollo ...................................... 180

2.5 Tarea 6 – Despliegue del prototipo ........................................................ 232

2.5.1 Despliegue del prototipo .................................................................... 232

2.6 Tarea 7- Pruebas ................................................................................... 238

2.6.1 Pruebas ............................................................................................. 238

3 CONCLUSIONES ...................................................................................... 252

4 BIBLIOGRAFÍA .......................................................................................... 256


Ref: PT-2007-023-12IEME 4

Índice Figuras

Figura 1: Evolución de integración de sistemas ........................................................... 20

Figura 2: Componentes básicos en los tres niveles de abstracción............................. 21

Figura 3 : Modelo orientado a servicios........................................................................ 24

Figura 4: Pila de protocolos WS ................................................................................... 27

Figura 5: Elementos de SOAD ..................................................................................... 32

Figura 6: Comparativa de la implementación de los estándares WS-* por las diferentes

soluciones.....................................................................................................................37

Figura 7: Patrón de integración básico ......................................................................... 54

Figura 8: Patrón de integración arquitectura MOSCA .................................................. 55

Figura 9: Patrón de integración arquitectura MOSCA .................................................. 56

Figura 10: Arquitectura MOSCA a alto nivel................................................................. 56

Figura 11: Casos de uso Control de Acceso de Vehículos .......................................... 88

Figura 12: Caso de uso Control de Acceso de Usuarios.............................................. 88

Figura 13: Casos de uso Gestión de zonas o áreas restringidas ................................. 89

Figura 14: Casos de uso Gestión de eventos............................................................... 89

Figura 15: Diagrama de Bloques Alta de Vehículo....................................................... 91

Figura 16: Diagrama de Bloques Baja de Vehículo...................................................... 93

Figura 17: Diagrama de Bloques Modificación de Vehículo ......................................... 95

Figura 18: Acceso a área restringida............................................................................ 97

Figura 19: Alta de un área restringida .......................................................................... 98

Figura 20. Baja de un área restringida ....................................................................... 100


Ref: PT-2007-023-12IEME 5

Figura 21: Modificación de área restringida................................................................ 101

Figura 22: Alta de un usuario...................................................................................... 103

Figura 23: Baja de un usuario..................................................................................... 105

Figura 24: Modificación de un usuario con permisos de acceso ................................ 107

Figura 25. Acceso área restringida............................................................................. 110

Figura 26. Alta de un nuevo evento............................................................................ 111

Figura 27. Baja de un evento...................................................................................... 112

Figura 28. Modificación de un evento......................................................................... 114

Figura 29: Casos de uso del sistema de control de incendios ................................... 116

Figura 30: Casos de uso del sistema de monitorización de balizamiento .................. 117

Figura 31: Casos de uso de la gestión de dispositivos............................................... 118

Figura 32: Caso de uso de consulta de estado de sistema de control de incendios.. 119

Figura 33: Caso de uso alta nuevo sistema de control de incendios ......................... 121

Figura 34: Caso de uso de baja de un sistema de control de incendios existente..... 124

Figura 35: Caso de uso cambio de estado de sistema de control existente .............. 126

Figura 36: Caso de uso alta elemento de balizamiento.............................................. 127

Figura 37: Caso de uso baja elemento de balizamiento............................................. 129

Figura 38: Caso de uso de visualización de estado y características de un elemento de

balizamiento................................................................................................................ 131

Figura 39: Caso de uso de modificación estado elemento de balizamiento............... 133

Figura 40. Alta de un nuevo dispositivo...................................................................... 134

Figura 41. Baja de un dispositivo................................................................................ 135

Figura 42. Modificación de un dispositivo................................................................... 137


Ref: PT-2007-023-12IEME 6

Figura 43: Casos de uso del servicio de visualización GIS ........................................ 138

Figura 44: Caso de uso de la operación de visualización en puerto .......................... 140

Figura 45: Caso de uso de visualización de una operación de atraque ..................... 141

Figura 46: Caso de uso de la operación de visualización por temático...................... 142

Figura 47: Caso de uso de la operación de hacer zoom sobre la imagen ................. 143

Figura 48: Casos de uso del servicio de gestión de atraques .................................... 144

Figura 49: Casos de uso del servicio de gestión de las concesiones ........................ 145

Figura 50: Caso de uso lanzamiento de la aplicación GISPORT-ATRAQUES .......... 147

Figura 51: Caso de uso de la configuración de la aplicación GISPORT-ATRAQUES149

Figura 52: Caso de uso actualización de la aplicación GISPORT.............................. 151

Figura 53: Caso de uso lanzamiento de la aplicación GISPORT-Concesiones ......... 152

Figura 54: Caso de uso de configuración de la aplicación GISPORT-Concesiones .. 153

Figura 55: Caso de uso actualización de la aplicación GISPORT-Concesiones........ 153

Figura 56: Diseño de la apariencia de la pantalla principal de la herramienta ........... 157

Figura 57: Captura de la pantalla principal de la herramienta .................................... 159

Figura 58: Diseño de la aplicación de gestión de eventos ......................................... 160

Figura 59: Diseño de la pantalla de creación de nuevo evento.................................. 161

Figura 60: Captura de pantalla del listado de eventos ............................................... 162

Figura 61: Captura de pantalla de formulario para un nuevo evento ......................... 163

Figura 62: Captura de pantalla de creación de acción ............................................... 164

Figura 63: Diseño de pantalla del control de accesos ................................................ 165

Figura 64: Captura de pantalla del control de accesos .............................................. 166


Ref: PT-2007-023-12IEME 7

Figura 65: Áreas de la pantalla de la aplicación ......................................................... 178

Figura 66: Evento de un buque .................................................................................. 179

Figura 67: Evento de control de accesos ................................................................... 180

Figura 68: GUI Principal ............................................................................................. 181

Figura 69: GIS (PortMap) ........................................................................................... 182

Figura 70: Buscador de dispositivos........................................................................... 185

Figura 71: Gestión de Eventos ................................................................................... 187

Figura 72: Edición de Eventos.................................................................................... 188

Figura 73: Creación de Eventos ................................................................................. 189

Figura 74: Información de buque................................................................................ 191

Figura 75: Información de válvula............................................................................... 192

Figura 76: Información de Cámara ............................................................................. 192

Figura 77: Información de Control de Acceso ............................................................ 193

Figura 78: Sistema ControlCAM................................................................................. 195

Figura 79: Sistema CAB+ ........................................................................................... 197

Figura 80: Gestión personas ...................................................................................... 198

Figura 81: Gestión de Vehículos ................................................................................ 199

Figura 82: Gestión de dispositivos.............................................................................. 200

Figura 83: Gestión de Zonas ...................................................................................... 202

Figura 84: Gestión de Perfiles .................................................................................... 203

Figura 85: Gestión de Horarios................................................................................... 204

Figura 86: Gestión de Visitas...................................................................................... 205


Ref: PT-2007-023-12IEME 8

Figura 87: Conexion de gadgets EzWeb.................................................................... 207

Figura 88: Arquitectura ............................................................................................... 214

Figura 89: MapGadget................................................................................................ 226

Figura 90: InfoGadet................................................................................................... 228

Figura 91: EventGadet................................................................................................ 229

Figura 92: Grabaciones de seguridad ........................................................................ 231

Figura 93: Servidor Central......................................................................................... 233

Figura 94: Cámara IP ................................................................................................. 234

Figura 95: Maqueta aparcamiento.............................................................................. 235

Figura 96: Scalextric ................................................................................................... 237

Figura 97: Demostrador acceso biométrico................................................................ 237

Figura 98: Lectura correcta de matrícula y abertura de la barrera de entrada. .......... 239

Figura 99: Lectura incorrecta de matrícula y permiso de acceso denegado. ............. 240

Figura 100: Ventana de registro del nuevo perfil de usuario ...................................... 242

Figura 101: Datos de horario ininterrumpido .............................................................. 243

Figura 102: Datos de permisos de accesos a las zonas del puerto ........................... 244

Figura 103: Configuración de la cuadrícula de cámaras en formato 2x2 ................... 245

Figura 104: Acceso al portal de Atraques DUEWEB.................................................. 246

Figura 105: Acceso al portal de Gestión de Mercancías Peligrosas .......................... 247

Figura 106: Visión general del mapa del puerto ......................................................... 248

Figura 107: Información específica de un buque........................................................ 249

Figura 108: Evento de un buque en área restringida ................................................. 250


Ref: PT-2007-023-12IEME 9

Figura 109: Detalle del evento de un buque en área restringida................................ 251


Ref: PT-2007-023-12IEME 10

1 INTRODUCCIÓN

El proyecto “Herramienta de seguridad para análisis de riesgo en instalaciones

portuarias” se ha dividido en varias fases, que se asocian a las tareas representadas

en el Plan de Trabajo. Estas fases se corresponden con la metodología general de

creación de software en el que se diferencian la recopilación de requisitos de la

herramienta, el diseño del sistema en función de los requisitos, la implementación del

sistema y por último las pruebas y la implantación del sistema.

Las tareas que aparecen en el Plan de Trabajo son las siguientes:

Tarea 0 – Coordinación de Actividades. Esta tarea ha estado activa durante toda la

duración del proyecto, y con ella se ha llevado el control durante la integración de

tareas.

Tarea 1 – Adecuación legal, funcional y operativa. Se ha realizado un estudio

exhaustivo de la normativa nacional e internacional existente relativa a la seguridad en

recintos portuarios.

Tarea 2 – Requisitos, Modelo de Datos y Análisis de Casos de Uso. Se ha elaborado

el análisis de requisitos, localizando la funcionalidad necesaria para la implementación

del sistema. Se ha definido el modelo de datos, buscando siempre una estructura lo

más homogénea posible en cuanto a agrupación de datos para simplificar el diseño y

obtener un modelo eficiente y completo. Posteriormente se ha realizado el diseño de

los Casos de Uso en función de la especificación de requisitos y del modelo de datos.

Tarea 3 – Modelo del Sistema. Partiendo del diseño de los Casos de Uso se ha

generado un prototipo de la interfaz de la aplicación que ha servido de ayuda a

depurar iterativamente los errores que no se detectaron durante las fases anteriores.

Esta tarea generó cambios en el Modelo de Datos y en los Casos de Uso. Con Modelo

de Sistema entendemos un diseño inicial del interfaz, vacío de funcionalidades, que

servirá para detectar necesidades de la aplicación no encontradas hasta el momento.

Tarea 4 – Desarrollo UML. Una vez definidos los Casos de Uso se comenzó con la

implementación de las funcionalidades. Se generó el código siguiendo un sistema

modular y a la finalización de cada módulo se realizan pruebas unitarias para

confirmar el buen funcionamiento de la implementación. La depuración del desarrollo


Ref: PT-2007-023-12IEME 11

se fue haciendo en un proceso iterativo, de forma que se fue refinando la aplicación

poco a poco.

Tarea 5 – Integración de Sistemas. A medida que se iban desarrollando módulos

funcionales, se iba haciendo la integración con el esto de módulos del sistema y se

realizaron pruebas para comprobar el correcto funcionamiento del mismo.

Tarea 6 – Despliegue del demostrador. Se ha realizado la integración de cada uno de

los componentes hardware que representan una pequeña parte de los sistemas que

podemos encontrar en un puerto real. También se ha llevado a cabo la integración de

dichos componentes con los módulos software que los gestionan.

Tarea 7 – Desarrollo de un Plan de Implantación. Por último se ha preparado y

aplicado una batería de pruebas a cada uno de los módulos que forman parte del

sistema y también al sistema completo. Así se prueba el funcionamiento global de la

herramienta y se constata el correcto comportamiento de la misma en un entorno de

pruebas lo más parecido a la situación real en un puerto. No se ha podido preparar un

plan de implantación ya que no teníamos un puerto real que ofreciera sus

instalaciones para poner en funcionamiento una herramienta en fase de desarrollo.

1.1 Cambios

Desde el comienzo del proyecto, se han producido algunos cambios relativos al Plan

de Trabajo inicial presentado en la solicitud de ayuda del proyecto y en el equipo de

trabajo encargado del desarrollo del mismo.

La modificación del Plan de Trabajo tiene como objetivo solventar algunos

planteamientos erróneos. En la solicitud inicial, las tareas a realizar estaban

diferenciadas según la temática correspondiente (módulo de control de accesos,

módulo de control de vehículos, módulo de video vigilancia…) sin tener en cuenta la

posible duplicación de datos y la reutilización de la información para gestionarla

eficientemente. Puesto que en este proyecto se pretenden integrar los sistemas

utilizados en las entidades portuarias en una sola plataforma que permita el control y

acceso total sobre varios procesos, y los sistemas que actualmente se encuentran en

explotación pueden ser de diversa naturaleza y estar implementados sobre


Ref: PT-2007-023-12IEME 12

plataformas muy dispares (desde un Sistema de Información propietario hasta el

proceso manual de formularios en papel), se ha considerado que las tecnologías a

utilizar deben proporcionar la agilidad y flexibilidad necesaria para poder abstraer

todos los procesos que actualmente se llevan a cabo e integrarlos en una plataforma

que satisfaga los requisitos de este proyecto.

Por ello se llegó a la conclusión que para generar una herramienta potente y sólida era

necesario realizar un análisis SOA (Service Oriented Architecture) puesto que la

herramienta final estará formada por varios servicios independientes, algunos

existentes de forma previa y otros creados a propósito, que deben ser capaces de

trabajar de forma conjunta en caso necesario. Para poder desarrollar una herramienta

software es necesario utilizar un método de trabajo adecuado para esta función. Por

ello se planteó el cambio a un Plan de Trabajo específico para la creación de software

que suponía diferenciar las tareas de extracción de requisitos, análisis y diseño de los

datos, definición de casos de uso, implementación del código y generación de baterías

de pruebas unitarias, modulares y de implantación. Así pues utilizando este proceso

iterativo de generación de aplicaciones generamos código más eficiente, mayor

homogeneidad en el modelo de datos y una menor tasa de fallos en el sistema final.

Otros cambios asociados al desarrollo del proyecto han sido los relativos al personal.

Estos cambios han sido solventados con la incorporación al proyecto de personal

altamente cualificado y con una titulación similar o superior a los participantes que han

causado baja en el proyecto.

Todos los cambios realizados tanto en el Plan de Trabajo como en el equipo de

personal encargado no suponen la modificación de los costes asociados al proyecto

aunque sí están generando dificultades para mantener los plazos estipulados en el

proyecto inicial.

En vistas a una futura implantación comercial de la herramienta se ha decidido buscar

un nombre para la misma y se ha concretado que sea MOSCA, Monitorización y

Operación de los Servicios de Control y Análisis de Riesgo. Esto es un cambio que no

supone modificación alguna en el desarrollo, pero es necesario tener en cuenta que en

el documento se usa este nombre para referirse a la aplicación que se está

desarrollando.


Ref: PT-2007-023-12IEME 13

2 DESCRIPCIÓN DEL PROYECTO

Para poder tener una visión completa del desarrollo que se ha seguido durante todo el

proyecto, se pasa a describir cada una de las tareas llevadas a cabo, tratando así de

mostrar no solo el alcance obtenido, sino también el proceso seguido para la obtención

de la aplicación final.

2.1 Tarea 1 – Adecuación legal, funcional y operativa

La adecuación al marco legal es una tarea importante dentro de este proyecto puesto

que los principales objetivos del desarrollo de la aplicación son facilitar la implantación

de todas las normativas vigentes nacionales e internacionales relativas a los sistemas

de seguimiento e información de tráfico marítimo, la incorporación de medidas para la

mejora de la protección de los puertos y del transporte marítimo y la gestión de las

mercancías peligrosas cuando se encuentran en el ámbito portuario.

La legislación vigente relativa a los temas antes descritos puede encontrarse en los

siguientes documentos:

Convenio SOLAS y el código PBIP de la OMI. La Organización Marítima

Internacional (OMI) adoptó, en la Conferencia de los Gobiernos contratantes

del Convenio Internacional para la seguridad de la vida humana en el mar

(Convenio SOLAS), 1974, celebrada del 9 al 13 de diciembre de 2002, un

conjunto de resoluciones dirigidas a regular la mejora de la protección del

transporte marítimo. Entre ellas cabe destacar la referente a la adopción de un

Código Internacional para la protección de los buques y de las instalaciones

portuarias (Código PBIP o ISPS). Con todo ello se pretende mejorar la

protección de los buques utilizados en el comercio internacional y la protección

de las instalaciones portuarias asociadas a los mismos a través de una interfaz

buque-puerto.

DIRECTIVA 2005/65/CE del Parlamento Europeo y del Consejo de 26 de

octubre de 2005 sobre mejora de la protección portuaria. La Unión Europea

aprobó esta directiva con el objetivo de introducir en el ámbito comunitario

medidas para mejorar la protección de los puertos frente a la amenaza de

sucesos que afecten a la protección marítima, con lo que se asegura que las


Ref: PT-2007-023-12IEME 14

medidas de protección establecidas por el Reglamento 725/2004 se beneficien

adicionalmente de una mejora en la protección aplicada al resto de la zona de

actividades portuarias. La Directiva establece el desarrollo y aplicación de un

plan de protección portuaria, fundamentado en el resultado de la evaluación de

riesgos de amenazas de sucesos contra la protección marítima, incluyendo

instalaciones portuarias.

Reglamento (CE) 725/2004 relativo a la mejora de la protección de los buques

y las instalaciones portuarias. Este reglamento tiene como principal objetivo

instaurar y aplicar medidas comunitarias que mejoren la protección de los

buques utilizados tanto en comercio internacional como en el tráfico nacional,

así como las instalaciones portuarias asociadas a los mismos, frente a la

amenaza de actos ilícitos deliberados.

Ley 48/2003 de Régimen Económico y de Prestación de Servicios en los

Puertos de Interés General. Dentro de esta ley se clarifican los servicios

portuarios ofrecidos, clasificados en diferentes tipos, y los regímenes de

acceso a dichos servicios. También incluye esta legislación el régimen

económico del sistema portuario de titularidad estatal y el régimen de

planificación, presupuestario, tributario, de funcionamiento y de control, aunque

estos apartados tienen una menor aplicación en el desarrollo del proyecto.

Ley 31/1995 de prevención de riesgos laborales en la que se establece la

normativa de prevención de riesgos derivados del trabajo y que desarrolla las

acciones preventivas en coherencia con las decisiones de la Unión Europea

para la mejora progresiva de las condiciones de trabajo en los diferentes

países europeos.

Ley 2/1985 de 21 de Enero sobre Protección Civil donde se establece el marco

institucional adecuado para poner en funcionamiento el sistema de protección

civil enfocado a la autoprotección y basando todas las actuaciones dentro del

respeto del principio de legalidad previsto constitucionalmente.

Real Decreto 145/1989. Reglamento de Admisión, Manipulación y

Almacenamiento de Mercancías Peligrosas en Puertos. Este decreto engloba

todas las obligaciones relativas a los buques, gabarras, ferrocarriles incluso


Ref: PT-2007-023-12IEME 15

operadores de muelles o terminales que operen con mercancías peligrosas,

además de ofrece una clasificación exhaustiva de las mismas y referencias a

cómo deben ser manipuladas.

Real Decreto 393/2007 por el que se aprueba la Norma Básica de

Autoprotección de los centros, establecimientos y dependencias dedicados a

actividades que puedan dar origen a situaciones de emergencia.

Real Decreto 1617/2007 por el que se establecen medidas para la mejora de la

protección de los puertos y del transporte marítimo (transposición de la

Directiva 2005/65/CE).

Real Decreto 210/2004, de 6 de febrero, por el que se establece un sistema de

seguimiento y de información sobre el tráfico marítimo en aguas en las que

España ejerce soberanía, derechos soberanos o jurisdicción, con la finalidad

de incrementar la seguridad marítima y la eficacia de dicho tráfico, mejorar la

capacidad de respuesta de la Administración marítima a los problemas,

accidentes o situaciones potencialmente peligrosas en el mar, incluidas las

operaciones de búsqueda y rescate y contribuir a una más temprana detección

y a una mejor prevención de la contaminación que pueda ser ocasionada por

los buques.

2.1.1 Conclusiones del análisis del marco legal

Del análisis del marco legal descrito, se extraen las siguientes conclusiones:

No existe impedimento legal alguno para la puesta en operación de la

herramienta objeto del proyecto.

Aunque son responsables de ello, las Autoridades Portuarias tienen delegada

la función de control de tráfico marítimo en aguas de servicio a Sasemar, a

través de convenios específicos, si bien monitorizan el mismo a través de los

sistemas AIS.

Las Autoridades Portuarias son responsables de la seguridad contra

accidentes, seguridad contra actos ilícitos y conservación de las

infraestructuras en el recinto portuario.


Ref: PT-2007-023-12IEME 16

Las Autoridades Portuarias controlan el tráfico de buques, en lo relativo a

escalas, manifiestos y mercancías peligrosas, con objeto de facilitar su entrada

y salida en los recintos portuarios.

Las Autoridades Portuarias son responsables de los flujos terrestres de

vehículos, personas y mercancías, debiendo establecer los sistemas que

permitan su control.

No existe recomendación o norma específica que determine la conveniencia de

la integración de servicios de tráfico de buques, seguridad contra accidentes

(safety), seguridad contra actos ilícitos (security) y conservación en un Centro

de Control o Coordinación de Servicios.

Puertos del Estado lleva tiempo trabajando en definir las funciones de los

Centros de Control y Coordinación de Servicios, si bien los resultados de este

trabajo no son públicos todavía (Portel no ha podido acceder a ellos).

2.1.2 Presentación y debate con las Autoridades Portuarias

También fue importante la decisión de organizar visitas a varias Autoridades

Portuarias para extraer información de primera mano sobre los problemas de

seguridad que encuentran los responsables de la misma, en sus actividades

cotidianas. Esta decisión obligó al replanteamiento de requisitos para adaptarlos a las

necesidades que se establecen imprescindibles para la seguridad.

Con objeto de contrastar la línea de trabajo del proyecto, en lo relativo a la concepción

de la herramienta de análisis de riesgos, a sus objetivos y alcance, y a su

funcionalidad y tecnología, se han realizado diversas acciones, entre las que destacan

las siguientes:

Elaboración de folletos descriptivos del proyecto en español e inglés.

Presentación del proyecto en la feria internacional de terminales marítimas

TOC EUROPE 2008, celebrada en Amsterdam en junio de 2008, en el stand de

Portel


Ref: PT-2007-023-12IEME 17

Reunión con representantes de la Autoridad Portuaria de Rotterdam en la que

se comentaron, entre otros, aspectos relativos a la integración de servicios de

explotación y seguridad en una sola herramienta. La Autoridad Portuaria de

Rotterdam nos presentó una de las herramientas de que disponen en el Centro

de Control, que integra tráfico de buques con seguimiento y control de

mercancías peligrosas y escalas. Los datos de tráfico de buques son obtenidos

de sus sistemas VTS y AIS y de los procesos EDI de su Port Community

System (anteriormente Port-Infolink, denominado PortBase en la actualidad).

La aplicación muestra la información mediante tecnología GIS. Sus sistemas

de CCTV y Control de Accesos no están integrados en dicho sistema.

Presentaciones específicas del proyecto y discusión sobre el contenido del

proyecto en Puertos del Estado y en la siguientes Autoridades Portuarias:

Alicante

Almería

Avilés

Cartagena

Ceuta

Coruña

Málaga

Melilla

Valencia

Ni Puertos del Estado ni ninguna de las Autoridades Portuarias ha expresado interés

en que integre datos radar del VTS dado que no disponen de personal cualificado para

operar una estación de estas características, siendo operadas por Sasemar a través

de convenios específicos, si bien integrar los datos AIS con la Ventanilla Única y los

sistemas de seguridad y conservación se considera de interés para sus Centros de

Control, ya que carecen de dichas prestaciones en la actualidad. De igual forma

recomiendan la utilización de tecnología GIS para la monitorización de la información.


Ref: PT-2007-023-12IEME 18

Presentación del proyecto en el Grupo de Trabajo de Seguridad del Comité de

Usuarios de Autoridades Portuarias, en el que participan las Autoridades

Portuarias de Algeciras, Málaga, Cartagena, Tarragona, Las Palmas, Puertos

del Estado, Santander y Gijón que conforman su Junta Directiva. Durante esta

reunión se recomendó la presentación del proyecto al conjunto de Autoridades

Portuarias durante las jornadas de trabajo de la Asamblea General de dicho

Comité, dado su interés.

Presentación del proyecto en la Asamblea General del Comité de Usuarios de

Autoridades Portuarias celebrado en noviembre de 2008. En general, las

Autoridades Portuarias expresaron su interés por el proyecto y por la

herramienta que eventualmente se va a poner en el mercado.

Las conclusiones de todas estas reuniones y presentaciones se pueden resumir en los

siguientes puntos:

La herramienta objeto del proyecto presenta funcionalidades y prestaciones de

interés para las autoridades portuarias

No existe una herramienta estándar similar, si bien las Autoridades Portuarias

de Barcelona, Valencia y Algeciras tienen experiencia con desarrollos que

cubren la integración entre AIS e información de escalas y mercancías

peligrosas, y la de Valencia con información relativa a los sistemas de señales

marítimas y ayudas a la navegación

Es conveniente la utilización de tecnología de representación gráfica, GIS o

similar

Si bien, no interesa la integración con las estaciones de radar o VTS, la

funcionalidad presentada es adecuada para este tipo de herramienta


Ref: PT-2007-023-12IEME 19

2.2 Tarea 2 – Requisitos, Modelo de Datos y Análisis de Casos de

Uso

2.2.1 Requisitos

2.2.1.1 Estado del Arte

Se va a proceder a describir las tecnologías e infraestructuras de uso que se quieren

utilizar. A nivel tecnológico se describen las tecnologías a utilizar como base del

proyecto ya que son comunes a los diferentes módulos que compondrían la aplicación

(Módulo de Seguridad, Módulo de Conservación, Módulo de Control de Tráfico de

Buques y Módulo de Conservación). El nivel de infraestructuras describe aquellas que

podrían utilizarse en la implementación de cada módulo, aunque las infraestructuras

que se utilicen en el último momento dependerán de cada Autoridad Portuaria de

forma independiente.

2.2.1.1.1 TECNOLOGÍAS

Arquitecturas Orientadas a Servicios

De forma resumida, podemos decir que la arquitectura orientada a servicios (SOA) es

un enfoque para la construcción de software donde la funcionalidad se agrupa en

procesos de negocio y se empaqueta como servicios autónomos e interoperables. Por

tanto, generalizando, una arquitectura SOA describe la infraestructura IT que permite a

diferentes aplicaciones intercambiar datos entre sí, cuando estos están ejecutando

esos procesos de negocio.

SOA supone una estrategia general de organización de los elementos de IT, de forma

que una colección de sistemas distribuidos y aplicaciones complejas se pueda

transformar en una red de recursos integrados simplificada y flexible. SOA establece

un marco de diseño para la integración de aplicaciones independientes de manera que

desde Internet pueda accederse a sus funcionalidades, las cuales se ofrecen como

servicios. La solución final se compone, en general, de servicios desarrollados en

diferentes lenguajes de programación, ubicados en plataformas muy dispares, con

distintos modelos de seguridad y procesos de negocio.

Este concepto, que en un principio suena bastante complejo, no es nuevo. Algunos

argumentan que SOA se ha desarrollado basándose en experiencias asociadas con el


Ref: PT-2007-023-12IEME 20

diseño y desarrollo de sistemas distribuidos y con tecnologías disponibles en el

pasado. De hecho, muchos de los conceptos asociados con SOA, como servicios,

descubrimiento o invocación estaban asociados con CORBA y DCOM. De forma

similar, muchos de los principios de diseño tienen mucho en común con técnicas

OOA/OOD (Análisis y Diseño Orientado a Objetos) basadas en encapsulación,

abstracción e interfaces bien definidas. La Figura 1 muestra cómo ha evolucionado en

el proceso de integración de aplicaciones monolíticas. Desde el desarrollo basado en

componentes hasta la orientación a servicios que ofrece mayor flexibilidad.

Figura 1: Evolución de integración de sistemas

Aunque SOA tiene diferentes definiciones dependiendo del nivel de abstracción con el

que se trabaje. Zimmerman[8] propone tres definiciones según el nivel de abstracción

considerado:

Analista de Dominio (Business Domain Analyst): a este nivel de abstracción se

define SOA como un conjunto de servicios que la lógica de negocio ofrece a

sus clientes, socios u otras partes de la organización.

Arquitecto IT (IT Architecture): el arquitecto de IT ve SOA como un conjunto de

patrones de arquitectura tales como el Enterprise Service Bus (ESB),

composición de servicios, registro de servicios, etc. Haciendo uso de ellos


Ref: PT-2007-023-12IEME 21

promueve los principios de modularidad, diseño en capas y débil acoplamiento

que caracterizan una solución SOA para conseguir los objetivos de

reusabilidad, flexibilidad y modularidad en el diseño de la arquitectura.

Desarrollador/Administrador (Developer/Administrator): Desde el punto de vista

del desarrollador SOA es un conjunto de estándares, herramientas y

tecnologías que permiten la implementación de Servicios Web.

Figura 2: Componentes básicos en los tres niveles de abstracción

En la Figura 2 podemos ver los componentes básicos asociados a cada nivel de

abstracción.

Otras definiciones muy extendidas de SOA son:

W3C[9]: De acuerdo con el W3C, una arquitectura orientada a servicios,

especifica un conjunto de componentes cuyas interfaces se pueden describir,

publicar, descubrir e invocar a través de la red. SOA promueve el desarrollo de

software que impulse la construcción de sistemas dinámicos fácilmente

adaptables a entornos volátiles y de fácil mantenimiento.


Ref: PT-2007-023-12IEME 22

OASIS[7]: Un paradigma para organizar y utilizar aplicaciones distribuidas que

además están bajo el control de diferentes propietarios y dominios. Manera

uniforme de ofrecer, descubrir, interactuar y usar dichas capacidades y producir

los efectos deseados de manera consistente y medible.

A continuación se enumeran los principios de diseño que deben guiar el desarrollo,

mantenimiento y uso de una arquitectura SOA.

Modularidad. El principio de modularidad que debe estar presente en una

solución SOA va intrínsecamente ligada a la definición de servicio en tanto que

el mismo debe proporcionar cierta funcionalidad que hace que un conjunto de

servicios pueda ser visto como un conjunto de módulos independientes. La

modularidad en una aplicación SOA ayuda a la modificabilidad del mismo y a

su reutilización.

Reutilización. El hecho de que una aplicación SOA sea modular y proporcione

una serie de servicios independientes ayuda en la reutilización de estos

servicios tanto en la composición de servicios de más alto nivel como su

reutilización en otras soluciones SOA.

Composición. En una solución SOA los servicios pueden unirse y proporcionar

servicios de más alto nivel.

Acoplamiento débil. Los servicios deben mantener una relación en la que se

minimice las dependencias entre ellos. Un servicio sólo debe saber que otro

servicio existe.

Granularidad. Se refiere al alcance en la funcionalidad de servicio que éste

ofrece al mundo exterior. Se debe estudiar con detenimiento el grado de

granularidad que deben tener cada uno de los servicios en la solución que se

plantee.

Sin estado (stateless). Los servicios en una solución SOA son sin estado, es

decir, los servicios no dependen de ninguna condición con respecto a cualquier

otro servicio. Reciben toda la información necesaria a través de su interfaz y

proporcionan una respuesta a la petición.


Ref: PT-2007-023-12IEME 23

Interoperabilidad y Cumplimiento de estándares. Una solución SOA que

utiliza estándares en su implementación e implantación proporciona

interoperabilidad tanto en la propia solución SOA (interoperabilidad entre

servicios) como con otras soluciones incluso que no sean SOA.

Gestión de Servicios (Categorización de servicios, identificación, provisión y

entrega, monitorización y tracking). La gestión de los servicios es vital para que

tanto usuarios como otros servicios puedan utilizarlos.

Adicionalmente cualquier solución SOA debe dar soporte a las siguientes actividades

básicas:

Creación de servicios. En una solución SOA alguien debe ocuparse de la

creación del servicio en sí, por ejemplo, en el caso del control de accesos la

creación de los servicios puede estar a cargo de diferentes entidades; la

entidad A puede crear un servicio biométrico para verificación de identidades

mediante biometría facial, la entidad B puede proporcionar también un servicio

de verificación de identidades pero mediante comprobación de credenciales

con tarjeta de identificación, etc.

Descripción de servicios. El servicio debe de estar descrito en alguna parte.

Esta descripción indica qué hace el servicio y cómo se puede acceder a él

(Contrato). Cada uno de los servicios debe tener una interfaz que indique qué

es lo que ofrece y qué parámetros necesita para poder acceder a él, así como

la información que devuelve. En el caso de servicios de control de acceso

puede ser interesante saber, por ejemplo, el formato de los datos y el tipo de

encriptación utilizada.

Publicación de servicios (repositorios en intranet o Internet) para que

potenciales usuarios puedan localizarlos. Para que un servicio pueda ser

utilizado debe estar público.

Descubrimiento de servicios por potenciales usuarios. Para que un servicio

pueda ser utilizado debe ser descubierto. Alguna entidad debe proporcionar

ese descubrimiento. En Internet existen entidades para el descubrimiento de

servicios, aunque en el control de accesos el caso general es que el usuario

que desee el servicio contacte directamente con el proveedor del servicio y


Ref: PT-2007-023-12IEME 24

facilite al usuario los datos (contrato, políticas de acceso, etc.) para su

utilización.

Invocación de servicios. En la descripción del servicio se indica la forma de

invocarlo (Contrato).

Figura 3 : Modelo orientado a servicios

Actualización de servicios (así como baja del servicio (unpublishing)), en

caso de que el servicio no esté disponible o los requerimientos hayan

cambiado.

Además de estas actividades básicas existen otras actividades que se deben llevar a

cabo: composición, gestión y monitorización, facturación y seguridad.

En cualquier caso, toda arquitectura SOA requiere al menos las siguientes actividades

básicas:

Descripción.

Publicación/Actualización/baja (unpublishing).

Invocación/bind de servicios.

Estas tres actividades básicas implican tres roles: Service Provider (proveedor de

servicios), Service Requester (Solicitante de servicios) y el Service Broker. En la

Figura 3 se puede ver una representación gráfica de los tres roles así como la

interacción entre ellos.


Ref: PT-2007-023-12IEME 25

De forma resumida podemos describir los tres roles como sigue:

Service Provider: En una solución SOA, un proveedor de servicios es la parte

que proporciona las aplicaciones software como servicios. El Service Provider

publica, actualiza y da de baja los servicios. Desde la perspectiva de la

arquitectura SOA, esta es la plataforma que de alguna manera hace de

middleware entre el Service Requester y la máquina que contiene la

implementación del servicio.

Service Requester: El Service Requester es la parte solicitante que tiene una

necesidad funcional que se satisface a través de algún servicio disponible en

Internet. Desde una perspectiva arquitectónica esta es la aplicación que busca

e invoca al servicio. El que solicita el servicio puede ser un usuario accediendo

al servicio a través de una aplicación de escritorio, un navegador wirelesss o

cualquier otro servicio. La petición encuentra los servicios requeridos a través

del Service Broker y enlaza con los servicios vía el Service Provider.

Service Broker: Un Service Broker proporciona un repositorio de

descripciones de servicios donde los proveedores de servicios publican sus

servicios y los Service Requesters los encuentran y obtienen la información

relevante que los une. El repositorio debe ser susceptible de hacer búsquedas

en él. Es como las páginas amarillas de los servicios (un ejemplo de ello en el

caso de los servicios Web es el UDDI-Universal Description, Discovery and

Integration-). En algunos casos el Service Broker no es un elemento necesario,

ya que los servicios se pueden descubrir vía medios de comunicación y

marketing o referencias a otros proveedores de servicios.

Para terminar de entender el concepto de SOA es necesario saber qué entendemos

por servicio. La sección siguiente se ocupa de este aspecto concreto.

Servicios Un servicio es una funcionalidad concreta que puede ser descubierta en la

red y que describe tanto lo que puede hacer el servicio, como el modo de interactuar

con él. Desde la perspectiva de un negocio, el servicio realiza una tarea concreta;

puede corresponder a un proceso de negocio tan sencillo como introducir o extraer un

dato o realizar un cálculo específico.


Ref: PT-2007-023-12IEME 26

Además, la estrategia de orientación a servicios permite la creación de servicios y

aplicaciones compuestas (composición de servicios) que pueden existir con

independencia de las tecnologías subyacentes. En lugar de exigir que todos los datos

y lógica de negocio residan en un mismo ordenador, el modelo de servicios facilita el

acceso y consumo de los recursos de IT a través de la red. Puesto que los servicios

están diseñados para ser independientes, autónomos y para interconectarse

adecuadamente, pueden combinarse y recombinarse con suma facilidad en

aplicaciones complejas que respondan a las necesidades de cada momento en el

seno de una organización.

Así, cada uno de los recursos de software se convierte en un pilar para desarrollar

otras aplicaciones, reduciendo la complejidad de los sistemas utilizando un estilo

común de interacción que funciona tanto con código nuevo como legado. SOA no está

unida a una tecnología específica y puede ser implementada utilizando un amplio

rango de tecnologías entre las que se incluye por ejemplo, SOAP, REST, RPC,

DCOM, CORBA, Web Services o WCF. Aunque la forma más habitual de implementar

SOA es mediante Servicios Web, una tecnología basada en estándares e

independiente de la plataforma con la que SOA puede descomponer aplicaciones

monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma

modular. A continuación se describe con más detalle esta opción tecnológica.

Servicios web Un Servicio Web[4] es un sistema software diseñado para dar soporte

a la interacción entre máquinas en la red. Un servicio Web se describe por una interfaz

en un formato procesable por la máquina (WSDL). Otros sistemas interactúan con el

Servicio Web como se indica en su descripción utilizando mensajes SOAP,

típicamente utilizando HTTP con una serialización XML en conjunción con otros

estándares Web

El principal objetivo de los Servicios Web es crear piezas funcionales de software

independientes de plataforma, y que sean accesibles en Internet (utilizando protocolos

estándares). Es precisamente la pila de protocolos en servicios Web (ver Figura 4) la

que proporciona la tecnología que da soporte al diseño de un modelo orientado a

servicios.


Ref: PT-2007-023-12IEME 27

Figura 4: Pila de protocolos WS

La Figura 4 muestra una representación gráfica de cómo todas las categorías de

estándares y especificaciones se adaptan dentro del contexto del marco de Servicios

Web.

La pila de protocolos para Servicios Web es una colección de protocolos que se

utilizan para definir, implementar, descubrir Servicios Web e interactuar entre ellos. La

pila de protocolos engloba principalmente las siguientes áreas:

Transporte. Responsable del transporte de mensajes entre las aplicaciones de

red y los protocolos en los cuales se incluyen como HTTP, SMTP, FTP, así

como también el más reciente Blocks Extensible Exchange Protocol (BEEP).

Mensajería XML: responsable por la codificación de mensajes en un formato

común XML de forma que puedan ser entendidos en cualquier extremo de una

conexión de red. Actualmente, esta área incluye protocolos tales como XML-

RPC, SOAP y REST.


Ref: PT-2007-023-12IEME 28

Descripción del Servicio: utilizado para describir la interfaz pública de un

Servicio Web específico. El formato de interfaz Web Services Description

Language (WSDL) es típicamente utilizado para este propósito.

Descubrimiento de servicios: centraliza servicios en un registro común tal

que los servicios Web de la red puedan publicar su localización y descripción, y

hace que sea fácil descubrir qué servicios están disponibles en la red.

Actualmente, la API Universal Description Discovery and Integration (UDDI) se

utiliza para el descubrimiento de servicios.

Seguridad: Conjunto de protocolos destinados a dar soporte de seguridad en

servicios Web.

La Pila de Protocolos para servicios también incluye un amplio rango de protocolos

recientemente definidos: Business Process Execution Language - BPEL, SOAP

Security Extensions: Digital Signature- SOAP-DSIG.

Seguridad en el acceso a la información y las comunicaciones La seguridad en el

acceso a la información y las comunicaciones es otro factor muy importante a tener en

cuenta, ya que se pretende poder acceder remotamente al sistema. Además cada

sistema actualmente en uso puede tener sus propios requisitos de seguridad (por

ejemplo solicitar un nombre de usuario y contraseña) con lo cual se requiere de un

sistema que permita gestionar las credenciales de los usuarios para identificarse una

sola vez (en lugar de tener que volver a identificarse para acceder a los diferentes

sistemas que se van a integrar en la arquitectura). Para este propósito se pueden

utilizar tecnologías .NET Passport, entre otras.

Los niveles de seguridad que se deben contemplar son los siguientes:

Seguridad a nivel de aplicación

Autenticación de usuarios ante la plataforma mediante mecanismos

seguros (login y contraseña, certificados digitales, DNI-e, etc), que permitan

identificar al usuario y presentarle únicamente la información a la que tiene

acceso, salvaguardando la confidencialidad del resto de datos.

Protocolos seguros de comunicación entre los diferentes sistemas que

interoperan con la plataforma.


Ref: PT-2007-023-12IEME 29

Canales de comunicación encriptados y seguros: HTTP con autenticación

(RFC 2617), HTTPS (RFC 2812).

Desarrollo e integración del software bajo pautas de calidad:

Revisión del código fuente.

Testeo de la aplicación.

Búsqueda de vulnerabilidades.

Seguridad a nivel de red:

Firewalls.

Sistemas de detección de intrusos en red.

Dispositivos de Control de Acceso.

Network Assessment, con el fin de evaluar y ajustar las prestaciones

del acceso en red.

Seguridad a nivel de servidor (de sistema operativo):

Autenticación de usuarios.

Sistema de detección de intrusos en host.

Chequeo de Integridad de Archivos.

Host Assessment, con el fin de evaluar y ajustar las prestaciones de

los servidores.

Servicios web de MOSCA Cuando se revisan las soluciones que actualmente se

utilizan en los Puertos para las diferentes áreas que componen el sistema, queda

patente que para determinar cómo los WS (Web Services) pueden encajar en la

solución, necesitamos analizar la implementación o la ejecución de dichas soluciones.

De esta forma podemos hacernos una idea de en qué parte de la solución podemos

usar los WS para mejorar los beneficios que la solución ofrece por sí misma.

Como norma general, los WS afectarán a la implementación e integración de nuestras

aplicaciones donde quiera que haya un punto a través del cual deba intercambiarse

información. Los WS están diseñados para conseguir ciertos beneficios en cuanto a la

interoperabilidad y flexibilidad en la información que se transmite a través de esos

puntos. Sin embargo, es importante destacar que la decisión de aplicar o no los WS a

esos puntos depende por entero de los requisitos individuales de cada solución. En

cualquier caso, hay un beneficio directo de la aplicación de WS: cualquier cambio que


Ref: PT-2007-023-12IEME 30

se realice en las aplicaciones finales (migración a un nuevo sistema de BBDD, uso de

una nueva infraestructura, etc.) sería factible sin la necesidad de cambios en la parte

del cliente.

Por supuesto, el poder adaptar el sistema para utilizar los WS acarrea una carga de

trabajo considerable. Para poder justificar mejor el esfuerzo a realizar, vamos primero

a revisar los principales beneficios derivados de la aplicación de las tecnologías de

WS:

Ayudan a reducir la complejidad encapsulando los procesos de negocio dentro

de componentes reutilizables.

Ayudan a mejorar la interoperabilidad actuando como un wrapper para

aplicaciones específicas para una plataforma.

Pueden usarse de forma conjunta, componiéndolos para realizar funciones de

negocio de alto nivel.

Ayudan a ocultar los detalles de implementación definiendo interfaces

estandarizados o bien conocidos.

Permiten una integración just-in-time promoviendo el acoplamiento débil y la

vinculación dinámica.

Son neutrales respecto a la implementación y a la plataforma, con lo que

realmente promueven la interoperabilidad.

Promocionan el uso de estándares de Internet existentes y bien establecidos.

Una vez visto en qué consiste el concepto de SOA y su implementación más común

(los servicios Web) el siguiente punto indica brevemente un listado de arquitecturas de

referencia SOA y tecnologías para poner en práctica el diseño y la implantación de una

solución SOA.

METODOLOGÍAS SOA DE REFERENCIA Este apartado recoge, de forma resumida,

las principales metodologías SOA para que puedan tenerse en cuenta en la elección

de la arquitectura MOSCA. La metodología de modelado y diseño para aplicaciones

SOA se conoce como análisis y diseño orientado a servicios.


Ref: PT-2007-023-12IEME 31

El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en

términos de planificación, herramientas e infraestructura. Para que un proyecto SOA

tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta

mentalidad de crear servicios comunes que son orquestados por clientes o middleware

para implementar los procesos de negocio.

La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de

software como un marco de trabajo de implantación. Las metodologías de desarrollo

de software orientadas a servicios han tenido en los últimos tiempos una gran

aceptación apareciendo, tanto en entornos académicos como en el mundo

empresarial, multitud de arquitecturas de referencia para soluciones SOA junto con su

correspondiente metodología de desarrollo de software.

Estas metodologías son útiles para los proyectos de integración de aplicaciones

empresariales (EAI) y el desarrollo de sistemas Business to Business (B2B). Algunos

ejemplos de estas metodologías son: SAE Service Architecture and Engineering

(CBDI)[3], SMART - Service Oriented Migration and Reuse Technique (SEI) [6], SOAD

- Service-Oriented Analysis and Design (IBM)[5], SODA - Service-Oriented

Development of Applications (Gartner)[4], SOMA - Service-Oriented Modeling and

Architecture (IBM)[5], RUP for SOA (IBM)[5].

A continuación se describen brevemente las más representativas:

SOAD Creado por IBM, SOAD es un enfoque que contiene elementos de OOAD, BPM

y EA (Enterprise Architecture) y los complementa con ciertos elementos innovadores,

por ejemplo, categorización y agregación de servicios, políticas y aspectos, procesos

meet-in-the-middle.


Ref: PT-2007-023-12IEME 32

Figura 5: Elementos de SOAD

SOAD, también llamado "Service-oriented modeling", es una metodología para

modelado y desarrollo de software para SOA. En la Figura 5 se puede ver los

elementos de SOA y a que nivel (negocio, arquitectura o aplicación) influyen los

diferentes enfoques (OOAD, BPM y EA) en SOAD.

SMART Esta técnica fue desarrollada para analizar aplicaciones ya existentes en una

organización e integrarlas dentro de la nueva arquitectura con que se deseaba

implantar. SMART se deriva del método OAR (Options Analysis for Reengineering),

que ha sido aplicado con éxito para conocer el potencial de reutilización de las

aplicaciones existentes en una organización.

SMART es una técnica para el análisis de aplicaciones y sistemas heredados que

ayuda a determinar si sus funcionalidades, o un subconjunto de éstas, pueden actuar

como servicios en una arquitectura SOA. SMART considera las interacciones que se

requieren para implantar SOA y los cambios que se deben llevar a cabo en los

componentes legados. SMART recoge gran cantidad de información sobre los

componentes antiguos, sobre SOA y sobre los potenciales servicios, para generar una

estrategia de migración de servicios. Sin embargo, SMART también produce otras

salidas que son útiles para la organización incluso si decide finalmente no llevar a

cabo la migración.


Ref: PT-2007-023-12IEME 33

SODA Service-Oriented Development of Applications (SODA) nace de un conjunto de

actividades o procesos para el desarrollo de aplicaciones SOA, definido por Gartner[4].

SODA aborda los procesos o actividades software críticas (según Gartner) para el

éxito de los desarrollos de aplicaciones basados en SOA. SODA capacita a una

organización para desarrollar mejor software, en menos tiempo y más barato,

basándose en nuevas herramientas y estrategias de desarrollo basadas en la

aproximación SOA, que permiten la tan necesaria evolución tecnológica de las

empresas.

SODA se basa en la reutilización de artefactos (desde patrones y marcos a planes de

testing). Sólo sería beneficioso en proyectos en los que se apliquen los principios de

reutilización. Otra idea sobre la que se sustenta es la idea de ”agilidad" para adaptarse

a los cambios. Muchos expertos aconsejan a la hora de desarrollar una solución

integral empresarial seguir un híbrido de varias metodologías de desarrollo,

escogiendo aquellas secciones de cada una de ellas que más se ajustan a nuestras

necesidades.

Tecnologías SOA de referencia Junto con las arquitecturas de referencia, muchas

empresas (especialmente las de mayor envergadura) han propiciado la salida al

mercado de diversas tecnologías y productos empresariales que dan soporte a una

solución SOA empresarial.

Estas soluciones empresariales, a pesar de tener por detrás a grandes compañías,

soportan en diferente medida los diferentes aspectos que una solución SOA debe

proporcionar en cuanto a cumplimiento de estándares, estabilidad del producto,

implementación de los procesos, etc. A continuación puede verse la relación de

empresas que ofrecen soluciones SOA y que son según diversos estudios[10] las más

utilizadas a nivel mundial. Otras opciones interesantes son Tibco o WebMethods.

Oracle: http://www.oracle.com/technologies/soa/soa-suite.html

BEA: http://es.bea.com/products/

IBM: http://www-01.ibm.com/software/solutions/soa/

MICROSOFT: http://www.microsoft.com/soa/

SAP: http://www.sap.com/platform/esoa/index.epx


Ref: PT-2007-023-12IEME 34

Sun: http://www.sun.com/software/media/ash/tour soa/index.html

JBOSS: http://www.jboss.com/products/index

Estos estudios [10] basados en criterios de estrategia comercial, cumplimiento de

estándares, lógica de negocio, etc., indican que de todas las tecnologías enumeradas

anteriormente, Oracle, BEA e IBM presentan una mayor puntación. Cabe destacar que

todas esas soluciones, a excepción de JBOSS, son productos propietarios.

Motivación Los beneficios de implantar una solución SOA tanto a nivel del usuario

como a nivel de la organización IT son claros. Desde el punto de vista de la

organización, SOA permite el desarrollo de nuevas aplicaciones que resuelven una

gran cantidad de problemas de alto nivel. Se mejora la toma de decisiones al integrar

el acceso a los servicios e información de negocio dentro de un conjunto de

aplicaciones compuestas dinámicamente. Además permite el desarrollo de

aplicaciones con independencia de plataforma y lenguajes de programación de sus

componentes, integración de sistemas heredados, reusabilidad, independientes de la

infraestructura subyacentes, y en general flexibilidad en el diseño de cualquier

solución.

En general una solución SOA ofrece servicios que pueden ser vistos como unidades

funcionales separadas, solo disponibles vía una interfaz definida, de forma que actúan

como miniempresas que se pueden mejorar/eliminar/añadir con mucha facilidad.

Además, el diseño de estos servicios se basa en estándares, lo que facilita la creación

de repositorios de servicios reutilizables y combinables en servicios de mayor nivel.

Siguiendo esta filosofía y teniendo en cuenta los principios que guían su desarrollo

vistos en secciones anteriores, podemos decir que una solución SOA para la

plataforma MOSCA es la mejor opción actual para diseño e implantación de dicha

plataforma.

Varios son los aspectos SOA a tener en cuenta a la hora de definir la plataforma

MOSCA. A continuación se enumeran los más relevantes:

Definición de Interfaces de los Servicios.

Los servicios que MOSCA ofrecerá (Seguridad, Conservación, Tráfico y

Explotación) deben proporcionar una definición (contract) pública de la


Ref: PT-2007-023-12IEME 35

interfaz que ofrecen al mundo exterior. Toda interacción con el servicio

debe suceder a través de esta interfaz pública.

Estos servicios deben ser fáciles de consumir, es decir, el servicio debe ser

diseñado de forma que si evoluciona, los actuales consumidores/clientes

del servicio puedan seguir utilizando este servicio.

En su implementación se deben evitar llamadas RPC.

Se debe intentar minimizar el número de interfaces que ofrecen el mismo

servicio, de esa forma el mantenimiento se hace más sencillo. Por ejemplo,

el servicio de control de acceso (seguridad) se puede realizar mediante

reconocimiento facial, huella dactilar, información documental o fusión

multimodal, pero en todos los casos la interfaz debería ser idéntica.

Servicios independientes.

Los servicios diseñados por MOSCA deben ser totalmente independientes y

además en su diseño se debe adoptar un punto de vista pesimista, es decir,

que los servicios posiblemente fallarán, que están sujetos a cambio, que el

tiempo de respuesta respecto al consumidor será alto, etc. También desde

la perspectiva del cliente/consumidor de servicios se debe de adoptar una

perspectiva pesimista, es decir, que no haya respuesta en el servicio, que el

tiempo de respuesta sea elevado, etc.

Los servicios se deberían desplegar y versionarse de forma independiente

al sistema desde donde es consumido.

El contrato de servicio (normalmente especificado en el WSDL) una vez es

publicado, no se debería poder modificar.

Abstracción de Servicios.

Los consumidores/clientes de servicios confían en el contrato del servicio

para invocarlo e interactuar con él, por lo tanto, se debe asegurar que el

contrato del servicio sea estable, para minimizar el impacto sobre los

consumidores.

El contrato se debe diseñar para evitar la mala interpretación, se deben

evitar la confusión entre las representaciones de datos privados y públicos.


Ref: PT-2007-023-12IEME 36

Cuando cambia el contrato del servicio se debe cambiar la versión del servicio. Esto

minimiza el impacto en implementaciones de consumidores/clientes.

Definición de Políticas en los Servicios. Junto con el contrato del servicio se

puede/debe definir una política del servicio. Ésta proporciona un conjunto de

elementos semánticos interoperables que gobiernan el comportamiento y las

expectativas del servicio. Por ejemplo, un servicio de seguridad en un puerto

puede requerir un determinado nivel según su política, en la que se fuerce el

cumplimiento de un determinado escenario, por ejemplo, el servicio puede

requerir que un usuario sea validado contra una determinada lista negra de

pasajeros si se tiene ciertas sospechas, etc.

Meet in the middle. En oposición a los enfoques puramente top-down o bottom-

up es necesario adoptar un enfoque Meet-in-the-middle. Teniendo en cuenta

que por un lado tenemos los requisitos en entornos controlados y por el otro

tenemos unos sistemas que hemos de utilizar/reutilizar.

Es por ello que con el objetivo de conseguir un sistema fácilmente interoperable que

permita la actualización del mismo, añadiendo nuevos módulos que se desarrollen en

el futuro, un sistema con una arquitectura flexible facilitando la interoperabilidad entre

los diferentes sistemas (bases de datos externas, etc.), la solución adoptada en

MOSCA para el diseño de la arquitectura será una solución SOA.

La solución tecnológica SOA que acompañará a esta arquitectura será la de los

Servicios Web descrita anteriormente, y la tecnología a utilizar JBOSS, solución libre y

completa que da soporte a toda la integración de la arquitectura SOA MOSCA en un

entorno real. Dado que el proyecto MOSCA está ligado a la seguridad, se intentará

ofrecer una solución segura. Para ello se intentará desarrollar los servicios de la

plataforma MOSCA utilizando Axis2, que actualmente, y según se puede observar en

la Figura 6, es la única solución que implementa el conjunto de los estándares WS-*

orientados a la seguridad.


Ref: PT-2007-023-12IEME 37

Figura 6: Comparativa de la implementación de los estándares WS-* por las diferentes soluciones

Así pues, la plataforma MOSCA será desarrollada en un entorno Axis2 aunque su

despliegue se realice finalmente sobre una plataforma JBossWS, aprovechando así la

implementación del módulo de seguridad Apache Rampart que proporciona Axis2 y las

ventajas de la utilización de JBoss como servidor de aplicaciones.

SOAP (Simple Object Access Protocol)

SOAP es un protocolo estandarizado utilizado, en el marco de la tecnología WS, para

intercambiar mensajes entre aplicaciones. La especificación tan solo define una simple

“envoltura", basada en XML, para la información que se va a transferir y un conjunto

de reglas para transformar los tipos de datos dependientes de la aplicación/plataforma

a una representación en XML. El diseño de SOAP es adecuado para una gran

variedad de patrones de mensajes e integración entre aplicaciones.


Ref: PT-2007-023-12IEME 38

SOAP es XML. Esto es, SOAP es una aplicación de la especificación de XML. Se

apoya en estándares XML como XML Schema y XML Namespaces, para su definición

y funcionamiento.

XML y JSON

XML, sigla en inglés de Extensible Markup Language (lenguaje de marcas ampliable),

es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web

Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la

gramática de lenguajes específicos (de la misma manera que HTML es a su vez un

lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en

particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos

de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML.

XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un

estándar para el intercambio de información estructurada entre diferentes plataformas.

Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier

cosa imaginable.

XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y

la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un papel

muy importante en la actualidad ya que permite la compatibilidad entre sistemas para

compartir la información de una manera segura, fiable y fácil.

JSON (JavaScript Object Notation, D.Crockford [11]) es un formato ligero para el

intercambio de datos ampliamente utilizado que permite pasar objetos Java o

JavaScript a un formato plano que puede ser generado y tratado muy fácilmente, lo

cual lo hace perfecto para el intercambio de mensajes e información entre cliente y

servidor. Además es independiente del lenguaje de programación que se use, y

comparado con XML es mucho más sencillo y eficiente, puesto que no conlleva una

notación demasiado complicada como en el caso de XML.

2.2.1.1.2 INFRAESTRUCTURAS

Biometría


Ref: PT-2007-023-12IEME 39

Debido a los recientes acontecimientos en los últimos años, como atentados terroristas

o casos de espionaje industrial, la seguridad se ha convertido en el principal objetivo y

también quebradero de cabeza de gobierno y empresa. Por una parte, la seguridad de

los servicios públicos; aeropuertos, estaciones de tren y en general, espacios donde el

paso masivo de población es habitual, hace que la seguridad pase a ser uno de los

elementos principales a tener en cuenta, sino el más importante, en la gestión de estos

servicios. Por otra parte, los casos de espionaje industrial, usuarios malintencionados

en contra de los intereses de empresas o simplemente el acceso restringido a cierta

información sensible fuerza a las empresas a tener que invertir gran cantidad de su

presupuesto en seguridad. Es un hecho conocido que la mayor parte de los ataques

de seguridad que sufren las empresas sobre la confidencialidad de sus sistemas de

información proviene de los propios empleados. Los llamados insiders utilizan sus

propios privilegios de acceso para recuperar información confidencial y hacerla

pública, o incluso para destruir información sensible. En estos casos, es

extremadamente útil para la empresa contar con sistemas que ofrezcan propiedades

de no repudio, de forma que en todo momento se pueda saber quién fue el empleado

que realizó cierta acción, y que éste no pueda negar la realización de la misma. En

este sentido, la biometría es un valor añadido que impide (al menos a priori) la

suplantación de la identidad entre los propios empleados, haciendo la vida mucho más

difícil a los mencionados insiders. Esta preocupación por la seguridad ha hecho que

haya aumentado el interés general por la biometría. Y cada vez son más los que eligen

esta opción, aeropuertos, hoteles, hospitales, bancos, empresas, y en general todos

los espacios que requieren niveles altos de seguridad para que su uso y disfrute no se

vea entorpecido por situaciones peligrosas para el usuario. Pero en biometría la

seguridad de las personas implica en la mayoría de las ocasiones cierto

esfuerzo/adaptación por parte de las mismas, o al menos una participación parcial de

la persona en el proceso. Para ello tiene que registrar sus características biométricas

en un sistema automático sacrificando así cierta intimidad para poder desempeñar su

labor.

Reconocimiento Automático de Matrículas

El reconocimiento automático de matrículas (Automatic number plate recognition o

ANPR en inglés) es un método de vigilancia en masa que utiliza reconocimiento óptico

de caracteres en imágenes para leer las matrículas de los vehículos. En 2005, los


Ref: PT-2007-023-12IEME 40

sistemas eran capaces de escanear las matrículas con una frecuencia aproximada de

una por segundo en vehículos con velocidades de hasta 160 km/h.

Pueden utilizar el circuito cerrado de televisión existente o radares, o unas

infraestructuras diseñadas específicamente para dicha tarea. Son utilizadas por las

diversas fuerzas de policía y como método de recaudación electrónica de peaje en las

autopistas de pago o aparcamientos públicos, y para vigilar la actividad del tránsito

como una luz roja en una intersección.

El ANPR se puede utilizar para almacenar las imágenes capturadas por las cámaras

fotográficas, así como el texto de la matrícula, y algunas se pueden configurar para

almacenar una fotografía del conductor. Estos sistemas a menudo utilizan iluminación

infrarroja para hacer posible que la cámara pueda tomar fotografías en cualquier

momento del día. En al menos una versión de cámara fotográfica para la supervisión

de intersecciones se incluye un flash de gran alcance, que sirve para iluminar la

escena y hacer que el infractor se dé cuenta de su error. La tecnología ANPR tiende a

ser específica para una región, debido a la variación entre matrículas de un lugar a

otro.

El software del sistema se ejecuta sobre un hardware de PC estándar y puede ser

enlazado con otras aplicaciones o bases de datos. Primero utiliza una serie de

técnicas de manipulación de la imagen para detectar, normalizar y realzar la imagen

del número de la matrícula, y finalmente reconocimiento óptico de caracteres para

extraer los alfanuméricos de la matrícula. Los sistemas ANPR/ALPR se pueden utilizar

de dos modos; uno permite que el proceso sea realizado en su totalidad en el lugar de

la toma en tiempo real, mientras que el otro transmite todas las imágenes de muchas

cámaras a un ordenador remoto en que se realiza el proceso de OCR más tarde.

Cuando se realiza in situ, la información capturada de la matrícula alfanumérica, fecha

y hora, identificación del lugar y cualquier otra información que se requiera es

completada en unos 250 milisegundos. Esta información, convertida ahora en

pequeños paquetes de datos, se puede transmitir fácilmente a algún ordenador remoto

para un posterior procesamiento en caso de que sea necesario, o ser almacenado en

el lugar para ser recuperada posteriormente. En la otra disposición, típicamente hay

una gran cantidad de PCs usados en una granja de servidores para manejar altas

cargas de trabajo, como los que se encuentran en el proyecto de carga de congestión


Ref: PT-2007-023-12IEME 41

de Londres. A menudo en dichos sistemas existe la necesidad de remitir imágenes al

servidor remoto y éste puede requerir medios de transmisión con un gran ancho de

banda. Los inconvenientes de estos sistemas están centrados en el temor en cuanto a

la privacidad de los movimientos de los ciudadanos y los informes de los medios sobre

la identificación errónea. Sin embargo, según se han ido desarrollando, estos sistemas

han logrado ser mucho más exactos y fiables.

Tarjetas de Identificación

Hoy en día es muy común en empresas e instituciones públicas el uso de tarjetas de

identificación para acceder a los recintos no públicos. Las tecnologías utilizadas para

este tipo de tarjetas puede ser muy variada, desde tarjetas con banda magnética hasta

tarjetas basadas en RFID. RFID (siglas de Radio Frequency IDentification, en español

identificación por radiofrecuencia) es un sistema de almacenamiento y recuperación de

datos remoto que usa dispositivos denominados etiquetas, transpondedores o tags

RFID. El propósito fundamental de la tecnología RFID es transmitir la identidad de un

objeto (similar a un número de serie único) mediante ondas de radio. Las tecnologías

RFID se agrupan dentro de las denominadas Auto ID (automatic identification, o

identificación automática).

Cámaras IP

Una cámara IP o también conocida como cámara de red puede ser descrita como la

combinación de una cámara y una computadora en una sola unidad, la cual captura y

transmite imágenes en vivo a través de una red IP, habilitando a usuarios autorizados

a ver, almacenar y administrar el video sobre una infraestructura de red estándar

basada en el protocolo IP.

Una cámara de red tiene su propia dirección IP, se conecta a la red, tiene

interconstruidos una serie de aplicaciones, funciones y servicios como son un servidor

web, un servidor FTP, cliente de correos, administración de alarmas y muchos otros

que en su conjunto permiten inclusive realizar programación directamente en la

cámara. Algo muy importante es que a diferencia de cualquier otro tipo de cámara, las

cámaras de red no necesitan estar conectadas a una computadora ni dependen de

ella, son totalmente independientes y autoadministrables, lo cual incrementa aún más

su funcionalidad.


Ref: PT-2007-023-12IEME 42

En resumen podemos decir que todo lo necesario para tomar y transmitir imágenes

esta dentro de la cámara, lo único que se necesita afuera de ella es el medio para ver

el video que es una computadora con un Explorador de Internet, las cuales se pueden

encontrar prácticamente en cualquier lugar del mundo.

Almacenamiento

Cabe esperar que la arquitectura desarrollada necesite una infraestructura de

almacenamiento de datos que permita guardar y recuperar de forma eficiente los datos

manejados por el sistema. Las características deseables que debe reunir un SGBD

(Sistema de Gestión de Bases de datos) son:

Gran cantidad de datos.

Heterogeneidad de los datos.

Heterogeneidad en los tipos de almacenes de dato. (Servidores de bases de

datos, sistemas de ficheros, etc.).

Concurrencia.

Variedad de interfaces de programación.

Disponibilidad de mecanismos de clustering.

En la actualidad existe en el mercado un gran número de sistemas de bases de datos.

Como por ejemplo: Oracle Database 11g, Microsoft SQL Server, MySQL, etc. Siendo

algunos de licencia libre y otros de licencia propietaria.

Monitorización de Estados y Conservación

La importancia de la actividad comercial y económica de los recintos portuarios

conlleva una serie de inversiones para mantener el buen funcionamiento y el trasiego

sin interrupciones de pasajeros y mercancías. Los centros de control son los

encargados de mantener, no solo la seguridad si no también de asegurar la resolución

de problemas en el menor tiempo posible, de modo que la implicación económica ante

cualquier suceso inesperado sea la menor posible. Para que el lector comprenda la

importancia de estos hechos planteamos un caso práctico: si se declara un incendio

en un almacén cercano a un muelle de carga y descarga, es posible que haya que


Ref: PT-2007-023-12IEME 43

interrumpir las operaciones planificadas para ese muelle hasta que el incendio haya

sido controlado o extinguido, con la consiguiente pérdida a nivel de facturación.

Por estos motivos una de las utilidades que se incluye es la monitorización de la

conservación y el estado de instalaciones existentes en los recintos portuarios, tales

como los sistemas de control de incendios, los sistemas de balizamiento o

señalización. Además es importante gestionar los suministros que ofrece el puerto

como servicios al buque (agua, electricidad), para la gestión comercial de los mismos,

y controlar el estado y el correcto funcionamiento de los mismos. Estas utilidades

pueden cubrirse utilizando sistemas SCADA (Supervisory Control and Data

Adquisition) que son aplicaciones que controlan la producción y la comunicación con

los controladores de dispositivos distribuidos en diferentes tipos de instalaciones, pero

la complejidad de estos sistemas exceden las necesidades del proyecto, que pueden

ser cubiertas con un sistema basado en tecnologías GIS (Geographic Information

System). Esta tecnología permite la visualización de información asociada a una

representación geográfica, y la superposición de capas temáticas que clasifican los

diferentes tipos de información.

Monitorización del Tráfico de buques

Otra de las actividades que se realizan en los Centros de Control es la supervisión del

correcto funcionamiento de las operaciones de tráfico marítimo y la ejecución segura

de las operaciones de carga y descarga. Para ello es necesario tener una herramienta

que permita visualizar geográficamente la posición de los buques atracados en puerto

y las características de los mismos y las mercancías que transportan. Esas funciones

requieren de la tecnología GIS mencionada anteriormente, puesto que dan la

información gráfica sobre un plano del puerto con la posición de los buques atracados

dentro de ese plano. Además es importante ofrecer una representación de los buques

lo más real posible, recopilando la información necesaria de manga, eslora para

representar los buques a escala real, de forma que sirva de ayuda durante las

operaciones de tráfico marítimo. También es de vital importancia la información de

posición de los buques cuando están en las inmediaciones del puerto o entrando en el,

pero aún no han atracado, puesto que se pueden evitar accidentes e incluso avisar a

los buques de que llevan una velocidad inadecuada para la operación que van a

realizar. La posición de los buques antes de la entrada en la bocana del puerto sirve


Ref: PT-2007-023-12IEME 44

además para la gestión de practicaje y remolque en caso de que el buque lo hubiera

solicitado.

Operaciones portuarias

Finalizamos con el módulo de Operaciones (o Explotación), de vital importancia debido

a las grandes transformaciones económicas sufridas por los rápidos procesos de

globalización que han incrementado el comercio mundial, produciéndose un aumento

de la demanda y aumento de la capacidad (transhipment). Todo ello ha llevado al

sistema portuario a realizar una integración en la cadena de transporte y en la función

de la logística, de forma que, las funcionalidades que se incluyen son las siguientes:

normalización de las cargas/descargas y sus procesos asociados, aumentado la

seguridad (documentos de manifiesto de carga y descarga), gestión documental de las

mercancías (documentos de entréguese/admítase de los transportistas y documentos

de despacho aduanero de mercancías). De esta forma se ha producido por una parte

una especialización del buque y por otra, de la gestión, financiación e infraestructuras

del puerto. Además otras servicios portuarios a tener en cuenta serán los relacionados

con el practicaje (para los buques que lo requieran) y las operaciones de remolque en

puerto, en caso de que se hayan solicitado con anterioridad. Todo ello construye la

funcionalidad relativa al módulo de Explotación, permitiendo al operador responsable

de la herramienta, gestionar las operaciones portuarias desde el Centro de Control.

Para ello se requiere la misma tecnología GIS de la que se hablaba en los apartados

anteriores.

2.2.1.2 Requisitos Técnicos

2.2.1.2.1 MOTIVACIONES Y OBJETIVOS DE DISEÑO

Muy pocas aplicaciones empresariales funcionan de forma aislada. La mayor parte de

ellas están conectadas a otras aplicaciones y servicios bien porque beben de la misma

fuente de datos, bien porque la una usa como datos de entrada la salida de la otra. Al

final, si abstraemos desde el nivel de aplicación aislada y nos subimos hasta el nivel

de empresa en el que aparece la lista completa de software desplegado y en uso,

veremos que existe un conjunto complejo de aplicaciones, plataformas, y grupos de

datos. Es más, en ocasiones descubriremos que estos servicios están duplicados y se


Ref: PT-2007-023-12IEME 45

interconectan por medio de mensajes, objetos, transferencia de ficheros o interacción

humana.

El caso de MOSCA es quizás el más extremo dentro de este estudio, dado que los

servicios ofrecidos no sólo son remotos y sin una conexión preestablecida entre ellos,

sino que además pueden proceder de distintas empresas y de ámbitos muy variados.

Además, los propios datos usados por los servicios pueden proceder de bases de

datos locales que no están compartidas o cuyos requisitos de seguridad y privacidad lo

impiden.

En principio, la tecnología de Servicios Web ("WS" de aquí en adelante) está diseñada

para ofrecer un alto grado de interoperabilidad entre este tipo de sistemas, y exige

desde el principio que las empresas interesadas en ello usen un enfoque integrador

cuando construyen sus aplicaciones y servicios. Es importante resaltar este último

punto puesto que implica que las empresas deben realizar cierto esfuerzo adicional

para adaptar a la nueva arquitectura las aplicaciones que desean compartir. Según

esto, ¿cómo creamos una cartera de aplicaciones y servicios integrados para

MOSCA?

Una arquitectura de integración tiene que balancear los requisitos de negocio y los

requisitos individuales de las aplicaciones. Muchos desarrolladores y arquitectos de

software comienzan diseñando y construyendo aplicaciones individualistas, pensadas

para actuar de forma aislada. Más tarde, debido a la aparición de nuevos requisitos,

esas aplicaciones progresan hacia sistemas más complejos que actúan a nivel de toda

la empresa e interactúan a su vez con otras aplicaciones y sistemas. A medida que las

aplicaciones requieren conexiones hacia recursos compartidos, lo más natural en esos

casos es crear abstracciones y wrappers que encapsulan los recursos, y así la

aplicación accede a ellos. Este enfoque lleva a que muchas veces, dependiendo de la

aplicación que acceda el recurso, hay que crear un wrapper nuevo o una nueva

abstracción.

Aunque esta opción funciona bien desde la perspectiva de una aplicación individual

que accede a varios recursos, conectar así todas las aplicaciones no parece la mejor

forma de producir un conjunto bien ordenado y coherente de aplicaciones e interfaces.

En su lugar, hace falta un diseño lógico a nivel de integración, del mismo modo que se

necesita un diseño lógico a nivel de aplicación. Para pensar claramente en una


Ref: PT-2007-023-12IEME 46

carpeta completa y coherente de aplicaciones y servicios a nivel de empresa, hay que

invertir el punto de vista. No podemos empezar pensando en la aplicación y luego en

la integración. Hay que considerar primero las necesidades de la empresa como un

todo integrado, y después pensar en cómo ofrecer una funcionalidad compartida a

través de aplicaciones en red, tal y como se pretende hacer en este proyecto.

Llegados a este punto, habría que plantearse cuál es nuestra noción de aplicación

dentro de una arquitectura integradora. La mayor parte de las definiciones para el

término aplicación aluden a ésta como cualquier parte de un sistema software que

ofrece una funcionalidad al usuario final o “un programa de ordenador diseñado para

ayudar al usuario a realizar una tarea determinada". Estas definiciones nos llevan a

pensar en el diseño desde una perspectiva tradicional centrada en la aplicación. En

estos casos, lo más normal es que esperemos encapsular la funcionalidad total en uno

o más ficheros ejecutables que más tarde se instalarán en los servidores

correspondientes.

Sin embargo, si enfocamos el problema desde la perspectiva de una arquitectura de

integración, la aplicación ideal consiste simplemente en una fina capa de presentación

que consume datos o funcionalidad que se encuentran compartidos a nivel de

empresa, justo por encima del nivel de aplicación. Lo ideal, por tanto, sería aprovechar

aplicaciones ya existentes que ofrezcan parte de esta funcionalidad y (algo más

complicado) fuesen accesibles a un nivel de granularidad apropiado para la aplicación

que se quiere construir. Por otro lado, si hay alguna funcionalidad que no se encuentra

y, en consecuencia, hay que construir desde cero, lo ideal sería diseñarla no como

algo aislado, sino como un servicio que a su vez puede ser compartido con otras

aplicaciones a nivel de empresa o usado junto con otros servicios.

2.2.1.2.2 REQUISITOS

Funcionales

Aspectos Generales

El proyecto trata de ofrecer un valor añadido dentro del campo de la seguridad y el

análisis de riesgos, ofreciendo una interfaz capaz de trabajar con toda la información


Ref: PT-2007-023-12IEME 47

disponible en un puerto a nivel de seguridad y facilitando la realización de análisis

mucho más completos que hasta ahora, ya que se podrá disponer de toda la

información en una misma aplicación.

Para ello, MOSCA agrupa un conjunto de aplicaciones utilizadas en los puertos

(Seguridad, Conservación, Control de tráfico y Explotación). Cada uno por separado

ofrece una funcionalidad más o menos completa que va desde el control de accesos a

personas y vehículos, control de cámaras de CCTV hasta la obtención de información

relativa a los buques atracados en el puerto.

Sin embargo, hay un aspecto fundamental que debe tenerse en cuenta a la hora de

desarrollar la arquitectura MOSCA. Como se refleja en el documento de descripción

del proyecto, la idea es construir un servicio común que no sólo agrupe los servicios o

aplicaciones actualmente desarrollados, sino que esté preparado para alojar nuevos

servicios o métodos de adquisición. Es decir, no se trata de una iniciativa aislada, sino

de una arquitectura diseñada con una estrategia a largo plazo. Por eso es fundamental

contar con una arquitectura técnica bien concebida, que integre sin complicaciones

futuros avances o añadidos en los servicios ofrecidos.

Aspectos Operacionales

La herramienta de análisis objeto del presente proyecto debe permitir su

operación por parte de los operadores de los Centros de Control de las

Autoridades Portuarias.

Además debe integrar a nivel operativo los módulos de seguridad tales como

CCTV, control de accesos, reconocimiento de matrículas, … de forma que el

operador del centro de control sólo tenga que interactuar con la herramienta

desarrollada en este proyecto.

La herramienta debe facilitar el acceso a la base de datos de explotación de la

Autoridad Portuaria de forma que no sea necesario arrancar la aplicación de

gestión de servicios portuarios (por ejemplo SIGMA, INTEGRA, …).

A nivel de tráfico de buques, la herramienta permitirá visualizar desde su

interfaz la señal AIS integrada con los datos de la Ventanilla Única (DUE,

Manifiesto de carga y Mercancías Peligrosas).


Ref: PT-2007-023-12IEME 48

También se mostrará sobre un plano GIS del puerto, las infraestructuras de

servicio más destacadas, como son las de telecomunicaciones, electricidad,

red de hidrantes, etc. permitiendo interactuar con ellas, en caso de que sea

posible, desde la propia terminal del operador del centro de control.

Funcionalidades

Las principales funcionalidades a incluir en la aplicación serán:

Visualizar: La herramienta permite una visualización total de las actividades del

puerto desde un mismo interfaz. Incluirá un mapa del puerto dividido por zonas,

que responderán a necesidades de seguridad y control. El trazado de las

infraestructuras de comunicaciones, electricidad, etc. también será visible en

caso de requerirse. Sobre el mismo plano se visualizará la posición de los

buques gracias a la señal del AIS. Finalmente se visualizarán las imágenes de

las cámaras de seguridad, permitiendo seleccionar aquella o aquellas que se

quiera visualizar en cada momento.

Consultar: Se podrá consultar el estado de las instalaciones e infraestructuras,

pudiendo saber si las compuertas de una canalización están abiertas o

cerradas, ect. Se podrá consultar el estado del control de accesos, así como un

seguimiento de las personas que en todo momento se encuentran en el interior

de las instalaciones.

Registrar: Todos los individuos que accedan a áreas controladas dentro de la

zona portuaria quedarán registrados por el sistema para posterior

comprobación en caso de ser necesario. También quedará registrada en el

sistema la entrada de vehículos de transporte, incluyendo qué mercancía se

acude a recoger.

Eventos y alarmas: El sistema generará avisos en aquellos casos en los que se

puedan detectar situaciones anómalas de forma remota. Estos avisos pueden

dividirse en eventos o alarmas. Los eventos son aquellas situaciones que

necesitan atención, pero que la gravedad del evento no requiere de atención

inmediata. Un ejemplo de evento podría ser un aviso de que los niveles en los

depósitos de combustible para los barcos están cercanos a acabarse. Las

alarmas son aquellos avisos que requieren de acción inmediata. Un ejemplo de


Ref: PT-2007-023-12IEME 49

alarma puede ser el intento de acceso no identificado en recintos controlados,

valores peligrosos en las variables de control de las infraestructuras, etc. Estas

alarmas serán clasificadas por niveles de gravedad, para que los operadores

del centro de control puedan atenderlas de forma priorizada.

Grabación: La herramienta garantizará el acceso a las grabaciones de los

sistemas de seguridad, que deben haberse guardado en un servidor de vídeo

por un período mínimo de un mes (conforme a la ley de Protección de Datos).

Históricos: La herramienta llevará un control histórico de los accesos, de las

recogidas de mercancías, de las operaciones de mantenimiento, etc. De esta

manera se podrá consultar lo ocurrido anteriormente y además se podrán

hacer estudios de larga duración sobre cualquier actividad o la relación entre

varias de ellas, simplemente accediendo a información de los históricos.

Procedimentales

Se ha de facilitar la ejecución de procedimientos estandarizados, tales como

las actuaciones ante una emergencia.

Ha de facilitar la información necesaria para que el operador pueda llevar a

cabo el análisis de riesgos no estructurado.

Tecnológicos

Queremos construir una arquitectura para aplicaciones cliente basadas en web,

que permita a los usuarios la consulta del estado del sistema y su manejo

desde una posición remota.

Las aplicaciones que se utilizan pueden encontrarse en servidores distribuidos

espacialmente. De esta forma, es posible contar con una aplicación de

verificación de matrículas físicamente situada en una localización geográfica, y

otra aplicación esta vez para el control de acceso mediante documentación

situada en una localización geográfica diferente.

Las aplicaciones podrían estar desarrolladas en cualquier lenguaje, siendo las

opciones más comunes Java y C/C++.


Ref: PT-2007-023-12IEME 50

En el modelo más optimista, la idea es contar con una base de datos

centralizada, a la que accederán todos y cada uno de los servicios del sistema.

Sin embargo, es más realista pensar que cada aplicación o servicio accederá a

su base de datos local, no teniendo referencia ni acceso a las bases de datos

del resto de componentes del Puerto.

El sistema debe ser igualmente aplicable a (i) entornos controlados, en los que

el usuario se conoce y los sistemas están bajo la supervisión de la autoridad

competente; y (ii) a entornos no controlados, en los que el usuario puede estar

en cualquier otro lugar (por ejemplo un centro de control en Madrid) a la hora

de acceder al servicio.

En principio, el sistema ha de ser multiplataforma. En este sentido, existiría la

posibilidad de desarrollar clientes en Java o quizás sea recomendable la

implementación de un cliente apto para navegadores web.

El sistema debe estar preparado para un volumen de uso intermedio, con la

posibilidad de aumentar su potencial en caso de que el rango y número de

usuarios aumente exponencialmente. De igual forma, los tiempos de respuesta

del sistema han de ser razonables, si fuese de otra forma, el sistema se

convertiría en un incordio para el usuario en lugar de una ventaja, viendo

reducida su utilidad drásticamente.

Seguridad

El sistema ha de respetar la integridad y confidencialidad de: (i) los datos biométricos y

personales del usuario transmitidos durante el proceso de verificación/identificación;

(ii) los datos almacenados en las bases de datos de cada uno de los proveedores de

servicio. Igualmente, el sistema debe garantizar la autenticidad de toda la información

sensible transmitida.

Para garantizar la integridad de los datos transmitidos debemos asegurarnos

de que la información llega a su destino tal y como salió del origen, sin las

alteraciones que haya podido causar una tercera parte malintencionada.

Garantizar la integridad no es garantizar que los datos lleguen íntegros, sino

garantizar que en el caso que así sea, lo sabremos.


Ref: PT-2007-023-12IEME 51

Para garantizar la confidencialidad de los datos transmitidos es importante que

ninguno los datos circulen en claro (sin cifrar). Se trata de aplicar algoritmos de

cifrado/descifrado de datos en los procesos de envío/recepción de la

información. Los estándares propuestos actualmente en WS-Security cubren

perfectamente los requisitos de integridad y confiabilidad que se acaban de

exponer.

Para garantizar la autenticación quiere con un servicio de autenticación que

permita comprobar la autenticidad de la información transmitida. Es decir, no se

trata simplemente de cifrar la información (confidencialidad) y de comprobar

que los datos no han sido manipulados (integridad), sino de saber además que

los datos recibidos proceden realmente del interlocutor que dice haberlos

enviado. El caso de un ataque man-in-the-middle podría ser detectado con la

simple comprobación del certificado o firma digital del emisor. Si la firma

corresponde con el emisor esperado, el mensaje se considera auténtico. En

cualquier otro caso, el mensaje se descartaría.

Por último, sería también deseable la consideración de otros requisitos de

seguridad tales como el no-repudio (de emisor y de receptor) o la garantía de

disponibilidad de los servicios.

2.2.1.2.3 INTEROPERABILIDAD

Interoperabilidad a nivel de Aplicación

El uso de WS como piezas de software a las que se puede acceder por Internet, hace

que podamos ofrecer alguna de las funciones de las aplicacion MOSCA para que se

pueda acceder a ellas desde cualquier sistema y lugar usando una simple URL.

Los WS suelen usar en su gran mayoría la tecnología SOAP (Simple Object Access

Protocol), un protocolo RPC (Remote Procedure Call) que permite hacer llamadas

remotas a métodos de objetos. Este protocolo está basado en XML para definir su

estructura y HTTP para el transporte (aunque también puede usarse sobre otros

protocolos de transporte). Esto la convierte en una tecnología muy portable e

interoperable, ambos requisitos fundamentales de nuestra arquitectura.


Ref: PT-2007-023-12IEME 52

Según lo expuesto, los WS requieren un mecanismo de descripción basado en XML.

Es precisamente ahí dónde encaja la tecnología WSDL (Web Services Description

Language). Se trata de un lenguaje basado en XML que permite definir los métodos

que se pueden llamar, su formato, y el punto de acceso al servicio (URL, Puerto).

Muchas herramientas usan los ficheros WSDL de forma automática, generando código

fuente para la parte cliente que se requiere para llamar a los WS descritos en los

ficheros. Como es evidente, para cada una de las aplicaciones que actualmente se

esta utilizando en los Puertos, habría que construir la definición WSDL

correspondiente. Dado un documento WSDL que describe un servicio, cualquiera

puede construir una aplicación que siguiendo la estructura y formato de datos y

llamadas establecidas en el documento, haga uso de dicho servicio dentro de su

aplicación.

La definición de WS que nos da la W3C menciona también el descubrimiento de los

servicios. Lo cierto es que hoy en día hablar de descubrimiento de servicios es hablar

de UDDI, aunque oficialmente no se trate de una relación cerrada. En muchos casos la

literatura ha considerado el descubrimiento de servicios como un elemento central

dentro de la Arquitectura Orientada a Servicios, aunque la realidad ha demostrado que

muchas de las aplicaciones que usan WS no implementan ni usan UDDI, y que en

caso de usarlo, se trata de un rol muy especializado.

Interoperabilidad a nivel de datos

Hoy en día, muchas organizaciones y empresas están empezando a utilizar los WS

bien para ofrecer funcionalidad a sus clientes, o bien para añadir funcionalidad a sus

propios sistemas. Evidentemente, el uso cada vez más extendido de los WS habilita el

acceso a inmensas cantidades de información sensible controlada por ellos, bien sea

personal, médica o financiera, así como a información perteneciente a posibles

clientes (por ejemplo, el gobierno). Huelga decir que la seguridad es un punto crítico

para la adopción definitiva de dichos WS. En este sentido, se debe proponer la

aplicación de los recientes estándares basados en XML para transferir información de

cualquier tipo y las nuevas técnicas de encriptación que hacen posible el uso seguro

de los sistemas.


Ref: PT-2007-023-12IEME 53

2.2.2 Modelo de Datos

2.2.2.1 Definición de la Arquitectura

Una SOA es un método de diseño y construcción de soluciones software débilmente

acopladas que presentan funciones de negocio como un conjunto de servicios

software accesibles mediante programación. Dichos servicios se diseñan para ser

usados por otras aplicaciones a través de interfaces públicas y fácilmente

identificables.

Por tanto, la arquitectura resultante debe ofrecer a los posibles clientes la posibilidad

de componer y organizar aplicaciones a partir de un conjunto de servicios distribuidos.

Llegados a este punto, el cliente tiene dos posibilidades: usar los servicios para

construir nuevas aplicaciones; o alterar sus actuales aplicaciones para incorporar en

ellas los recursos que ahora se comparten.

2.2.2.1.1 Visión de la Arquitectura

En el proyecto actual, las aplicaciones de cada uno de los módulos se han

desarrollado de forma totalmente independiente unas de otras. Por tanto hemos de

asumir que cada una de ellas puede estar escrita en un lenguaje de programación

distinto, en una plataforma cualquiera, y distribuidas geográficamente. Con este

escenario, queda claro que es necesario aplicar algún patrón de integración que

permita a todas y cada una de las aplicaciones integrarse dentro de una única

arquitectura y actuar como un todo.

En estas situaciones, es interesante la aplicación de Patrones de Integración que nos

aseguren una correcta unificación de los patrones de negocio individuales que ha

tomado cada componente de forma que satisfagan los requisitos de una solución de

negocio completa. La tecnología de WS simplifica la integración de aplicaciones

permitiendo a las organizaciones usar procesos de negocio existentes. Gracias a que

los WS ofrecen descripciones de su interfaz y comportamiento bien definidos y

accesibles mediante programación, es posible integrarlas directamente en otras

aplicaciones manteniendo un entorno débilmente acoplado y heterogéneo.

En los dos casos presentados en la Figura 7 el usuario interactúa con múltiples

aplicaciones plenamente funcionales (Empresa X, Empresa Y...) usando un único


Ref: PT-2007-023-12IEME 54

front-end, al que hemos llamado Aplicación Final. Sin embargo, cada caso consigue su

objetivo de manera muy distinta.

Figura 7: Patrón de integración básico

En el primer caso presenta un reto para la empresa que tiene que hacer la integración

final, ya que el propio código de las aplicaciones X y Z debe incluirse en la aplicación

final para formar un todo único y estrechamente integrado. Esta opción puede ser

especialmente útil cuando la integración ocurre a nivel aplicación-aplicación, pero

compleja y poco flexible cuando hablamos de la capa de negocio.

En el segundo caso, se ha hecho el esfuerzo de presentar el front-end de sus

aplicaciones nuevas como un WS y se ha añadido un wrapper de WS a las

aplicaciones que actualmente se encuentran en explotación. Esto ha permitido la

integración entre la aplicación final y las aplicaciones de forma programática, usando

un patrón de composición que permite añadir los servicios como plug-ins directamente


Ref: PT-2007-023-12IEME 55

en el proceso. Gracias a la tecnología de WS, esa integración directa es fácil de

mantener, de más fácil evolución, y en conjunto, menos costosa.

Es más, esta forma de representación permite ofrecer varias aplicaciones

(funcionalidades) a través de un único WS, ya que un mismo WS puede tener varios

puertos, cada uno de ellos dedicado a una aplicación. Aplicado al caso de MOSCA;

sería posible agrupar todas las aplicaciones bajo un mismo WS, que sería invocado

con unos parámetros u otros según el servicio concreto que se desee obtener.

Figura 8: Patrón de integración arquitectura MOSCA


Ref: PT-2007-023-12IEME 56

Figura 9: Patrón de integración arquitectura MOSCA

Las figuras Figura 8 y Figura 9 representan el Patrón de Integración propuesto para la

arquitectura MOSCA. Está compuesto por un WS central que se encarga de

encaminar las peticiones a los diferentes módulos del sistema. Cada módulo del

sistema es un WS que a su vez integra otros WS (Las aplicaciones finales, algunas

desarrolladas desde cero y otras obtenidas añadiendo un wrapper WS a la aplicación

actual). La Aplicación Final, es también un WS desde el cual se lanzan las peticiones

al servidor de WS central y obtiene los resultados de las acciones realizadas.

Figura 10: Arquitectura MOSCA a alto nivel

Llegados a este punto, podemos presentar el diseño de la arquitectura a alto nivel,

incluyendo tanto la zona de presentación, en la que residirán las aplicaciones cliente,

como la zona de aplicación, en la que residirán los servicios propiamente dichos. La

Figura 10 agrupa todos los conceptos presentados hasta el momento dentro de una

arquitectura orientada a servicios. Podemos dividirla en tres zonas:

Zona de Aplicaciones Cliente: engloba tanto la capa de presentación de los

WS hacia el usuario final, como la gestión de las interfaces de cada modulo.

Podríamos identificar estas aplicaciones como la caja Aplicación Final (con

Servicio Web) de la Figura 8, y por tanto, hemos de asumir que todas estas

aplicaciones incluyen un pequeño módulo dentro de su código, que les permite

comunicarse con los WS correspondientes. Las aplicaciones aquí presentes

incluyen:


Ref: PT-2007-023-12IEME 57

Elementos de Gestión: Existen una gran cantidad de aplicaciones

de gestión que pueden asociarse a esta arquitectura, como por

ejemplo la gestión (alta, baja, modificación) de puntos de acceso,

gestión de usuarios, etc. Las aplicaciones identificadas como

Elementos de Gestión, harán uso de la interfaz de gestión ofrecida

por los WS. Es decir, usarán los puertos en los que el WS ofrece sus

funciones de alta, baja, configuración, etc.

Elementos de visualización: Dentro de este grupo de elementos

se engloban los que permiten una visualización o de los que se

espera alguna respuesta que se pueda representar. Como por

ejemplo la visualización de las cámaras de seguridad o la

visualización de un aviso generado por un evento lanzado por

alguno de los componentes del sistema.

Zona de MOSCA Web Services: esta zona agrupara, a todos los servicios

ofrecidos por MOSCA, junto con la información manejada por dichos servicios.

Hemos dividido esta zona en cuatro secciones bien diferenciadas:

La primera, implica la creación de una capa SOAP/WSDL que

encapsule los servicios, y los haga disponibles para su acceso como

WS. Aunque en principio no está planteado incluir el descubrimiento

de servicios (UDDI) dentro de la arquitectura, el soporte de SOAP y

WSDL simplificaría una futura ampliación que incluyese el

descubrimiento.

La segunda sección agruparía cada uno de los servicios ofrecidos.

Es decir, los núcleos de las aplicaciones que son capaces de

procesar la petición de servicio y devolver una respuesta. Es

importante destacar que los servicios (cajas 1, 2, 3 y 4 en el dibujo)

podrían estar deslocalizados. Es decir, la arquitectura se planteará

de forma que los servicios no tengan porqué compartir la misma

localización física. Muy al contrario, se debe promover la

deslocalización e incluso la replicación de los servicios. En cualquier

caso, la localización del servicio deberá ser transparente al usuario.

Es más, sería deseable que dados dos servicios que ofrecen la


Ref: PT-2007-023-12IEME 58

misma funcionalidad, se pudiese enlazar de forma dinámica a uno u

otro, según las necesidades concretas del cliente en cada momento.

Otro aspecto importante que debe ofrecer la arquitectura es el

desacople parcial o total entre la capa de datos y la de aplicación, o

lo que es lo mismo, entre la BBDD y los servicios. La arquitectura

ideal es aquella en la que los servicios acceden a la base de datos

siguiendo un mecanismo que oculte la implementación concreta de

la BBDD. En la presente arquitectura, todos los servicios lanzan sus

consultas sobre el elemento de Acceso a la BBDD.

Independientemente de la arquitectura concreta de la BBDD. Esta

capa de acceso separa la aplicación de los datos, dejando libertad

para que la BBDD se implemente según convenga en cada caso.

Algunas instancias de la arquitectura pueden proponer el uso de una

BBDD distribuida, mientras que en otros casos puede ser más

interesante la creación de una gran BBDD unificada que centralice

todas las consultas. Es más, según la arquitectura propuesta, es

factible el uso de bases de datos locales donde exista una relación 1

a 1 entre servicio y BBDD. En este último caso, cada servicio

mantendría su propia BBDD y ésta sería completamente

independiente del resto de BBDD.

La última sección recoge la capa de BBDD de la arquitectura. La

instancia representada agrupa las BBDD por tipo de información

almacenada. Plantea la existencia de varias BBDD agrupadas bajo

un único punto de acceso. Se trata de una representación

simplificada, dejando a discreción del diseñador la adición de

nuevas agrupaciones de BBDD según las necesidades de su

sistema. De igual forma, el diseño se podría simplificar aún más si

dejamos a un lado la posible agrupación de BBDD y pensamos en

bases de datos simples, sin distribución, agrupación o replicación.

Por último, existiría también la posibilidad de construir una BBDD

única en la que los datos se distribuyesen por tablas. Así tendríamos

una tabla para la información de seguridad, otra para conservación,

etc. Si el elemento de acceso a la BBDD está correctamente

diseñado, cualquiera de las combinaciones expuestas es posible.


Ref: PT-2007-023-12IEME 59

Zona Capa de Comunicación: al tratarse de una arquitectura orientada a

servicios, la comunicación está especialmente pensada para hacerse a través

de Internet, vía http. Dicha comunicación está basada en envío/recepción de

información XML de forma asíncrona. Dentro de este apartado es importante

también la consideración de requisitos de seguridad tales como:

La integridad de los datos transmitidos: debemos asegurarnos de

que la información llega a su destino tal y como salió del origen, sin

las alteraciones que haya podido causar una tercera parte

malintencionada. Garantizar la integridad no es garantizar que los

datos lleguen íntegros, sino garantizar que en el caso que así sea, lo

sabremos.

La confidencialidad de los datos transmitidos: al tratarse de

información personal, es importante que ninguno los datos circulen

en claro. Se trata de aplicar algoritmos de cifrado/descifrado de

datos en los procesos de envío/recepción de la información. Los

estándares propuestos actualmente en WS-Security cubren

perfectamente los requisitos de integridad y confiabilidad que se

acaban de exponer.

En ocasiones, sería también interesante contar con un servicio de

autenticación que permitiese comprobar la autenticidad de la

información transmitida. Es decir, no se trata simplemente de cifrar

la información (confidencialidad) y de comprobar que los datos no

han sido manipulados (integridad), sino de saber además que los

datos recibidos proceden realmente del interlocutor que dice

haberlos enviado. El caso de un ataque man-in-the-middle podría

ser detectado con la simple comprobación del certificado o firma

digital del emisor. Si la firma corresponde con el emisor esperado, el

mensaje se considera auténtico. En cualquier otro caso, el mensaje

se descartaría.

Por último, sería también deseable la consideración de otros

requisitos de seguridad tales como el no-repudio (de emisor y de

receptor) o la garantía de disponibilidad de los servicios.


Ref: PT-2007-023-12IEME 60

2.2.2.2 Detalle del Modelo de Datos

El Modelo de Datos es un modelo abstracto que describe la representación de la

información en un problema y el modo de acceder a esa información. Dentro de los

Modelos de Datos existen varios tipos que dependen del grado de abstracción de los

datos que representan (conceptual, lógico). Los Modelos de Datos más utilizados son

el Modelo Entidad-Relación y el Modelo Relacional, que trabajan en el plano

conceptual y en el plano lógico respectivamente. Para el proyecto que estamos

desarrollando lo más importante es hacer una representación de los datos existentes

en la realidad del mismo (representación que se da en el modelo Entidad-Relación),

con la descripción de datos y relaciones, que una representación en función de las

operaciones a realizar. En los Modelos Entidad-Relación (Modelo E-R en adelante) se

representan la información de interés en el problema cómo Entidades que tienen unas

características o Atributos, y esas entidades se interrelacionan unas con otras

(Relaciones). Además los atributos serán descritos mediante una serie de restricciones

de integridad, que hacen posible la representación más fiel posible de la realidad. Con

estos tres conceptos (Entidad, Atributo y Relación) pasamos a describir el Modelo E-R

que se plantea para el proyecto.

2.2.2.2.1 Descripción de las entidades

Cada una de las entidades que se describen a continuación va a tener como primer

atributo un identificador de tipo entero, que será la clave primaria (key o K) y por tanto

es obligatorio rellenar este campo (mandatory o M). Los demás atributos podrán ser

obligatorios o no, y en algunos casos serán claves ajenas (foreign key o FK). Estos

atributos formarán parte de la clave que identifica al dato, y se corresponderán con las

claves primarias de alguna de las entidades existentes. Otro atributo que aparecerá

con frecuencia en las tablas de las entidades será una marca de tiempo (TimeStamp).

Así quedará registrado el momento en el que se introducen los datos en la Base de

Datos. Los atributos cuyo tipo sea “String <número>”, se almacenarán en la base de

datos como una cadena de caracteres de tamaño máximo el número que se encuentra

entre los símbolos “<>”. Los atributos cuyo tipo sea “Int”, se almacenarán en la base

de datos como un número entero.


Ref: PT-2007-023-12IEME 61

2.2.2.2.2 Tablas de entidades

La entidad Persona almacena los nombres y apellidos de todas las personas que

estarán guardadas en el sistema.

PERSONA

Id_Per Int , M, K

Nom_Per String<30>, M

Apellido1 String<30>, M

Apellido2 String<30>

Cada persona que no esté acreditada y quiera acceder al recinto portuario deberá

facilitar el motivo de su visita. Dentro de esta entidad se tendrá como clave ajena el

identificador del nivel de seguridad con el que se corresponde este tipo de persona.

Obligatoriamente se deberá corresponder con un identificador de Persona y con un

identificador de tarjeta de acceso.

NO ACREDITADO

Id_No_Acred Int , M, K

Motivo_Visita String<100>, M

Id_M_Nivel_Seg M, FK

Id_Per M

Id_Tarjeta M

TimeStamp timestamp

Si una persona va a visitar puntualmente una determinada empresa o instalación

portuaria, por ejemplo, deberá ser acreditado por algún responsable del lugar visitado.

Para ello se deben introducir en el sistema los datos de visitante esporádico, la


Ref: PT-2007-023-12IEME 62

nacionalidad, el número de documento identificativo y las fechas de alta y baja en las

cuales estará acreditada la visita. Opcionalmente se puede especificar el motivo de la

visita. Además dentro de esta entidad se almacenarán como claves ajenas los

identificadores del nivel de seguridad y del tipo de documento de identificación, y será

obligatorio el identificador que lo relacione con los datos de persona y de tarjeta de

acceso. También se guardará una marca de tiempo.

ESPORADICO

Id_Esporadico Int , M, K

Esp_Nacionalidad String<2>, M

Esp_Num_Doc String<20>, M

Esp_Mot_Visit String<100>

Esp_F_Alta Date, M

Esp_F_Baja Date, M


Id_M_Doc_Id M, FK

Id_Per M

Id_Tarjeta M

TimeStamp timestamp

Si una persona externa al puerto (p.ej. usuarios del puerto deportivo, pescadores, etc.)

quiere acceder al recinto portuario, deberá identificarse previamente. Así estará

acreditado y podrá acceder al recinto siempre que quiera y quedará constancia de su

entrada. Los datos a almacenar son la nacionalidad, el número de documento

identificativo y opcionalmente el motivo de la visita. Además dentro de esta entidad se

almacenarán como claves ajenas los identificadores del nivel de seguridad y del tipo

de documento de identificación, y será obligatorio el identificador que lo relacione con


Ref: PT-2007-023-12IEME 63

los datos de persona. También se guardará un identificador de la foto de carné de la

persona, un identificador de tarjeta de acceso y una marca de tiempo.

EXTERNO

Id_Externo Int , M, K

Ext_Nacionalidad String<2>, M

Ext_Num_Doc String<20>, M

Ext_Mot_Visit String<100>


Id_M_Doc_Id M, FK

Id_Per M

Id_Foto_Persona FK

Id_Tarjeta M

TimeStamp timestamp

Las personas que trabajen en el puerto deben tener acceso abierto al recinto y para

ello deben estar almacenados la nacionalidad y el número de documento de identidad.

Además dentro de esta entidad se almacenarán como claves ajenas los identificadores

del nivel de seguridad y del tipo de documento de identificación, y será obligatorio el

identificador que lo relacione con los datos de persona. También se guardará el

identificador de la foto del trabajador interno, el identificador de tarjeta y una marca de

tiempo.

INTERNO

Id_Interno Int , M, K

Int_Nacionalidad String<2>, M


Ref: PT-2007-023-12IEME 64

Int_Num_Doc String<20>, M


Id_M_Doc_Id M, FK

Id_Per M

Id_Foto_Persona FK

Id_Tarjeta M

TimeStamp timestamp

Para los usuarios de la aplicación habrá que crear una entidad en la base de datos

para almacenar los nombres de usuario, las contraseñas y el tipo de usuario que es

(p.ej. administrador o usuario normal). Además dentro de esta entidad se almacenarán

como clave ajena el tipo maestro de usuario y será obligatorio el identificador que lo

relacione con un trabajador interno al puerto. También se guardará una marca de

tiempo.

USUARIO_APL

Id_Usuario_Apl Int, M, K

Nombre_Usuario String<10>, M

Contraseña_Usuario String<10>, M

Id_M_Usuario M, FK

Id_Interno M

TimeStamp timestamp


Ref: PT-2007-023-12IEME 65

Los conductores de vehículos de transporte de mercancías deberán estar

almacenados en la base de datos. Se requiere su nacionalidad, número de documento

identificativo, número de tarjeta de transportista, fecha de expedición y fecha de

comienzo y fin de validez de la tarjeta. Además dentro de esta entidad se almacenarán

como claves ajenas los identificadores del nivel de seguridad y del tipo de documento

de identificación, y será obligatorio el identificador que lo relacione con los datos de

persona. También se guardará el identificador de la fotografía de carné, el de la tarjeta

de acceso y una marca de tiempo.

TRANSPORTISTA

Id_Transportista Int , M, K

Trans_Nacionalidad String<2>, M

Trans_Num_Doc String<20>, M

Num_Tarj_Trans String<20>, M

Trans_F_Exped Date, M

Trans_F_Ini_Tarj Date, M

Trans_F_Fin_Tarj Date, M


Id_M_Doc_Id M, FK

Id_Per M

Id_Foto_Persona FK

Id_Tarjeta M

TimeStamp timestamp


Ref: PT-2007-023-12IEME 66

Las personas que accedan al puerto como pasaje de algún barco atracado en el

mismo, deberán estar registrados en la base de datos. Se almacenará su

nacionalidad, número de documento identificativo, un bit para marcar si es residente

en Baleares o en Canarias y se guardará origen y destino del trayecto a realizar.

Además dentro de esta entidad se almacenarán como claves ajenas los identificadores

del nivel de seguridad y del tipo de documento de identificación, y será obligatorio el

identificador que lo relacione con los datos de persona y el de la tarjeta de acceso.

También se guardará una marca de tiempo.

PASAJERO

Id_Pasajero Int , M, K

Pas_Nacionalidad String<2>, M

Pas_Num_doc String<20>, M

Reside_Baleares Bit, M

Reside_Canarias Bit, M

Pas_Origen String<30>, M

Pas_Destino String<30>, M


Id_M_Doc_Id M, FK

Id_Per M

Id_Tarjeta M

TimeStamp timestamp

Los usuarios de un crucero, deberán estar identificados del mismo modo que los

pasajeros comunes, pero además, habrá que almacenar el nombre del buque en el


Ref: PT-2007-023-12IEME 67

que viajan y el número de escala. Opcionalmente se puede almacenar las fechas de

inicio y fin de escala del buque en el puerto. Además dentro de esta entidad se

almacenarán como claves ajenas los identificadores del nivel de seguridad y del tipo

de documento de identificación, y será obligatorio el identificador que lo relacione con

los datos de persona y con los datos de la tarjeta de acceso. También se guardará una

marca de tiempo.

CRUCERISTA

Id_Crucerista Int , M, K

Cruc_Nacionalidad String<2>, M

Cruc_Num_Doc String<20>, M

Nom_Buque String<30>, M

Num_Escala String<30>, M

Cruc_Origen String<30>, M

Cruc_Destino String<30>, M

F_Ini_Escala Date

F_Fin_Escala Date


Id_M_Doc_Id M, FK

Id_Per M

Id_Tarjeta M

TimeStamp timestamp

En el caso de los vehículos que accedan al recinto portuario, solo tendremos una

entidad que almacene todos los vehículos, de los cuales obligatoriamente habrá que

almacenar el número de matrícula. De forma opcional, y dependiendo de si el vehículo


Ref: PT-2007-023-12IEME 68

está acreditado se almacenará la marca, el modelo, el color y la fecha de fin de validez

de la acreditación. Si el vehículo tiene base en puerto, se guardarán las fechas de

última ITV realizada y próxima ITV. Si es un vehículo particular no se almacenarán

datos especiales, y si el vehículo es de transporte de mercancías, se guardará el

número de ejes, la tara y la masa máxima autorizada (MMA). Las diferentes clases de

vehículos (Acreditado, con Base en Puerto, Particular y de Mercancías) serán una

clave ajena de la tabla maestro Tipo_M_Vehiculo y el tipo de vehículo clasificado como

turismo, moto, furgoneta, autobús, entoldado… será una clave ajena de la tabla

maestro T_M_Entidad_Veh. Además se almacenará la clave de la persona que

conduzca dicho vehículo.

VEHICULO

Id_Vechiculo Int , M, K

Veh_Num_Mat String<10>, M

Veh_Marca String<30>

Veh_Modelo String<30>

Veh_Color String<30>

Veh_F_Fin_Acredit Date

Veh_F_Ultim_ITV Date

Veh_F_Prox_ITV Date

Veh_Num_Ejes Int

Veh_Tara Int

Veh_MMA Int

Id_M_Entidad_Veh M, FK

Id_M_Vehiculo M, FK


Ref: PT-2007-023-12IEME 69

Id_No_Acred FK

Id_Esporadico FK

Id_Externo FK

Id_Interno FK

Id_Transportista FK

Id_Pasajero FK

Id_Crucerista FK

TimeStamp timestamp

Todas los Dispositivos que hay en el recinto portuario, como por ejemplo, las cámaras

de vídeo vigilancia, los interfonos, los postes SOS, etc., se registrarán en la base de

datos, guardando la marca, el modelo y el fabricante. También se almacenará una

descripción de sus características técnicas, el lugar donde está ubicada y la fecha de

fin de la garantía de producto. Como claves ajenas se almacenarán los identificadores

del tipo de dispositivo correspondiente, y los identificadores de las empresas que

instalaron el dispositivo y que se encarga de la revisión.

DISPOSITIVO

Id_Dispositivo Int, M, K

Disp_Marca String<20>, M

Disp_Modelo String<20>, M

Disp_Fabricante String<20>, M

Disp_Descripcion String<100>

Disp_Ubicación String<100>


Ref: PT-2007-023-12IEME 70

Disp_F_Fin_Garantia Date, M

Id_M_Dispositivo M, FK

Id_Empresa_instalacion M, FK

Id_Empresa_revision M, FK

TimeStamp Timestamp

Para los elementos de control de accesos (tanto los de acceso de vehículos como los

de acceso de personas) se registrará en la base de datos la marca, el modelo y el

fabricante. Será posible guardar una descripción de las características técnicas, el

lugar donde está ubicada y obligatoriamente, la fecha de fin de la garantía de

producto. También se almacenarán las claves ajenas que hacen referencia al nivel de

seguridad que tiene el acceso, el tipo de acceso, y los identificadores de las empresas

de instalación y de mantenimiento.

ACCESO

Id_Acceso Int, M, K

Acc_Marca String<20>, M

Acc_Modelo String<20>, M

Acc_Fabricante String<20>, M

Acc_Descripción String<100>

Acc_Ubicación String<100>

Acc_F_Fin_Garantía Date, M


Id_M_Acceso M, FK


Ref: PT-2007-023-12IEME 71



TimeStamp Timestamp

De los sistemas contra incendios que se encuentran dentro del recinto portuario, se

guardarán los elementos comunes a todos los dispositivos instalados en el puerto:

marca, modelo y fabricante. También será posible guardar una descripción del

sistema, la ubicación y la fecha de fin de garantía. Además, en el caso de los

hidrantes, se puede almacenar el diámetro en milímetros y la presión en boca. Las

claves ajenas harán referencia al tipo de sistema contra incendio y a las empresas de

instalación y revisión del mismo.

CONTRA_INCENDIOS

Id_Contra_Incendios Int, M, K

Cont_Marca String<20>, M

Cont_Modelo String<20>, M

Cont_Fabricante String<20>, M

Cont_Descripcion String<100>

Cont_Ubicacion String<100>

Cont_F_Fin_Garantia Date, M

Cont_Diametro Int

Cont_Presion Int

Id_M_Contra_Incen M, FK




Ref: PT-2007-023-12IEME 72

TimeStamp Timestamp

Los elementos de señalización marítima se guardarán en la base de datos con los

campos antes definidos que son comunes a todos los dispositivos. También se

almacena el nombre del dispositivo además de la posición, representada con

coordenadas geográficas y la profundidad a la que se encuentran los flotadores

sumergidos. Como claves ajenas, tendremos los identificadores del tipo de

señalización marítima y los de las empresas de instalación y mantenimiento.

SENNAL_MARITIMA

Id_Senal_Maritima Int, M, K

Senn_Nombre String<50>, M

Senn_Marca String<20>, M

Senn_Modelo String<20>, M

Senn_Fabricante String<20>, M

Senn_Posicion String<10>, M

Senn_Profundidad Int

Id_M_Sennal_Maritima M, FK



TimeStamp Timestamp

El recinto portuario albergará diversas empresas. Estas se caracterizan según la

actividad que desarrollan. Todas las empresas se almacenarán en la base de datos

con los mismos campos. El identificador, el número CIF de la empresa, el nombre de


Ref: PT-2007-023-12IEME 73

la empresa y como claves ajenas el tipo de actividad de la empresa y el nivel de

seguridad asociado.

EMPRESA

Id_Empresa Int, M, K

Empr_CIF String <10>, M

Empr_Nombre String<100>, M


Id_M_Actividad M, FK

TimeStamp Timestamp

Las Autoridades Portuarias que aparecen en el sistema serán registradas con el

Código de la Autoridad Portuaria, el nombre y una descripción opcional. Además cada

Autoridad Portuaria estará formada por entre uno y varios puertos y estos a su vez

entre uno y varios Subpuertos. De ellos se almacenarán también el Código y el

Nombre. Por ejemplo la Autoridad Portuaria de Valencia se divide en tres puertos

(Valencia, Gandía y Sagunto). El puerto de Valencia además está formado por varios

subpuertos entre ellos la Dársena Interior o el Port America’s Cup.

AUTORIDAD PORT

Id_AP Int, M, K

AP_Codigo String <10>, M, K

AP_Nombre String<100>, M

AP_Descripcion String<100>

PUERTO


Ref: PT-2007-023-12IEME 74

Id_Puerto Int, M, K

Puerto_Codigo String <10>, M

Puerto_Nombre String<100>, M

Id_AP M, FK

SUBPUERTO

Id_Subpuerto Int, M, K

Sub_Codigo String <10>, M

Sub_Nombre String<100>, M

Id_Puerto M, FK

Cada Autoridad Portuaria controlará a nivel de accesos, los Organismos Públicos que

se encuentran en el recinto portuario. Se almacena el código de Organismo Público y

como claves ajenas, los identificadores de tipo de organismo público, el nivel de

seguridad requerido para dicho organismo y el identificador del subpuerto.

ORGANISMO PUBLICO

Id_Organismo_Pub Int, M, K

Org_Codigo String <10>, M, K

Id_M_Organismo_Pub M, FK


Id_Subpuerto M, FK

TimeStamp Timestamp


Ref: PT-2007-023-12IEME 75

La entidad Dirección almacena los datos de la dirección física de una empresa. Estos

datos son el nombre de la calle, el número de calle, la población, la provincia, el código

postal, el teléfono, fax, dirección de correo electrónico, página Web y si la dirección es

de naturaleza Fiscal. Todos estos datos son obligatorios excepto el número de calle,

puesto que podría ser una calle sin número específico y la página Web, ya que es

posible que no exista página Web de las empresas o los organismos públicos que se

ubican en dicha dirección. Esta entidad se crea a partir de la necesidad de que una

misma empresa pueda estar ubicada en varias direcciones distintas.

DIRECCION

Id_Direccion Int, M, K

Dir_Calle String<30>, M

Dir_Numero Int

Dir_Poblacion String<30>, M

Dir_Provincia String<30>, M

Dir_CP Int, M

Dir_Tel Int, M

Dir_Fax Int, M

Dir_Mail String, M

Dir_Web String

Dir_Fiscal Bit, M

Para los elementos que componen los sistemas de comunicaciones, se almacenará en

la base de datos la marca, el modelo, el fabricante, las características técnicas del

dispositivo y opcionalmente, una descripción de la ubicación del dispositivo. También

se almacena la fecha de fin de garantía. Además como claves ajenas se almacenan


Ref: PT-2007-023-12IEME 76

los identificadores del tipo de sistema o red de comunicaciones y los de las empresas

instaladora y de mantenimiento.

SISTEM_ COMUNICACIONES

Id_Sistem_Comunicacion Int, M, K

Sis_Com_Marca String<20>, M

Sis_Com_Modelo String<20>, M

Sis_Com_Fabricante String<20>, M

Sis_Com_Caracteristicas String<100>, M

Sis_Com_Ubicacion String<100>

Sis_Com_F_Fin_Garantía Date, M

Id_M_Sistem_Com M, FK



TimeStamp Timestamp

RED_ COMUNICACIONES

Id_Red_Com Int, M, K

Red_Marca String<20>, M

Red_Modelo String<20>, M

Red_Fabricante String<20>, M

Red_Caracteristicas String<100>, M

Red_Ubicacion String<100>


Ref: PT-2007-023-12IEME 77

Red_F_Fin_Garantía Date, M

Id_M_Red_Com M, FK



TimeStamp Timestamp

Para los tipos de redes de comunicaciones y para los sistemas de control de tráfico

marítimo (AIS y RADAR) se almacenarán los mismos datos que para los sistemas de

comunicaciones.

SIST_CTRL_TRAFICO_MARITIMO

(AIS/RADAR)

Id_Ctrl_Trafico Int, M, K

Ctrl_Marca String<20>, M

Ctrl_Modelo String<20>, M

Ctrl_Fabricante String<20>, M

Ctrl_Caracteristicas String<100>, M

Ctrl_Ubicacion String<100>

Ctrl_F_Fin_Garantia Date, M

Id_M_Ctrl_Mar M, FK



TimeStamp Timestamp


Ref: PT-2007-023-12IEME 78

Las instalaciones portuarias que se pueden encontrar dentro del recinto portuario

deben ser registradas en la base de datos. De ellas se almacena el código de

instalación, si es gestionada directamente por la autoridad portuaria, el nombre, una

descripción del uso y las fechas de construcción, entrada en servicio y concesión. El

tipo de instalación y el nivel de seguridad serán claves ajenas.

INSTALACION_PORTUARIA

Id_Instalacion Int, M, K

Instal_Codigo String<20>, M

Inst_Gestión_Directa Bit, M

Inst_Nombre String<100>, M

Inst_Uso String<100>, M

Inst_F_Construcción Date, M

Inst_F_Ini_Servicio Date, M

Inst_F_Concesión Date, M

Id_M_Instalacion_Port M, FK

Id_M_Nivel_Seguridad M, FK

TimeStamp Timestamp

Para los medios mecánicos de uso en el puerto se almacenará en la base de datos el

nombre y el uso que tiene. En caso de tener matrícula, se guarda su número, el tipo de

energía empleada, la carga máxima y la descripción de las características técnicas. Se

almacenarán como claves ajenas el tipo de medio mecánico y los identificadores de

las empresas de instalación y revisión.

MEDIO MECANICO


Ref: PT-2007-023-12IEME 79

Id_Medio_Mec Int, M, K

Med_Nombre String<100>, M

Med_Uso String<100>, M

Med_Matricula String<10>

Med_Tipo_Energia String<20>, M

Med_Carga_Max Int

Med_Caracteristicas String<100>, M

Id_M_Medio_Mec M, FK



TimeStamp Timestamp

Para hacer la gestión de eventos o incidencias de seguridad es necesario crear una

entidad en la que se almacenarán los datos necesarios. Estos datos serán la fecha en

la que se ha producido la incidencia, y el estado actual. Además se almacena el tipo

de incidencia, el lugar en el que tiene lugar, el identificador de la persona que da el

aviso y la prioridad para resolver la incidencia. Todos estos datos serán claves ajenas

que provienen de otras entidades.

INCIDENCIA

Id_Incidencia Int, M, K

Inci_Fecha Date, M

Inci_Estado String<20>, M


Ref: PT-2007-023-12IEME 80

Id_M_Incidencia M, FK

Id_Instalacion FK

Id_Organismo_Pub FK

Id_Empresa FK

Id_Per M, FK

Id_M_Prioridad M, FK

TimeStamp Timestamp

Para gestionar las acciones a realizar dentro del recinto portuario se almacenan la

fecha de creación de esa acción o tarea, el estado de la misma, el tipo, el lugar en el

que se va a realizar, el usuario de la aplicación que ha creado la tarea y la prioridad

que tiene.

ACCIONES

Id_Accion Int, M, K

Acc_Fecha Date, M

Acc_Estado String<20>, M

Id_M_Accion M, FK

Id_Instalacion FK

Id_Organismo_Pub FK

Id_Empresa FK

Id_Usuario_Apl M, FK

Id_M_Prioridad M, FK

TimeStamp Timestamp


Ref: PT-2007-023-12IEME 81

Para guardar las fotos que se realizan al llegar un vehículo a un acceso, se creará una

entidad en la que se almacena el identificador de la foto y el path en el que se ha

almacenado la imagen. Así se consigue descargar a la base de datos de tener que

almacenar todas las imágenes. Además el identificador de cada foto se añadirá a la

relación entre las entidades Vehículo y Acceso, de forma que al llegar un coche a un

acceso, se almacenará la foto y se guardará un evento que una estas tres entidades.

FOTO_OCR

Id_Foto_OCR Int, M, K

OCR_Path String<100>, M

TimeStamp Timestamp

Del mismo modo, las fotos de los trabajadores internos, externos y los transportistas

que accedan al recinto portuario serán almacenadas fuera de la Base de Datos y se

guardará solo el identificador único y la ruta o path en la que se encuentra

almacenada.

FOTO_PERSONA

Id_Foto_Persona Int, M, K

Persona_Path String<100>, M

TimeStamp Timestamp

Para hacer el control de acceso de personas, se adjudicará a cada persona autorizada

una tarjeta en la que se registrarán los datos personales del propietario. Esta tarjeta

permitirá el acceso a zonas del puerto cuyo nivel de seguridad sea menor o igual al

asignado a la persona que posea la tarjeta. Se almacenarán la marca, el modelo y el

fabricante, además de una descripción opcional.


Ref: PT-2007-023-12IEME 82

TARJETA

Id_Tarjeta Int, M, K

Tarj_Marca String<20>, M

Tarj_Modelo String<20>, M

Tarj_Fabricante String<20>, M

Tarj_Descripcion String<100>

TimeStamp Timestamp

2.2.2.2.3 Tablas maestro

Las tablas maestro son tablas en las que se definen los únicos valores posibles para

algunos de los atributos que tendrán las entidades de la Base de Datos. Estas

entidades de la base de datos tendrán solo dos atributos, el primero el identificador (y

por tanto clave) de cada elemento y el tipo, donde se almacenarán los valores de los

datos de cada una de las tablas maestro. A continuación se muestran algunos

ejemplos de los valores que pueden tomar.

Tipo_M_Usuario: Id, Tipo (Administrador, Usuario).

Tipo_M_Doc_Id: Id, Tipo (NIF, Pasaporte, NIE->número de identificación de

extranjero).

Tipo_M_Vehículo: Id, Tipo (Acreditado, con Base en Puerto, Particular y de

Mercancías).

Tipo_M_Entidad_Veh: Id, Tipo (turismo, moto, furgoneta, autobús, entoldado, caja,

descubierto, cubierto, semirremolque, semirremolque cisterna, remolque, rígido,

camión, tractora, tracto camión, furgón, camión mixto, portacontenedores, tolva, silo o

basculante).


Ref: PT-2007-023-12IEME 83

Tipo_M_Dispositivo: Id, Tipo (Interfonos, Postes SOS, Cámaras, Semáforos o

Paneles de información luminosos, estaciones meteorológicas, CPD).

Tipo_M_Acceso: Id, Tipo (Barreras de coches, puerta giratoria, torno, puerta abatible

para vehículos, puerta normal, lectores de tarjetas).

Tipo_M_Contra_Incen: Id, Tipo (hidrantes, casetas, detectores de humo/gas,

extintores, rociadores y la señalización de emergencias).

Tipo_M_Sennal_Maritima: Id, Tipo (boya, baliza, faro, castillete…).

Tipo_M_Actividad: Id, Tipo (Naviera, Consignataria de buques, Consignataria de

carga, Transitario, Consolidador, Almacenista, Estibadora, Terminal, Cargador,

Transportista, Terminal de productos petroquímicos, Puesto de Inspección Fronteriza,

Amarrador, Remolcador, Práctico, Suministro al buque, Bunkering, Suministro de

agua, Suministro de luz, Marpol, Estatal de Estiba, Astillero, Taller, Varadero,

Restaurante, Cafetería, Cine, Puerto Deportivo, Club Náutico, Ofinicas y Despachos,

Lonja, Puerto pesquero, Pesquería o almacén de pescado, Empresa de

Mantenimiento… ).

Tipo_M_Organismo_Pub: Id, Tipo (Aduana, Capitanía Marítima, SASEMAR, Sanidad

Exterior, Agentes de Inspección Fronteriza).

Tipo_M_Sistem_Com: Id, Tipo (emisores, receptores, codificadores o antenas).

Tipo_M_Red_Com: Id, Tipo (fibra óptica, red inalámbrica).

Tipo_M_Ctrl_Mar: Id, Tipo (AIS, RADAR).

Tipo_M_Instalacion_Port: Id, Tipo (Tinglado, Almacenes, Muelles, Líneas de atraque,

Plataformas Ro-Ro, Grúas, Silos, Noray, Depots, Cubetos, Terminales).

Tipo_M_Medio_Mec: Id, Tipo (grúas, mafis, excavadoras, remolques, palas o

tractores).

Tipo_M_Nivel_Seguridad: Id, Tipo (Acceso Libre, Temporal Parcial, Temporal Global,

Temporal Instalaciones Especiales, Permanente Parcial, Permanente Global,

Permanente Instalaciones Especiales).


Ref: PT-2007-023-12IEME 84

Tipo_M_Nacionalidad: Id, Nacionalidad (Afghanistan, Albania, Algeria, American

Samoa, Andorra,…France,… Spain…).

En este caso el Identificador (Id) será un código compuesto por dos letras que

representan al país. En las nacionalidades mostradas anteriormente serían: AF -

Afghanistan, AL - Albania, DZ - Algeria, AS - American Samoa, AD - Andorra,… FR –

France,… ES – Spain…). Esta codificación se obtiene del listado proporcionado por

las Naciones Unidas (UNECE o United Nations Economic Commission for Europe) y

se puede consultar en la página web

http://www.unece.org/cefact/locode/service/main.htm.

Tipo_M_Incidencia: Id, Tipo (incendio, explosión, escape de sustancias tóxicas,

entrada no autorizada de personas al recinto, peligro por condiciones atmosféricas

adversas…).

Tipo_M_Prioridad: Id, Tipo (Alta, Media, Baja).

Tipo_M_Accion: Id, Tipo (Mantenimiento, Inspección, …).

2.2.2.2.4 Tablas generadas por eventos

Para representar en la base de datos la información a almacenar cada vez que se

produce un evento, se guardará en tablas separadas. Con evento, se entiende una

acción que se produce por ejemplo cuando un vehículo pasa a través de un acceso,

cuando una empresa inspecciona o revisa una instalación o cuando una persona visita

una instalación portuaria. Estas tablas son las que se crean al hacer el paso a tablas a

partir del Modelo Entidad/Relación y que surgen de cada relación entre entidades con

cardinalidad (N, M). Las tablas que se generan tendrán como atributos las claves

primarias (K) de las entidades que se ven involucradas y se almacenará un sello de

tiempo (timestamp).

Las nuevas tablas generadas por eventos serán:

Tablas generadas por eventos (entre dos entidades)

NO_ACREDITADO visita EMPRESA


Ref: PT-2007-023-12IEME 85

ESPORADICO visita EMPRESA

EXTERNO visita EMPRESA

INTERNO visita EMPRESA

TRANSPORTISTA visita EMPRESA

PASAJERO visita EMPRESA

CRUCERISTA visita EMPRESA

NO_ACREDITADO visita ORGANISMO_PUBLICO

ESPORADICO visita ORGANISMO_PUBLICO

EXTERNO visita ORGANISMO_PUBLICO

INTERNO visita ORGANISMO_PUBLICO

TRANSPORTISTA visita ORGANISMO_PUBLICO

PASAJERO visita ORGANISMO_PUBLICO

CRUCERISTA visita ORGANISMO_PUBLICO

NO_ACREDITADO visita INSTALACION_PORTUARIA

ESPORADICO visita INSTALACION_PORTUARIA

EXTERNO visita INSTALACION_PORTUARIA

INTERNO visita INSTALACION_PORTUARIA

TRANSPORTISTA visita INSTALACION_PORTUARIA

PASAJERO visita INSTALACION_PORTUARIA

CRUCERISTA visita INSTALACION_PORTUARIA

NO_ACREDITADO pasa por ACCESO


Ref: PT-2007-023-12IEME 86

ESPORADICO pasa por ACCESO

EXTERNO pasa por ACCESO

INTERNO pasa por ACCESO

TRANSPORTISTA pasa por ACCESO

PASAJERO pasa por ACCESO

CRUCERISTA pasa por ACCESO

NO_ACREDITADO conduce VEHICULO

ESPORADICO conduce VEHICULO

EXTERNO conduce VEHICULO

INTERNO conduce VEHICULO

TRANSPORTISTA conduce VEHICULO

PASAJERO conduce VEHICULO

CRUCERISTA conduce VEHICULO

ORGANISMO_PUBLICO tiene DIRECCION

EMPRESA tiene DIRECCION

Tablas generadas por eventos (entre tres entidades)

VEHICULO atraviesa ACCESO genera FOTO_OCR

2.2.3 Análisis de casos de uso

Se ha realizado un gran número de casos de estudio para la aplicación objeto de este

proyecto. A continuación se describen varios casos de estudio del sistema.


Ref: PT-2007-023-12IEME 87

2.2.3.1 Servicio de Seguridad

En esta sección se procede a enunciar los casos de uso del Servicio de Seguridad,

éstos se dividen en varios casos de estudio. Enunciamos a continuación los casos de

estudio con sus casos de uso correspondientes:

Control de acceso de vehículos (Figura 11)

Alta de vehículo.

Baja de vehículo.

Modificación de vehículo.

Control de acceso de personas (Figura 12)

Alta de usuario.

Baja de usuario.

Modificación de usuario.

Gestión de zonas o áreas restringidas (Figura 14)

Alta de zona.

Baja de zona.

Modificación de zona.

Gestión de eventos (Figura 15)

Alta de evento.

Baja de evento.


Ref: PT-2007-023-12IEME 88

Modificación de evento.

Figura 11: Casos de uso Control de Acceso de Vehículos

Alta persona

Baja persona

Modificación persona

Administrador Usuario

Acceso persona

Figura 12: Caso de uso Control de Acceso de Usuarios


Ref: PT-2007-023-12IEME 89

Figura 13: Casos de uso Gestión de zonas o áreas restringidas

Figura 14: Casos de uso Gestión de eventos

Alta de vehículo: Este caso de uso analiza el alta en el sistema de un vehículo

autorizado a acceder a las áreas restringidas del puerto.

Actor Principal: Empleado

Actor Secundario: Administrador

Precondiciones:


Ref: PT-2007-023-12IEME 90

Postcondiciones: El vehículo puede acceder a las áreas del recinto

portuario para las cuales se le ha asignado permiso.

Escenario Principal de Éxito (o Flujo Básico): El administrador

indica en el GUI (Graphical User Interface) que desea dar de alta en

el sistema a un nuevo vehículo. El empleado (conductor del

vehículo) presenta los datos necesarios para el alta en el sistema.

Esto puede ser por ejemplo un formulario de solicitud de permiso

con los datos del vehículo, la empresa y el conductor. Los datos se

validan en el sistema (se comprueba que la empresa tiene permiso

para operar en el puerto, etc.), si los datos son correctos se

comprueba que el vehículo no está ya dado de alta. Si no lo está se

asignan los permisos de acceso pertinentes y se guardan los datos

en la base de datos correspondiente para garantizar el acceso del

vehículo a las áreas restringidas

Extensiones (o Flujos Alternativos): Si la verificación de los datos

del vehículo falla o el vehículo ya está dado de alta en el sistema, la

transacción falla.

La Figura 16 muestra el diagrama de bloques para el caso de uso de Alta de Vehículo.


Ref: PT-2007-023-12IEME 91

Figura 15: Diagrama de Bloques Alta de Vehículo

Baja de vehículo Este caso de uso analiza la baja en el sistema de un

vehículo autorizado a acceder a las áreas restringidas del puerto.

Actor Principal: Administrador

Actor Secundario:


Ref: PT-2007-023-12IEME 92

Precondiciones: El vehículo debe estar dado de alta en el sistema

antes de intentar darlo de baja

Postcondiciones:El vehículo deja de tener permiso de acceso a las

áreas restringidas del recinto portuario.

Escenario Principal de Éxito (o Flujo Básico):El administrador

indica en el GUI que desea dar de baja un vehículo en el sistema. El

administrador introduce los datos de identificación del vehículo en el

sistema. El servicio consulta la base de datos y comprueba la

existencia del vehículo. Si el vehículo existe se le muestra al

Administrador una ventana de confirmación. Si el administrador

confirma la transacción el sistema borra de la base de datos el

apunte correspondiente al vehículo en cuestión. A partir de ese

momento el vehículo deja de tener permiso de acceso a las áreas

restringidas.

Extensiones (o Flujos Alternativos): Si el vehículo no se

encuentra dado de alta en el sistema se produce un error.

La Figura 17 muestra el diagrama de bloques para el caso de uso de Baja de

Vehículo.


Ref: PT-2007-023-12IEME 93

Figura 16: Diagrama de Bloques Baja de Vehículo

Modificación de vehículo Este caso de uso analiza la modificación en el

sistema de los datos de un vehículo autorizado, o los permisos de acceso a las

áreas restringidas del puerto.


Actor Secundario:

Precondiciones: El vehículo debe estar dado de alta en el sistema

antes de intentar modificarlo.

Postcondiciones: Los datos referentes al vehículo sus permisos de

acceso se han modificado.


Ref: PT-2007-023-12IEME 94

Escenario Principal de Exito (o Flujo Básico): El administrador

indica en el GUI que desea modificar los datos de un vehículo. El

administrador introduce en el sistema los datos de identificación del

vehículo. El sistema comprueba la existencia del vehículo y en caso

de que exista, la GUI de la aplicación muestra al Administrador un

formulario desde el que puede modificar los datos del vehículo y sus

permisos de acceso. Una vez el administrador confirma que la

modificación de datos es correcta los datos se guardan en la base

de datos correspondiente.

Extensiones (o Flujos Alternativos): Si el vehículo no se

encuentra dado de alta en el sistema se produce un error.

La Figura 18 muestra el diagrama de bloques para el caso de uso de modificación de

Vehículo.


Ref: PT-2007-023-12IEME 95

Figura 17: Diagrama de Bloques Modificación de Vehículo

Acceso de vehículos a un área restringida Este caso de uso analiza el

acceso de un vehículo a un área restringida.

Actor Principal: Usuario


Precondiciones: El vehículo ha sido dado de alta previamente en el

sistema, se ha revisado su documento de identidad almacenado en

el sistema, su número único de identificación; además el empleado


Ref: PT-2007-023-12IEME 96

ha realizado el alta del vehículo para el reconocimiento automático

de matriculas. Se asume que, en su caso, las condiciones de

iluminación y posición de la cámara son adecuadas para la captura

de imágenes.

Postcondiciones: Si el vehículo se identifica correctamente se

activará una señal que abrirá la barrera que da acceso al área

restringida.

Escenario Principal de Éxito (o Flujo Básico): El usuario se

acerca con su vehículo al punto de acceso automático para

vehículos. El sistema detecta la presencia de un vehículo y lanza la

captura de la imagen. Se detecta la matricula y se compara con las

matriculas almacenadas en la base de datos. Si la matricula se

encuentra y tiene permiso para acceder al área restringida se

genera una señal que abre la barrera de acceso.

Extensiones (o Flujos Alternativos): si la matricula no se detecta

se volverá a intentar el proceso, si el numero de matricula no es

detectado o no es válido en el sistema se generará un evento que

deberá ser atendido por un Administrador.

La Figura 19 muestra el diagrama de bloques para el caso de uso de acceso área

restringida.


Ref: PT-2007-023-12IEME 97

Figura 18: Acceso a área restringida

Alta de área restringida Este caso de uso analiza el alta en el sistema de un

área restringida del puerto.


Actor Secundario:

Precondiciones:

Postcondiciones: Se crea un área de acceso restringido a la cual

se le pueden empezar a asignar recursos.


Ref: PT-2007-023-12IEME 98


indica en el GUI que desea dar de alta una nueva área restringida.

El GUI muestra la pantalla de introducción de datos para una nueva

área restringida. El administrador introduce los datos requeridos y

estos se validan. En caso de ser validos los datos se guardan en la

base de datos.


del área o el área ya está dado de alta en el sistema, la transacción

falla.

Figura 19: Alta de un área restringida

La Figura 20 muestra el diagrama de bloques para el caso de uso de Alta de un área

restringida.

Baja de Área Restringida Este caso de uso analiza la baja en el sistema de un

área restringida del puerto.


Ref: PT-2007-023-12IEME 99


Actor Secundario:

Precondiciones: El área debe estar dada de alta en el sistema

antes de intentar darlo de baja.

Postcondiciones: El área deja de existir, eliminando las posibles

referencias de permisos de usuarios y vehículos.


introduce los datos de identificación del área en el sistema. El

servicio consulta la base de datos y comprueba la existencia del

área. Si el área existe se le muestra al Administrador una ventana

de confirmación. Si el administrador confirma la transacción el

sistema borra de la base de datos el apunte correspondiente al área

en cuestión. A partir de ese momento deja de existir en la base de

datos el área restringida.

Extensiones (o Flujos Alternativos): Si el área no se encuentra

dada de alta en el sistema se produce un error.

La Figura 21 muestra el diagrama de bloques para el caso de uso de Baja de un área

restringida.


Ref: PT-2007-023-12IEME 100

Figura 20. Baja de un área restringida

Modificación de área restringida Este caso de uso analiza la modificación en

el sistema de los datos de un área restringida del puerto.


Actor Secundario:

Precondiciones: El área debe estar dada de alta en el sistema


Postcondiciones: Los datos referentes al área o sus permisos de

acceso se han modificado.


introduce en el sistema los datos de identificación del área. El


Ref: PT-2007-023-12IEME 101

sistema comprueba la existencia del área y en caso de que exista, la

GUI de la aplicación muestra al Administrador un formulario desde el

que puede modificar los datos del área y sus permisos de acceso.

Una vez el administrador confirma que la modificación de datos es

correcta los datos se guardan en la base de datos correspondiente.

Extensiones (o Flujos Alternativos): Si el área no se encuentra

dada de alta en el sistema se produce un error.

La Figura 22 muestra el diagrama de bloques para el caso de uso de modificación de

un área restringida.

Figura 21: Modificación de área restringida


Ref: PT-2007-023-12IEME 102

Alta de usuario Este caso de uso analiza el alta en el sistema de un usuario

con permisos de acceso a un área restringida del puerto.



Precondiciones:

Postcondiciones: Se crea un nuevo perfil de usuario y se le

asignan los permisos de acceso a áreas restringidas pertinentes.


indica en el GUI que desea dar de alta una nuevo usuario con

permisos de acceso. El GUI muestra la pantalla de introducción de

datos para un nuevo usuario. El administrador introduce los datos

requeridos y estos se validan. En el supuesto de que existan

controles biométricos u otros procedimientos, el sistema procederá a

mostrar al usuario las instrucciones y los pasos a seguir para tomar

una captura de entrenamiento o satisfacer cualesquiera que sean

los requisitos del control de accesos. En caso de ser validos los

datos se guardan en la base de datos.


del usuario falla o el usuario ya está dado de alta en el sistema, la

transacción falla.

La Figura 23 muestra el diagrama de bloques para el caso de uso de Alta de un

usuario.


Ref: PT-2007-023-12IEME 103

Figura 22: Alta de un usuario

Baja de Usuario Este caso de uso analiza la baja en el sistema de un área

restringida del puerto.


Actor Secundario:


Ref: PT-2007-023-12IEME 104

Precondiciones: El usuario debe estar dado de alta en el sistema

antes de intentar darlo de baja

Postcondiciones: El usuario deja de existir, eliminando las posibles

referencias de permisos de áreas restringidas.

Escenario Principal de Exito (o Flujo Básico): El administrador

introduce los datos de identificación del usuario en el sistema. El

servicio consulta la base de datos y comprueba la existencia del

usuario. Si el usuario existe se le muestra al Administrador una

ventana de confirmación. Si el administrador confirma la transacción,

el sistema borra de la base de datos el apunte correspondiente al

usuario en cuestión. A partir de ese momento deja de existir en la

base de datos el usuario, con lo que ya no tiene acceso a las áreas

restringidas.

Extensiones (o Flujos Alternativos): Si el usuario no se encuentra

dado de alta en el sistema se produce un error.

La Figura 24 muestra el diagrama de bloques para el caso de uso de Baja de un

usuario.


Ref: PT-2007-023-12IEME 105

Figura 23: Baja de un usuario

Modificación de Usuario Este caso de uso analiza la modificación en el

sistema de los datos de un usuario con permisos de acceso a un área

restringida del puerto.


Actor Secundario:

Precondiciones: El usuario debe estar dado de alta en el sistema


Postcondiciones: Los datos referentes al usuario o sus permisos

de acceso se han modificado.


Ref: PT-2007-023-12IEME 106


introduce en el sistema los datos de identificación del usuario. El

sistema comprueba la existencia del usuario y en caso de que

exista, la GUI de la aplicación muestra al Administrador un

formulario desde el que puede modificar los datos del usuario y sus

permisos de acceso. Una vez el administrador confirma que la

modificación de datos es correcta los datos se guardan en la base

de datos correspondiente.

Extensiones (o Flujos Alternativos): Si el usuario no se encuentra

dado de alta en el sistema o la validación de los datos modificados

falla se produce un error.

Figura 25 muestra el diagrama de bloques para el caso de uso de modificación de un

usuario con permisos de acceso a un área restringida.


Ref: PT-2007-023-12IEME 107

Figura 24: Modificación de un usuario con permisos de acceso

Acceso de usuarios a un área restringida Este caso de uso analiza el

acceso de un usuario a un área restringida.



Precondiciones: el empleado ha sido dado de alta previamente en

el sistema, se ha revisado su documento de identidad almacenando

en el sistema, su número único de identificación; además el

empleado ha realizado el alta para cada una de las modalidades

biométricas existentes (facial, dactilar, etc). Se asume que, en su


Ref: PT-2007-023-12IEME 108

caso, las condiciones de iluminación y posición de la cámara son

adecuadas para la captura de imágenes faciales frontales y que el

lector de huellas está limpio y devuelve muestras fiables.

Postcondiciones: si el empleado introduce correctamente su

documento de identidad y la muestra adquirida para realizar la

verificación biométrica proporciona un resultado de verificación

verdadero, entonces se activará una señal sobre el puerto paralelo

durante 10 segundos que activará el relé de control de apertura de

la puerta o barrera, haciendo posible la apertura de la misma y

facilitando el acceso al recinto.

Escenario Principal de Éxito (o Flujo Básico): el empleado se

acercará a la puerta de acceso, a su lado encontrará el dispositivo

de control de acceso que constará de un lector de documentos de

identidad, una pantalla táctil, una cámara Web o un lector de huellas

digitales, según proceda. La pantalla táctil mostrará el logotipo de la

empresa, el empleado pulsará sobre la pantalla y la GUI indicará

cuales son las instrucciones para realizar la identificación. Una vez

introducidas las credenciales, el sistema verificará si son válidas. En

caso de identificación biométrica la GUI presentará instrucciones

necesarias para realizar la captura de una muestra biométrica. Una

vez se disponga de la muestra, se recuperará el template del

usuario de la base de datos y se realizará la verificación. Si tanto el

PIN del usuario como la verificación biométrica son correctos,

entonces se activará una señal que permitirá la apertura de la puerta

durante un intervalo configurable de 10 segundos por defecto,

tiempo mientras el cual la GUI mostrará el color verde como fondo.

Si el número de identificación personal es erróneo o la verificación

biométrica es falsa, la GUI mostrará durante 3 segundos el fondo de

color rojo y volverá a la pantalla de logo inicial. Para la captura de

las muestras faciales, el usuario deberá mirar frontalmente a la

cámara (por eso, la cámara debe estar situada a una altura

adecuada) -el flujo de video será mostrado con una barra que mida

la frontalidad de la cara en ese momento-, y cuando se encuentre


Ref: PT-2007-023-12IEME 109

una buena imagen facial según criterios de frontalidad e iluminación,

el proceso de captura habrá terminado.

Extensiones (o Flujos Alternativos): si el empleado introduce

erróneamente su documento de identidad se cancelará el proceso y

deberá volver a intentarlo con la orientación adecuada. Si el

documento es auténtico pero el número de identificación no es

válido en el sistema, se informará del error a través de la GUI una

vez haya realizado la verificación. Si sucede un fallo de adquisición

de muestra por vencimiento del temporizador, el usuario tendrá que

empezar de nuevo el proceso de autenticación volviendo a

presentar su documento de identidad. Si la muestra biométrica

capturada no alcanza la calidad mínima exigida, se solicitará otra al

usuario. Si el proceso falla durante 3 veces seguidas, el sistema

lanzará un evento de error que será atendido por el administrador

del sistema.

Figura 26 muestra el diagrama de bloques para el caso de uso de acceso área

restringida.


Ref: PT-2007-023-12IEME 110

Figura 25. Acceso área restringida

Alta de evento Este caso de uso analiza el alta en el sistema de un nuevo

evento.



Precondiciones:


Ref: PT-2007-023-12IEME 111

Postcondiciones: Se crea un nuevo evento con la información que

introduzca el usuario, incluyendo el estado inicial del que parte, la

ubicación la hora y fecha de comienzo etc.


indica en el GUI que desea dar de alta un nuevo evento o alarma. El

GUI muestra la pantalla de introducción de datos para un nuevo

evento. El usuario introduce los datos relativos al evento y si estos

no están ya registrados como un evento, se almacenarán en BBDD.

Extensiones (o Flujos Alternativos): Si el evento ya ha sido

introducido con anterioridad, se terminará el proceso de creación de

nuevo evento.

Figura 27 muestra el diagrama de bloques para el caso de uso de Alta de un evento.

Figura 26. Alta de un nuevo evento


Ref: PT-2007-023-12IEME 112

Baja de evento Este caso de uso analiza la baja en el sistema de un evento.



Precondiciones: el evento debe estar almacenado en base de datos.

Postcondiciones: Se elimina de la base de datos el evento.


indica en el GUI que desea dar de baja un evento o alarma

seleccionando del listado el que desea eliminar. El evento se elimina

de la base de datos.

Extensiones (o Flujos Alternativos): Si el evento no existe en la

base de datos, se terminará el proceso de eliminación de evento.

Figura 28 muestra el diagrama de bloques para el caso de uso de Baja de un evento

Figura 27. Baja de un evento


Ref: PT-2007-023-12IEME 113

Modificación de evento Este caso de uso analiza la modificación de un

evento.



Precondiciones: el evento debe estar almacenado en base de datos.

Postcondiciones: Se almacenan en la base de datos las

modificaciones introducidas por el usuario.


indica en el GUI que desea modificar un evento o alarma

seleccionando del listado. El evento se modifica en la base de datos.

Extensiones (o Flujos Alternativos): Si el evento no existe en la

base de datos, se terminará el proceso de modificación de evento.

Figura 29 muestra el diagrama de bloques para el caso de uso de Modificación de un

evento


Ref: PT-2007-023-12IEME 114

Figura 28. Modificación de un evento

2.2.3.2 Servicio de Conservación

Enunciamos a continuación los casos de uso correspondientes:

Sistema de control de incendios (Figura 30).

Consulta de estado.

Cambiar estado de sistema existente.


Ref: PT-2007-023-12IEME 115

Alta nuevo sistema.

Baja sistema existente.

Sistema de monitorización de balizamiento (Figura 31):

Alta elemento de balizamiento.

Baja elemento de balizamiento.

Modificar estado.

Visualización de estado y características.

Sistema de gestión de dispositivos instalados (Figura 32):

Alta dispositivo.

Baja dispositivo.

Modificar dispositivo.


Ref: PT-2007-023-12IEME 116

Figura 29: Casos de uso del sistema de control de incendios

La aplicación propuesta para el sistema de control de incendios consiste en el

formulario de consulta y control de altas y bajas de los sistemas de control de

incendios de la zona portuaria. Se considera que existen dos tipos de actores, los

operarios del centro de control, que realizan consultas sobre el estado de los sistemas

de control de incendios y pueden modificar ciertos parámetros de dichos sistemas, y el

administrador del sistema, cuyas funciones principales serían la realización de altas y

bajas en la base de datos de sistemas de control de incendios.


Ref: PT-2007-023-12IEME 117

Figura 30: Casos de uso del sistema de monitorización de balizamiento

La aplicación propuesta consiste en la monitorización por parte de los empleados u

operadores del centro de control y del administrador del sistema de los elementos de

balizamientos localizadas en el área perteneciente a la Autoridad Portuaria. El

administrador será el único usuario con los permisos necesarios para dar de alta y de

baja elementos de balizamiento.


Ref: PT-2007-023-12IEME 118

Figura 31: Casos de uso de la gestión de dispositivos

Consulta de Estado: Este caso de uso analiza la consulta de estado sobre un

sistema de control de incendios específico.

Actor principal: Operario del centro de control.

Precondiciones: Se asume que existe una base de datos con los

servicios de control de incendios existentes en la zona portuaria,

ordenados por áreas y edificios. Se asume que cada sistema de

control de incendios dispone de un sistema de monitorización del

estado y de actuación en caso de ser necesario, que transmite la

información a un servidor con el que se comunicará la aplicación

objeto del presente proyecto.

Postcondiciones: Si se selecciona correctamente el área o edificio

en el que se localiza el sistema de control de incendios, y se

selecciona correctamente el sistema de control de incendios que se

desea consultar, se mostrará en pantalla una tabla con todos los

parámetros monitorizados para dichos sistema de control de

incendios.

Escenario Principal de Éxito (o Flujo Básico): El operario del

centro de control, tras haber accedido al sistema mediante la

contraseña adecuada, seleccionará el área o edificio en el que se

ubica el sistema de control de incendios sobre el que se quiere

realizar la consulta. Tras esto en la pantalla se mostrará una lista de

los sistemas de control de incendios disponibles en dicha área o

edificio. El operario del centro de control deberá seleccionar el

sistema de control de incendios deseado. Una vez realizada dicha

selección la aplicación obtendrá la información del servidor que

almacena la información del sistema de control de incendios

seleccionado y la mostrará por pantalla.

Extensiones (o Flujos Alternativos): No existen para este caso de

uso.


Ref: PT-2007-023-12IEME 119

Figura 32: Caso de uso de consulta de estado de sistema de control de incendios

Alta nuevo sistema: Este caso de uso analiza el alta de un nuevo sistema de

control de incendios en un área o edificio de la zona portuaria.

Actor principal: Administrador del sistema.







objeto del presente proyecto. Se considera que el alta de un nuevo

sistema de control de incendios se producirá por la instalación de

mejoras de control en áreas o edificios que antes carecían de ellas.

Estas mejoras deben ser estándares en el mercado, de forma que


Ref: PT-2007-023-12IEME 120

ya estarían recogidas en las bases de datos del sistema; si alguna

de estas mejoras fuesen innovaciones que no existían en el

momento de la instalación de la aplicación el proceso de alta sería

más complicado y debería realizarse como una actualización del

software.


en el que se localiza el nuevo sistema de control de incendios, y se


desea dar de alta, se mostrará en pantalla un formulario que solicite

la información necesaria para poder comunicarse con los servidores

que monitorizan dicho sistema de control de incendios. Si esta

información se introduce correctamente, el nuevo sistema de control

de incendios será dado de alta en el sistema y se podrán realizar

consultas y cambios de estado con posterioridad por parte de los

operarios del centro de control.


del sistema, tras haber accedido al sistema mediante la contraseña

adecuada y haberse realizado la validación de la contraseña como

administrador, tendrá que acceder al módulo de la aplicación que

permite dar de alta nuevos sistemas de control de incendios.

Seleccionará el área o edificio en el que se ubicará el nuevo sistema

de control de incendios. La aplicación mostrará una lista de posibles

sistemas de control de incendios que se pueden dar de alta y el

administrador seleccionará el tipo de sistema de control de incendios

al que se quiere dar de alta. La aplicación mostrará un formulario en

el que se solicite la información necesaria para poder comunicarse

con los servidores que monitorizarán el nuevo sistema de control de

incendios. Se realizará la comprobación de que la comunicación con

dichos servidores se realiza correctamente. Finalmente se aceptará

el alta del nuevo sistema de control de incendios, que se incluirá en

la base de datos de sistemas de control disponibles en el área o

edificio seleccionado.

Extensiones (o Flujos Alternativos): si al comprobar la contraseña

introducida se detecta que no corresponde a ningún administrador


Ref: PT-2007-023-12IEME 121

se interrumpe el proceso, que se tendría que volver a iniciar en caso

de que se haya producido error al introducir la contraseña. Si al

introducir los datos sobre las conexiones a los servidores del nuevo

sistema se recibe un error por imposibilidad de realizar la conexión a

dicho servidor se volvería a solicitar dicha información hasta que se

introdujese correctamente.

Figura 33: Caso de uso alta nuevo sistema de control de incendios


Ref: PT-2007-023-12IEME 122

Baja sistema existente: Este caso de uso analiza la baja de un

sistema de control de incendios existente en un área o edificio de la

zona portuaria.

Actor principal: Administrador del sistema.







objeto del presente proyecto. Se considera que la baja de un

sistema de control de incendios ya existente en un área o edificio

puede producirse porque se vaya a instalar un sistema más

novedoso que sustituya al anterior o porque se va cambiar la

funcionalidad del edificio por lo que habría que sustituir los sistemas

existentes por otros adecuados.




desea dar de baja, se solicitará confirmación para dar de baja dicho

sistema y en caso de que se confirme se procederá a la baja de

dicho sistema de control de incendios y su eliminación de las bases

de datos correspondientes.


del sistema, tras haber accedido al sistema mediante la contraseña

adecuada y haberse realizado la validación de la contraseña como

administrador, tendrá que acceder al módulo de la aplicación que

permite dar de baja sistemas de control de incendios existentes.

Seleccionará el área o edificio en el que se ubica el sistema de

control de incendios que se quiere dar de baja. La aplicación

mostrará una lista de los sistemas de control de incendios existentes

y el administrador seleccionará el sistema de control de incendios


Ref: PT-2007-023-12IEME 123

que se quiere dar de baja. La aplicación solicitará confirmación de la

operación que se va a realizar. Tras proporcionar confirmación de

que se quiere realizar se procede a dar de baja dicho sistema de

control de incendios en las bases de datos correspondientes.

Extensiones (o Flujos Alternativos): si al comprobar la contraseña

introducida se detecta que no corresponde a ningún administrador

se interrumpe el proceso, que se tendría que volver a iniciar en caso

de que se haya producido error al introducir la contraseña.


Ref: PT-2007-023-12IEME 124

Figura 34: Caso de uso de baja de un sistema de control de incendios existente

Cambiar estado sistema existente: Este caso de uso analiza la operación de

cambio de estado en aquellos sistemas de control de incendios que permitan

algún tipo de actuación sobre ellos.

Actor principal: Operario del centro de control.


Ref: PT-2007-023-12IEME 125







objeto del presente proyecto.



selecciona correctamente el sistema de control de incendios sobre el

que se desea actuar, la aplicación mostrará todas las posibles

acciones (en caso de que exista alguna) que se pueden realizar

sobre dicho sistema de control de incendios.

Escenario Principal de Éxito (o Flujo Básico): El operario del

centro de control, tras haber accedido al sistema mediante la

contraseña adecuada, seleccionará el área o edificio en el que se

ubica el sistema de control de incendios sobre el que se quiere

cambiar el estado. Tras esto en la pantalla se mostrará una lista de

los sistemas de control de incendios disponibles en dicha área o

edificio. El operario del centro de control deberá seleccionar el

sistema de control de incendios deseado. Una vez realizada dicha

selección la aplicación obtendrá la información del servidor que

almacena la información del sistema de control de incendios

seleccionado y la mostrará por pantalla, dando la opción de realizar

las actividades disponibles para el sistema de control de incendios

seleccionado, en caso de que haya alguna acción que pueda

realizarse.


Ref: PT-2007-023-12IEME 126

Figura 35: Caso de uso cambio de estado de sistema de control existente

Alta de Elementos de balizamiento: Este caso de uso analiza la operación de

alta de un nuevo elemento de balizamiento.

Actor principal: Administrador

Precondiciones: Se asume que el usuario Administrador está dado

de alta en el sistema y se ha logado correctamente en la aplicación.

También se da por hecho que existe una Base de Datos creada en

la que se almacenan elementos de balizamiento y que dentro de la

misma no existe una boya de balizamiento igual a la que se quiere

dar de alta.

Postcondiciones: Al terminar el proceso de alta de boya de

balizamiento correctamente, se habrá insertado la misma con sus

características y un estado inicial dentro del sistema.


seleccionará el tipo de balizamiento que desea insertar en el


Ref: PT-2007-023-12IEME 127

sistema (faros, boyas, balizas…). Una vez seleccionado el tipo de

balizamiento se mostrará una ficha con las características

requeridas para dicho tipo, que el administrador deberá completar.

El sistema asignará un nuevo número de identificador de

balizamiento y se mostrará por pantalla. El administrador deberá

introducir la posición (latitud y longitud) en la que se ubica el nuevo

balizamiento y el estado inicial con el que se pondrá en marcha el

mismo.

Extensiones (o Flujos Alternativos): No hay.

Figura 36: Caso de uso alta elemento de balizamiento


Ref: PT-2007-023-12IEME 128

Baja de Elementos de balizamiento: Este caso de uso analiza la operación

de baja de un elemento de balizamiento preexistente.


Precondiciones: Se asume que el usuario Administrador está dado

de alta en el sistema y se ha logado correctamente en la aplicación.

También se da por hecho que existe una Base de Datos creada en

la que se almacenan elementos de balizamiento.

Postcondiciones: Si el caso de uso finaliza con éxito, se habrá

eliminado de la base de datos de elementos de balizamiento, la

entrada correspondiente a la boya de balizamiento de entrada. En

caso contrario la base de datos se mantendrá invariable.


introducirá unos datos de búsqueda referentes a la boya de

balizamiento que quiere eliminar del sistema. Estos datos pueden

ser desde el número de identificador hasta el nombre, la posición o

el tipo de boya de balizamiento. Como resultado de esta búsqueda

se mostrará un listado con las entradas localizadas para que el

usuario seleccione la que quiere eliminar. Una vez seleccionada, se

elimina de la base de datos y se muestra un mensaje por pantalla de

fin de borrado con éxito.

Extensiones (o Flujos Alternativos): En caso de que no se

encuentre la entrada de balizamiento deseada o tras realizar la

búsqueda no se obtengan ningún resultado, se podrá cancelar la

operación, con lo que se mostrará un mensaje por pantalla de

operación de borrado cancelada.


Ref: PT-2007-023-12IEME 129

Figura 37: Caso de uso baja elemento de balizamiento

Visualización de Estado y Características: Este caso de uso analiza la

operación de visualización del estado un elemento de balizamiento existente, y

muestra sus características principales.

Actor principal: Operador o Administrador.

Precondiciones: Se asume que el usuario Administrador u

Operador están dados de alta en el sistema y se han logado

correctamente en la aplicación. También se da por hecho que existe

una Base de Datos creada en la que se almacenan elementos de

balizamiento y que esta no está vacía.


Ref: PT-2007-023-12IEME 130

Postcondiciones: Si la finalización de este caso de uso tiene

resultado satisfactorio, se habrá mostrado al usuario por pantalla las

características básicas de un balizamiento y el estado en el que se

encuentra el mismo en el momento de hacer la consulta.

Escenario Principal de Éxito (o Flujo Básico): Este caso de uso

comienza cuando el operador o el administrador seleccionan dentro

de su sesión en la aplicación la opción de Visualizar Estado y

Características de elementos de balizamiento. Para seleccionar el

elemento de balizamiento del que se quiere consultar el estado o las

características se puede realizar una búsqueda introduciendo datos

para filtrar las entradas almacenadas en la base de datos. Esos

datos pueden ser desde el nombre del elemento, hasta el tipo o el

número de identificación del mismo entre otros que harán las

funciones de filtrado. A continuación se muestra por pantalla la lista

de entradas encontradas que cumplen con el filtro que se ha

introducido y el usuario podrá seleccionar una de ellas. Una vez

seleccionada se mostrarán las características de ese elemento

como pueden ser (nombre, tipo, posición, señal luminosa, señal

acústica, DGPS…) y el estado en el que se encuentran las

características y el elemento de balizamiento.

Extensiones (o Flujos Alternativos): En caso de que la búsqueda

no devuelva ningún resultado al aplicar el filtro introducido, se podrá

volver a introducir otras características de filtrado y realizar una

nueva búsqueda o finalizar la operación.


Ref: PT-2007-023-12IEME 131

INICIO

Introducción de características de

elemento

Lista vacía Cambiar filtroSI

SI

FIN

NO

Mostrar listado

Seleccionar elemento

Mostrar características de

elemento

NO

FIN

Figura 38: Caso de uso de visualización de estado y características de un elemento de balizamiento

Modificar Estado del Elemento de Balizamiento: Este caso de uso analiza la

operación de modificación de estado de un elemento de balizamiento.

Actor principal: Operador o Administrador

Precondiciones: Se asume que el usuario Administrador u

Operador están dados de alta en el sistema y se han logado

correctamente en la aplicación. También se da por hecho que existe


Ref: PT-2007-023-12IEME 132

una Base de Datos creada en la que se almacenan elementos de

balizamiento y que esta no está vacía.

Postcondiciones: Si la finalización de este caso de uso tiene

resultado satisfactorio, se habrá modificado el estado del elemento

de balizamiento seleccionado o de alguna de sus características.


comienza cuando el operador o el administrador seleccionan dentro

de su sesión en la aplicación la opción de Modificar el Estado de

elementos de balizamiento. Para seleccionar el elemento de

balizamiento al que se quiere modificar el estado se puede realizar

una búsqueda introduciendo datos para filtrar las entradas

almacenadas en la base de datos. Esos datos pueden ser desde el

nombre del elemento, hasta el tipo o el número de identificación del

mismo entre otros que harán las funciones de filtrado. A

continuación se muestra por pantalla la lista de entradas

encontradas que cumplen con el filtro que se ha introducido y el

usuario podrá seleccionar una de ellas. Una vez seleccionada se

mostrarán las características de ese elemento como pueden ser

(nombre, tipo, posición, señal luminosa, señal acústica, DGPS…) y

el estado en el que se encuentran las características y el elemento

de balizamiento. Se podrá seleccionar el cambio de estado del

elemento de balizamiento o de alguna de sus características y al

finalizar se mostrará un mensaje por pantalla de “cambios

efectuados correctamente”.

Extensiones (o Flujos Alternativos): En caso de que la búsqueda

no devuelva ningún resultado al aplicar el filtro introducido, se podrá

volver a introducir otras características de filtrado y realizar una

nueva búsqueda o finalizar la operación.


Ref: PT-2007-023-12IEME 133

INICIO

Introducir características de

elemento

Mostrar listado

Lista vacía Cambiar filtroSI

NO

SI

FIN

NO

Seleccionar elemento

Mostrar características de

elemento

Cambiar estado del elemento o las

características

FIN

Figura 39: Caso de uso de modificación estado elemento de balizamiento

Alta de dispositivo Este caso de uso analiza el alta en el sistema de un nuevo

dispositivo.



Ref: PT-2007-023-12IEME 134


Precondiciones:

Postcondiciones: Se crea un nuevo dispositivo con la información

que introduzca el usuario.


indica en el GUI que desea dar de alta un nuevo dispositivo El GUI

muestra la pantalla de introducción de datos para un nuevo

dispositivo. El usuario introduce los datos relativos al dispositivo y si

estos no están ya registrados, se almacenarán en BBDD.

Extensiones (o Flujos Alternativos): Si el dispositivo ya ha sido

introducido con anterioridad, se terminará el proceso de creación de

nuevo dispositivo.

Figura 41 muestra el diagrama de bloques para el caso de uso de Alta de un

dispositivo.

Figura 40. Alta de un nuevo dispositivo

Baja de dispositivo Este caso de uso analiza la baja en el sistema de un

dispositivo.



Precondiciones: el dispositivo debe estar almacenado en base de

datos.


Ref: PT-2007-023-12IEME 135

Postcondiciones: Se elimina de la base de datos el dispositivo.


indica en el GUI que desea dar de baja un dispositivo seleccionando

del listado el que desea eliminar. El dispositivo se elimina de la base

de datos.

Extensiones (o Flujos Alternativos): Si el dispositivo no existe en

la base de datos, se terminará el proceso de eliminación de

dispositivo.

Figura 42 muestra el diagrama de bloques para el caso de uso de Baja de un

dispositivo

Figura 41. Baja de un dispositivo

Modificación de dispositivo Este caso de uso analiza la modificación de un

dispositivo.


Ref: PT-2007-023-12IEME 136



Precondiciones: el dispositivo debe estar almacenado en base de

datos.

Postcondiciones: Se almacenan en la base de datos las

modificaciones introducidas por el usuario.


indica en el GUI que desea modificar un dispositivo seleccionando

del listado. Las modificaciones se almacenan en la base de datos.

Extensiones (o Flujos Alternativos): Si el dispositivo no existe en

la base de datos, se terminará el proceso de modificación de

dispositivo.

Figura 43 muestra el diagrama de bloques para el caso de uso de Modificación de un

dispositivo


Ref: PT-2007-023-12IEME 137

Figura 42. Modificación de un dispositivo

2.2.3.3 Servicio de Control de Tráfico de Buques

Esta sección enuncia los casos de uso genéricos para el Servicio de Control de Tráfico

de Buques.

Servicio visualización GIS (Figura 44).


Ref: PT-2007-023-12IEME 138

Visualizar en el puerto.

Mostrar información Atraque.

Visualizar por temático.

Hacer Zoom sobre la imagen.

Visualizar en Puerto

Mostrar Información del Atraque

Visualizar por Temático

Usuario

Hacer Zoom sobre la imagen

Figura 43: Casos de uso del servicio de visualización GIS

El módulo de tráfico de buques permite la monitorización por parte de los operadores

del centro de control del los buques atracados dentro del área del puerto. El tipo de

información que se extraerá de los DUE (Documento Único de Escala) que son

enviados por el Agente Consignatario del buque a la Ventanilla Única Española, antes

de la entrada del buque en aguas del puerto.

Visualización en Puerto: Este caso de uso analiza la operación de

visualización del puerto en el sistema GIS.


Ref: PT-2007-023-12IEME 139

Actor principal: Usuario. Con la palabra “usuario” nos referimos

tanto a los Operadores del Centro de Control como a los

Administradores de la aplicación. Ambos tendrán permisos

suficientes para realizar operaciones de visualización como las que

se describen a continuación.

Precondiciones: Se asume que el usuario está dado de alta en el

sistema y se ha logado correctamente en la aplicación.

Postcondiciones: Al terminar la ejecución de este caso de uso, el

estado del sistema permanecerá invariable, puesto que las acciones

referenciadas aquí no suponen modificaciones en las bases de

datos, pero se habrá mostrado por pantalla al usuario una imagen

del puerto con la representación de los buques sobre el plano, en la

posición real en la que están atracados.


comienza cuando el usuario selecciona la funcionalidad de

Visualización en Puerto. En ese momento se recopilan los datos

relativos a los buques atracados en el área del puerto y se pide al

usuario que seleccione el tipo de fondo en el que mostrar los barcos.

Las opciones serán una imagen real del puerto o un plano

esquemático que se corresponde con el contorno del puerto. Al

seleccionar el usuario una de estas opciones, se muestra sobre el

plano o la imagen del puerto un icono por cada buque atracado en el

mismo.

Extensiones (o Flujos Alternativos): No hay


Ref: PT-2007-023-12IEME 140

Figura 44: Caso de uso de la operación de visualización en puerto

Mostrar Información del Atraque: Este caso de uso analiza la operación de

visualización de una operación de atraque en el sistema GIS.

Actor principal: Usuario.


sistema y se ha logado correctamente en la aplicación. Además es

imprescindible que el usuario se encuentre en una pantalla de

“Visualización en Puerto” o “Visualización por Temático”.

Postcondiciones: A la finalización de este caso de uso, se habrán

mostrado por pantalla los datos de atraque de un buque que haya

seleccionado el usuario.

Escenario Principal de Éxito (o Flujo Básico): Una vez el usuario

se encuentre en una de las pantallas de Visualización, tendrá la

posibilidad de pinchar sobre uno de los buques representados y se

mostrará en una tabla los datos de atraque del buque. Algunos de

los datos que se podrán visualizar son los referentes a la

información del buque, las horas de entrada y salida del puerto

estimadas y reales, información sobre la mercancía que transporta,

datos de la tripulación y el pasaje, etc.


Ref: PT-2007-023-12IEME 141


Figura 45: Caso de uso de visualización de una operación de atraque

Visualización por Temático: Este caso de uso permite visualizar el puerto

clasificado por temáticas, permitiendo presentar únicamente los buques que

cumplan las características especificadas.



sistema y se ha logado correctamente en la aplicación.

Postcondiciones: Al terminar la ejecución de este caso de uso, el

estado del sistema permanecerá invariable, puesto que las acciones

referenciadas aquí no suponen modificaciones en las bases de

datos, pero se habrá mostrado por pantalla al usuario una imagen

del puerto con la representación de los buques que han superado el

filtro seleccionado por el usuario sobre el plano, en la posición real

en la que están atracados.


comienza cuando el usuario selecciona la funcionalidad de

Visualización por Temático. El usuario debe seleccionar un tipo de


Ref: PT-2007-023-12IEME 142

buque y con él se realizará una búsqueda dentro de los datos

relativos a los buques atracados en el área del puerto que sean del

tipo seleccionado por el usuario. Posteriormente se muestra sobre el

plano del puerto un icono por cada buque del tipo seleccionado.


Figura 46: Caso de uso de la operación de visualización por temático

Hacer zoom sobre la imagen: Este caso de uso analiza la operación de

realizar zoom sobre la imagen.



sistema y se ha logado correctamente en la aplicación. Además es

imprescindible que el usuario se encuentre en una pantalla de

“Visualización en Puerto” o “Visualización por Temático” y esté

visualizando una imagen del puerto.

Postcondiciones: Al término de este caso de uso, el sistema

permanecerá inalterado, pero se habrá mostrado por pantalla al

usuario una ampliación de una parte de la imagen anterior o una

vista más alejada del puerto.


Ref: PT-2007-023-12IEME 143

Escenario Principal de Éxito (o Flujo Básico): Una vez el usuario

se encuentre en una de las pantallas de Visualización, y esté

visualizando una imagen, tendrá la posibilidad hacer zoom. El zoom

puede ser para ampliar la imagen de una zona específica del puerto

o para ver la imagen ampliada del puerto.


Figura 47: Caso de uso de la operación de hacer zoom sobre la imagen

2.2.3.4 Servicio de Explotación

Esta sección enuncia los casos de uso genéricos para el Servicio de Explotación.

Servicio de gestión de atraques (Figura 49).

Lanzamiento de la aplicación GISPORT-ATRAQUES.

Configuración de GISPORT-ATRAQUES.

Actualización de GISPORT-ATRAQUES.

Servicio de gestión de concesiones (Figura 50).


Ref: PT-2007-023-12IEME 144

Lanzamiento de la aplicación GISPORT-CONCESIONES.

Configuración de GISPORT-CONCESIONES.

Actualización de GISPORT-CONCESIONES.

Figura 48: Casos de uso del servicio de gestión de atraques

La aplicación integrada en el sistema gestiona las operaciones de atraque y escala

dentro del área portuaria. A través de esta herramienta el operario es capaz de

consultar las de solicitudes de atraque y estado de estas solicitudes. Permite la

consulta gráfica de buques en puerto, de estado previo y situaciones. Es posible la

generación de informes temáticos, por tipo de buque línea regular. Hace posible la

generación de informes y herramienta de filtrado.


Ref: PT-2007-023-12IEME 145

Figura 49: Casos de uso del servicio de gestión de las concesiones

La aplicación integrada en el sistema gestiona las consultas de bienes públicos,

Expedientes y Contadores, la consulta de facturación periódica, las consultas de fichas

de inmovilizado, la asignación de bienes público a expedientes, el registro y la consulta

de datos de contadores, la generación de mapas telemáticos de bienes públicos y

expedientes, la consulta y generación de zonas de valoración, la asignación y consulta

de fotografías de los bienes públicos y la generación de informes gráficos y

alfanuméricos con datos de bienes públicos, expediente, contadores y facturación.

Lanzamiento de la aplicación GISPORT-ATRAQUES: Este caso de uso

analiza el proceso de lanzamiento de la aplicación GISPORT-ATRAQUES.

Actor principal: Operador

Precondiciones: El operario, en su perfil de usuario, tiene permitido

el uso de la aplicación GISPORT-ATRAQUES.

Postcondiciones: El operario tendrá acceso limitado también pos

sus permisos a la aplicación GISPORT-ATRAQUES. El sistema

estará pendiente de la finalización de la aplicación para cerrar la

instancia.

Escenario Principal de Éxito (o Flujo Básico): El operario pulsará

en el botón correspondiente al lanzamiento de la aplicación de

GISPORT-ATRAQUES. La aplicación procederá a la llamada de la

aplicación e iniciará un proceso de vigilancia para el tratamiento de


Ref: PT-2007-023-12IEME 146

los errores que pueda lanzar el inicio de dicha aplicación. Una vez

comprobado el correcto inicio de la aplicación se incluye en una

pestaña de proceso activo dentro del ámbito del sistema.

Escenario Principal de Éxito (o Flujo Básico): Una vez

comprobado que el lanzamiento de la aplicación ha arrojado un

mensaje de error el proceso de inicio comprobará este error y lo

tratará de forma que si es un error del que conozca la solución se

vuelva a intentar con las modificaciones necesarias. En caso de que

no se conozca la solución del error lanzado se presentará este error

por pantalla y se abortará el inicio de la aplicación.


Ref: PT-2007-023-12IEME 147

Figura 50: Caso de uso lanzamiento de la aplicación GISPORT-ATRAQUES

Configuración de la aplicación GISPORT-ATRAQUES: Este caso de uso

analiza la configuración de la aplicación GISPORT-ATRAQUES.



Ref: PT-2007-023-12IEME 148

Precondiciones: El administrador, en su perfil de usuario, tiene

permitida la configuración de la aplicación GISPORT-ATRAQUES.

Postcondiciones: El administrador tendrá acceso limitado también

por sus permisos a la configuración de GISPORT-ATRAQUES. El

sistema estará pendiente de la finalización de la configuración para

cerrar la instancia de configuración


pulsará en el botón correspondiente al lanzamiento de la

configuración de GISPORT-ATRAQUES. La aplicación procederá a

la llamada de la aplicación de configuración e iniciará un proceso de

vigilancia para el tratamiento de los errores que pueda lanzar el

inicio de dicha aplicación. Una vez comprobado el correcto inicio de

la aplicación se incluye en una pestaña de proceso activo dentro del

ámbito del sistema.



mensaje de error este error lanzado se presentará por pantalla y se

abortará el inicio de la aplicación.


Ref: PT-2007-023-12IEME 149

Figura 51: Caso de uso de la configuración de la aplicación GISPORT-ATRAQUES

Actualización de la aplicación GISPORT-ATRAQUES: Este caso de uso

analiza la actualización de la aplicación GISPORT-ATRAQUES.



Ref: PT-2007-023-12IEME 150


permitida la actualización de la aplicación GISPORT-ATRAQUES.


pulsará en el botón correspondiente al lanzamiento de la

actualización de GISPORT-ATRAQUES. La aplicación procederá a

la llamada de la aplicación de actualización e iniciará un proceso de

vigilancia para el tratamiento de los errores. El procedimiento pedirá

un fichero para realizar dicha actualización y una vez realizado el

proceso de actualización se mostrará el correspondiente mensaje de

éxito detallando los pormenores de la actualización



mensaje de error este error lanzado se presentará por pantalla y se

abortará el inicio de la aplicación.


Ref: PT-2007-023-12IEME 151

Figura 52: Caso de uso actualización de la aplicación GISPORT

Lanzamiento de la aplicación GISPORT-CONCESIONES: Este caso de uso

analiza el proceso de lanzamiento de la aplicación GISPORT-CONCESIONES.

Actor principal: Operador

Precondiciones: El operario, en su perfil de usuario, tiene permitido

el uso de la aplicación GISPORT-CONCESIONES.

Postcondiciones: El operario tendrá acceso limitado también pos

sus permisos a la aplicación GISPORT-CONCESIONES. El sistema

estará pendiente de la finalización de la aplicación para cerrar la

instancia.


Ref: PT-2007-023-12IEME 152

Escenario principal: El operario pulsará en el botón

correspondiente al lanzamiento de la aplicación de GISPORT-

CONCESIONES. La aplicación procederá a la llamada de la

aplicación e iniciará un proceso de vigilancia para el tratamiento de

los errores que pueda lanzar el inicio de dicha aplicación. Una vez

comprobado el correcto inicio de la aplicación se incluye en una

pestaña de proceso activo dentro del ámbito del sistema.

Exensiones: Una vez comprobado que el lanzamiento de la

aplicación ha arrojado un mensaje de error el proceso de inicio

comprobará este error y lo tratará de forma que si es un error del

que conozca la solución se vuelva a intentar con las modificaciones

necesarias. En caso de que no se conozca la solución del error

lanzado se presentará este error por pantalla y se abortará el inicio

de la aplicación.

¡Error! No se pueden crear objetos modificando códigos de campo.

Figura 53: Caso de uso lanzamiento de la aplicación GISPORT-Concesiones

Configuración de la aplicación GISPORT-CONCESIONES: Este caso de uso

analiza el proceso de configuración de la aplicación GISPORT-

CONCESIONES.



permitida la configuración de la aplicación GISPORT-

CONCESIONES.

Postcondiciones: El administrador tendrá acceso limitado también

por sus permisos a la configuración de GISPORT-CONCESIONES.

El sistema estará pendiente de la finalización de la configuración

para cerrar la instancia de configuración

Escenario principal: El administrador pulsará en el botón

correspondiente al lanzamiento de la configuración de GISPORT-



Ref: PT-2007-023-12IEME 153

aplicación de configuración e iniciará un proceso de vigilancia para

el tratamiento de los errores que pueda lanzar el inicio de dicha

aplicación. Una vez comprobado el correcto inicio de la aplicación se

incluye en una pestaña de proceso activo dentro del ámbito del

sistema.


aplicación ha arrojado un mensaje de error este error lanzado se

presentará por pantalla y se abortará el inicio de la aplicación.


Figura 54: Caso de uso de configuración de la aplicación GISPORT-Concesiones

Actualización de la aplicación GISPORT-CONCESIONES: Este caso de uso

analiza el proceso de actualización de la aplicación GISPORT-

CONCESIONES.



permitida la actualización de la aplicación GISPORT-

CONCESIONES.

Escenario principal: El administrador pulsará en el botón

correspondiente al lanzamiento de la actualización de GISPORT-


aplicación de actualización e iniciará un proceso de vigilancia para el

tratamiento de los errores. El procedimiento pedirá un fichero para

realizar dicha actualización y una vez realizado el proceso de

actualización se mostrará el correspondiente mensaje de éxito

detallando los pormenores de la actualización


aplicación ha arrojado un mensaje de error este error lanzado se

presentará por pantalla y se abortará el inicio de la aplicación.


Figura 55: Caso de uso actualización de la aplicación GISPORT-Concesiones


Ref: PT-2007-023-12IEME 154

2.2.3.5 LISTA DE SERVICIOS Y SUS WRAPPERS

A continuación se ofrece una lista de los servicios que se van a utilizar en la aplicación

y los wrappers que se crearán para encapsular dichos servicios. Normalmente esos

servicios se implementarán en PHP o ASP y la comunicación se realizará mediante

mensajes codificados en XML o JSON. Posteriormente y una vez fijados los servicios

se completarán los wrappers con un proxy SOAP que permitirá que el servicio sea

utilizado como un servicio web estándar. Por el momento se tienen identificados

algunos de los servicios más importantes que se listan a continuación y que se irán

definiendo más adelante durante el desarrollo de la aplicación.

Los servicios serán los siguientes:

Servicio acceso a BBDD que recibirá y devolverá el contenido en formato

JSON, almacenándolo en BBDD.

Servicio Buques y devuelve un listado en XML con la información de los

buques (aquí se accederá a la información de DUEWEB y del AIS).

Servicio de video que recibirá el identificador de la cámara a visualizar, el sello

de tiempo desde el que se quiere visualizar y la longitud en minutos a visualizar

y devolverá en JSON la url de la secuencia de vídeo generada.

Servicio control de acceso (se compone de diversos servicios, aún está por

definir el formato de entrada y salida de datos).

Servicio control barreras, recibe el identificador de barrera y la operación a

realizar en formato JSON.

Servicio de Eventos, utiliza el servicio de base de datos y la comunicación será

en formato JSON.


Ref: PT-2007-023-12IEME 155

2.3 Tarea 3 – Modelo de Sistema

En este punto del documento se muestra una introducción al modelo de sistema y el

proceso seguido durante la elaboración del mismo (tarea 3 del plan de trabajo). Se

mostrarán algunos de los diseños en papel utilizados para el diseño y sus

correspondientes pantallas en el formato de la herramienta.

2.3.1 Introducción

El modelo de sistema o prototipo de papel, como también se conoce, es un método

ampliamente utilizado para el diseño, testeo y redefinición de interfaces de usuario. A

principios de los años 90 era una técnica incipiente utilizada por pocos pioneros de la

usabilidad pero desconocida para la mayoría de equipos de desarrollo de productos. A

mediados de los 90 su uso comenzó a extenderse. Los equipos de desarrollo de

software de empresas bien conocidas (IBM, Microsoft y Honeywell, por citar algunos

ejemplos) experimentaron con esta técnica, encontrándola muy útil, y comenzaron a

utilizarla como parte integral de su proceso de desarrollo de productos.

¿En qué consiste el modelo de sistema o prototipo de papel? En su sentido amplio, el

modelo de sistema puede ser considerado como un método de lluvia de ideas, diseño,

creación, prueba y comunicación de interfaces de usuario. El método consiste en

desarrollar un modelo o prototipo de la interfaz que se va a utilizar con un coste de

creación bajo y que sea fácilmente desechable. Para ello pueden utilizarse

herramientas de prototipado gráfico (como Visio, PowerPoint o herramientas de

programación gráfica) o incluso papel.

El flujo de trabajo es el siguiente: Se selecciona al tipo de usuario más representativo

de la audiencia a la que va dirigida la interfaz. Se determinan algunas tareas típicas

que se puede esperar que un usuario lleve a cabo. Después se generan algunas

capturas de pantalla o dibujos hechos a mano de todas las ventanas, menús, cajas de

dialogo, y demás que sean necesarios para llevar a cabo dichas tareas. No es

necesario tener una versión funcional de la interfaz. Incluso se puede realizar en

papel.


Ref: PT-2007-023-12IEME 156

Una vez creado el prototipo, se lleva a cabo un test de usabilidad. Se escoge a una

persona representativa del público al que va dirigida la interfaz y a los miembros

necesarios del equipo de desarrollo. Se le propone a dicho usuario que “interactúe”

directamente con el prototipo y a ejecutar una tarea sin explicarle cómo funciona el

sistema. Uno o dos miembros del equipo de desarrollo hacen el papel de

“computadora”, manipulando piezas de papel o cambiando las pantallas que se

muestran al usuario.

Rápidamente se descubren que partes de la interfaz funcionan debidamente y cuales

serán fuente de problemas. Al ser un prototipo realizado en “papel” se puede modificar

fácilmente (incluso durante la sesión de prueba) o desechar completamente. Así pues

el modelo de sistema permite iterar y mejorar el diseño rápidamente basándose en los

test de usabilidad.

2.3.2 Elaboración del modelo de sistema

Para la elaboración del modelo de sistema se reunió al equipo de trabajo de forma que

se pudiera hacer un brainstorming o tormenta de ideas para realizar los diseños

iniciales de las pantallas en papel. Una vez estuvieron terminados se presentaron a un

compañero ajeno al proyecto para poder validar la usabilidad de los diseños. Para ello

se le pidió que describiese la funcionalidad que creía podrían tener los botones que

aparecían y que realizase unas operaciones básicas de consulta de información y

creación de una emergencia. Fue así como se descubrieron varios problemas que se

solventaron en el momento, rehaciendo el diseño en papel y añadiendo los botones

que faltaban. Además se descubrió que la representación en el mapa de diferentes

tipos de dispositivos a la vez podrían despistar sobre la utilidad de cada uno y se

decidió mostrar la información de dispositivos en capas diferenciadas, de modo que el

usuario seleccionase la capa a mostrar en un menú en la parte superior.

Tras varios bocetos de la pantalla principal, se llegó al que se muestra a continuación.

En él se puede ver la apariencia que tendrá la pantalla principal de la aplicación.


Ref: PT-2007-023-12IEME 157

Figura 56: Diseño de la apariencia de la pantalla principal de la herramienta

Para determinar la usabilidad de la pantalla principal primero se hizo un boceto a mano

alzada de cual iba a ser la distribución de la pantalla. Como se puede apreciar, se ha

optado por dividir el área de la pantalla en tres partes, una primera parte situada a la

izquierda que muestra el GIS con el plano del puerto y todos los elementos a

representar, separados por capas. Una segunda parte en la que se muestra

información detallada del elemento que se haya seleccionado en el GIS en un

momento dado y una tercera parte, situada debajo de las dos anteriores, que muestra

una lista de los eventos pendientes de atender por parte del operador.

Después de su primera validación se implementó en un prototipo del sistema para su

validación final. A continuación se puede observar una captura de pantalla de la

pantalla principal del prototipo.


Ref: PT-2007-023-12IEME 158


Ref: PT-2007-023-12IEME 159

Figura 57: Captura de la pantalla principal de la herramienta

El resto de pantallas del sistema siguieron un ciclo de vida similar para su diseño y

validación. Como ejemplo se muestra también el diseño de la interfaz del gestor de

eventos.

En el sistema MOSCA cada evento tiene un código de identificación, que asigna

automáticamente el sistema cuando se produce el evento, un tipo de evento, una zona

asignada, una descripción del lugar en el que ha ocurrido el evento, una fecha de

inicio, una fecha de fin, un código de fase, un nivel de prioridad y unas acciones a

llevar a cabo asociadas.

Desde la pantalla principal se visualiza una lista los eventos pendientes, al hacer clic

sobre un evento se debe abrir una ventana para la edición de los datos del evento. En

esta ventana se debe poder modificar cualquier dato, desde el tipo de evento a las

acciones asociadas. Así mismo en esta ventana de edición se debe mostrar una lista

de acciones a llevar a cabo, esta lista también se debe poder modificar, por lo que al

hacer clic en uno de los elementos de la lista de acciones se debe abrir otra ventana

en la que poder modificar los detalles de la acción. A continuación se muestra el

primer boceto de la interfaz.


Ref: PT-2007-023-12IEME 160

Figura 58: Diseño de la aplicación de gestión de eventos


Ref: PT-2007-023-12IEME 161

A partir de este primer boceto se refinó la interfaz para la edición de un evento, a

continuación se muestra su boceto.

Figura 59: Diseño de la pantalla de creación de nuevo evento

Una vez definidos y refinados los bocetos se procede a su implementación en el

prototipo. A continuación se muestran las capturas de pantalla de la implementación

de los bocetos.


Ref: PT-2007-023-12IEME 162

Figura 60: Captura de pantalla del listado de eventos

La captura de pantalla anterior muestra la lista de eventos pendientes de atender por

parte del operador. Cuando el operador hace clic sobre alguno de los eventos debe

aparecer una pantalla como la siguiente para poder introducir los datos necesarios.


Ref: PT-2007-023-12IEME 163

Figura 61: Captura de pantalla de formulario para un nuevo evento

El apartado “Acciones” de la pantalla anterior mostrará una lista con las acciones

asociadas para el evento en cuestión. Al hacer clic sobre alguna de las acciones de

dicha lista se debe abrir una pantalla como la siguiente en la que se permite editar la

descripción de la acción seleccionada.


Ref: PT-2007-023-12IEME 164

Figura 62: Captura de pantalla de creación de acción

Otro ejemplo se puede observar en la definición de la interfaz de conexión con el

módulo de control de accesos, que se muestra a continuación.


Ref: PT-2007-023-12IEME 165

Figura 63: Diseño de pantalla del control de accesos

Desde esta pantalla se debe poder consultar la actividad (entradas y salidas de las

diferentes zonas controladas) de los usuarios. Se debe poder especificar una fecha

para la búsqueda y opcionalmente un nombre de usuario para refinar la consulta. Una

vez se hace clic sobre el botón “Buscar” el sistema debe consultar todos los registros

de actividad del sistema de control de accesos y mostrar una lista con todos ellos. Al

hacer clic sobre un elemento de la lista de actividad se debe mostrar los detalles del

acceso (Fotografía, ficha del usuario, datos sobre el acceso, etc)


Ref: PT-2007-023-12IEME 166

Figura 64: Captura de pantalla del control de accesos

2.4 Tareas 4 y 5 - Desarrollo SW e Integración de sistemas

Una vez estuvieron claros los objetivos que se querían conseguir con la aplicación se

comenzó con la preparación del equipo de trabajo y el entorno de desarrollo en el que

se iba a trabajar. Para ello era necesario hacer las instalaciones pertinentes en el

servidor y en los equipos de trabajo de cada uno de los miembros que iban a trabajar

en el desarrollo para crear un espacio común de trabajo. El primer módulo con el que

se empezó a trabajar fue el de visualización de buques y zonas en un mapa del puerto

con tecnología GIS. El siguiente conjunto de funcionalidades con las que continuó el

desarrollo fue el módulo de control de accesos para vehículos y la integración con la

lectura de matrículas además de comenzar con el sistema de control remoto de la

cámara Domo. Poco a poco se fueron añadiendo nuevas capas a la representación


Ref: PT-2007-023-12IEME 167

GIS y se crearon las capas de las redes de hidrantes distribuidas por el recinto

portuario y la representación de las válvulas que controlarían el flujo de las

canalizaciones de agua o combustible. El siguiente paso fue comenzar con el sistema

de almacenamiento de imágenes grabadas con la cámara ip en un servidor, para

poder ser visualizadas bajo demanda a posteriori en una representación en forma de

grid o rejilla de imágenes. El siguiente módulo funcional que se comenzó a desarrollar

fue el de gestión de eventos que permite listar las alarmas que se introducen al

sistema mediante la creación de nuevos eventos, y la modificación a lo largo del

tiempo de las acciones y características de la alarma o evento hasta que este se da

por finalizado.

El siguiente paso fue el comienzo de la tarea 5 de Integración de Sistemas, puesto que

uno de los principales objetivos era conseguir la integración de diferentes sistemas en

una sola herramienta que permitiese la gestión de muchas funcionalidades desde la

misma aplicación. En paralelo a estas tareas, continuaba el proceso de depuración de

todas las funcionalidades que estaban en desarrollo para conseguir un resultado

óptimo.

Por último se comenzó con el desarrollo de la funcionalidad encargada de recibir los

datos AIS. Para ello se adquirió un receptor AIS que se instaló en una localización en

Valencia. Los datos AIS que se recibían eran enviados a un sistema gestionado por

una comunidad de usuarios llamada AISHub de forma que se compartían con el resto

de usuarios de esta comunidad a cambio de recibir los datos del resto de receptores

conectados a la red. Además, los datos AIS que se recibían de AISHub eran

decodificados para poder mostrar la información de forma legible dentro de la

aplicación y para representar los buques en tiempo real dentro del mapa GIS de la

herramienta.

El inicio del desarrollo de la aplicación, se vio retrasado debido a la acumulación de

demoras ocurridas en las tareas anteriores. Además durante la tarea fueron

apareciendo dificultades en algunas funcionalidades que hicieron que el fin de la

misma tuviera lugar en septiembre, y no en julio como se hubiera estimado debido al

retraso inicial. No obstante se podría considerar un avance haber comenzado con la

tarea 5 de integración de sistemas durante la etapa de desarrollo, de forma que se


Ref: PT-2007-023-12IEME 168

iban solventando dificultades que hubieran aparecido más tarde, y que tal vez

hubieran aumentado la demora acumulada.

En este documento se han incluido los pasos referentes a la integración. Durante la

implementación del diseño de la herramienta ha surgido la necesidad de tener un

sistema sobre el que probar la aplicación que se iba generando. Por esto, a pesar de

que la integración de sistemas era un punto del desarrollo que se haría una vez

implementada la herramienta (finalizado el desarrollo Software), se ha ido

desarrollando paralelamente durante el desarrollo software. De otra manera no habría

sido posible comprobar el correcto avance en esta implementación.

Estas tareas de integración de sistemas se han realizado sobre un conjunto de

elementos hardware y software que se han implementado o adaptado con el propósito

de servir como campo de pruebas. Dentro de este conjunto de elementos hardware y

software nos encontramos tanto con los gadgets desarrollados dentro del proyecto

como otros gadgets de terceros utilizados e integrados en la herramienta. A pesar de

existir aplicaciones y dispositivos comerciales de estos componentes, como pueden

ser los controles de acceso y captadores de datos AIS, se ha decidido integrar la

herramienta sobre unos sistemas de muestra desarrollados para la ocasión para no

atar la aplicación a ninguna tecnología comercial.

Dado que la pretensión de Portel es poner esta herramienta en el mercado, se ha

decidido utilizar el nombre MOSCA para referirnos a la aplicación.

2.4.1 Objetivos a cumplir

La tarea que se presenta en este documento es la que encontramos en el Plan de

Trabajo como Tarea 4: Desarrollo UML. Esta tarea es una de las más importantes del

proyecto junto con la Tarea 2 en la que se analizaban los requisitos y se definía la

arquitectura del sistema y las funcionalidades a desarrollar. En la tarea 4 se realiza el

desarrollo de todas las funcionalidades detectadas a lo largo de todo el proyecto.

También se comenzó a desarrollar también la tarea 5: Integración de Sistemas con el

fin de ir integrando las funcionalidades dentro del mismo entorno y para poder incluir a

medida que se creaba el software las diferentes características del análisis de riesgos.

Como se había definido, había 4 agrupaciones fundamentales de funcionalidades que

eran Tráfico de Buques, Seguridad, Conservación y Operaciones.


Ref: PT-2007-023-12IEME 169

Estos 4 módulos contenían diferentes funcionalidades las cuales interactúan para

formar la herramienta de seguridad para el análisis del riesgo en instalaciones

portuarias. Los módulos tienen una concepción lógica, no obstante el conjunto de

funcionalidades que conforman el sistema no están individualizadas por módulo ya

que en la mayoría de los casos se trata de funcionalidades transversales. Por ello se

considera más relevante la descripción detallada de cada una de las funcionalidades

con el objeto de entender cada uno de los módulos.

Las funcionalidades que se querían construir eran las siguientes:

Representación de un mapa GIS con los dispositivos localizados en el mismo.

Uno de los principales objetivos de la herramienta era construir un sistema que

facilitase la rápida toma de decisiones a los usuarios, de forma que se

acelerase el proceso de gestión de incidencias, minimizando al máximo los

tiempos de acción. Para ello llegamos a la conclusión de que una de las

funcionalidades fundamentales que debía ofrecer la herramienta era la de

mostrar gráficamente el mapa del recinto portuario a controlar, con los

diferentes dispositivos ubicados en el mismo en su posición geográfica real. Así

el responsable de seguridad podrá visualizar la posición del evento, así como

las zonas colindantes que pudieran verse afectadas y tomar las medidas

pertinentes para mantener la seguridad dentro del recinto. Para ello era

necesario utilizar una representación GIS que permitiese mostrar diferentes

capas en las cuales se ubicasen los dispositivos que pueden ser gestionados

desde el centro de control de una Autoridad Portuaria y añadir la distribución de

las zonas diferenciadas del puerto en las cuales se localizan dichos

dispositivos.

Gestor de eventos. Una de las funciones más importantes de los responsables

de seguridad es controlar y gestionar los eventos o alarmas que puedan tener

lugar en el recinto portuario. Cada vez que un evento se produce en cualquier

punto de las instalaciones se da aviso a los responsables de seguridad para

que se puedan adoptar las medidas oportunas y así no poner en riesgo los

recursos humanos o materiales que se encuentran dentro del puerto. Dado que

pueden registrarse nuevos eventos antes de que se hayan cerrado los

anteriores, es necesario ofrecer una funcionalidad que permita almacenar los


Ref: PT-2007-023-12IEME 170

eventos recibidos y asociarle las tareas o acciones que deben realizarse para

dar por terminados dichos eventos. Además algunos eventos o alarmas serán

más prioritarios que otros y se clasificarán por su nivel de importancia. El

personal de seguridad que trabaje con la aplicación se encargará de

suministrar la información necesaria al gestor de eventos y de ir resolviendo y

finalizando los eventos que se introduzcan en el sistema. Una vez que los

eventos se den por finalizados pasarían a una lista en la que quedaría reflejado

temporalmente cada suceso y las acciones que se llevaron a cabo. Otra

funcionalidad deseada dentro del gestor de eventos es poder introducir avisos

para eventos futuros como por ejemplo revisiones de mantenimiento de las

instalaciones o llegadas a puerto de mercancías peligrosas previstas con

antelación.

Control de cámaras. Para poder gestionar la seguridad en grandes áreas como

las que componen un recinto portuario, es imprescindible hacer un control

mediante video vigilancia que garantice la seguridad de los bienes y las

personas que se encuentran en el lugar. Para ello se debe controlar de forma

remota las funciones de las cámaras instaladas a lo largo de las instalaciones,

de forma que los operarios de seguridad desde el centro de control tengan la

capacidad de mover los objetivos o hacer zoom desde su puesto sin tener que

desplazarse hasta el lugar que quieren visualizar o controlar en determinado

momento. Además puede servirles de ayuda para observar comportamientos

sospechosos y enviar al lugar exacto en el que se puede estar cometiendo un

delito, al personal necesario para atajarlo.

Visualización de grabaciones de seguridad y almacenamiento en un servidor

del histórico de grabaciones. Además de visualizar en tiempo real las imágenes

del puerto, es importante almacenarlas para su posterior visualización bajo

demanda. En caso de que ocurra alguna emergencia o accidente, y que sea

necesario ver lo que ocurrió en un periodo de tiempo determinado, deben

poder mostrar las imágenes de hasta un mes de antigüedad, por lo que

deberán ser almacenadas en un servidor con capacidad para dicho volumen de

grabaciones.


Ref: PT-2007-023-12IEME 171

Control de accesos de personas: Dado que los puertos son lugares de paso

masivo de población, y debido a que en los últimos años han aumentado los

atentados terroristas en estos espacios, es necesario hacer un control riguroso

de las personas que entran y salen del recinto portuario, lo que además

representa una obligatoriedad como consecuencia de un marco legal vigente.

Por ello, un objetivo fundamental es controlar las entradas y salidas que se

producen en cada acceso. Además es importante poder asignar a las personas

las áreas o recintos a los que tiene acceso y poder establecer los horarios en

los que la persona tendrá el acceso habilitado. Para evitar suplantaciones de

personalidad, es una buena idea incluir tecnologías biométricas que aseguren

que los accesos los hace la persona que está almacenada en el sistema, y de

este modo evitamos accesos indebidos de personal fuera del control de los

responsables de seguridad.

Reconocimiento de Matrículas para el control de acceso de vehículos. El

reconocimiento automático de matrículas (Automatic Number Plate

Recognition) es una tecnología utilizada para el control de acceso de vehículos.

Esta tecnología utiliza el reconocimiento de caracteres mediante fotografía o

video de las matrículas de los coches que pasan a lo largo de un vial a una

velocidad de hasta 160 km/h (dependiendo del sistema utilizado) o cuando el

vehículo se detiene por medios mecánicos como una barrera o por indicación

de un agente de seguridad o una señal luminosa. Al tomarse las fotografía de

la matrícula, el sistema la lee y almacena la fotografía asociada al momento

exacto en el que se produce el acceso y dependiendo del sistema puede

almacenar otra información como fotografía del conductor, resultado del

acceso, etc. Todos los recintos portuarios están dotados de estos mecanismos

de seguridad, puesto que se recoge en el Código ISPS - International Ship and

Port Facility Security, por lo tanto un objetivo de este desarrollo es integrar un

sistema de control de accesos que facilite al usuario de la aplicación la

supervisión del control de accesos de vehículos al puerto, pudiendo

gestionarse el control de accesos desde el mismo centro de control.

Monitorización de estados y conservación: para garantizar el correcto

funcionamiento de todos los dispositivos instalados en el recinto portuario juega

un papel muy importante la correcta conservación de los mismos y el control en


Ref: PT-2007-023-12IEME 172

tiempo real de su estado. Así se pueden prevenir accidentes y mejorar la

protección contra actos ilícitos dentro de las instalaciones del puerto por un

mantenimiento incorrecto de las mismas. Para ello la herramienta que se

presenta en este documento tiene como objetivo ofrecer la posibilidad de

manejar y comprobar el estado de los dispositivos que puedan ser

monitorizados mediante una aplicación informática, como por ejemplo la

apertura de puertas o barreras, el control de las válvulas de las canalizaciones

de agua o combustible, el control de la red de hidrantes para la extinción de

incendios.

Monitorización del tráfico de buques: La funcionalidad de monitorización del

tráfico de buques es una de las partes más importantes de la herramienta ya

que ayudaría al responsable de seguridad a tener una visión global de la

situación de los buques atracados en el puerto de modo que pueda llevar a

cabo las medidas necesarias para acotar al máximo los riesgos que puedan

producirse durante cualquier maniobra de un buque entrando a puerto. Para la

representación de los buques se usa la información del sistema AIS que llevan

instalado, de forma que se pueden representar todos los buques que se

encuentren en las proximidades del puerto a estudio y que tengan su sistema

AIS activo. Puede ocurrir que cuando el buque esté parado (atracado o

fondeado), el sistema AIS esté desconectado o que la velocidad sea muy baja

y en ese caso el buque se mostrará como atracado si está junto a un muelle o

como fondeado si está en la bahía.

Otro objetivo a conseguir es el del análisis de riesgos. El objetivo fundamental

de la herramienta es proporcionar una ayuda para los responsables de

seguridad de los puertos para el análisis de riesgos y la toma de decisiones en

caso de situaciones de peligro o riesgo tanto para los bienes materiales como

para las personas que se encuentran en el recinto portuario. Para poder llegar

a hacer un buen análisis de riesgos es importante manejar el máximo de

información posible referente a todos los aspectos que puedan afectar a la

seguridad del puerto. El objetivo en esta aplicación es permitir que toda la

información que se maneja de los distintos sistemas pueda interactuar, de

forma que se ofrezca al usuario una visión rápida, ágil y en tiempo real de los

posibles riesgos que pueden tener lugar en el ámbito del puerto.


Ref: PT-2007-023-12IEME 173

2.4.2 Grado de desarrollo

En este punto del documento se describe el grado de cumplimiento de los objetivos

esperados para la tarea de Fin del desarrollo UML. Para poder examinar el alcance del

desarrollo iremos punto por punto sobre las funcionalidades detalladas en el apartado

anterior.

Representación GIS: Se ha desarrollado un área dentro de la aplicación en el que se

muestra el mapa del puerto a estudio. Ese mapa puede mostrarse sobre la cartografía

real del puerto que incluye la carta náutica del entorno marino del puerto, sobre la

representación que ofrece Google Maps –Streets y sobre la representación de Google

Maps –Satellite. Estas tres representaciones del fondo del mapa ofrecen una calidad

muy alta con la única diferencia de que la primera de ellas se reduce a los límites

geográficos del mapa en formato pdf con el que se trabaja.

Sobre cualquiera de estas representaciones encontramos el resto de capas que

contienen los diferentes dispositivos, sistemas y zonas que podemos encontrar en un

puerto. La primera capa es en la que se representan las diferentes zonas de un puerto.

Estas se representan como áreas en color azul, y si se hace clic sobre alguna de ellas,

se mostrará el nombre de la zona y una descripción de la misma. Queda pendiente de

ser desarrollada la visualización de la información relativa al número de personas que

se encuentran en cada zona. Se estudia hacer este desarrollo para una futura fase de

ampliación y mejora del proyecto.

La siguiente capa representada en el mapa GIS es la del Campo de regatas. Se

representa como un área cerrada en el mar (donde podría haber una zona de regatas)

y al hacer clic sobre ella se mostrará en un globo de información una descripción de la

misma. Cuando un buque entre en este campo de regatas se generará una alarma en

el gestor de eventos.

Otra capa representada es la de la red de hidrantes. Esta capa está formada por las

líneas de distribución de agua y los hidrantes para la extinción de incendios. Del

mismo modo que en las capas anteriores, al hacer clic sobre los hidrantes aparece el

nombre del hidrante y una descripción del mismo.


Ref: PT-2007-023-12IEME 174

También se representan las válvulas que se podrían encontrar en el recinto portuario y

además de mostrar una descripción de la válvula, se muestra el estado en el que se

encuentra (abierta o cerrada) y se ofrece la posibilidad de cambiar ese estado.

La siguiente capa es la de Cámaras, en la cual se representan todas las cámaras del

sistema de videovigilancia que existen en el recinto portuario. Al hacer clic sobre una

de las cámaras, se muestra un globo de información con la descripción general de la

cámara y en el área central de la página aparece el stream de video en tiempo real

que está grabando dicha cámara, con los botones de zoom y posición para poder

controlar la cámara.

Otra capa representada en el mapa GIS es la de los accesos de vehículos. En esta

capa se visualizan los accesos para vehículos que se encuentran en las entradas o

salidas del recinto portuario, y al clicar sobre alguno de esos accesos se muestra en el

área de información la posibilidad de accionar las barreras de dicho acceso y si hay

una cámara de videovigilancia asociada a dicho acceso, la ventana de visualización de

las imágenes que están grabándose en ese momento, para que el usuario de la

aplicación pueda dar paso de forma manual a un vehículo, desde el centro de control.

La siguiente funcionalidad implementada en la representación GIS es la visualización

de los buques en las aguas del puerto. Para esta representación se ha utilizado

información procedente de 3 fuentes distintas, de la aplicación DUE, del sistema AIS y

la aplicación SIGMA. La posición geográfica se obtiene del sistema AIS, que se va

actualizando en tiempo real, y nos ofrece algunos otros datos como el nombre el

buque, el origen, el destino y el tiempo estimado de llegada a su destino. Además

ofrece los datos de manga y eslora que se utilizan para representar el buque a escala.

En caso de que los datos recibidos por el AIS no contengan información sobre manga

y eslora, se hará una representación genérica del buque. La información del DUE

mostrará los datos del Documento Único de Escala y la información de SIGMA, la

información relativa a los atraques que se han producido en el puerto. Además los

buques se representan de diferentes colores dependiendo del tipo de atraque o de si

lleva mercancías peligrosas, ayudando así al usuario de la aplicación a detectar

posibles riesgos como los buques que contienen mercancías peligrosas.


Ref: PT-2007-023-12IEME 175

La última funcionalidad representada en el mapa GIS es la de Alertas, y con esta

funcionalidad se muestra un icono especial cuando un buque perteneciente a la lista

negra.

El gestor de eventos era otro de los objetivos a desarrollar en esta aplicación. Dicho

módulo aparece representado en el área derecha de la pantalla y cumple con todas las

expectativas planteadas en el diseño. Muestra no solo los eventos en curso, sino

también los eventos futuros y los finalizados, de forma que se puede tener un control

histórico de las acciones llevadas a cabo por el personal de seguridad ante las

distintas emergencias aparecidas. Cada suceso anómalo ocurrido en las instalaciones

portuarias, producirá un evento automático que se verá reflejado en el listado de

eventos, de forma que el responsable de seguridad pueda asignar las acciones

necesarias para finalizar un evento, e ir modificando las fases y los niveles de prioridad

por los que va pasando dicho evento. Además dependiendo del nivel de riesgo que

suponga cada evento, se mostrará en diferente color (rojo, amarillo y verde). Se

permite la introducción manual de eventos ocurridos dentro del puerto, que se

mostrarán dentro de la misma área de eventos. La lista de eventos mostrará un

resumen que contendrá la información sobre el tipo de evento, el lugar en el que se

está produciendo, la fecha y hora de inicio y la de fin que contendrá el valor 0 hasta

que se finalice dicho evento.

La aplicación tiene un módulo que controla las cámaras de videovigilancia de forma

remota, ofreciendo al usuario la posibilidad de manejar la posición a la que enfoca la

cámara en cuestión, controlar el zoom de la cámara y establecer algunas posiciones

predeterminadas que faciliten el retorno de la cámara a una posición inicial. Además

es posible modificar la calidad del video grabado aumentando o disminuyendo la

cantidad de frames por segundo que almacena la cámara y modifica el tamaño de la

ventana en la que se muestra la imagen.

Estos videos son almacenados en un servidor de forma que se permite la reproducción

de las imágenes de forma posterior y bajo demanda. Se puede seleccionar el formato

de cuadrícula en la que se quiere mostrar las imágenes (1, 2x2, 3x3, 4x4) y la fecha y

hora exacta a partir de la cual se quiere mostrar la secuencia de video, y el intervalo

de cada video en minutos.


Ref: PT-2007-023-12IEME 176

La gestión de accesos de personas se puede llevar a cabo desde la misma aplicación,

dando de alta o baja distintos perfiles y almacenando de cada persona información

relativa a sus datos personales, a las características del acceso que se le concede a

las diferentes zonas, datos de contacto y datos de la empresa. Además se le puede

asignar al usuario un una imagen facial de modo que el portero biométrico evalúe si el

acceso está siendo un acceso indebido o no.

Del mismo modo se gestiona el alta y baja de vehículos autorizados, almacenando

información sobre el vehículo, sobre el tipo de control de accesos y sobre el

responsable del vehículo, que debe estar identificado en la aplicación para que se le

pueda vincular con una matrícula.

Para el acceso automático de vehículos se ha configurado una cámara (que captura

imágenes al detectar movimiento) y el software correspondiente al reconocimiento de

matrículas de forma que de permita el acceso de forma automática cuando el coche

llega a la barrera y si la matrícula ha sido dada de alta en el sistema. También se

puede activar manualmente las barreras de entrada y de salida para dar paso a un

vehículo.

La monitorización de estados y conservación se ha desarrollado mostrando el estado

de los controles de acceso, de las válvulas de las canalizaciones de agua, de los

hidrantes etc y mediante la visualización de las cámaras de videovigilancia. En el caso

de las válvulas se simula su apertura o cierre y su control de estado y en el caso de los

controles de acceso se controla el manejo de las barreras del scalextric.

La monitorización del tráfico de buques se hará mediante el mapa GIS, detallado

anteriormente y la información asociada de las aplicaciones DUE y SIGMA y con los

datos AIS. Los buques se representan a escala en función de la manga y la eslora y

de un color determinado dependiendo del tipo de atraque que tenga el buque:

Autorizado (verde), Solicitado (amarillo), No Solicitado (marrón), Denegado (rojo),

Buque en zona restringida (negro con el borde en rojo), Buque en la lista negra (una

banderita negra), Buque sin movimiento (un círculo rojo con una cruz blanca).

El objetivo de facilitar el análisis de riesgos se consigue a través de la integración total

en una misma herramienta de casi todas las aplicaciones que se pueden localizan en

un recinto portuario, como los controles de acceso, los gestores de eventos, los


Ref: PT-2007-023-12IEME 177

sistemas de videovigilancia y control de otros dispositivos distribuidos en el puerto.

Esto junto a la monitorización de buques en tiempo real y la clasificación de los

eventos por su peligrosidad, hacen que el usuario de la aplicación sea capaz de tratar

las situaciones de peligro con mayor garantía de controlar la seguridad de las

personas y los bienes materiales que se encuentran en el puerto y de prevenir daños

mayores. Así se ha conseguido crear un sistema que facilita al responsable de

seguridad el control del riesgo y la toma de decisiones para garantizar la seguridad y

prevenir accidentes o actos ilícitos dentro del recinto portuario. El beneficio de haber

incluido de este modo el análisis del riesgo es que el usuario no tiene que solicitar

explícitamente (por ejemplo pulsando en un botón o accediendo a un módulo

específico de análisis de riesgo) que comience el control del riesgos, sino que es un

proceso activo durante las 24 horas del día y no solo cuando el responsable de

seguridad “tenga tiempo” de gestionar el riesgo entre el resto de funciones que tiene

asignadas.

Por lo tanto entendemos como un gran avance este tipo de integración para el análisis

de riesgos.

Como se puede observar al iniciar la aplicación el interfaz gráfico, o escritorio, de la

herramienta no separa los cuatro módulos sobre los que se levanta el sistema:

mantenimiento, seguridad, tráfico de buques.

Dada la naturaleza integradora de la herramienta, y siguiendo el objetivo de facilitar el

manejo a los usuarios potenciales, se ha diseñado un despliegue visual en el que se

acceda a las operaciones más comunes de manera sencilla. Por ello se ha dividido la

pantalla en áreas que permiten obtener en un solo vistazo la situación del puerto en

cuanto a las operaciones integradas.

Estas áreas se han elegido teniendo en cuenta la importancia y la velocidad con la

que se van a refrescar los datos que se muestran en ella. Por ejemplo la muestra de

los datos GIS tendrá un área en este escritorio ya que, aparte de aportar información

visual del estado del puerto en un momento dado se actualiza con los datos del

movimiento de los buques sobre los cuales el operador podrá identificar movimientos

sospechosos o dar prioridad a eventos por la cercanía de determinados buques. Otra

información que deberá estar siempre visible en pantalla será la de los eventos, ya que


Ref: PT-2007-023-12IEME 178

por su importancia y la urgencia que pueden tener determinados eventos hace que el

operador tenga que ver estos datos en cuanto se generen.

Figura 65: Áreas de la pantalla de la aplicación

La pantalla se encuentra dividida en 4 bloques:

Área 1 (Visualización GIS): En la que se muestra la información gráfica que maneja la

herramienta.

Área 2 (Área de información): Esta área actuará como área multifuncional. Mostrará

información de las distintas selecciones que realicemos en las áreas. Empezará por

defecto el control de las cámaras y de los accesos. En esta área aparecerán las

informaciones de los buques, de los elementos de control como son las válvulas y los

hidrantes.

Área 3 (Gestión de eventos): En el que se listan los mensajes que el sistema va

generando a partir de los eventos que van ocurriendo.

Área 4 (Localización de dispositivos): Esta sección sirve como apoyo del GIS y permite

localizar y seleccionar elementos que el sistema controla, como son la red de


Ref: PT-2007-023-12IEME 179

Hidrantes, las válvulas, las cámaras, etc. y presentar su localización dentro del plano

del puerto.

De la misma manera que los procesos internos de la herramienta interrelacionan los

diferentes módulos, en el escritorio de la herramienta las acciones que se lleven a

cabo en cada una de las áreas tendrán reflejo en las áreas relacionadas. Por ejemplo,

al seleccionar un evento de un buque en las áreas del GIS aparecerá el buque en

cuestión seleccionado, y en el área de información aparecerán los datos del buque.

Figura 66: Evento de un buque

En otro ejemplo se puede observar como seleccionando un evento de control de

accesos, nos aparecerá en el área de información la cámara del control de accesos y

en el área del GIS señalado el elemento que ha generado el evento.


Ref: PT-2007-023-12IEME 180

Figura 67: Evento de control de accesos

La creación y manejo de eventos se realizará en pantallas que aparecerán sobre el

área de eventos. Esta edición y visualización de eventos se podrá realizar sin tener

que perder de vista la situación; los eventos seguirán apareciendo y el GIS se seguirá

actualizando.

Los casos de funciones que se realizarán en otras pantallas son la visualización de

vídeos grabados por el sistema y la configuración del control de accesos. Pero dado

que estas funcionalidades no se utilizarán habitualmente, se concluye que el tiempo

que el operario podrá resolver situaciones sobre la misma pantalla será del 95%.

2.4.3 Descripción científico técnica del desarrollo

2.4.3.1 El Sistema MOSCA

La imagen Figura 68 muestra una captura de pantalla de la interfaz de usuario

principal del sistema MOSCA. Desde esta interfaz se puede acceder y controlar todas

las funcionalidades del sistema: monitorización y control de buques, monitorización y


Ref: PT-2007-023-12IEME 181

control de cámaras de seguridad, control de dispositivos, gestión del control de

accesos, gestión de eventos, etc...

Figura 68: GUI Principal

Como se puede observar, la pantalla está dividida en 4 zonas: GIS (PortMap),

Información (Info), Eventos (Gestión de eventos) y Buscador (Búsqueda de

dispositivos). Todas ellas están conectadas entre sí, de manera que las acciones

llevadas a cabo en una de las áreas provocan actualizaciones y cambios en las

demás.

El Buscador de dispositivos se puede utilizar para localizar rápidamente cualquier

dispositivo presente en el sistema. Solo hay que introducir su nombre o tipo en la

casilla de texto y pulsar el botón "Buscar dispositivos". Si se selecciona cualquiera de

los resultados proporcionados se resaltará su posición en el GIS y se cargará la

información correspondiente en la ventana de Información.


Ref: PT-2007-023-12IEME 182

De la misma manera, cualquier evento seleccionado en la ventana de "Gestión de

eventos" provocará que se resalte su dispositivo/buque asociado (si lo hay) en el GIS y

que la ventana de información muestre la información pertinente.

A continuación se describe con mayor detalle el uso y funcionalidades de cada una de

las partes del sistema MOSCA.

2.4.3.1.1 GIS (PortMap)

Este gadget muestra todos los dispositivos y buques, controlados por el sistema, sobre

un plano del puerto. Como imagen de fondo aparece por defecto la carta náutica de

las proximidades del puerto, aunque se puede seleccionar opcionalmente las

imágenes aéreas proporcionadas por Google Maps.

Figura 69: GIS (PortMap)

Ref: PT-2007-023-12IEME 183

Aparte de los buques que se encuentran dentro de la zona de acción del puerto, el GIS

muestra las siguientes capas de datos:

Zonas: Las diferentes zonas en las que se divide el puerto

Campo de Regatas: Un ejemplo de la definición de un área de regatas. Si algún

buque se adentra en ésta zona de acceso restringido, se generará un evento y

se resaltará con un color específico (actualmente rojo) el buque infractor.

Hidrantes: La distribución de la red de hidrantes del puerto

Válvulas: Las posiciones de las válvulas.

Cámaras: Las posiciones de las cámaras de vigilancia.

Acceso Vehículos: La posición de los controles de acceso.

Alertas: Esta es una capa especial de datos que se utiliza para imprimir iconos

específicos sobre los objetos del mapa. Por ejemplo se utiliza para dibujar el

icono de una bandera negra sobre un buque que aparece en la "Lista Negra".

Éste gadget se encuentra integrado dentro de la plataforma EzWeb con lo cual tiene

definidas varios puntos de entrada y salida de datos para comunicarse con otros

gadgets. La definición XML del servicio se puede encontrar en trunk/map-danes/map-

gadget.xml y se puede leer a continuación.

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Port Map 2.1</Name> <Version>2.1</Version> <Author>David Anes</Author> <Mail>[email protected]</Mail> <Description>Port Map</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI> <WikiURI>http://localhost</WikiURI> </Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>

Ref: PT-2007-023-12IEME 184

<Platform.StateProperties> </Platform.StateProperties>  <Platform.Wiring> <Event name="type" type="text" label="Type" friendcode="type"/> <Event name="identifier" type="text" label="Identifier" friendcode="identifier"/> <Slot name="typein" type="text" label="Type in" friendcode="type"/> <Slot name="identifierin" type="text" label="Identifier in" friendcode="identifier"/> </Platform.Wiring> <Platform.Link> <XHTML href="http://demo-mosca.portel.es/repository/map-danes/mosca.gadget.php"/> </Platform.Link> <Platform.Rendering width="11" height="40"/> </Template>

Tal y como se desprende del listado XML anterior, el gadget tiene dos puntos de

entrada de datos, uno para tipo de dispositivo y otro para identificador de dispositivo.

Cuando el gadget recibe datos a través de estos puntos de entrada, resalta en el mapa

el dispositivo con "type" e "identifier" correspondientes a los recibidos. Finalmente

envía a través de sus "slots" de salida el mismo tipo e identificador para que los

gadgets que estén conectados al puerto de salida del GIS se actualicen.

El gadget GIS también posee la capacidad de generar nuevos eventos, por ejemplo

detecta si un buque ha entrado en una zona no permitida o si hay un buque listado en

la "lista negra" que se encuentre cerca del puerto.

2.4.3.1.2 Buscador de dispositivos

En la parte inferior de la pantalla principal del sistema MOSCA se encuentra el

buscador de dispositivos. Si se introduce una cadena de búsqueda y se pulsa el botón

"Buscar dispositivos" se consulta la base de datos de dispositivos y se muestran los

resultados pertinentes.

Ref: PT-2007-023-12IEME 185

Figura 70: Buscador de dispositivos

La Figura 70 muestra un ejemplo de búsqueda estableciendo como cadena "válvulas".

Esta búsqueda devuelve todas las válvulas registradas en el sistema y si se escoge

alguna de la lista, ésta se resalta en el GIS y se actualiza el gadget de información.

Este gadget también está integrado en la plataforma EzWeb y gracias a esto se puede

alterar el contenido del GIS y del gadget de información al seleccionar alguno de los

resultados devueltos por la búsqueda. A continuación se muestra su definición en

XML.

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Busqueda de dispositivos</Name> <Version>1.0</Version> <Author>Martin Peris Martorell</Author> <Mail>[email protected]</Mail> <Description>Port Map</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI> <WikiURI>http://localhost</WikiURI> </Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>  <Platform.StateProperties> </Platform.StateProperties>  <Platform.Wiring> <Event name="type" type="text" label="Type" friendcode="type"/> <Event name="identifier" type="text" label="Identifier" friendcode="identifier"/>  </Platform.Wiring>


Ref: PT-2007-023-12IEME 186

<Platform.Link> <XHTML href="http://demo-mosca.portel.es/repository/gadgets/busqueda/BusquedaGadget.html"/> </Platform.Link> <Platform.Rendering width="40" height="10"/> </Template>

2.4.3.1.3 Gestor de eventos

En la parte derecha de la pantalla principal del sistema MOSCA se encuentra el gestor

de eventos. Este consiste en una lista de eventos resaltados en color dependiendo de

su prioridad (Color verde = prioridad baja, amarillo = prioridad media, rojo = prioridad

alta). Cada evento tiene una serie de datos asociados, como por ejemplo su código,

tipo, hora de inicio, hora de fin, etc... La tabla puede ser ordenada utilizando cualquiera

de estos datos como índice. Así los eventos se pueden organizar por prioridad o por

fecha de inicio por ejemplo.

La Figura 71 muestra el aspecto del gestor de eventos.


Ref: PT-2007-023-12IEME 187

Figura 71: Gestión de Eventos

Dado que algunos eventos pueden ser programados para que se lancen en una fecha

futura (por ejemplo los eventos de mantenimiento se pueden programar para, la

semana que viene, el mes que viene o cualquier otra fecha futura) y habrá gran

cantidad de eventos finalizados que ya no interese visualizar, por defecto el sistema no

muestra ni los eventos futuros, ni los eventos finalizados. Si se quiere añadir a la lista

de eventos actuales cualquiera de los dos tipos de eventos descritos anteriormente se

debe pulsar los botones Mostrar eventos futuros y Mostrar eventos finalizados.

Cuando se pulsa sobre el botón Nuevo Evento... o se pulsa sobre cualquier evento de

la lista se abre una ventana de edición en la que se pueden introducir las

características del evento. Tal y como se muestra en la Figura 72.


Ref: PT-2007-023-12IEME 188

Figura 72: Edición de Eventos

Así mismo, para cada evento se asocia una lista de acciones a tomar. Esta lista de

acciones ayudará a los responsables de toma de decisiones a poder seguir un

protocolo de actuación. Ningún evento debería finalizar sin que antes se hayan

realizado todas las acciones descritas en la lista de acciones asociada al evento. La

Figura 73 muestra el diálogo de creación de acciones.

Ref: PT-2007-023-12IEME 189

Figura 73: Creación de Eventos

Al igual que los gadgets del GIS y del Buscador de dispositivos, el gadget de gestión

de eventos también está integrado en la plataforma EzWeb de manera que al

seleccionar alguno de los eventos disponibles en la lista de eventos, los gadgets de

GIS e información se actualizarán mostrando la información relacionada con el

dispositivo o buque que haya generado el evento. A continuación se muestra su

definición XML.

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Gestion de eventos</Name> <Version>1.0</Version>

Ref: PT-2007-023-12IEME 190

<Author>Martin Peris Martorell</Author> <Mail>[email protected]</Mail> <Description>Gestion de eventos</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI> <WikiURI>http://localhost</WikiURI> </Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>  <Platform.StateProperties> </Platform.StateProperties>  <Platform.Wiring> <Event name="type" type="text" label="Type" friendcode="type"/> <Event name="identifier" type="text" label="Identifier" friendcode="identifier"/>  </Platform.Wiring> <Platform.Link> <XHTML href="http://demo-mosca.portel.es/repository/gadgets/eventos/EventosGadget.html"/> </Platform.Link> <Platform.Rendering width="10" height="10"/> </Template>

2.4.3.1.4 Información (Info)

Este gadget muestra la información relacionada con el dispositivo activo en el GIS (el

dispositivo que se ha seleccionado en el Mapa, o se ha pulsado mediante el buscador

de dispositivos, o está relacionado con el evento seleccionado en el gestor de

eventos).

Dependiendo del dispositivo activo, la información que muestra este gadget puede

pertenecer a:

Un buque. En este caso la información que se muestra es la procedente del

sistema AIS, el sistema DUE y el sistema SIGMA. Véase la Figura 74.

Válvulas. En el caso de que se haya seleccionado una válvula, el campo de

información mostrará el estado de la misma y las operaciones que se pueden

llevar a cabo sobre ella, típicamente: abrir y cerrar. Véase la Figura 75.


Ref: PT-2007-023-12IEME 191

Cámaras. En este caso se mostrará la imagen en directo de la cámara,

permitiendo controlar hacia dónde se enfoca en cada momento. Véase la

Figura 76.

Control de Acceso. Esta vista muestra la imagen en directo de la cámara de

seguridad más próxima al control de accesos y proporciona la opción de abrir o

cerrar la barrera en caso de que falle el sistema de control de accesos

automático. Véase la Figura 77.

Figura 74: Información de buque


Ref: PT-2007-023-12IEME 192

Figura 75: Información de válvula

Figura 76: Información de Cámara

Ref: PT-2007-023-12IEME 193

Figura 77: Información de Control de Acceso

Al igual que el resto de gadgets expuestos hasta el momento, éste gadget también

está integrado dentro de la plataforma EzWeb, de manera que los demás gadgets se

pueden comunicar con el gadget de información a través de los canales EzWeb. La

definición XML de este gadget se muestra a continuación.

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Info 0.41</Name> <Version>1.0</Version> <Author>alx</Author> <Mail>[email protected]</Mail> <Description>Port Map</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI>

Ref: PT-2007-023-12IEME 194

<WikiURI>http://localhost</WikiURI> </Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>  <Platform.StateProperties> </Platform.StateProperties>  <Platform.Wiring>  <Slot name="type" type="text" label="Type" friendcode="type"/> <Slot name="identifier" type="text" label="Identifier" friendcode="identifier"/> </Platform.Wiring> <Platform.Link> <XHTML href="http://demo-mosca.portel.es/repository/gadgets/prueba/InfoGadget.html"/> </Platform.Link> <Platform.Rendering width="8" height="18"/> </Template>

2.4.3.2 ControlCAM

ControlCAM es el sistema de registro y visualización de vídeos de seguridad. Se

puede acceder a él a través del botón "ControlCAM" que hay situado en la parte de

arriba del gadget de información. Éste botón abre una nueva ventana en la cual se

pueden seleccionar los parámetros de visualización de vídeo.


Ref: PT-2007-023-12IEME 195

Figura 78: Sistema ControlCAM

Ésta aplicación está pensada para poder visualizar varias grabaciones de seguridad al

mismo tiempo. Actualmente el sistema sólo dispone de una cámara de seguridad así

que la aplicación sirve para poder visualizar varias porciones de vídeo de la misma

cámara al mismo tiempo. De esta manera si, por ejemplo, se configura ControlCAM

para visualizar 4 ventanas de vídeo y un intervalo de 15 minutos de vídeo a partir de

una cierta fecha y hora, se puede visualizar 60 minutos de grabación de seguridad en

tan solo 15 minutos. Lo cual resulta ideal para localizar rápidamente algún suceso

relevante en la grabación de seguridad.

Los parámetros que se pueden ajustar en esta aplicación son los siguientes:


Ref: PT-2007-023-12IEME 196

Tamaño de cuadrícula: Permite seleccionar el tamaño de la cuadrícula en la

que dividir la pantalla para la visualización de vídeo. Los posibles valores son

1, 2x2, 3x3 y 4x4.

Fecha: La fecha en la que se registró la secuencia de vídeo. Se selecciona

mediante un calendario desplegable.

Hora Inicio: Hora a partir de la cual se desea empezar a ver el vídeo. Se debe

seleccionar hora, minuto y segundo.

Intervalo: Número de minutos de vídeo a visualizar en cada cuadrícula. Si por

ejemplo se selecciona un intervalo de 15 minutos y una tamaño de cuadricula

de 2x2 entonces se visualizará un total de 60 minutos de vídeo.

El reproductor de vídeo permite avanzar y retroceder la secuencia de vídeo a antojo

del operario. También permite la visualización de cualquier secuencia de vídeo a

pantalla completa. Así como situar las ventanas que contienen el vídeo en cualquier

orden en la cuadrícula.

2.4.3.3 CAB+

Esta sección describe el sistema de control de accesos. La Figura 79 muestra la

pantalla principal del sistema de gestión de los controles de acceso.


Ref: PT-2007-023-12IEME 197

Figura 79: Sistema CAB+

2.4.3.3.1 Personas y vehículos

El sistema debe ser capaz de manejar controles de acceso tanto para personas como

para vehículos. Para ello deberá registrar la actividad de entradas y salidas de

personas y vehículos a través de los diferentes puntos de control. La Figura 80 y

Figura 81 muestran los paneles de gestión de Personas y Vehículos. Para cada

persona se almacenan una serie de datos personales junto con datos relativos al

control de accesos, además de asociarle un perfil de usuario y una empresa (en caso

de que el usuario pertenezca a alguna empresa).

Mediante este formulario el superusuario podrá dar de alta/modificar/borrar la

información de una persona. De cada persona se debe almacenar información de

contacto. Se podrá asociar una empresa y/o un vehículo a una persona (éstos deberán

existir previamente en la base de datos o ser creados en ese instante).

También se podrá asociar un perfil de acceso a una persona.


Ref: PT-2007-023-12IEME 198

Si se trata de una visita se asociará una persona de contacto que esté dada de alta en

el sistema.

Figura 80: Gestión personas

Mediante este formulario el superusuario podrá dar de alta/modificar/borrar la

información de un vehículo. Un vehículo debe ser asociado a una persona que esté

dada de alta en el sistema y se le debe asignar un perfil de acceso.


Ref: PT-2007-023-12IEME 199

Figura 81: Gestión de Vehículos

2.4.3.3.2 Control de presencia básico

Con el fin de mejorar el análisis de riesgos y el control de planes de emergencia de las

entidades portuarias, el sistema de control de accesos debe permitir conocer en cada

momento cuantas personas hay en el interior de cada zona y de qué personas se

trata. Lo mismo para los vehículos. Para ello se requiere la implementación de un

servicio básico de control de presencia. (No en el sentido de controlar cuantas horas

trabaja dentro del puerto cada trabajador si no en el sentido de conocer cuantas

personas se encuentran en una zona).

2.4.3.3.3 Multi-dispositivo

El sistema de control de accesos debe soportar múltiples dispositivos, desde los que

generan un apunte en la tabla de actividad automáticamente hasta los que el apunte

de la actividad se realiza manualmente por un usuario acreditado (un empleado de

seguridad en una garita de control de acceso). La Figura 82 muestra el formulario que

se utiliza para gestionar los dispositivos.


Ref: PT-2007-023-12IEME 200

Figura 82: Gestión de dispositivos

2.4.3.3.4 Independencia del modo de identificación

Se debe proporcionar independencia de la característica que se utilice para identificar

a un individuo. Se debe poder utilizar cualquier tipo de método de identificación: huella,

cara, voz, tarjeta magnética, tarjeta rfid... Para el desarrollo que nos ocupa hemos

decidido que la forma más eficiente de identificación para un puerto es el

reconocimiento facial (o algún otro mecanismo biométrico) para poder evitar

suplantaciones de personalidad para conseguir acceder al recinto portuario.

2.4.3.3.5 Almacenamiento de prueba de acceso

Almacenar una prueba de acceso para cada individuo o vehículo que accede al puerto.

Por ejemplo, la fotografía tomada para identificación mediante biometría facial, la

fotografía de la huella en caso de biometría dactilar, etc...

Todas las grabaciones de seguridad de las cámaras conectadas al sistema MOSCA

son almacenadas, en este sentido, se debe poder asociar una (o varias) cámaras de


Ref: PT-2007-023-12IEME 201

seguridad a los puntos de control de acceso para poder ser utilizados como prueba

durante el "análisis forense" de algún evento.

2.4.3.3.6 Monitorización en tiempo real

Se debe poder monitorizar en tiempo real todos los eventos que generan cada uno de

los controles de acceso. Esto es, poder consultar todas las actividades de

entrada/salida de los dispositivos de control de acceso y que se actualice cuando un

nuevo acceso ocurra.

2.4.3.3.7 Generación de eventos

Capacidad para generar eventos que puedan ser capturados por una aplicación

externa cuando algún acceso falle. (Poder ver en el mapa del puerto de la aplicación

MOSCA un pop-up marcando algún evento ocurrido).

2.4.3.3.8 Restricciones de acceso

El sistema debe implementar ciertas restricciones de acceso tanto espaciales como

temporales. Éstas restricciones se detallan a continuación. Los permisos que cada

usuario tenga permitirá al sistema conocer qué tipo de restricciones y en qué mesura

tiene que aplicarlas. Para implementar esto se utilizarán perfiles de usuario en los que

se describirá que privilegios y restricciones tiene cada usuario en particular.

Zonas

El recinto portuario se dividirá en Zonas que corresponderán con zonas físicas del

puerto. Cada zona puede contener subzonas. Todas las zonas deben tener al menos

un dispositivo de control de entrada/salida asociado.


Ref: PT-2007-023-12IEME 202

Figura 83: Gestión de Zonas

Permisos de acceso

Se debe controlar los permisos que cada usuario (persona o vehículo) tiene para

acceder a las diferentes zonas. Un usuario no tiene por qué tener permiso para

acceder a todas las zonas del recinto portuario, e incluso puede que no tenga permiso

a utilizar todos los accesos de una misma zona.


Ref: PT-2007-023-12IEME 203

Figura 84: Gestión de Perfiles

Restricción de horarios

Como medida de seguridad en las instalaciones portuarias, se establecen restricciones

horarias a las personas autorizadas a acceder a las diferentes áreas del recinto. El

sistema debe proporcionar la funcionalidad de restringir el horario en el que un usuario

conocido puede acceder a las instalaciones portuarias.


Ref: PT-2007-023-12IEME 204

Figura 85: Gestión de Horarios

Anti-passback

Dado el nivel de seguridad de un puerto, el sistema debe poder detectar situaciones

en las que un usuario (persona o vehículo) intenta acceder a través de un control de

acceso y previamente no se ha registrado un acceso en sentido contrario. Es decir, un

usuario no puede "entrar" dos veces seguidas en un mismo recinto, para que un

usuario pueda entrar en una zona controlada, el último registro del sistema para ese

usuario debe ser una "salida" de esa zona. Esta funcionalidad se puede implementar

junto con la comprobación de los permisos de acceso a zonas y las restricciones de

horarios.

Visitas

Las personas que no están identificadas en la base de datos y necesiten acceder al

recinto portuario por alguna circunstancia (visita) deberán aportar sus datos a la

entrada de los controles de acceso para proceder a su "alta temporal" en el sistema.


Ref: PT-2007-023-12IEME 205

Así mismo, cualquier visitante deberá tener asociado una persona de contacto que sí

esté registrada en la base de datos para que se responsabilice de la visita.

Al mismo tiempo también se debe controlar el acceso de los visitantes a las

instalaciones controladas del puerto. Para ello se utiliza el panel de gestión de visitas

que se muestra en la Figura 86.

Figura 86: Gestión de Visitas

2.4.3.4 Componentes Software

Todo el software desarrollado para mosca se puede encontrar en el directorio trunk.

2.4.3.4.1 Servidor central

El servidor central es la pieza central de este rompecabezas, proporciona la

infraestructura necesaria para poder ejecutar el sistema.

LAMP + ezweb


Ref: PT-2007-023-12IEME 206

El servidor se basa en una tecnología conocida, desde los últimos años, como LAMP:

Linux Apache MySQL PHP.

En el servidor se ha instalado una distribución de Linux de 64 bits (Ubuntu 8.04) para

poder aprovechar al máximo su potencial. A continuación se muestran los detalles de

configuración.

Nombre de dominio: demo-mosca.portel.es

Usuario principal: mosca

Contraseña: mosca

URL: http://demo-mosca.portel.es

Usuario URL: mosca

Contraseña URL: mosca2portel

Directorio base: /home/mosca

También se ha instalado un servidor Apache para ofrecer la funcionalidad de servidor

Web. Se han instalado las extensiones de Apache para PHP de manera que se puede

utilizar este lenguaje para programar los servicios que web que se ofrecen.

Para almacenar los datos del sistema se ha instalado el motor de base de datos

MySQL. Para hace más sencilla la administración de la base de datos se ha instalado

el paquete phpMyAdmin que permite acceder a la base de datos a través de un

interfaz web. A continuación los detalles:

URL: http://demo-mosca.portel.es/phpmyadmin

Usuario principal: mosca

Contraseña: mosca

Como base del sistema se ha tomado la plataforma EzWeb. Esta plataforma permite el

desarrollo e integración rápida de diferentes servicios (Gadgets) y acceder a ellos

utilizando un navegador web. Básicamente cada "gadget" es una pieza de código

html+javascript. Los gadgets tienen una serie de variables de entrada y de salida, lo


Ref: PT-2007-023-12IEME 207

que permite interconectarlos entre ellos. Las entradas y salidas de cada gadget se

definen en un fichero XML y se manejan mediante JavaScript en el cuerpo HTML del

gadget. Para más información sobre esta plataforma visitar su web oficial:

http://ezweb.morfeo-project.org.

El esquema mostrado en la Figura 87 ilustra las conexiones entre los gadgets de

EzWeb desarrollados. Se puede encontrar la definición de estos gadgets en la primera

sección de este apartado.

Figura 87: Conexion de gadgets EzWeb

También se está utilizando OpenLayers (http://www.openlayers.org). Éste software

permite añadir con facilidad un mapa dinámico, e implementa una API JavaScript para

construir aplicaciones geográficas basadas en web. La API es similar a la de Google

Maps y MSN Virtual Earth, con la diferencia de que OpenLayers es Software Libre.

Además, implementa métodos estándar en la industria para el acceso a datos

geográficos, como Web Mapping Service (WMS) y Web Feature Service (WFS) del

OpenGIS Consortium.

Configuraciones especiales. A continuación se muestran los ficheros de

configuración necesarios para configurar correctamente el servidor apache:

NameVirtualHost * <VirtualHost *> ServerAdmin webmaster@localhost ServerName demo-mosca ServerAlias demo-mosca.portel.es DocumentRoot /var/www/ezweb-platform/ ErrorLog /var/log/apache2/ezweb-error.log LogLevel warn


Ref: PT-2007-023-12IEME 208

CustomLog /var/log/apache2/ezweb-access.log combined ServerSignature On <Location /> SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE settings PythonPath "['/usr/share/ezweb-platform'] + sys.path" </Location> Alias /media /usr/share/python-support/python-django/django/contrib/admin/media Alias /site-media /usr/share/ezweb-platform/media Alias /repository /home/mosca/mosca <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /camera/ http://cam-mosca.portel.es/ #ProxyPassReverse /camera/ http://cam-mosca.portel.es/ ProxyHTMLURLMap http://cam-mosca.portel.es /camera ProxyHTMLExtended On <Location /camera/> SetHandler None ProxyPassReverse / SetOutputFilter proxy-html ProxyHTMLURLMap / /camera/ ProxyHTMLURLMap /camera /camera RequestHeader unset Accept-Encoding </Location> <Location /media> SetHandler None </Location> <Location /site-media> SetHandler None </Location> <Location /repository> SetHandler None </Location> <Location /phpmyadmin> SetHandler None </Location> <Directory /var/www/gadgets> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory>


Ref: PT-2007-023-12IEME 209

# phpMyAdmin default Apache configuration Alias /phpmyadmin /usr/share/phpmyadmin <Directory /usr/share/phpmyadmin> Options Indexes FollowSymLinks DirectoryIndex index.php # Authorize for setup <Files setup.php> # For Apache 1.3 and 2.0 <IfModule mod_auth.c> AuthType Basic AuthName "phpMyAdmin Setup" AuthUserFile /etc/phpmyadmin/htpasswd.setup </IfModule> # For Apache 2.2 <IfModule mod_authn_file.c> AuthType Basic AuthName "phpMyAdmin Setup" AuthUserFile /etc/phpmyadmin/htpasswd.setup </IfModule> Require valid-user </Files> <IfModule mod_php4.c> AddType application/x-httpd-php .php php_flag magic_quotes_gpc Off php_flag track_vars On php_flag register_globals Off php_value include_path . </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php php_flag magic_quotes_gpc Off php_flag track_vars On php_flag register_globals Off php_value include_path . </IfModule> </Directory> </VirtualHost>

Cuando se accede a http://demo-mosca.portel.es se debe pasar 2 filtros de seguridad,

el primero es el establecido por apache, cuyo nombre de usuario ya se ha

proporcionado antes y el segundo es el que establece ezweb. Para poder acceder a la

aplicación MOSCA se debe proporcionar las siguientes credenciales:

Usuario: admin


Ref: PT-2007-023-12IEME 210

Contraseña: admin

Servidor FTP

Para almacenar las imágenes procedentes de la cámara IP se ha instalado un servidor

de FTP (proftpd), la configuración es estándar. Los detalles de acceso:

URL: ftp://demo-mosca.portel.es

Usuario: mosca

Contraseña: mosca

Sistema de archivos

Todos los archivos del sistema MOSCA tienen su raíz en el directorio /home/mosca. A

partir de ese directorio cuelgan otras dos carpetas:

ftp

mosca

La carpeta ftp contiene las imágenes transferidas desde la cámara IP. Hay una tarea

programada periódicamente que organiza las imágenes en carpetas correspondientes

a la fecha en la que se capturaron. De ésta carpeta se nutre después el servicio que

genera los vídeos de las cámaras de seguridad.

La carpeta mosca contiene a su vez otras carpetas:

crud

gadgets

services

La carpeta crud contiene los ficheros necesarios para administrar el sistema de control

de accesos a través de la web. La carpeta gadgets contiene la definición de los 3

gadgets básicos insertados en ezweb: MapGadget, InfoGadget y EventGadget. La


Ref: PT-2007-023-12IEME 211

carpeta services contiene la implementación de los diferentes servicios que ofrece la

plataforma : controlAccesos, controlCamara, controlHidrantes, controlValvulas,

controlZonas, controlBarreras, etc...

Cámara IP

La cámara IP puede ser accedida y configurada a través de un navegador web:

URL: http://cam-mosca.portel.es

Usuario: admin

Contraseña: admin

Configuraciones especiales Se ha configurado la cámara para que envíe, una vez

por segundo, las imágenes capturadas. En concreto el lugar en el que se almacenan

las imágenes es: ftp://mosca@mosca:demo-mosca.portel.es/ftp

Demostrador CAB+

Se suministra un demostrador del sistema CAB+ para la gestión del control de

accesos de usuarios. El demostrador, tal y como se explica en la sección de

Hardware, incorpora una pantalla táctil para las interacciones con el usuario. Cuando

se enciende este demostrador aparece una pantalla inicial que muestra un icono con

el logotipo del sistema CAB+, para lanzar el sistema basta con pulsar dos veces sobre

este icono.

Configuraciones especiales

El demostrador lleva en su interior un pequeño PC con Linux instalado. De ser

necesario acceder a funcionalidades avanzadas, de configuración o acceso remoto de

administración se deberá utilizar la siguiente configuración:


Ref: PT-2007-023-12IEME 212

SSH: portero-mosca.portel.es

Usuario: portero

Contraseña: m0sca (nótese el cero en lugar de -o- en la palabra mosca)

Base de datos

Se han creado 2 bases de datos diferentes, una para los datos generales de MOSCA

(mosca) y otra para los datos específicos del sistema de control de accesos

(mosca\_crud).

Configuraciones especiales Se puede encontrar una copia de seguridad de la base

de datos en /trunk/serversrc

2.4.3.4.2 Demonios

Hay algunas tareas que deben ser ejecutadas periódicamente, por ejemplo organizar

las imágenes de la carpeta /home/mosca/ftp u obtener la información AIS de los

buques.

Organización de imágenes

Se ha programado un shell script que organiza las imágenes de la carpeta

/home/mosca/ftp. El script se encuentra en trunk/backend/organiza-imagenes.sh

Este script se ha programado para su ejecución cada 10 minutos mediante el comando

crontab. El contenido del fichero de configuración del demonio cron es el siguiente:

# m h dom mon dow command # Lanzar cada 10 minutos el script que pone las imagenes de la camara de seguridad en su sitio */10 * * * * /home/mosca/ftp/organiza-imagenes.sh >> /dev/null

AIS

Los datos AIS (Automatic Identification System) provienen de un servicio externo

proporcionado por la red AISHub (http://www.aishub.net). Como condición para poder


Ref: PT-2007-023-12IEME 213

obtener datos AIS de esta red se debe proporcionar una fuente de AIS propia. Así

pues, se ha adquirido un receptor AIS que se encuentra en la sede del ITI en Valencia

y proporciona la fuente de datos recibida de los buques cercanos al puerto de

Valencia, a cambio se obtiene la fuente de datos AIS de los buques cercanos al puerto

de Málaga.

Existe un demonio que descarga los datos AIS regularmente del servicio

proporcionado por la red AIShub y los actualiza localmente. Se trata de un programa

que se ejecuta en segundo plano y transforma los datos recibidos a través del servicio

AISHub en una cadena XML adecuada para el gadget de visualización de mapas y

actualiza la base de datos local con las nuevas posiciones de los buques.

Una vez obtenidos los datos del AIS, se debe consultar el servicio DUEWEB:

URL: http://berman.portel.es/aplicaciones/due\_def/berthMosca.asp

Usuario: mosca

Contraseña: PorteL09

Ejemplo:

http://berman.portel.es/aplicaciones/due\_def/berthMosca.asp?user=mosca\&p

assword=PorteL09\&imoNumber=9387073\&portID=50

La consulta al servicio DUEWEB devuelve un fichero XML que debe ser procesado y

adjuntado a la información AIS

2.4.3.4.3 Servicios

La arquitectura final de los servicios se puede apreciar en la Figura 88.


Ref: PT-2007-023-12IEME 214

Figura 88: Arquitectura

Capa de abstracción de Acceso a Base de Datos

Los datos que se utilizan en el prototipo provienen o provendrán de fuentes de datos

dispersas, por ejemplo el servicio AIS, el servicio DUEWEB, las cámaras de vigilancia,

los puntos de acceso, etc.

Otros datos se aportarán en el momento de configurar el sistema en su puerto de

destino (Zonas, niveles de acceso, posiciones de cámaras, etc.), además los datos

que provengan de otras fuentes y que no cambien frecuentemente deben ser

guardados en una cache para no saturar la red de comunicaciones con peticiones de

datos que ya se han obtenido.

Pero para el sistema, todos los datos deben estar accesibles como si se tratara de una

sola base de datos. Por ello, se ha implementado una clase en PHP que engloba los

accesos a las bases de datos, de esta manera se introduce una capa que proporciona

independencia (u ocultación) de la base de datos real que se esté utilizando.


Ref: PT-2007-023-12IEME 215

La implementación de esta capa de ocultación de base de datos se puede encontrar

en /trunk/serversrc (ver fichero adjunto de código fuente). Este directorio contiene

varias subcarpetas:

classes: Implementación PHP de las clases correspondientes a cada entidad

del sistema (Barco, Cámara, Persona...)

dblayer: Es la capa que implementa el acceso a la base de datos real

(actualmente los datos se almacenan en un servidor MySQL)

dbscripts: Estos son los scripts SQL que se utilizan para crear la base de datos

gets: Definición de los métodos de consulta de los elementos de la base de

datos mediante peticiones HTTP GET

posts: Definición de los métodos de inserción de elementos en la base de datos

mediante peticiones HTTP POST

A continuación se muestran ejemplos de código fuente de cada una de las carpetas

anteriores. Para ilustrar lo comentado anteriormente se va a utilizar la entidad: Zona.

classes/Zona.class.php

<?php // File Zona.class.php class Zona { private $posicion; private $nombre; private $descripcion; private $riesgo; private $id; public function setPosicion ( $posicion ) { $this->posicion = $posicion; } public function getPosicion() {


Ref: PT-2007-023-12IEME 216

return $this->posicion; } public function setNombre ( $nombre ) { $this->nombre = $nombre; } public function getNombre() { return $this->nombre; } public function setDescripcion ( $descripcion ) { $this->descripcion = $descripcion; } public function getDescripcion() { return $this->descripcion; } public function setRiesgo ( $riesgo ) { $this->riesgo = $riesgo; } public function getRiesgo() { return $this->riesgo; } public function setId ( $id ) { $this->id = $id; } public function getId() { return $this->id; } } ?>

dblayer/ZonaDAO.php

<?php //File ZonaDAO.php require_once("../classes/Zona.class.php"); require_once("connect_db.php"); function DBInsertZona($conn, Zona $object) { $query = "INSERT INTO table_zona (posicion, nombre, descripcion, riesgo, id) VALUES ("; $posicion = $object->getPosicion(); $posicion = "'{$posicion}'"; $query .= $posicion.", ";


Ref: PT-2007-023-12IEME 217

$nombre = $object->getNombre(); $nombre = "'{$nombre}'"; $query .= $nombre.", "; $descripcion = $object->getDescripcion(); $descripcion = "'{$descripcion}'"; $query .= $descripcion.", "; $riesgo = $object->getRiesgo(); $query .= $riesgo.", "; $query .= "NULL) "; if(!mysql_query($query, $conn)) throw new Exception('Error connecting with Database'); else $object->setID(mysql_insert_id($conn)); } function DBUpdateZona($conn, Zona $object) { $query = "UPDATE table_zona SET "; $posicion = $object->getPosicion(); $posicion = "'{$posicion}'"; $query .= "posicion={$posicion}, "; $nombre = $object->getNombre(); $nombre = "'{$nombre}'"; $query .= "nombre={$nombre}, "; $descripcion = $object->getDescripcion(); $descripcion = "'{$descripcion}'"; $query .= "descripcion={$descripcion}, "; $riesgo = $object->getRiesgo(); $query .= "riesgo={$riesgo}, "; $query = substr($query, 0, strlen($query) - 2); $query .= " WHERE id={$object->getId()}"; if(!mysql_query($query, $conn)) throw new Exception('Error connecting with Database'); } function DBDeleteZona($conn, Zona $object) { $query = "DELETE FROM table_zona WHERE id = {$object->getId()}"; if(!mysql_query($query, $conn)) throw new Exception('Error connecting with Database'); }


Ref: PT-2007-023-12IEME 218

function DBGetZonaById($conn, $primaryKey) { $query = "SELECT * FROM table_zona WHERE id = {$primaryKey}"; $result = mysql_query($query, $conn); if(!$result) die('Invalid query: ' .mysql_error()); $info = mysql_fetch_assoc($result); $object = new Zona(); $object->setPosicion($info[posicion]); $object->setNombre($info[nombre]); $object->setDescripcion($info[descripcion]); $object->setRiesgo($info[riesgo]); $object->setId($info[id]); mysql_free_result($result); return $object; } function DBGetZonaSubList($conn, $first, $offset) { $query = "SELECT * FROM table_zona WHERE id >= {$first} LIMIT 0, {$offset}"; $result = mysql_query($query, $conn); if(!$result) die('Invalid query: ' .mysql_error()); $retArray = array(); while($info = mysql_fetch_assoc($result)){ $object = new Zona(); $object->setPosicion($info[posicion]); $object->setNombre($info[nombre]); $object->setDescripcion($info[descripcion]); $object->setRiesgo($info[riesgo]); $object->setId($info[id]); array_push($retArray, $object); } mysql_free_result($result); return $retArray; } function DBGetZonaByQuery($conn, $text) { $query = "SELECT * FROM table_zona WHERE nombre LIKE '%{$text}%' OR descripcion LIKE '%{$text}%'"; $result = mysql_query($query, $conn); if(!$result) die('Invalid query: ' .mysql_error()); $retArray = array();


Ref: PT-2007-023-12IEME 219

while($info = mysql_fetch_assoc($result)){ $object = new Zona(); $object->setPosicion($info[posicion]); $object->setNombre(str_replace("\"","",$info[nombre])); $object->setDescripcion(str_replace("\"","",$info[descripcion])); $object->setRiesgo($info[riesgo]); $object->setId($info[id]); array_push($retArray, $object); } mysql_free_result($result); return $retArray; } ?>

dbscripts/createTableZona.sql

DROP TABLE IF EXISTS `table_zona`; CREATE TABLE `table_zona` ( `id` int(11) NOT NULL auto_increment, `posicion` text NOT NULL, `nombre` text NOT NULL, `descripcion` text NOT NULL, `riesgo` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;

gets/ZonaGet.php

<?php // File ZonaGet.php require_once("../dblayer/ZonaDAO.php"); $first = 0; $offset = 15; if(isset($_GET[first])) $first = $_GET[first];


Ref: PT-2007-023-12IEME 220

if(isset($_GET[offset])) $offset = $_GET[offset]; $conn = DBConnect(); $ret = DBGetZonaSubList($conn, $first, $offset); DBClose($conn); for($it = 0; $it < count($ret); $it++){ $object = current($ret); $item[id] = $object->getId(); $item[id] = '"id": '.$item[id]; $item[posicion] = $object->getPosicion(); $item[posicion] = '"'.$item[posicion].'"'; $item[posicion] = '"posicion": '.$item[posicion]; $item[nombre] = $object->getNombre(); $item[nombre] = '"'.$item[nombre].'"'; $item[nombre] = '"nombre": '.$item[nombre]; $item[descripcion] = $object->getDescripcion(); $item[descripcion] = '"'.$item[descripcion].'"'; $item[descripcion] = '"descripcion": '.$item[descripcion]; $item[riesgo] = $object->getRiesgo(); $item[riesgo] = '"riesgo": '.$item[riesgo]; $implode_items = implode(",", $item); $json_item[$it] = "{{$implode_items}}"; next($ret); } $implode_json = "[".implode(",", $json_item)."]"; $json = '{"totalCount": '.count($ret).', "data": '.$implode_json.'}'; echo $json; ?>

posts/ZonaPost.php

<?php // File ZonaPost.php require_once("../dblayer/ZonaDAO.php"); $postVar = new Zona(); if(strlen($_POST[posicion]) > 0) $postVar->setPosicion($_POST[posicion]); else $postVar->setPosicion(null); if(strlen($_POST[nombre]) > 0) $postVar->setNombre($_POST[nombre]); else


Ref: PT-2007-023-12IEME 221

$postVar->setNombre(null); if(strlen($_POST[descripcion]) > 0) $postVar->setDescripcion($_POST[descripcion]); else $postVar->setDescripcion(null); if(strlen($_POST[riesgo]) > 0) $postVar->setRiesgo($_POST[riesgo]); else $postVar->setRiesgo(null); $conn = DBConnect(); DBInsertZona($conn, $postVar); DBClose($conn); echo '{"success":true}'; ?>

Fuentes de datos GeoRSS

Para poder representar datos en los gadgets de visualización (concretamente en

MapGadget) estos datos deben ser recopilados y representados en un formato

estándar. El formato que se ha elegido en este caso es GeoRSS, es un formato

basado en XML y muy similar al RSS (Really Simple Syndication) utilizado para

publicar contenidos que se actualizan frecuentemente en Internet. La característica

principal es que a cada item se le puede asociar una coordenada geográfica. A

continuación se muestra un ejemplo de éste formato:

<rss xmlns="http://backend.userland.com/rss2"> <item> <title>camara | 0 | Camara 0</title> <description>Camara de seguridad del parking</description> <georss:point xmlns:georss="http://www.georss.org/georss">36.706413 -4.424229 </georss:point> <link>http://demo-mosca.portel.es/repository/gadgets/images/Hardware-Webcam-48x48.png</link> </item> </rss>


Ref: PT-2007-023-12IEME 222

Zonas La definición del servicio que proporciona la fuente de datos GeoRSS para las

Zonas del puerto y se encuentran en:

SVN: /trunk/services/controlZonas/getZonasGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlZonas/getZonasGeoRSS.php

Hidrantes

La definición del servicio que proporciona la fuente de datos GeoRSS para los

Hidrantes del puerto y se encuentran en:

SVN: /trunk/services/controlHidrantes/getHidrantesGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlHidrantes/getHidrantesGeoRSS.php

Valvulas

La definición del servicio que proporciona la fuente de datos GeoRSS para las

Valvulas del puerto y su url son las siguientes:

SVN: /trunk/services/controlValvulas/getValvulasGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlValvulas/getValvulasGeoRSS.php

Camaras

La definición del servicio que proporciona la fuente de datos GeoRSS para las

Camaras del puerto y su url es la siguiente:

SVN: /trunk/services/controlCamaras/getCamarasGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlCamaras/getCamarasGeoRSS.php


Ref: PT-2007-023-12IEME 223

Acceso Vehículos y personas. La definición del servicio que proporciona la fuente de

datos GeoRSS para los controles de acceso de vehículos y personas del puerto y su

url es la siguiente:

SVN: /trunk/services/controlAccesos/getAccesosGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlAccesos/getAccesosGeoRSS.php

Motores

La definición del servicio que proporciona la fuente de datos GeoRSS para los Motores

del puerto y su url es la siguiente:

SVN: /trunk/services/controlMotores/getMotoresGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlMotores/getMotoresGeoRSS.php

Routers

La definición del servicio que proporciona la fuente de datos GeoRSS para los Routers

del puerto y su url es la siguiente:

SVN: /trunk/services/controlRouters/getRoutersGeoRSS.php

URL: http://demo-

mosca.portel.es/repository/services/controlRouters/getRoutersGeoRSS.php

Gadgets de Visualización

La pantalla principal de visualización del sistema MOSCA está dividida en 4 áreas o

gadgets diferentes. Toda la interacción entre el usuario y el sistema se realiza a través

de estos gadgets. Están interconectados entre ellos (ezweb), de manera que las

acciones realizadas en alguno de los gadgets tiene su repercusión en los demás.

Ref: PT-2007-023-12IEME 224

MapGadget. El mapa principal se encarga de mostrar todos los elementos del sistema

(zonas, barcos, tendidos, cámaras) y proporciona el interfaz principal de interactuación

con el sistema. El código fuente completo se puede encontrar en /trunk/map-

danes/mosca.gadget.php. En mosca.gadget.php se definen las entradas y salidas del

gadget así como las llamadas al servicio de gestión de eventos para atender a las

posibles situaciones que requieren atención por parte del operario (un buque entra en

una zona no permitida, se detecta un buque de la lista negra, etc...). En este caso el

gadget tiene 2 variables de salida type e id, estas 2 variables permiten hacer

reaccionar a los demás gadgets cuando un elemento del mapa se selecciona. El

código fuente que define estas variables es el siguiente:

// Variables de comunicacion entre gadgets var sendType = EzWebAPI.createRWGadgetVariable("type"); var sendId = EzWebAPI.createRWGadgetVariable("id"); function sendData(type, id){ sendType.set(type); sendType.set(id); }

Y su declaración en XML a continuación /trunk/gadgets/map-gadget.xml:

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Port Map 1.0.22</Name> <Version>1.0</Version> <Author>alx</Author> <Mail>[email protected]</Mail> <Description>Port Map</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI> <WikiURI>http://localhost</WikiURI> </Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>  <Platform.StateProperties> </Platform.StateProperties>

Ref: PT-2007-023-12IEME 225

<Platform.Wiring> <Event name="type" type="text" label="Type" friendcode="type"/> <Event name="identifier" type="text" label="Identifier" friendcode="identifier"/>  </Platform.Wiring> <Platform.Link> <XHTML href="http://demo-mosca.portel.es/repository/gadgets/map-gadget.php"/> </Platform.Link> <Platform.Rendering width="11" height="40"/> </Template>

La Figura 89 muestra el aspecto que tiene el gadget.

Ref: PT-2007-023-12IEME 226

Figura 89: MapGadget

Este gadget se nutre principalmente de las fuentes de datos GeoRSS y del servicio de

control de buques que se han comentado anteriormente. Cada fuente de datos

GeoRSS (Zonas, Hidrantes, Válvulas, Cámaras, Accesos, etc...) se dibuja sobre el

mapa en una capa independiente. Adicionalmente se dibuja otra capa con la

información asociada a los buques.

Cada vez que se hace click con el ratón sobre algún elemento del mapa se envía su

tipo e identificador al gadget de información, el cual lleva a cabo las operaciones

pertinentes.

Adicionalmente se ha definido un modo de edición que permite alterar la geometría de

cada una de las capas, excepto de la capa de buques.

A través de este gadget se accede también al servicio de visualización de cámaras de

seguridad.

InfoGadget. El gadget de información muestra información completa sobre el

elemento que se seleccione en el MapGadget. En caso de tratarse de un buque, el

InfoGadget mostrará la información obtenida a través del AIS y DUEWEB para el

búque correspondiente.

En caso de tratarse de cualquier otro elemento del sistema, se mostrará la información

pertinente y se podrán llevar a cabo las acciones permitidas para dicho elemento (abrir

válvulas, controlar la cámara IP, abrir y cerrar barreras del control de acceso, etc...)

Su declaración en XML se puede encontrar en /trunk/gadgets/info-gadget.xml.

<?xml version="1.0" encoding="UTF-8"?> <Template schemaLocation="http://morfeo-project.org/2007/Template">  <Catalog.ResourceDescription> <Vendor>PORTEL</Vendor> <Name>Info-Prev 0.21</Name> <Version>1.0</Version> <Author>alx</Author> <Mail>[email protected]</Mail> <Description>Port Map</Description> <ImageURI>http://localhost/imgs/map.jpg</ImageURI> <WikiURI>http://localhost</WikiURI>

Ref: PT-2007-023-12IEME 227

</Catalog.ResourceDescription>  <Platform.Preferences> </Platform.Preferences>  <Platform.StateProperties> </Platform.StateProperties>  <Platform.Wiring>  <Slot name="type" type="text" label="Type" friendcode="type"/> <Slot name="id" type="text" label="Identifier" friendcode="id"/> </Platform.Wiring> <Platform.Link> <XHTML href="http://demo-mosca/repository/gadgets/info-gadget.php"/> </Platform.Link> <Platform.Rendering width="8" height="18"/> </Template>


Ref: PT-2007-023-12IEME 228

Figura 90: InfoGadet

EventGadget El EventGadget es el encargado de consultar periodicamente el servicio

de base de datos en busca de nuevos eventos. Se nutre principalmente de


Ref: PT-2007-023-12IEME 229

http://demo-mosca.portel.es/repository/services/eventos/getNewEvents.php para

obtener una lista de eventos no atendidos y de http://demo-

mosca.portel.es/repository/services/eventos/getEventById.php para obtener los

detalles de un evento en concreto.

La declaración XML de EventGadget se puede encontrar en https://demo-

mosca.portel.es/repository/gadgets/eventos/EventosGadget.xml.

Figura 91: EventGadet

Los eventos están clasificados por prioridad, de manera que los eventos prioritarios

aparecen representados en la lista con un color llamativo. Al hacer click en un evento,

si éste lleva asociado algún dispositivo que esté representado en el mapa (por

ejemplo el control de accesos), éste se resaltará haciendo que MapGadget muestre el

pop-up correspondiente y InfoGadget muestre la información pertinente.


Ref: PT-2007-023-12IEME 230

Buscador de dispositivos. Este gadget permite buscar de manera rápida los

diferentes dispositivos conectados al sistema mediante su nombre o su tipo. De esta

manera no es necesario buscar manualmente un dispositivo en concreto en el

MapGadget ya que pude existir una gran cantidad de dispositivos disponibles.

Visualización de grabaciones de seguridad

Para la visualización de grabaciones de seguridad se ha desarrollado un servicio web

que genera los vídeos bajo demanda, a partir de las imágenes almacenadas en la

carpeta /home/mosca/ftp.

La definición del servicio se puede encontrar en la carpeta trunk/services/video. Los

ficheros más destacados de esa carpeta son:

getVideoInterval.php: implementa el servicio web al que se le pasa un

identificador de cámara, una fecha y hora inicial y el numero de segundos video

a generar a partir de esa fecha y hora inicial. El servicio devuelve una cadena

JSON que contiene la URL desde la que se puede descargar la secuencia de

vídeo en formato flv (flash video).

*.sh: Scripts auxiliares que organizan las imagenes y generan la secuencia de

video gracias al comando ffmpeg


Ref: PT-2007-023-12IEME 231

Figura 92: Grabaciones de seguridad

Para poder visualizar los videos en el navegador web se utiliza el visor flowplayer. Este

reproductor permite controlar la reproducción de los videos y visualizarlos a pantalla

completa.

2.4.3.4.4 VirtualBox

Dado que la aceptación de Linux en el entorno final al que va dirigida la aplicación no

es demasiado elevada, se ha optado por instalar un sistema Windows XP virtualizado

mediante VirtualBox en la maquina servidor, de manera que Linux y Windows se


Ref: PT-2007-023-12IEME 232

ejecuten concurrentemente. Linux juega el papel de servidor y Windows el de cliente

de visualización. Para una mejor visualización del sistema se recomienda utilizar el

navegador web Google Chrome.

El sistema windows no está protegido mediante ninguna contraseña ni posee una

configuración especial.

2.5 Tarea 6 – Despliegue del prototipo

2.5.1 Despliegue del prototipo

Para la realización de este proyecto es necesario integrar cierto hardware, que va

desde los sistemas de control de acceso hasta las válvulas que regulan ciertos

procesos, pasando por las cámaras de seguridad y otros sistemas. Evidentemente, no

se dispone de acceso a la totalidad del hardware que compone un puerto, así que el

hardware a integrar en este demostrador o prototipo se compondrá de un servidor

central, una cámara IP, simulación de un aparcamiento controlado por un sistema de

identificación de matriculas y una simulación de un punto de acceso controlado por un

sistema de identificación biométrica. Se ha seleccionado el reconocimiento facial para

la parte de identificación biométrica, puesto que impide la suplantación de

personalidad. El cualquier caso, el sistema en un futuro podrá integrar diferentes

sistemas aunque para este demostrador solo tengamos algunos ejemplos de lo que

podemos encontrar en un puerto.

Además de llevar a cabo la integración de cada uno de los componentes hardware, se

realizaron pruebas de integración del módulo software que se comunicaba con cada

elemento hardware con el fin de verificar la correcta comunicación entre ambos y

comprobar que el funcionamiento era el deseado.

2.5.1.1 Servidor central

Para llevar a cabo la demostración se ha adquirido un PC de sobremesa que hará las

veces de servidor central. Sobre este servidor se ejecutarán la mayor parte de tareas


Ref: PT-2007-023-12IEME 233

del sistema. Será el encargado de mantener la infraestructura sobre la que se está

desarrollando el prototipo (Servidor web, servidor de aplicaciones, etc...).

Figura 93: Servidor Central

Las características principales de este servidor son las siguientes:

Procesador: Intel Core 2 DUO E8400 3.0Ghz

Memoria RAM: 8 Gb (Esto fuerza a utilizar un S.O. de 64 bits, en nuestro caso

Ubuntu 8.10 64bits)

Disco duro: Seagate SATA2 500Gb

Monitor: Philips 240SW9FS 24"


Ref: PT-2007-023-12IEME 234

2.5.1.2 Camara IP

Se adquirió por parte de Portel una cámara IP Sony IPELA SNC-RZ25N. Dicha

cámara se utiliza para la simulación del control de cámaras de seguridad y la

grabación de vídeos de seguridad para su posterior reproducción.

Ésta cámara incorpora un entorno de desarrollo (SDK) bien definido que ha permitido

hacer la integración con el sistema de una manera mucho mas sencilla.

Figura 94: Cámara IP

2.5.1.3 Scalextric + cámara firewire

Se va a simular la integración con un sistema de control de acceso a un aparcamiento.

El control de acceso se lleva a cabo mediante identificación automática de matrículas.

Para la simulación se está construyendo una maqueta que muestre la funcionalidad

del sistema. Dicha maqueta se basa en un scalextric por el cual circula un coche con

matrículas intercambiables, también se dispone de una barrera de entrada y otra de

salida. De manera que cuando el coche se aproxima a la barrera, se detiene y la


Ref: PT-2007-023-12IEME 235

barrera se abre en caso de que el sistema de reconocimiento de matrículas identifique

positivamente la matrícula del vehículo. Una vez la barrera se ha abierto, el coche

continua la marcha. La Figura 95 muestra los detalles de la maqueta.

Figura 95: Maqueta aparcamiento

A continuación se muestran los detalles de cada uno de los componentes de la

maqueta.

1. Fuente de alimentación. Éste circuito se encarga de proporcionar la tensión

de alimentación a la pista, a los motores que mueven las barreras y al

circuito que controla los motores.

2. Mini SSC II. Éste circuito controla hasta 7 servos, en nuestro caso solo es

necesario controlar 2 servos (barrera de entrada y de salida).


Ref: PT-2007-023-12IEME 236

3. Conector RS232. Se utiliza para conectar el Mini SSC II al puerto serie del

servidor central. Ésto nos permite controlar el comportamiento de las

barreras desde el PC.

4. Cámara Firewire. Ésta cámara se conecta mediante puerto IEEE 1394 al

servidor central y se encarga de obtener las imágenes del coche para

localizar las matrículas.

5. (a y b). Los servos que mueven las barreras.

6. (a y b). Pulsadores de final de carrera para las barreras. Las porciones de

pista que están sombreadas en azul, en la Figura 95, no tienen

alimentación, estos pulsadores la activan.

El flujo de trabajo de la simulación es el siguiente:

El coche circula por la pista hasta que llega a una de las zonas sombreadas en

azul (Figura 95). Al no haber corriente eléctrica en esa porción de pista, el

coche para.

La cámara detecta la llegada del coche, lanza la captura de imagen y procesa

la matrícula.

Si la matrícula es correcta, el Servidor Central activa la barrera

correspondiente, esta se levanta. Cuando la barrera llega al final de carrera, el

pulsador (6a o 6b en la Figura 95) se activa dando corriente a la pista y

poniendo el coche en marcha.

Una vez el coche ha pasado, la barrera se cierra.

La apariencia final de la maqueta se puede apreciar en la siguiente figura (Figura 96).


Ref: PT-2007-023-12IEME 237

Figura 96: Scalextric

2.5.1.4 Demostrador CAB+

Para la simulación de control de acceso biométrico se ha adquirido un demostrador

con pantalla táctil. Ver Figura 97.

Éste demostrador incluye un pequeño PC encargado de ejecutar la parte cliente del

sistema de control de acceso biométrico.

Figura 97: Demostrador acceso biométrico

El demostrador simulará el control de acceso biométrico instalado en uno de los

accesos del puerto. Durante la demostración el administrador del sistema podrá dar de


Ref: PT-2007-023-12IEME 238

alta nuevos usuarios para que se identifiquen en el sistema. También se podrá simular

el intento de acceso fallido haciendo que alguien no registrado intente acceder a través

del demostrador.

2.5.1.5 Switch de Conexión

Se necesita un switch ethernet para conectar los 3 componentes del sistema que se

comunican a través de la red: servidor central, cámara IP y demo CAB+.

2.6 Tarea 7- Pruebas

Dentro de la tarea 7 estaban comprendidas dos partes bien diferenciadas que

consistían en desarrollar un plan de implantación de la herramienta para un puerto

concreto y la realización de una batería de pruebas con el demostrador para

comprobar el correcto funcionamiento de la aplicación. La elaboración de un plan de

implantación no fue posible ya que era necesaria la colaboración de un puerto que

estuviera interesado en dedicar recursos suficientes para facilitarnos la información

necesaria con el fin de realizar un estudio a medida de dicho puerto. Al ser un proyecto

de investigación y por lo tanto no ser un producto listo para poner en funcionamiento

dentro de un puerto, no se encontró ningún candidato dispuesto a integrar una

herramienta nueva que pudiera perjudicar los sistemas de seguridad existentes en los

recintos portuarios.

2.6.1 Pruebas

Para llevar a cabo la parte de las pruebas, se diseñó una batería de pruebas unitarias

de cada una de las funcionalidades con el sistema que integraba y una batería de

pruebas de toda la herramienta para comprobar el correcto funcionamiento de la

misma. Además se han preparado unos escenarios de ejemplo y se han puesto en

práctica para poder comprobar que la seguridad en el desarrollo habitual de un día en

el puerto está cubierta por la aplicación.


Ref: PT-2007-023-12IEME 239

Escenario 1. Control de acceso de vehículos

Como cada día Javier Pérez se dirige al Puerto de Ciudad del Mar en el vehículo de su

empresa, al igual que Ricardo González. Javier y Ricardo trabajan para sendas

empresas que realizan operaciones dentro del puerto.

Debido a su trabajo ambos deben realizar múltiples salidas del recinto portuario, con lo

cual el vehículo debe someterse a los controles rutinarios de acceso.

Javier es una persona a la que no le importa madrugar, lleva haciéndolo desde hace

mucho tiempo, así que llega puntualmente a las 6:00 al punto de acceso de vehículos

del Puerto de Ciudad del Mar. El sistema de reconocimiento automático de matriculas

identifica el número de la matrícula del vehículo que conduce Javier, la aplicación

MOSCA se comunica con el servicio de control de accesos para consultar el permiso

de la matricula identificada. El sistema corrobora que la matricula es correcta y por lo

tanto el vehículo tiene permiso de entrada (todos los vehículos que circulan

normalmente a través del control de accesos están registrados en una base de datos).

Una vez verificado el permiso (es un proceso automático que lleva solo unos

segundos) las barreras se abren, dejando paso a Javier.

Figura 98: Lectura correcta de matrícula y abertura de la barrera de entrada.

Por otro lado a Ricardo se le han pegado las sábanas, son las 6:10 y todavía no ha

llegado al Puerto. Decide intentar tomar un atajo que no conoce demasiado bien, con

las prisas y el despiste por estar en un lugar desconocido no se da cuenta de que el

semáforo de la intersección que tiene justo delante se ha puesto en rojo y el coche que


Ref: PT-2007-023-12IEME 240

le precede ha parado. Se produce un pequeño choque, afortunadamente Ricardo no

circulaba a mucha velocidad, con lo cual no hay que lamentar daños personales y los

daños materiales son más bien escasos, un poco de chapa y pintura. Después de

rellenar los formularios para la compañía aseguradora y pedir disculpas por el

incidente, Ricardo se pone en camino de nuevo. Llega al puerto a las 6:51 y se dirige

al punto de control de accesos para vehículos, pero Ricardo no se ha dado cuenta de

que durante el percance ha perdido la placa delantera de la matrícula del vehículo.

El sistema detecta que un vehículo quiere acceder al recinto e intenta capturar el

número de matrícula, cuando el módulo de detección de matrículas se da cuenta de

que no hay matrícula, éste lanza un evento que es atendido remotamente por un

operario.

Figura 99: Lectura incorrecta de matrícula y permiso de acceso denegado.

El sistema es lo suficientemente flexible como para que la entrega de eventos sea

inteligente, es decir, el operario no tiene porqué estar dedicado a observar la pantalla

de un ordenador por si algo sucede, incluso no tiene porque estar sentado delante de

un ordenador, gracias a las conexiones inalámbricas (Ya sea Wifi, GPRS, etc...) el

operario se puede encontrar en cualquier lugar. El operario se pone en contacto con

Ricardo, le explica la situación y procede a verificar sus credenciales. El operario

determina que todo está en orden, con lo cual procede a introducir manualmente el

apunte del acceso. El servicio de control de accesos da la transacción por correcta y

abre la barrera para que Ricardo pueda acceder al área restringida del Puerto.


Ref: PT-2007-023-12IEME 241

Escenario 2. Registro Biométrico y CCTV

El puerto de Ciudad del Mar es un puerto muy importante y moderno, por él pasan

cada día toneladas de mercancías y multitud de viajeros. El principal objetivo de

gerencia es la seguridad del puerto; que las mercancías estén controladas y los

viajeros se sientan en todo momento confortables y seguros en el camino a su destino.

Manuel y María José, dos guardias de seguridad que desempeñan sus labores en el

puerto, lo saben muy bien.

Manuel llega al puerto de Ciudad del Mar y se dirige al punto de reunión de personal,

en Gerencia. Son las 7:00 de la mañana. Para acceder a esta zona Manuel se

identifica mediante un sistema de biometría facial, el sistema de verificación biométrico

que está implantado en todo el puerto. Para ello coloca su cara delante del sistema y

unos segundos después la puerta de la sala de personal se abre. Manuel ya puede

acceder. Una vez dentro le indican que hoy tendrá una nueva compañera que se

acaba de reincorporar, María José. Manuel tendrá que enseñarle como funciona la

seguridad del puerto e instruirla en los procesos de seguridad.

Manuel indica a María José que debe registrarse previamente para tener acceso a las

zonas restringidas del puerto.


Ref: PT-2007-023-12IEME 242

Figura 100: Ventana de registro del nuevo perfil de usuario

Así María José, se registra; se coloca delante del sistema de registro biométrico y

éste le da las instrucciones necesarias para el registro. El administrador le asigna a

María José un nivel de acceso completo a las instalaciones del Puerto, con lo cual ya

puede circular sin problemas por el recinto.


Ref: PT-2007-023-12IEME 243

Figura 101: Datos de horario ininterrumpido


Ref: PT-2007-023-12IEME 244

Figura 102: Datos de permisos de accesos a las zonas del puerto

Una vez finalizado el proceso de registro, Manuel indica a María José que su misión

durante las próximas horas será observar las cámaras de seguridad del puerto, así

pues María José procede a validar sus credenciales frente a un terminal del sistema y

accede a la plataforma MOSCA. El puerto tiene más de 100 cámaras instaladas, la

mayoría de ellas en zonas en las que no hay demasiado movimiento (hoy es Domingo

y los servicios del puerto están bajo mínimos). Así que María José, siguiendo las

indicaciones de Manuel, configura el sistema para que le muestre sólo las cámaras

que cubren las áreas sensibles y comienza su labor.


Ref: PT-2007-023-12IEME 245

Figura 103: Configuración de la cuadrícula de cámaras en formato 2x2

Como ya se ha comentado, el Puerto de Ciudad del Mar es muy moderno y tiene

instaladas cámaras de seguridad capaces de activarse cuando se detecta movimiento.

Son las 11:32, Maria José está observando las cámaras, cuando en su pantalla

aparece un aviso, una de las cámaras que no está visualizando ha detectado

movimiento y ha generado una alarma. María José selecciona la visualización de la

cámara que ha generado la alarma y observa movimientos de un individuo

sospechoso, no debería haber nadie en esa área. María José sigue el procedimiento

establecido y envía unos encargados de seguridad a atender la alarma. Los

encargados de seguridad solicitan al individuo que se identifique y comprueban que se


Ref: PT-2007-023-12IEME 246

trata de un intruso y es retenido para esclarecer su presencia, sin permiso, en un área

sensible.

Escenario 3. Visualización de buques atracados y consulta de datos específicos del buque.

Pedro es el encargado de controlar la seguridad de los buques que se encuentran

dentro de las aguas del puerto de Ciudad del Mar. Para ello, además de gestionar las

solicitudes de entrada a puerto con la aplicación DUEWEB y las solicitudes de entrada

de MMPP con IMOWEB, debe comprobar que los buques no provocan situaciones de

peligro.

Figura 104: Acceso al portal de Atraques DUEWEB


Ref: PT-2007-023-12IEME 247

Figura 105: Acceso al portal de Gestión de Mercancías Peligrosas

Para ello, en todo momento puede visualizar con la aplicación el mapa del puerto con

los buques atracados.


Ref: PT-2007-023-12IEME 248

Figura 106: Visión general del mapa del puerto

Y también puede visualizar la información específica más relevante de un buque en la

ventana de información.


Ref: PT-2007-023-12IEME 249

Figura 107: Información específica de un buque

Cuando está visualizando un buque que no tiene la escala autorizada, aparece un

evento nuevo en el gestor que le indica que un buque se encuentra en el campo de

regatas.


Ref: PT-2007-023-12IEME 250

Figura 108: Evento de un buque en área restringida

En el momento que se produce dicha alarma, Pedro pasa a realizar las acciones

necesarias para evitar que se produzca un accidente. Estas acciones son, avisar al

buque por radio de que se está navegando por una zona restringida y que debe

abandonarla cuanto antes. Y si el buque no modifica el rumbo para salir del campo de

regatas, avisar a Protección Civil.


Ref: PT-2007-023-12IEME 251

Figura 109: Detalle del evento de un buque en área restringida

Afortunadamente, el buque modifica su trayectoria y Pedro marca el evento como

finalizado.


Ref: PT-2007-023-12IEME 252

3 CONCLUSIONES

El mundo portuario actual, a nivel nacional, adolece de aplicaciones informáticas

integradoras enfocadas al análisis de riesgos en todas y cada una de las actividades

que se realizan en los puertos. El interés por estas herramientas queda patente en las

iniciativas tomadas tanto a nivel nacional como internacional. Los ejemplos más claros

de estas iniciativas se encuentran en los puertos de Rotterdam, Hamburgo y Valencia

entre otros, que ya están realizando esfuerzos de manera independiente para poder

agrupar toda la información relativa a la seguridad existente en el puerto y tenerla más

accesible e interrelacionada. Yendo un paso más allá, PORTEL ha pretendido

construir una solución estándar, que sea válida para todos los puertos, adaptándose a

todos ellos, de modo que les permita obtener información fiable en tiempo real, sobre

la seguridad en todos sus procesos para poder realizar un análisis de riesgos muy por

encima de las limitaciones que les imponen sus sistemas actuales. En el marco de

este proyecto de investigación se ha desarrollado un demostrador de dicha

herramienta estándar.

La herramienta que se ha desarrollado servirá para que los operadores de un centro

de control puedan visualizar todos los datos que necesitan de estas actividades en

tiempo real, para tomar las medidas oportunas y minimizar los riesgos que ocurren en

el recinto portuario. Por lo tanto con esta herramienta se verá cómo la monitorización

de los datos en tiempo real, puede representar una ayuda a la toma de decisiones y al

análisis de riesgos en el proceso de la operativa portuaria, potenciando la experiencia

de los controladores en dichas situaciones al facilitarles más y mejor información de la

que disponían hasta ahora.

Un inconveniente encontrado durante el desarrollo del proyecto, es que se ha

producido un desacople entre los periodos estimados en el plan de trabajo para el

desarrollo de las diferentes tareas planeadas, y el tiempo real necesitado para

finalizarlas. Estos retrasos se han intentado solventar incrementando el número de

horas de trabajo previstas para el personal asignado al proyecto, pero esto no ha sido

suficiente para finalizar las tareas dentro de las fechas planteadas. Por este motivo, y

ante la imposibilidad de desarrollar todas las tareas referenciadas en el Plan de

Trabajo dentro de los periodos estimados en el mismo, se solicitó una prórroga para la

finalización del proyecto, que finalmente ha sido suficiente para desarrollar todas las


Ref: PT-2007-023-12IEME 253

tareas previstas. De cualquier modo hay que tener en cuenta que este proyecto integra

la última tecnología existente para el desarrollo de aplicaciones junto con la tecnología

ya en uso en la actualidad en el ámbito portuario, por lo que inicialmente se ha

necesitado estudiar las aplicaciones en uso y las posibilidades que existían de

integrarlas con las últimas tecnologías. Esta tarea no ha sido sencilla puesto que

requería de la construcción de wrappers que permitiesen usar diferentes lenguajes de

programación en una misma aplicación. Al no ser expertos en este tipo de tecnologías,

el tiempo invertido en esta parte del proyecto ha sido demasiado elevado.

Dentro de la primera fase del proyecto, se estudiaron diferentes arquitecturas para la

herramienta, seleccionando la arquitectura SOA por su idoneidad para la integración

de aplicaciones existentes con otras de nueva creación. Se completó la definición de la

arquitectura, optando por una estructura en capas que nos permitiera obtener un

código más fácilmente reutilizable y actualizable. Esto se debe a que las tareas

realizadas en diferentes capas son independientes, permitiendo sustituir una capa por

otra sin que el resto de niveles deba sufrir modificación, siempre y cuando se

mantengan los interfaces. Una vez completada la definición de la arquitectura, se pasó

al diseño del modelo de datos y de los casos de uso. Una vez finalizado el diseño de

los casos de uso, se iniciaron las tareas de programación de la herramienta.

A partir del estudio exhaustivo del marco legal, y teniendo en cuenta la complejidad y

amplitud de la normativa asociada a este proyecto, uno de los objetivos era conseguir

que el demostrador fuera capaz de dar cabida a toda esta normativa y facilitar el

cumplimiento de la misma a los usuarios de la herramienta.

El demostrador para la gestión de riesgos en instalaciones portuarias, abarca tanto la

gestión de la seguridad y protección integral en los ámbitos marítimo y terrestre, como

la monitorización del seguimiento de actividades relacionadas con la cadena de

transporte y la detección de incidentes o situaciones anómalas. Esta herramienta

puede ser un buen punto de partida para el desarrollo futuro de una aplicación

comercial que además integre como análisis de riesgos el cálculo matemático a partir

de los datos reales monitorizados en la aplicación. El resultado final del proyecto es un

demostrador a partir del cual PORTEL podrá desarrollar la herramienta estándar citada

anteriormente e insertarla en el mercado de seguridad portuaria en los próximos años.

Para ello el desarrollo del demostrador está basado en la implementación en PHP de


Ref: PT-2007-023-12IEME 254

SOAP para la creación de los wrappers que encapsulan los servicios web y su

posterior registro en el servidor web, y utilizando XML o JSON para la mensajería

entre la aplicación y los servicios.

Se han alcanzado todos los objetivos que se habían establecido a raíz de las primeras

fases del proyecto en las que se detectaron las necesidades del sistema a partir del

estudio del marco legal y de las reuniones mantenidas con las Autoridades Portuarias.

Algunos de los objetivos como mostrar el número de personas y vehículos que hay en

una zona en un determinado momento, no se han desarrollado, pero se plantea para

un desarrollo futuro.

Como resultado de este desarrollo tenemos una herramienta muy fácil de utilizar que

permite a los responsables de seguridad, desde el centro de control, gestionar todos

los aspectos de la seguridad y la prevención de accidentes y riesgos dentro del recinto

portuario. Con esta herramienta, el usuario puede obtener a primera vista una idea

general del estado del puerto, los buques y los dispositivos que están bajo su

supervisión, de forma que la toma de decisiones se puede hacer más fácilmente al

poseer toda esa información. Además de esta visión general, también se ofrece un

detalle y posibilidad de manejo desde el mismo puesto de control de todos los

dispositivos de videovigilancia y control de accesos que soportan la seguridad en

cuanto a tránsito de personas y vehículos.

Además se puede obtener información de las operaciones que realizan los buques en

puerto, a partir de lo obtenido de las aplicaciones DUE y SIGMA y controlar el trayecto

de los buques durante su estancia en el puerto en tiempo real, gracias al sistema AIS.

Se puede gestionar el control de eventos y la ejecución de las acciones pertinentes

para solventar dichos eventos, y registrar el historial de acciones realizadas por el

personal de seguridad. Del mismo modo se registra el historial de vídeos grabados por

las cámaras de seguridad, para poder ser visualizados a posteriori en caso de

necesidad.


Ref: PT-2007-023-12IEME 255

Por todo ello, podemos concluir que es una herramienta completa que abarca

cualquier necesidad de información que deba recibir el responsable de seguridad de

un puerto que se encuentra en el centro de control.


Ref: PT-2007-023-12IEME 256

4 BIBLIOGRAFÍA

1. A., Arsanjani. Service-oriented modeling and architecture. How to identify specify and realize services for your SOA.

2. A., Roussekov. An SOA Vendor Evaluation Methodology. 2008.

3. Inc., Everware-CBDI. Report - CBDI-SAE TM - CBDI Service Architecture and Engineering TM - A framework and Methodology for Service Oriented Architecture (SOA). 2006.

4. Plumier, Gartner and Daryl C. SODA Haernesses Web Services for Process Fusion, 2003.

5. IBM. RUP Plug-In for SOA V1.0. May 2005.

6. Grace Lewis, E.M., Liam O-Brein, Dennis Smith, and Lutz Wrage. SMART: The Service-Oriented Migration and Reuse Technique. CMU&SEI-2005-TN-29, 2005 SVN.

7. K.L. C. Mathew MacKenzie, Francis McCabe, Peter F. Brown, Rebekah Metz and Booz Allen Hamilton. Reference Model for Service Oriented Architecture v1.0. s.l. : OASIS, 2006.

8. O., Zimmerman. Building Service-Oriented Architectures (SOAs) with Web Services. s.l. : OPSLA, 2007.

9. W3C. Web Services Glossary. s.l. : World Wide Web Consortium, W3C Working Group note 2004, 2004.

10. Oalf Zimmerman, P.K., and Clive Gee. Elements of Service Oriented Analysis and Design. An interdiciplinary modeling approach for SOA projects. s.l. : ITI, 2004.

11. D. Crockford, RFC 4627 The application/json Media Type for JavaScript Object

Notation (JSON): JSON.org, Julio 2006.

Informe CientificoTecnico Finalwebaux.cedex.es/.../INFORME_TECNICO_CIENTIFICO.pdf · 2010-11-02 ·...

Documents

Transcript of Informe CientificoTecnico Finalwebaux.cedex.es/.../INFORME_TECNICO_CIENTIFICO.pdf · 2010-11-02 ·...