PLIEGO DE PRESCRIPCIONESTÉCNICAS PARTICULARES

QUE DEBEN REGIR LACONTRATACIÓN DEL SISTEMA DE

CONTROL, INSPECCIÓN YREGULACIÓN DEL TRASPORTEDISCRECIONAL DE PASAJEROS

POR CARRETERA EN ELAEROPUERTO DE PALMA DE

MALLORCA

Revisión 5.0 - 2012-02-09Àrea d'Innovació tecnològica Consorci de Transports de Mallorca

© Consorci de Transports de Mallorca Pàgina 1 de 55

TABLA DE CONTENIDOSTABLA DE ACRÓNIMOS Y ABREVIACIONES.............................................................5PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD...............................................60.-) INTRODUCCIÓN........................................................................................................7

0.1.-) Situación actual.....................................................................................................80.1.1.-) Llegadas..........................................................................................................80.1.2.-) Salidas.............................................................................................................80.1.3.-) Vías de servicio...............................................................................................90.1.4.-) Zonas de estacionamiento...............................................................................9

0.2.-) Objetivos................................................................................................................91.-) REQUERIMIENTOS FUNCIONALES Y TÉCNICOS.............................................11

1.1.-) Arquitectura del sistema......................................................................................111.2.-) Diseño del sistema...............................................................................................13

1.2.1.-) Componentes de la función física.................................................................141.2.1.1.-) Lectores de matrículas.........................................................................141.2.1.2.-) Detectores de presencia........................................................................151.2.1.3.-) Videovigilancia....................................................................................151.2.1.4.-) Control de acceso.................................................................................15

1.2.2.-) Componentes de la función lógica................................................................161.2.2.1.-) Lógica de negocio y motor de tránsitos...............................................161.2.2.2.-) Subsistema de alarmas y eventos.........................................................171.2.2.3.-) Subsistema de informes e indicadores.................................................171.2.2.5.-) Aplicación móvil para inspectores y autoridad....................................17

1.2.3.-) Integraciones e interoperabilidad..................................................................171.2.3.1.-) Importación de información.................................................................171.2.3.2.-) Exportación de información.................................................................18

1.3.-) Marco regulatorio................................................................................................192.-) CARACTERÍSTICAS TÉCNICAS HARDWARE....................................................20

2.1.-) Control de accesos...............................................................................................202.1.1.-) Lectores de matriculas...................................................................................202.1.2.-) Detectores de presencia de vehículo.............................................................212.1.3.-) Cámaras de videovigilancia..........................................................................222.1.4.-) Ubicaciones del equipamiento en campo......................................................23

2.1.4.1.-) Bloque detector 1 - [E-1-L]..................................................................252.1.4.2.-) Bloque detector 2 - [E-2-S]..................................................................252.1.4.3.-) Bloque detector 3 – [E-3-S].................................................................262.1.4.4.-) Bloque detector 4 – [E-4-L].................................................................262.1.4.5.-) Bloque detector 5 [S-5-T]....................................................................272.1.4.6.-) Bloque detector 6 [T-6-L]....................................................................282.1.4.7.-) Bloque detector 7 [S-7-F]....................................................................282.1.4.8.-) Bloque detector 8 [S-8-F]....................................................................29

2.2.-) Centro de proceso de datos..................................................................................292.2.1.-) Servidores de aplicación................................................................................302.2.2.-) Almacenaje....................................................................................................30

© Consorci de Transports de Mallorca Pàgina 2 de 55

2.2.3.-) Videovigilancia..............................................................................................302.2.4.-) Base de datos.................................................................................................30

2.3.-) Comunicaciones..................................................................................................303.- SISTEMA SOFTWARE...............................................................................................32

3.1.-) Software base.......................................................................................................323.2.-) Arquitectura de la aplicación...............................................................................32

3.2.1.-) Business Rule Management System + Business Process Management........333.2.2.-) Nomenclatura de clases.................................................................................333.2.3.-) Jerarquía de paquetes....................................................................................353.2.4.-) Nomenclatura de clases y métodos...............................................................363.2.5.-) Servicios de directorio del servidor de aplicaciones.....................................363.2.6.-) JSP, Servlets y EJBs......................................................................................373.2.7.-) Seguridad y robustez del software................................................................37

3.3.-) Especificaciones funcionales...............................................................................383.3.1.-) Mantenimientos (alta,baja, modificación).....................................................383.3.2.-) Procesos de negocio......................................................................................383.3.3.-) Definición de reglas y flujos.........................................................................38

3.4.-) Especificaciones de integraciones.......................................................................383.5.-) Especificaciones de interoperabilidad.................................................................393.6.-) Modularidad en la gestión...................................................................................39

5.-) MANTENIMIENTO...................................................................................................415.1.-) Plan de Operación y Mantenimiento...................................................................41

5.1.1.-) Formación......................................................................................................425.1.2.-) Mantenimiento preventivo............................................................................425.1.3.-) Mantenimiento correctivo.............................................................................42

5.2.-) Recambios...........................................................................................................435.2.1.-) Stock inicial por garantía y SLA...................................................................435.2.2.-) Recambios a cargo del CTM.........................................................................43

5.3.-) Desplazamientos para mantenimiento de segundo nivel.....................................445.4.-) Herramientas de gestión......................................................................................44

4.-) CALIDAD DE SERVICIO. SLAs MíNIMOS EXIGIDOS........................................454.1.-) SLAs de tiempo de implantación........................................................................45

4.1.1.-) Garantías de tiempo de implantación............................................................454.2.-) SLAs de suministro y reparación........................................................................45

4.2.1.-) Garantías de suministro y reparación............................................................464.3.-) SLA's de calidad por equipo................................................................................46

4.3.1.-) Garantías de calidad por equipo....................................................................479.-) HITOS DEL PROYECTO. GARANTÍA Y MANTENIMIENTO.............................48

9.1.-) Plazo de ejecución...............................................................................................489.2.-) Garantía...............................................................................................................489.3.-) Mantenimiento.....................................................................................................48

............................................................................................................................................48DOCUMENTACIÓN........................................................................................................49PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD.............................................50

A.- Propiedad intelectual...............................................................................................50B.- Confidencialidad.....................................................................................................50

............................................................................................................................................50

© Consorci de Transports de Mallorca Pàgina 3 de 55

ASPECTOS GENERALES Y CONDICIONES ECONÓMICAS....................................51I..................................................................................................................................51MPORTE ECONÓMICO..........................................................................................51FORMA DE PAGO....................................................................................................51PERIODO DE GARANTÍA Y MANTENIMIENTO................................................51

© Consorci de Transports de Mallorca Pàgina 4 de 55

TABLA DE ACRÓNIMOS Y ABREVIACIONES

Abreviación

CDT Control de Tráfico

LAM Lector Automático de Matrículas

OCR Optical Character Recognition

MTBF Mean Time Between Failures

CPD Centro de Proceso de Datos

SNMP Simple Network Management Protocol

SAI Sistema d'Alimentació Ininterrompuda

NTP Network Time Protocol

SLA Service Level Agreement (Acord de nivell de servei)

IP Internet Protocol

RAID Redundant Array of Innexpensive Disks

PMI Aeropuerto Palma de Mallorca

DGT Direcció General de Transports

EJB Enterprise Java Bean

JAAS Java Authentication and Autorization Service

LDAP Ligthweight Directory Access Protocol

SGBD Sistema Gestor de Bases de Datos

JBMP JBoss Business Process Management

BRMS Business Rules Management System

Página 5 de 55

PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD

© Copyright CONSORCI DE TRANSPORTS DE MALLORCA, 2014. Todos los derechosreservados. La expresión, total o parcial así como todos los datos e informacióncontenida en el presente documento constituye una obra cuya propiedad intelectualy/o industrial pertenece a CONSORCI DE TRANSPOTS DE MALLORCA. Lareproducción, comunicación pública, distribución, modificación, cesión y cualquierotro acto que no haya sido expresamente autorizado por escrito por CONSORCI DETRANSPORTS DE MALLORCA quedan prohibidos.

La información comprendida en este documento es estrictamente confidencial ypertenece a CONSORCI DE TRANSPORTS DE MALLORCA. Cualquier forma dedivulgación, reproducción, copia o distribución total o parcial de la misma quedaestrictamente prohibida, no pudiendo ser utilizado su contenido para otros fines quela propia información del destinatario, sin la previa autorización expresa y por escritode CONSORCI DE TRANSPORTS DE MALLORCA.

Página 6 de 55

0.-) INTRODUCCIÓN

El objetivo del presente pliego es definir las bases de un sistema de control de tráficode vehículos que permita controlar y regular el transporte discrecional de pasajerospor carretera en el aeropuerto de Palma de Mallorca.

Este pliego se estructura en tres grandes suministros que se sintetizan acontinuación:

• Sistema hardware de obtención de información

◦ Subsistema LAM (Lectura Automática de Matrículas)

◦ Subsistema videovigilancia

◦ Subsistema de comunicaciones

• Sistema hardware de proceso de información

◦ Servidor central de proceso de información

◦ Unidad de almacenamiento de información

◦ Sistema de comunicaciones

• Sistema software de control del sistema de obtención de datos

◦ Software de definición de reglas de negocio

◦ Informes de actividad

◦ Aplicación de gestión del sistema

◦ Aplicación móvil para alarmas e infracciones

La entrega, instalación y configuración de los diferentes equipos y sistemas serealizará en las siguientes ubicaciones:

• Sistemas hardware en el aeropuerto de Palma de Mallorca

• Sistema software de control y gestión en el CPD del CTM ubicado en la C/Eusebi Estada nº28, planta baja, de Palma de Mallorca.

Página 7 de 55

0.1.-) Situación actual

Actualmente, el Aeropuerto consta de dos zonas diferenciadas, una para la salida depasajeros (descarga por parte de los vehículos) y otra para la llegada de pasajeros(recogida por parte de los vehículos). A estas dos zonas las llamaremos zona dedescarga y zona de recogida respectivamente.

En la siguiente figura se muestra un plano esquemático de los viales de entrada ysalida a las zonas de descarga, recogida de viajeros, parking y rent a car.

0.1.1.-) Llegadas

La zona de llegadas del aeropuerto de Palma de Mallorca se encuentra en el nivel dela planta noble entre el edificio de parking (P1 en el plano anterior) y las puertas dellegada. En esta zona, los vehículos particulares y no particulares disponen de dosparkings de pago (P1 y P2) que permiten estacionar el vehículo mientras se espera lallegada de pasajeros. Adicionalmente, los vehículos empresariales disponen de unparking propio P3 para poder esperar a los pasajeros. Entre los usuarios del P3 seencuentran los autobuses interurbanos y las emisoras de taxi que pueden cargarpasajeros en el aeropuerto.

0.1.2.-) Salidas

Página 8 de 55

E . 1E . 2

S . 1

S . 2

E . 1 . 2

P 1

P 2

P 3

La zona de salidas se encuentra en el nivel 1 del aeropuerto y consta de una zona deparking gratuito pero con tiempo limitado para la descarga de pasajeros, tantoparticulares como discrecionales.

0.1.3.-) Vías de servicio

Las vías de servicio son las rutas de entrada a las diferentes zonas del aeropuerto,siempre referidas al ámbito de este proyecto (tráfico rodado).

• Vial de entrada a llegadas (E.1) Este vial esta formado por una división de→la carretera de entrada al aeropuerto y se desdobla en 4 carriles, 2 dirigidosal parking P1, 1 dirigido al parking de rent a car también en P1 y el últimodirigido al parking P3 (E.1.2) de recogida de pasajeros.

• Vial de entrada a salidas (E.2) Este vial esta formado por una división de la→carretera de entrada al aeropuerto y se desdobla en 2 carriles, el primero sedirige a la zona de descarga para vehículos particulares y el segundo a lazona de descarga para vehículos discrecionales (taxis y autobusesprincipalmente).

• Vial de salida de llegadas (S.1) Este vial permite regresar a la autopista→MA-20 una vez recogidos los pasajeros de llegadas. También permite regresaral aeropuerto a cualquiera de las zonas definidas.

• Vial de salida de la zona de salidas (S.2) Este vial permite regresar a la→autopista MA-20 una vez descargados los pasajeros de salidas. Tambiénpermite regresar al aeropuerto a cualquiera de las zonas definidas.

0.1.4.-) Zonas de estacionamiento

El aeropuerto consta de tres zonas de estacionamiento con diferentes funciones. Laprimera es el edificio de aparcamientos para turismos particulares (marcada con P1en el plano). En este edificio aparcan los vehículos particulares que vienen a recogerpasajeros o bien los que van a volar y dejan el coche en el aeropuerto.

La segunda zona de aparcamiento, se encuentra justo al principio de la zona dellegadas (marcada con P2 en el plano). Este parking también es usado por vehículosparticulares y es el llamado “parking express” situado muy cerca de las puertas dellegadas pero con un precio superior al P1.

La tercera y última zona de aparcamiento (marcada con P3 en el plano) es ladedicada a la recogida de viajeros mediante vehículos profesionales (autobuses,taxis, etc.). Se encuentra en la zona de llegadas justo delante de las puertas desalida.

0.2.-) Objetivos

Página 9 de 55

Cómo hemos visto, el objetivo principal del proyecto es disponer de un sistema quepermita controlar de forma flexible y escalable el tráfico rodado de vehículos en elaeropuerto de Palma de Mallorca. Particularmente, se debe poder responder a lassiguientes preguntas de forma inequívoca:

• ¿Está autorizado este vehículo a cargar o descargar pasajeros en una zonaconcreta?

• ¿Está autorizado este vehículo a pasar por este punto?

• ¿Está autorizado este vehículo a realizar esta secuencia de acciones (cargas,descargas, tránsitos)?

• ¿Cuantas veces en un periodo de tiempo dado ha cargado o descargadopasajeros este vehículo?

• ¿Está este vehículo en lista negra? ¿Ha sido sancionado alguna vez estevehículo?

• ¿A que colectivo (empresa, emisora de taxi, etc.) pertenece este vehículo?

• ¿Ha sido sancionado alguna vez este vehículo?

El presente pliego, define las características y condiciones técnicas para laadquisición de los equipos, suministros y servicios necesarios para la correctaimplantación de un sistema que de solución al problema planteado.

Página 10 de 55

1.-) REQUERIMIENTOS FUNCIONALES Y TÉCNICOS

A continuación se expone la casuística anteriormente explicada y se requiere unasolución basándose en los siguientes criterios básicos:

• No invasiva. El sistema propuesto debe ser completamente transparente a lagestión aeroportuaria, no debe interferir con el día a día del aeropuerto.

• Debe permitir un control absoluto del tráfico rodado.

• Fiable. Debe permitir la correcta detección de un 95% de las matrículas queentran en el aeropuerto.

• Flexible. El comportamiento, entendiendo este por alarmas, filtros, informes yfuncionamiento del sistema, debe poder adaptarse sin esfuerzo a lasnecesidades cambiantes del entorno. Debe poder adaptarse rápidamente alcambio de costumbres de los usuarios de vehículos privados y conductores,sean estos particulares o empresas.

• Adaptable. El sistema se debe poder adaptar a los cambios estructurales delaeropuerto, cómo por ejemplo, desvíos de rutas, obras, ampliaciones, etc.

• Económica. Debe suponer el mínimo gasto monetario y el mínimo esfuerzo deimplantación, sin renunciar a ninguno de los objetivos estratégicos delproyecto.

• Debe poder ser integrable con múltiples fuentes de datos y debe poderexportar los resultados obtenidos a múltiples destinos de datos.

1.1.-) Arquitectura del sistema

Para cumplir los criterios expuestos anteriormente, se exige una arquitectura delsistema que separe las funciones físicas de las funciones lógicas. ¿Qué entendemospor función física y función lógica?:

• Función física Aquella que desarrolla el sistema con ayuda de elementos→físicos, por ejemplo, la detección de la entrada de un coche con una espira deinducción, o la lectura de una matrícula mediante una cámara especializada.Las funciones físicas son las que nutren de datos al sistema y las que leaportan capacidad ejecutiva sobre el entorno.

• Función lógica Aquella que desarrolla el sistema mediante algoritmos de→proceso de la información. Por ejemplo, la verificación de una matrículacapturada contra una base de datos de taxis. Las funciones lógicas son lasque otorgan inteligencia al sistema.

Página 11 de 55

Esta separación de funciones permite que en campo sólo se implanten los elementosde recogida de información, pudiendo llevar la “inteligencia” del sistema a cualquierinstalación disponible. De esta forma, se deben conseguir los siguientes objetivos:

• Reducción de costes. Al poder llevar toda la parte de almacenamiento,proceso de información y soporte dónde más convenga. Incluso, permitereutilizar instalaciones ya existentes que dispongan de capacidad paraabsorber el nuevo proyecto.

• Escalable. Podemos añadir tantos conjuntos de obtención de información(Camaras-OCR, espiras, barreras, etc.) cómo sean necesarios sin tener queduplicar los sistemas de soporte.

• Al separar la función física de recogida de datos de la función lógica o deinteligencia del sistema, se permite modificar o ampliar esta última sin tenerque modificar las instalaciones desplegadas. Por ejemplo, se podría añadir unnuevo flujo de vehículos, o una nueva secuencia de acciones (llegada,descarga, tránsito a gasolinera, tránsito a salidas, recogida, ….). Esta

Página 12 de 55

S U B S I S T E M A F Í S I C O S U B S I S T E M A L Ó G I C O

S U B S I S T E M A D E B A S E D E D A T O S

A R Q U I T E C T U R A

L E C T O R E S D E M A T R Í C U L A S

D E T E C T O R E S D E P R E S E N C I A

V I D E O V I G I L Á N C I A

L Ó G I C A D E N E G O C I O

S I S T E M A D E I N F O R M E S

A L A R M A S Y S U P E R V I S I Ó N

C O N T R O L D E A C C E S O I M P O R T A C I Ó N Y E X P O R T A C I Ó N

flexibilidad del sistema hace que su comportamiento no dependa de lainstalación sino de cómo se procesen los datos.

La única desventaja de este modelo es la dependencia de las comunicaciones. Alestar separados los elementos que obtienen la información de los elementos que laprocesan y la usan, el sistema depende completamente de la comunicación entreellos. El oferente deberá proponer un sistema de comunicación que de solución aesta problemática. Estas comunicaciones deberán ser fiables, de un ancho de bandasuficiente y redundadas para evitar una caída completa del sistema en caso de averíade un equipo de red.

1.2.-) Diseño del sistema

Una vez definida la arquitectura general del sistema, se debe definir que modelo decontrol seguirá el mismo. Dicha elección influirá inevitablemente en el diseño generaldel sistema, sus costes y su funcionamiento.

El aeropuerto de Palma de Mallorca es uno de los aeropuertos europeos con mástráfico y el tercero en cuanto a número de pasajeros del estado. Además, su tráficode pasajeros se modela con una pronunciada campana gaussiana, siendo los mesesde verano los que concentran la gran mayoría del tráfico anual.

Esta estacionalidad del tráfico de pasajeros obligará a dimensionar el sistema para elpico de tráfico que se produce los meses de Julio y Agosto. Con esta información depasajeros, se puede inferir que el flujo de vehículos será muy elevado en los mesesestivales. Por ello, debemos apostar por un sistema de control no invasivo que puedadesarrollar una gran capacidad de proceso de datos.

A continuación se presenta un esquema funcional de la solución propuesta. Dichasolución contempla la instalación de cámaras de lectura de matrículas, espiras deinducción magnética para la detección de vehículos, un servidor de detección dematriculas (LAM), un servidor de aplicaciones y un servidor de base de datos. Nóteseque en el gráfico presentado se muestran barreras automáticas de entrada y salida.Cómo se ha argumentado, por el elevado tráfico de este aeropuerto, se deberá

Página 13 de 55

2006 2007 2008 2009 2010803.141,00 780.353,00 795.264,00 730.819,00 698.260,00888.040,00 894.790,00 936.564,00 812.556,00 779.970,00

1.186.611,00 1.286.935,00 1.329.686,00 1.111.352,00 1.111.109,00Abril 1.646.995,00 1.648.637,00 1.567.969,00 1.591.376,00 1.333.747,00

2.279.723,00 2.354.213,00 2.482.502,00 2.216.690,00 2.191.818,002.697.070,00 2.793.021,00 2.722.477,00 2.590.757,00 2.535.485,003.058.719,00 3.187.636,00 3.124.509,00 2.980.446,00 3.042.502,00

Agosto 3.159.705,00 3.282.530,00 3.335.603,00 3.060.298,00 3.202.019,002.788.128,00 2.947.061,00 2.760.706,00 2.510.860,00 2.630.975,00

Octubre 2.141.719,00 2.199.737,00 2.108.486,00 1.978.216,00 2.054.101,00915.226,00 984.353,00 877.739,00 836.278,00 807.074,00828.357,00 854.866,00 776.847,00 775.354,00 719.604,00

22.393.434,00 23.214.132,00 22.818.352,00 21.195.002,00 21.106.664,00

EneroFebreroMarzo

MayoJunioJulio

Septiembre

NoviembreDiciembre

prescindir de cualquier elemento que entorpezca la circulación. Por lo que, latecnología OCR + espiras de inducción deben ser capaces de leer las matrículas a lavelocidad necesaria y con una tasa de aciertos aceptables, no inferior al 95%, sevalorará la mejora de este porcentaje. Los elementos invasivos, cómo barreras obumpers no están permitidos.

1.2.1.-) Componentes de la función física

Cómo hemos visto anteriormente se propone separar los elementos de obtención deinformación de los de proceso de información. A continuación, se describen loscuatro módulos a instalar.

1.2.1.1.-) Lectores de matrículas

El elemento primordial de todo el sistema físico es la cámara de detección dematrículas. Este elemento consta de dos partes, la primera, la propia cámara y lasegunda el controlador que identifica una matrícula sobre un stream de video.

Se deberán instalar en todos y cada uno de los viales de acceso al aeropuerto deforma que ningún vehículo que descargue o recoja viajeros pueda ser no detectadotanto a la entrada como en la salida.

Página 14 de 55

T r á n s i t o

S e r v i d o r B a s eD e D a t o s

S e r v i d o r O C R D e t e c c i ó n M a t r í c u l a s

C á m a r a M a t r í c u l a s C á m a r a M a t r í c u l a s

C á m a r a M a t r í c u l a s

E N T R A D A L L E G A D A S

S A L I D AL L E G A D A S

C á m a r a M a t r í c u l a s

S A L I D AS A L I D A S

E N T R A D AS A L I D A S

P D A I n s p e c t o r e s

I n f o r m e s e I n d i c a d o r e s

S e r v i d o r d e a p l i c a c i o n e s e i n t e g r a c i o n e s

T r á n s i t o

M a e s t r o s d e m a t r í c u l a s d e t a x i y s e r v i c i o s d i s c r e c i o n a l e s

Pun

to d

e co

ntr

ol y

sa

nció

n

1.2.1.2.-) Detectores de presencia

No se aceptan detectores de presencia que requieran una instalación que requiera elcorte del flujo del tráfico (por ejemplo espiras inductivas).

1.2.1.3.-) Videovigilancia

Las cámaras de videovigilancia no se consideran un elemento del CDT. Se valorarácomo mejora para proteger los demás elementos del sistema del vandalismo y cómosistema de apoyo en caso de ser necesaria la identificación de un conductor uocupantes de un vehículo. En todo caso, será obligación del oferente, definir,documentar y implementar todas las acciones necesarias para cumplir estrictamentela LOPD.

1.2.1.4.-) Control de acceso

El control de acceso es el sistema físico que dada la necesidad puede impedir elacceso de un vehículo a las instalaciones del aeropuerto.

Una vez estudiados los datos de pasajeros y tráfico del aeropuerto de Palma deMallorca no parece que una solución de control de acceso sea la más adecuada porlos siguientes motivos:

• Elevado flujo de vehículos.

• Ralentización del flujo de vehículos al tener que abrir y cerrar las barreras delsistema.

• Susceptible de vandalismo y costes elevados de mantenimiento al ser partesmóviles.

• Una incidencia (rotura) en el sistema del control de acceso incidiría muynegativamente en otros servicios de otras entidades (por ejemplo en AENA) yen el funcionamiento del aeropuerto.

Por todo ello, se prohíbe la instalación de un sistema de control de acceso y sepropone un sistema de control y sanción a posteriori y a la salida. ¿Qué entendemospor un sistema de control a posteriori y a la salida?.

• Control a posteriori el proyecto desarrollará un sistema de control y sanción→retardado en caso de que no se cuente con personal inspector en elaeropuerto. Por ejemplo, si el sistema detecta una infracción puede notificarloal cuerpo de inspectores y estos con los datos recogidos proceder a lasanción. Este punto requeriría colaboración y una integración con la dirección

Página 15 de 55

general de tráfico para obtener el propietario de un vehículo a partir de sumatrícula.

• Control a la salida el proyecto desarrollará una aplicación para equipos→móviles (tabletas, smartphones, etc.) que permitirá que los inspectores detransporte reciban en tiempo real las infracciones de tránsito. En este caso, siel inspector se sitúa en los viales de salida dispondrá de todos los elementosde información para realizar un control de salida de los vehículos.

1.2.2.-) Componentes de la función lógica

El software del sistema propuesto consta de cuatro módulos o subsistemas. Acontinuación se describen los cuatro módulos de forma detallada.

1.2.2.1.-) Lógica de negocio y motor de tránsitos

El módulo de lógica de negocio y motor de tránsitos será el cerebro del sistema. Seráel encargado de convertir eventos físicos en tránsitos de vehículos. Es decir, estemódulo convertirá eventos físicos en información capaz de ser entendida por uninspector o autoridad. Permitirá también la definición de reglas para discernir entreun tránsito “legal” y un tránsito “no permitido”. En definitiva, permitirá modelarinformáticamente la realidad de los movimientos de vehículos en el aeropuerto. Porejemplo, podemos definir un flujo invalido cómo:

Paso 1 Un vehículo es detectado en el vial de entrada a la zona de salidas.→Matrícula IB-4567-DH

Paso 2 Un vehículo es detectado en el vial de salida de la zona de salidas con la→matrícula IB-4567-DH

Paso 3 El vehículo con matrícula IB-4567-DH es detectado en el vial de entrada de→la zona de llegadas del aeropuerto. Dicha matrícula no consta en ningún maestro devehículos autorizados a cargar pasajeros en el aeropuerto.

Paso 4 El sistema emite una alarma e informa a los inspectores de transporte de la→secuencia de detecciones y la infracción cometida. Adjunta fotografías del vehículo encada uno de los pasos para identificar al conductor y contabilizar si lleva pasajeros ycuantos.

Este ejemplo anterior seria definido como un “Flujo de control”. En la fase de análisisse identificaran todos y cada uno de los flujos a auditar y se integrarán en unaaplicación llamada “Lógica de negocio y motor de tránsitos”

Este módulo permite trabajar y actuar en tiempo real. Es decir, permite tenerinspectores en campo que sancionen en el momento las infracciones detectadas.También permite un análisis a posteriori mediante el subsistema de informes eindicadores.

Página 16 de 55

1.2.2.2.-) Subsistema de alarmas y eventos

El módulo de alarmas y eventos será el encargado de generar los avisos a partir dela información que genere el módulo de motor de tránsitos. Estas alarmas o avisosserán enviados mediante múltiples opciones (página web, aplicación móvil, SMS,etc.) a las personas o sistemas informáticos capaces de actuar para sancionar,advertir o evitar las actuaciones “no permitidas”.

1.2.2.3.-) Subsistema de informes e indicadores

El módulo de informes e indicadores permitirá el seguimiento del día a día y lasupervisión a alto nivel del sistema. Más detalladamente:

• Los informes permitirán definir consultas a la base de datos que devuelvan elestado del sistema en un momento dado o en un período de tiempo. Sususuarios naturales serán los inspectores de transporte o autoridades concapacidad de actuación sobre los tránsitos no permitidos.

• La parte de indicadores permitirán medir la evolución del sistema en el tiempoy la realización de un cuadro gerencial o cuadro de mando. Este cuadro demando permitirá responder a preguntas de muy alto nivel cómo: ¿cual es laevolución de tránsitos no permitidos a lo largo del año? Su usuario evidenteserá la alta dirección del proyecto.

1.2.2.5.-) Aplicación móvil para inspectores y autoridad

La aplicación móvil permitirá dotar a los inspectores de transporte y autoridadessancionadoras, de la herramienta necesaria para realizar su trabajo. Esta aplicaciónse descargará e instalará en un sistema móvil (PDA, tableta, smartphone, etc.) ypermitirá que un inspector disponga de la información de infracciones en tiempo real.También permitirá que un inspector pueda consultar toda la información histórica detránsitos de un vehículo dado, así cómo su historial de sanciones.

1.2.3.-) Integraciones e interoperabilidad

El CDT es inherentemente un sistema que depende y del que dependerán otrossistemas de información. A continuación se enumeran las integraciones del CDT conlos restantes sistemas, tanto para la importación de datos como para la exportación.

1.2.3.1.-) Importación de información

El CDT necesitará para funcionar correctamente maestros de matrículas con losvehículos autorizados a realizar una determinada acción o acciones. Estos maestros

Página 17 de 55

permitirán al CDT validar si las acciones realizadas por un vehículo están o no estánpermitidas. Una vez recopilada esta información y comprobadas las autorizacionespertinentes se podrá proceder con las acciones correctivas que se estimenoportunas.

Para la adquisición de estos maestros de datos el CDT ofrecerá dos mecanismos paraimportar correctamente esta información. El primero será un servicio web quepermitirá entregar en tiempo real esta información. En caso de que la fuente deinformación no disponga de la tecnología necesaria para abordar una integración deestas características, el CDT le ofrecerá una aplicación web que permita laimportación manual de la información.

A continuación se enumeran las fuentes de datos del sistema CDT.

• Maestros de flota de autobuses discrecionales. El sistema CDT deberá contarcon la información de las matriculas que corresponden a las flotas deautobuses discrecionales que operan en el aeropuerto de palma de mallorca.

• Maestros de flota de taxis. El sistema CDT deberá contar con la informaciónde las matrículas que corresponden a las flotas de taxis que operan en elaeropuerto de palma de mallorca.

1.2.3.2.-) Exportación de información

Una vez el sistema haya procesado la información que le envían los diferentesequipos de detección de matrículas esta podrá ser exportada a múltiples aplicacionespara su uso por varias entidades.

A continuación se proponen los sistemas a los cuales el CDT podría exportarinformación. Estos receptores de datos recibirán la información del CDTprincipalmente en formato de webservices. De todas formas, cada exportación y/opublicación de datos se estudiará en el momento de análisis del proyecto.

• Policía local del aeropuerto. En caso de detectar una infracción, el CDT debeser capaz de avisar a la autoridad del aeropuerto, enviándole todos los datosdel vehículo infractor. Esta integración deberá ser implementada en tiemporeal, es decir, una infracción deberá ser comunicada en el mismo momento enque se detecte.

• El CDT deberá alimentar la aplicación móvil que se desarrollará para losinspectores de transporte. Al igual que en el punto anterior, esta integracióndeberá ser notificada en tiempo real.

Página 18 de 55

1.3.-) Marco regulatorio

• Diseño que dé cumplimiento al decreto 20/2003, de 28 de febrero, por el cualse aprueba el Reglamento de supresión de barreras arquitectónicas, y el Realdecreto 1544/2007, de 23 de noviembre, por el cual se regulan lascondiciones básicas de accesibilidad y no discriminación para el acceso yutilización de las modalidades de transporte para personas con discapacidad.

• Todos los materiales, tareas y suministros han de adaptarse a la normativavigente, incluidas las leyes de protección medioambiental, seguridad y salud.Se cumplirán todas las especificaciones técnicas europeas y las directivascomunitarias aplicables, disponiendo del marcaje CE que corresponda yademás las prescripciones de este Pliego. En caso de conflicto entre elpresente Pliego y el marco regulatorio autonómico, estatal y europeo, seránlos reglamentos los que prevalezcan encima el Pliego.

Página 19 de 55

2.-) CARACTERÍSTICAS TÉCNICAS HARDWARE

Una vez diseñado el sistema es necesario definir cada uno de sus elementos juntocon las características mínimas de cada uno de ellos. Estas características vendrándeterminadas por el ámbito geográfico, su ubicación física, las necesidades decapacidad y rendimiento, etc.

2.1.-) Control de accesos

2.1.1.-) Lectores de matriculas

Se deberán instalar 8 conjuntos de lectores de matrículas junto con suscorrespondientes controladores, armarios de protección y cableado (eléctrico y decomunicaciones).

Las características mínimas de dicho elemento deberán ser:

• Controlador del conjunto PC industrial con potencia y capacidades suficientespara procesar en todo momento la información que genere el flujo devehículos. Deberá ser capaz de procesar la información del propio sistemaLAM así cómo del sistema de videovigiláncia.

• Funcionamiento adaptado a entornos de atmósfera no controlada(temperatura, humedad y partículas en suspensión). Adaptado a intemperiepara las condiciones propias de Mallorca.

• Antivandálico. Máxima protección antivandálica de todo el conjunto: bastidor,controlador, cámara de lectura de matrículas, cámara de videovigiláncia ycableado.

• Bastidor de aluminio o acero inoxidable con anclaje inferior y posterior. Elbastidor debe disponer de espacio suficiente para futuras ampliaciones delconjunto.

• Norma IP65 como mínimo para el conjunto de controlador, cámaras ybastidores.

• Conectividad IP. Es obligatorio poder asignar una ip al controlador delconjunto. El conjunto ha de ser controlable a través de su dirección IP.

• Soporte para el protocolo SNMP para gestión de alarmas y verificación remotade funcionamiento.

• El controlador deberá contar con elementos hardware para llevar a cabo lasfunciones de watchdog.

Página 20 de 55

• Sincronismo de tiempo. Soporte para el protocolo NTP sobre IP. El conjuntodeberá usar como único elemento de sincronismo el protocolo NTP.

• La cámara LAM deberá contar con las siguientes características mínimas:

◦ Detección de matrículas en mas de un carril de circulación. En caso de queno se disponga de esta tecnología deberán aportarse tantas cámarascomo carriles en cada poste.

◦ Detección diurna y nocturna (mediante iluminación infrarroja)

◦ Rango de detección no inferior a 20 metros

◦ Velocidad de aproximación para la correcta lectura de la matrícula noinferior a 70Km/hora.

A parte de los requerimientos mínimos del conjunto, se deberán analizar los siguientes parámetros de funcionamiento:

• MTBF de los componentes individuales

• MTBF controlador

• Potencia eléctrica tolerada, requerimientos de estabilidad (max, min, avg)

• Detalle de los componentes reemplazables y su coste unitario

2.1.2.-) Detectores de presencia de vehículo

Hay sistemas de reconocimiento de matrícula que necesitan de un sistema adicionalque les avise de cuando se acerca un vehículo y por que carril lo está haciendo. Encaso de que el sistema lo necesite será necesario instalar detectores de presencia.

Para el tráfico rodado, los detectores de presencia más habituales son las espiras deinducción magnética. Estos sistemas son los más apropiados ya que son seguros,inalterables e inmunes al vandalismo. Las características mínimas se detallan acontinuación:

• Funcionamiento adaptado a entornos de atmósfera no controlada (temperatura, humedad y partículas en suspensión).

• Debe poder funcionar sin incidencias con las condiciones atmosféricas propias del clima de las Illes Balears.

• Norma IP65 como mínimo para todo el conjunto (espira + controlador +cableado)

• Antivandalico. Máxima protección antivandálica de todo el conjunto

Página 21 de 55

• Controlador programable

• Soporte para el protocolo SNMP para gestión de alarmas y monitorizaciónremota del funcionamiento del conjunto.

• Debe poder detectar una amplia variedad de vehículos, desde cochesutilitarios hasta autobuses articulados. En caso de ser necesario, se deberáninstalar dos espiras en cada ubicación para garantizar la correcta deteccióndel vehículo.

A parte de los requerimientos mínimos del conjunto, se deberán analizar los siguientes parámetros de funcionamiento:

• MTBF de los componentes individuales

• MTBF controlador

• Potencia eléctrica tolerada, requerimientos de estabilidad (max, min, avg)

• Detalle de los componentes reemplazables y su coste unitario

2.1.3.-) Cámaras de videovigilancia

Todo el equipo anteriormente descrito deberá instalarse en zonas abiertas al públicoy por tanto al vandalismo. Por este motivo, se valora como mejora dotar a cadainstalación de videovigilancia para disuadir cualquier posible acción vandálica. Encaso de que se aporte dicho equipamiento, las características mínimas se detallan acontinuación:

• Cámara IP pura. No se admitirán soluciones analógicas o analógicas concodificadores digitales

• Outdoor, IP65

• 1 MP mínimo, antivandalica, audio

• Formato mini-dome o similar con cristal translucido

• Lente: se debe poder escoger entre diferentes lentes y aperturas. La cantidadexacta de cada una de ellas se detallará en la fase de replanteo y análisisinicial del proyecto. Lente Varifocal, corrección IR, megapixel

• Sensor de imagen: RGB CMOS 1/3” progresivo

• Visión diurna y nocturna. En modo nocturno, la cámara deberá aportar suprópia iluminación infraroja y proporcionar una conmutación automática ailuminación infraroja/diurna. En el caso de que la cámara ofrecida no dispongade esta iluminación infraroja, podrá ser substituida por una fuente externaactivada por la misma cámara (por ejemplo, a través de uno de los puertos

Página 22 de 55

digitales de salida). El alcance mínimo para la luz IR nunca será menor de 15metros lineales.

• Iluminación mínima: Color: 0.5 lux, F1.2, B/W: 0.08 lux, F1.2

• Ajustes de angulo (pan & tilt & rotación) Pan 360°, tilt 170°, rotación 340°

• Soporte del protocolo SNMP para monitorización de la cámara. Todas lascámaras se deberan integrar dentro del gestor SNMP y graficador SNMP delCTM (actualmente Zabbix y Cacti)

• Generación de traps SNMP por disparo de alarma y/o sucesos programados

• Se valorará homologación ONVIF

2.1.4.-) Ubicaciones del equipamiento en campo

Pos 1 (Tipo): E (Entrada aeropuerto), S (Salida aeropuerto), T (Tránsito interno)

Pos 2 (ID): Cardinal del elemento

Pos 3 (Destino): L (Llegadas), S (Salidas), F (Fuera aeropuerto)

Se adjunta a continuación, el plano de situación de todo el equipo de campo.

Página 23 de 55

Página 24 de 55

2.1.4.1.-) Bloque detector 1 - [E-1-L]

• ID: P1• GPS: 2.728943 39.544774• Situación: Entrada de aeropuerto.• Tipo vehículo: Todos• Destino: Parking coches, Parking Bus/Taxi, Tránsito interno• Carriles a controlar: 2• Cámaras: 1 multicarril / 2 monocarril.• Instalación: Puerta carteles informativos. No necesita poste de sujeción.

2.1.4.2.-) Bloque detector 2 - [E-2-S]

• ID: P2• GPS: 2.730893 39.545386• Situación: Entrada de aeropuerto.• Tipo vehículo: Todos• Destino: Salidas particulares, Salidas discrecional (bus, taxi, vc), Tránsito

interno• Carriles a controlar: 3 (1 derecha, 2 izquierda)• Cámaras: 1 multicarril + 1 monocarril / 3 monocarril• Instalación: Necesita poste de sujeción.

Página 25 de 55

2.1.4.3.-) Bloque detector 3 – [E-3-S]

• ID: P3• GPS: 2.731365 39.546003• Situación: Entrada de aeropuerto.• Tipo vehículo: Particulares, Profesionales?• Destino: Salidas particulares• Carriles a controlar: 1 • Cámaras: 1 monocarril• Instalación: Necesita poste de sujeción?

2.1.4.4.-) Bloque detector 4 – [E-4-L]

• ID: P4• GPS: 2.730412 39.545717• Situación: Entrada de aeropuerto.• Tipo vehículo: Profesionales• Destino: Llegadas profesionales• Carriles a controlar: 1 • Cámaras: 1 monocarril• Instalación: Poste de farola.

Página 26 de 55

2.1.4.5.-) Bloque detector 5 [S-5-T]

• ID: P5• GPS: 2.729339 39.548878• Situación: Salida de aeropuerto.• Tipo vehículo: Particulares y Profesionales• Destino: Salida aeropuerto (profesionales y particulares), tránsito a llegadas

(profesionales)• Carriles a controlar: 3• Cámaras: 1 monocarril / 2 monocarril, 1 multicarril• Instalación: Puerta carteles informativos. No necesita poste de sujeción.

Página 27 de 55

2.1.4.6.-) Bloque detector 6 [T-6-L]

• ID: P6• GPS: 2.728391 39.548793• Situación: Transito interno[Salidas->Llegadas] vehículos profesionales• Tipo vehículo: Profesionales• Destino: tránsito a llegadas (profesionales) desde salidas• Carriles a controlar: 1• Cámaras: 1 monocarril • Instalación: Poste de farola

2.1.4.7.-) Bloque detector 7 [S-7-F]

• ID: P7• GPS: 2.728076 39.548565• Situación: Salida de aeropuerto.• Tipo vehículo: Profesionales• Destino: Salida de aeropuerto desde zona de llegadas• Carriles a controlar: 1• Cámaras: 1 monocarril • Instalación: Necesita poste de sujeción.

Página 28 de 55

2.1.4.8.-) Bloque detector 8 [S-8-F]

• ID: P8• GPS: 2.727112 39.548196• Situación: Salida de aeropuerto.• Tipo vehículo: Profesionales y particulares• Destino: Salida de aeropuerto desde zona de llegadas• Carriles a controlar: 2????? (comprobar)• Cámaras: 2 monocarril , 1 multicarril• Instalación: Puerta carteles informativos. No necesita poste de sujeción.

2.2.-) Centro de proceso de datos

El centro de proceso de datos (CPD), es el encargado de validar, almacenar yprocesar toda la información que le merite la función física del sistema.

Página 29 de 55

2.2.1.-) Servidores de aplicación

Los servidores centrales necesarios serán subministrados por el Consorci deTransports de Mallorca mediante máquinas virtuales con tecnología VMWARE. Seráresponsabilidad del adjudicatario subministrar tantas licencias como sean necesariasincluyendo la de sistema operativo a coste cero. Se excluyen las licencias VMWAREque ya obran en posesión del Consorci de Transports de Mallorca.

2.2.2.-) Almacenaje

Los datos que generará el sistema tendrán dos naturalezas diferentes. El primer tiposerán las matrículas y los datos generales de una detección: matrícula, lugar, fecha yhora, etc. El segundo tipo serán las imágenes con la imagen de la matrícula y la delconductor del vehículo.

A la vista de los dos tipos de datos a almacenar se requiere la ampliación de lacabina que posee el CTM (EMC VNX5300) mediante el subministro de discos SATAadicionales.

• Se debe ampliar la cabina con una capacidad de almacenaje bruta mínima de27TB mediante 9 discos de 3TB. El Consorci de Transprots subministrará lospart numbers apropiados al adjudicatario.

2.2.3.-) Videovigilancia

En caso de ofrecer como mejora cámaras de videovigilancia, estas se integraran enla plataforma centralizada del Consorci de Transports de Mallorca. Esta plataformaconsta de almacenamiento suficiente y el sistema de videoanalisis MilestoneCorporate. El licitador deberá subministrar las licencias de Milestone para permitir laintegración de las nuevas cámaras (una licencia de conexión por cámara).

2.2.4.-) Base de datos

El Consorci de Transports de Mallorca dispone de un SGBD completo y no se requiereel subministro de uno nuevo.

2.3.-) Comunicaciones.

En la fase de diseño del sistema, se ha visto que las comunicaciones son unelemento crítico para garantizar el éxito del proyecto. Por este motivo, se haprestado especial atención a este punto y en la definición de las característicasmínimas de la solución. A continuación se detallan las funciones mínimas del sistemade telecomunicaciones.

Líneas de comunicaciones entre elementos físicos y el centro de proceso de datos

Página 30 de 55

• 2 líneas de comunicaciones de diferentes operadores, tecnología ADSL, Cable o Fibra Óptica

• Capacidad de transmisión no inferior a 4Mbps simétricos

• Latencia no superior a 300ms• Soporte para el protocolo SNMP para gestión de alarmas y monitorización

remota del funcionamiento del conjunto.

• Equipos de red inalambricos para comunicar cada poste de detección con lalinea central mediante un enlace wifi en modo bridge. El equipo centraldeberá proveer tecnología MIMO (multiple input multiple output). De todasformas y por la complejidad inherente a las instalaciones aeroportuarias estepunto deberá ser validado y modificado en la fase de replanteo según lasnecesidades y requerimientos del gestor aeroportuario (AENA).

Página 31 de 55

3.- SISTEMA SOFTWARE

3.1.-) Software base

El Consorci de Transports de Mallorca apuesta por el software libre tanto en elsistema operativo base como en los lenguajes de programación. Para este proyecto,el CTM exige la siguiente configuración:

S.O: linux (redhat enterprise linux 6, Centos 6 o ubuntú server 14LTS)

Programación: J2EE en su versión jdk1.7.

Motor de reglas de negocio: Drools

Motor de Business Process Management: jBMP.

Motor de Business Intelligence: Pentaho

Servidor web: Apache 2.2

Servidor de aplicaciones: Jboss-6.1.0.GA + Tomcat 7 + EJB3

Base de datos: SQLServer si bien la implementación debe serindependiente de la plataforma.

Lenguaje de integración: XML sobre SOAP.

3.2.-) Arquitectura de la aplicación

La arquitectura del software es un elemento crítico para poder asegurar la flexibilidaddel mismo frente a cambios. A continuación se especifica la arquitectura general dela aplicación así cómo la tecnología a usar en cada uno de las partes:

Arquitectura, de como mínimo, 4 capas:

Presentación

Lógica de negocio

Persistencia de datos

Datos (base de datos relacional, tercera forma normal cómomínimo)

Se aceptaran frameworks de persistencia de datos (JPA,hibernate, etc.) , y frameworks de control y visualización (porejemplo: JSF, facelets, etc.), etc.

Página 32 de 55

Ningún elemento de la capa de presentación podrá accederdirectamente a la base de datos, siempre se deberá hacer a través dela lógica de negocio.

Debe separarse presentación de lógica, concretamente, debe podersecambiar cualquier elemento de la capa de presentación sin que estoimplique reprogramar ninguna parte de la lógica de negocio.

El sistema CDT utilizará para toda la capa de presentación tecnología WEB. No seaceptará que ninguna interfaz de usuario se desarrolle en arquitectura “cliente-servidor” ni mediante instaladores. La aplicación CDT deberá disponer de un módulofrontoffice y un backoffice para interactuar con el usuario (frontoffice) y para suconfiguración y administración (backoffice). A continuación se describe laarquitectura de ambos módulos.

3.2.1.-) Business Rule Management System + Business Process Management

Un aeropuerto es un sistema dinámico que cambia con el tiempo. Pueden cambiarlos accesos, sus dimensiones y los flujos a ellos asociados. Por tal motivo, se debeseparar la lógica de negocio de la definición semántica de los flujos, rutas y tránsitosdentro del aeropuerto. Todo ello debe realizarse mediante la utilización de un motorde reglas de negocio (Drools) para definir las reglas, los flujos y las alarmas,conjuntamente con un motor de procesos (jBMP) para lanzar los procesos una vezdetectada una alarma.

3.2.2.-) Nomenclatura de clases

Página 33 de 55

Página 34 de 55

Cada aplicación deberá poder convivir en el mismo servidor con otras de diferentesproveedores. Para permitir esta convivencia, cada aplicación deberá aislar elclasspath con un class-loader propio para evitar conflictos con las librerías de otros ysus propias clases.

En Jboss, esta funcionalidad se consigue definiendo un classloader propio tal y cómomuestra el siguiente ejemplo:

<jboss-app> <loader-repository> com.ctm.aplicacio:loader=aplicacion.ear <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </jboss-app>

3.2.3.-) Jerarquía de paquetes

Las clases de los objetos deberán estructurarse en aplicaciones y paquetes (estándarJ2EE). Todas las aplicaciones y paquetes deberán depender jerárquicamente deldominio:

com.ctm.*

Los caracteres válidos serán aquellos definidos por el estándar java: letrasmayúsculas y minúsculas del alfabeto inglés y números en posición no inicial.

Los nombres de la aplicación estarán siempre en minúsculas y deberán sersolicitados al CTM. Para el presente proyecto, el nombre de la aplicación principaldeberá ser:

com.ctm.CDT.*

Página 35 de 55

Los nombres de los paquetes estarán siempre en minúsculas y podrán ser bautizadosdentro del paquete a criterio de analistas y diseñadores.

3.2.4.-) Nomenclatura de clases y métodos

Las clases se llamaran con su primera letra en mayúsculas y el resto en minúsculas.Las clases formadas por varias palabras, utilizarán mayúsculas para cada inicial decada una de las palabras. Por ejemplo:

com.ctm.cdt.paquete.Clase com.ctm.cdt.paquete.ClaseDeVariasPalabras

Los métodos se llamaran con todas las letras en minúsculas incluida la inicial. Losmétodos bautizados con varias palabras utilizarán mayúsculas para las iniciales apartir de la segunda palabra.

com.ctm.cdt.paquete.Clase.metodo com.ctm.cdt.paquete.Clase.metodoDeVariasPalabras

3.2.5.-) Servicios de directorio del servidor de aplicaciones

El acceso al servicio de directorio (NamingFactory) se realizará siempre con losparámetros por defecto, asumiendo que los parámetros JNDI están correctamenteconfigurados por el CTM.

Página 36 de 55

Los servicios de directorio del servidor transaccional, identificaran cada EJB mediantesu nombre jerárquico completo, accediendo a las clases JAVA mediante dichonombre.

El acceso a otro tipo de recursos y servicios, tales como servicios de mail oconexiones a bases de datos, se realizaran a través de sus nombres jerárquicosdependiendo de la jerarquía de la aplicación, por ejemplo:

com.ctm.cdt.db.taxisdbcom.ctm.cdt.mail.cdtmail

3.2.6.-) JSP, Servlets y EJBs

Normalmente, la petición de un usuario será recogida por un servlet, el cuallocalizará el EJB adecuado a través del método lookup del servicio de directorio y lesolicitará las acciones pertinentes. Es imperativo, que bajo ninguna circunstancia, nilos servlets ni los jsps accedan a los pools de conexiones de base de datos de formadirecta. Toda conexión a la base de datos ha de ser siempre a través de los EJBs

Estos EJBs realizaran las operaciones necesarias a través del pool de conexión a labase de datos y devolverán la información al servlet. Este servlet analizará larespuesta y la redirigirá a la página JSP correspondiente. Esta página presentará lainformación al usuario.

En condiciones excepcionales, cuando la lógica de negocio sea prácticamente nula yno se deba mostrar una página u otra en función de las entradas del usuario, sepermitirá que el usuario envíe la petición http directamente a una página JSP.

3.2.7.-) Seguridad y robustez del software

Todo el software desarrollado, deberá estar asegurado contra los ataques máshabituales (cross-site scripting, sql injection, etc.). En particular, la parte debackoffice de la aplicación por ser la parte más sensible y con más capacidad deactuación sobre el comportamiento del sistema completo.

El acceso a módulos privados deberá realizarse siempre con usuario ypassword. Este usuario y password determinaran el perfil del usuario (medianteROLES) y por tanto las acciones que podrá llevar a cabo y las que tendrá prohibidas.La información del usuario y sus perfiles se obtendrán mediante un LDAPproporcionado por el CTM a través de JAAS. El formato de los ROLES será elsiguiente:

APP_ROLENAME, dónde APP sera el código de aplicación otorgado por la DGT y elROLENAME el nombre corto del ROLE. Por ejemplo:

• CDT_ADMCONF -> Podría ser el role que defina al administrador queconfigura el sistema CDT

• CDT_USUARIO -> Podría ser el role de usuario normal.

Los ROLES REALES se definirán en la fase de análisis del proyecto.

Página 37 de 55

3.3.-) Especificaciones funcionales

A continuación se describen una serie de funcionalidades básicas de la aplicaciónCDT. Debe tenerse en cuenta que esta breve descripción sólo es para dar una idea detamaño y que el detalle de la misma deberá realizarse en la fase de análisis delproyecto.

3.3.1.-) Mantenimientos (alta,baja, modificación)

• Elementos de estacionamiento, parkings, viales, zonas, etc.

• Elementos de captura de información (cámaras OCR, cámarasvideovigilancia).

• Maestros de vehículos (taxis, buses, limusinas, etc.)

• Gestión de usuarios (grupos de usuarios, usuarios, perfiles, permisos,accesos, etc.)

• y en general, cualquier otro mantenimiento que se requiera para el buenfuncionamiento de la aplicación.

3.3.2.-) Procesos de negocio

Implementación de los procesos de negocio expuestos en el apartado 1 del presente documento.

3.3.3.-) Definición de reglas y flujos

La aplicación debe disponer de la funcionalidad de poder definir reglas y flujos.Entendemos por regla la definición de una restricción de ser violada por un vehículo (por ejemplo: “un vehículo no puede pasar por la zona de llegadas más de 5 veces aldía”). Entendemos por flujos la definición de tránsitos entre elementos de detección,por ejemplo: “Entrada de X por Llegadas -> tránsito hasta salidas -> tránsito hastagasolinera -> salida aeropuerto”.

3.4.-) Especificaciones de integraciones

El sistema CDT deberá integrarse con diversos sistemas que le proveerán lainformación necesaria para su correcto funcionamiento. Igualmente, deberá permitir

Página 38 de 55

que otros sistemas adquieran información de sus datos de explotación (por ejemplo,la policía local).

• Maestros de taxis. Integración con las operadoras de taxis para recoger datosde matrículas, licencias y permisos de los vehículos que ellas gestionan. Estosvehículos tendrán diferentes permisos y atribuciones según la emisora a laque pertenezcan.

• Maestros de discrecionales. Integración con las empresas de transportediscrecional para recoger datos de matrículas, licencias y permisos de losvehículos que ellas gestionan. Estos vehículos tendrán diferentes permisos yatribuciones según la emisora a la que pertenezcan.

3.5.-) Especificaciones de interoperabilidad

El apartado de integraciones de software es un elemento crítico del sistema ya quesu éxito dependerá en buena medida de estas capacidades de integración. Debido aesta importancia, el CDT deberá disponer, como mínimo de las siguientesfuncionalidades:

• Debe ser capaz de exportar toda su funcionalidad a sistemas externos. Estaexportación deberá ser siempre a través de servicios web protegidos. Ningunaaplicación externa al CDT deberá poder acceder bajo ningún concepto a lacapa de datos del CDT. Toda la capa de servicios web deberá estar aseguradacontra el LDAP de la DGT. La DGT proveerá perfiles y roles específicos paraesta funcionalidad.

• Debe ser capaz de importar información de sistemas externos. Dado queestos sistemas externos pueden ser desde un trabajador autónomo a unagran empresa de transporte discrecional, deben implantarse diferentesmétodos de integración:

◦ Vía consumo de servicios web externos.

◦ Vía entrada manual de información mediante un formulario web.

◦ Vía consumo de ficheros de texto delimitados CSV.

3.6.-) Modularidad en la gestión

El software diseñado ha de permitir la modularidad en la gestión. La DGT entiendepor modularidad, la capacidad de delegar el control de un grupo de elementos delproyecto a terceros para su gestión desagregada. Por ejemplo, se deberá poderentregar el control de uno o varios elementos hardware a un responsable y el resto aotro. Se deberá permitir también dar de alta nuevos elementos hardware yasignarlos a operadores diferentes, por ejemplo, otros conjuntos cámara-OCR, odefinir otra zona de carga y descarga de viajeros. Toda esta operación delegada debe

Página 39 de 55

poder hacerse en remoto, funcionalidad que al ser una aplicación WEB cumpleimplícitamente.

3.7.- Mejoras de software

Los anteriores apartados describen la solución a entregar por el adjudicatario. El CTMha identificado los módulos obligatorios a entregar que se resumen a continuaciónjunto con las mejoras que se valoran en el apartado de software.

Módulos obligatorios:

• Portal del usuario de la aplicación◦ Alarmas generadas◦ Acceso al módulo de informes

• Portal del administrador◦ Mantenimientos◦ Gestión usuarios. Permisos de aplicación◦ Gestión del motor de reglas de negocio

• Módulo de integraciones◦ Maestros de vehículos de servicio público◦ Capa de exportación de información en webservices◦ Capa de importación de información en webservices

• Módulo de detección de matrículas (OCR)

Módulos valorados como mejora:

• Módulo de reporting y business intelligence ◦ Paquete de 10 informes a definir por el CTM desarrollados sobre Pentaho◦ Instalación y configuración de la suite Pentaho

• Desarrollo de la APP para la recepción de alarmas y consultas de estado de unvehículo en sistema android.

• Desarrollo e implantación de jBMP para la generación de tareas en base aalarmas◦ Instalación y configuración de la suite jBMP◦ Definición de 5 procesos de negoció a definir por el CTM

Página 40 de 55

4.-) MANTENIMIENTO

El mantenimiento de un sistema complejo es uno de los principales factores quecontribuyen al éxito o al fracaso de un proyecto. Por su criticidad, el CTM asumiráinternamente el mantenimiento de primer nivel de todos los equipossubministrados en este pliego, siendo responsabilidad del adjudicatario elmantenimiento de segundo nivel y el suministro de recambios. En consecuencia,cuando en este pliego se hace referencia a “mantenimiento” quiere decir, si no seindica lo contrario, mantenimiento de segundo nivel.

4.1.-) Plan de Operación y Mantenimiento

Para este modelo de explotación del proyecto se debe definir cuidadosamente larelación entre el adjudicatario y el licitador y establecer de forma inequívoca susáreas de responsabilidad. Esta información se deberá sintetizar en el “Plan deOperación y Mantenimiento”. En él se incluirán todas las tareas para la correctaprovisión del servicio y suministro y su mantenimiento posterior. La redacción deeste documento deberá realizarla el adjudicatario en paralelo con la fase deimplantación y permitirá definir las mejores prácticas, sus procedimientos y flujos deinformación para gestionar correctamente el proyecto en fase de explotación (y portanto, mantenimiento).

El documento “Plan de Operación y Mantenimiento” contendrá también la forma derelación entre el CTM y el adjudicatario que como mínimo deberá cumplir losiguiente:

• Interlocución nominal. En horario laborable, el acceso a cualquier servició deconsulta/mantenimiento/soporte se hará a través de interlocutoresnominalmente identificados. No se admitirán centros de soporteexternalizados como call-centers de soporte.

• En horario no laborable se dispondrá de un método rápido y efectivo decontacto para las emergencias.

• Interlocución presencial para los casos en los que así se solicite.

• Designación de interlocutores cualificados, con suficiente disponibilidad ycapacidad de actuación, influencia y decisión dentro de la empresaadjudicataria.

Además, en dicho plan, se deberán especificar todos y cada uno de los trabajos arealizar para un correcto mantenimiento de los equipos y programas, junto con losrecursos de primer nivel (CTM) cómo de segundo nivel (adjudicatario) necesariospara llevarlos a cabo siguiendo las siguientes premisas:

• Funcionamiento del sistema: 24x7x365

• Horario del soporte: 8x5 + móvil emergencias

Página 41 de 55

• Criticidad del sistema: media. Tiempo de respuesta de 24horas frente aaverías.

• Número máximo de horas-hombre necesarias para mantener el sistema enprimer nivel: 240h, que corresponden a 1 recurso a 20 horas /mes.

Este límite debe incluir tanto el mantenimiento preventivo, como el correctivo. No seaceptaran ofertas para este proyecto con unas necesidades de mantenimientosuperiores a las 240 horas-hombre / año, considerando que una tecnología quenecesite más de esa cantidad de horas-hombre de mantenimiento no cumple con losSLA's exigidos en este pliego.

5.1.1.-) Formación

Dentro del plan de operación y mantenimiento, el adjudicatario deberá diseñar,documentar y realizar el plan de formación para el mantenimiento. Con él, se deberáformar al personal que realizará el mantenimiento de primer nivel en todos losconocimientos necesarios para garantizar el correcto estado del sistema en todomomento. Deberá planificar como mínimo los siguientes items formativos:

• Procedimientos de mantenimiento y sus procesos asociados.

• Manuales de mantenimiento.

• Cursos de formación presenciales

El número y cantidad de estos elementos formativos deberán ser consensuados porel CTM y el adjudicatario, con el objetivo de formar al más alto nivel a los recursosdestinados al mantenimiento de primer nivel.

5.1.2.-) Mantenimiento preventivo

Dentro del plan de operación y mantenimiento, el adjudicatario será el responsablede elaborar el plan de mantenimiento preventivo que garantice el correctofuncionamiento de todo el equipamiento subministrado en este proyecto.

Dicho plan, será validado y negociado con el CTM. Una vez acordados los términosdel mismo, el CTM iniciará la gestión del mantenimiento preventivo. Así mismo, elCTM implantará una herramienta de gestión que permita al CTM y al adjudicatario elseguimiento exhaustivo de las tareas de mantenimiento.

5.1.3.-) Mantenimiento correctivo

El adjudicatario será el responsable de elaborar el plan de mantenimiento correctivoque garantice la correcta reparación de todo el equipamiento subministrado en esteproyecto.

Página 42 de 55

Dicho plan, será validado y negociado con el CTM. Una vez acordados los términosdel mismo, el CTM iniciará la gestión del mantenimiento correctivo de primer nivel.Así mismo, el CTM implantará una herramienta de gestión que permita al CTM y aladjudicatario el seguimiento exhaustivo de las tareas de mantenimiento.

5.2.-) Recambios

En el presente concurso se distinguen dos tipos de recambios: a cargo deladjudicatario y a cargo del CTM.

A cargo del adjudicatario:

• Recambios necesarios para cubrir las reparaciones/substituciones durante elperíodo de garantía

• Recambios necesarios para cubrir la “mortalidad infantil”

A cargo del CTM:

• Recambios necesarios una vez terminado el período de garantía

• Recambios necesarios para cubrir las reparaciones/substituciones por causasno imputables al adjudicatario: vandalismo, causas naturales, etc.

5.2.1.-) Stock inicial por garantía y SLA

El adjudicatario deberá proporcionar un stock inicial de recambios de todas las piezassusceptibles de requerir un mantenimiento correctivo. Este stock esta destinado adisminur los tiempos de no disponibilidad y reparación, mejorando sustancialmentelos SLAs del proyecto, cubriendo además el inicio del período de garantía.

El adjudicatario deberá proporcionar sin coste un elemento de cada tipo susceptiblede requerir un mantenimiento correctivo. No se pide un equipo completo (un postede detección) sino un elemento de cada uno de los que forma cada sistema (unacámara, un switch, un bridge WIFI, etc.)

5.2.2.-) Recambios a cargo del CTM

El stock inicial de recambios correrá a cargo del adjudicatario y está incluido en elprecio de licitación. Futuras compras de recambios serán por cuenta del CTM en basea los precios unitarios de los mismos que el adjudicatario esta obligado a entregarjunto con su oferta económica (ver apartado de “documentación”).

Página 43 de 55

5.3.-) Desplazamientos para mantenimiento de segundo nivel

En caso de ser necesario, durante el período de garantía, el adjudicatario deberárealizar desplazamientos para mantenimiento de segundo nivel in-situ. Estosdesplazamientos, sólo deben realizarse cuando el mantenimiento de primer nivel y elde segundo nivel remoto no hayan resultado efectivos.

5.4.-) Herramientas de gestión

En el siguiente punto se definen los SLAs (Service Level Agreements) mínimos que laoferta del adjudicatario debe cumplir en cuanto a calidad del servicio y componentes.Debido a que será el CTM el responsable del mantenimiento de primer nivel deberáproporcionar a todas las partes una herramienta de gestión de averías ymantenimientos.

Esta herramienta software será con arquitectura WEB, accesible bajo contraseñadesde cualquier dispositivo conectado a la red. Esta herramienta, deberá poderregistrar, seguir, imputar, asignar, cerrar y controlar todas y cada una de lasincidencias derivadas del mantenimiento descrito (preventivo, predictivo, correctivo).Dicha herramienta deberá almacenar en una base de datos propiedad del CTM todaesta información y deberá tener la capacidad de extraer informes automáticos decumplimiento de SLA's (tiempos de respuesta, tiempos de resolución, costes,materiales de reparación usados, etc.) Toda la información generada y la propiaherramienta serán propiedad de CTM, incluso después de finalizar el contrato.

El adjudicatario se compromete a usar dicha herramienta para las incidencias desegundo nivel y como base de datos autoritativa para el cálculo del grado decumplimiento de los SLAs.

Página 44 de 55

4.-) CALIDAD DE SERVICIO. SLAs MíNIMOS EXIGIDOS

Al ser este proyecto un elemento estratégico en la misión del CTM, se hace necesarioestablecer un nivel de servicio adecuado para afrontar las posibles incidencias del díaa día. En este apartado se definen los parámetros aceptables de calidad y servicio deobligado cumplimiento por parte del adjudicatario.

4.1.-) SLAs de tiempo de implantación

El proyecto que se describe en este pliego tiene un período de desarrollo, fabricación,pruebas e implantación máximo de 6 meses desde el momento de la adjudicación.No obstante, el adjudicatario puede mejorar este plazo. Para controlar los plazos deimplantación se definen las siguientes violaciones:

• Leve: si la implantación se desvía entre un 5% y un 10% del plazo máximoofertado por el adjudicatario.

• Grave: si la implantación se desvía entre un 10% y un 20% del plazo máximoofertado por el adjudicatario.

• Crítica: si la implantación se desvía mas de un 20% del plazo máximoofertado por el adjudicatario.

El desvío aquí especificado se calculará en base a los días naturales de retrasocontando que cada mes natural tiene 30 días naturales. Por ejemplo, si suponemosun plazo máximo de 6 meses un desvío de un 10% se calcularía cómo un desvío de0,6 meses naturales.

4.1.1.-) Garantías de tiempo de implantación

En el caso de incumplimiento del tiempo de implantación, se aplicará la siguientepenalización:

• Menos de un 5% Sin penalización→

• Entre un 5% y un 10% Penalización de un 5% sobre el montante total de la→oferta del adjudicatario

• Entre un 10% y un 20% Penalización de un 10% sobre el montante total de→la oferta del adjudicatario

• Mas de un 20% Penalización de un 15% sobre el montante total de la→oferta del adjudicatario

4.2.-) SLAs de suministro y reparación

Página 45 de 55

Para garantizar el correcto funcionamiento y mantenimiento de los sistemas licitadosse hace necesario establecer los SLAs para el suministro de recambios y lareparación de componentes averiados. Estos tiempos máximos permitirán definir losstocks de seguridad de los componentes más susceptibles de averías.

Nota: cuando se habla de horas y días se entiende siempre naturales, en casoalguno se podrán interpretar como horas y/o días laborables.

Para controlar los plazos de implantación se definen los siguientes límites:

• Leve: si una reparación o suministro se desvía entre un 10% y un 30% delplazo máximo ofertado por el adjudicatario.

• Grave: si una reparación o suministro se desvía entre un 30% y un 50% delplazo máximo ofertado por el adjudicatario.

• Crítica: si una reparación o suministro se desvía mas de un 50% del plazomáximo ofertado por el adjudicatario.

El desvío aquí especificado se calculará en base a los días naturales de retrasocontando que cada mes natural tiene 30 días naturales. Por ejemplo, si suponemosun plazo máximo de 1 mes un desvío de un 30% se calcularía cómo un desvío deuna semana y media natural.

4.2.1.-) Garantías de suministro y reparación

En el caso de incumplimiento de los SLAs de suministro y reparación decomponentes, definiremos las siguientes garantías teniendo en cuenta que:

• Una incidencia leve cuenta cómo una incidencia

• Una incidencia grave cuenta cómo 3 leves

• Una incidencia crítica cuenta cómo 5 leves

Así pues, si tenemos:

• Entre 0 y 6 incidencias 25% de los costes de mantenimiento de segundo→nivel para esa reparación o coste del suministro (recambio)

• Entre 6 y 12 incidencias 50% de los costes de mantenimiento de segundo→nivel para esa reparación o coste del suministro (recambio)

• Más de 12 incidencias 100% de los costes de mantenimiento de segundo→nivel para esa reparación o coste del suministro (recambio)

4.3.-) SLA's de calidad por equipo

Página 46 de 55

El conjunto de equipos no pueden superar en caso alguno el 30% de averías por añonatural. Es decir, si suponemos un parque de 10 equipos como máximo 3 de ellaspueden sufrir una avería en un año natural.

Se excluyen las pérdidas de servicio debidas a hechos no imputables al sistema ensí (vandalismo, fenómenos atmosféricos, negligencia, etc.)

Además de este límite global para el proyecto se definen SLAs de averías por equipoque ayudaran a establecer un nivel de calidad de cada equipo en particular. Parapoder cuantificar correctamente los SLAs definiremos tres tipos de situaciones encaso de averías por máquina:

• Leve: si un equipo determinado ha tenido entre 2 y 6 averías/año que hayanimposibilitado dar servicio.

• Grave: si un equipo determinado ha tenido entre 6 y 12 averías/año quehayan imposibilitado dar servicio.

• Crítica: si un equipo determinado ha tenido más de 12 averías/año que hayanimposibilitado dar servicio.

4.3.1.-) Garantías de calidad por equipo

En el caso de incumplimiento de los SLAs de calidad de los equipos subministradosdefiniremos las siguientes garantías teniendo en cuenta que:

• Una incidencia leve cuenta cómo una incidencia

• Una incidencia grave cuenta cómo 3 leves

• Una incidencia crítica cuenta cómo 5 leves

Así pues, si tenemos:

• Entre 0 y 6 incidencias 5% del coste del equipo averiado→

• Entre 6 y 12 incidencias 10% del coste del equipo averiado→

• Más de 12 incidencias 20% del coste del equipo averiado→

En el caso de tener más de un 30% del parque averiado en un año natural eladjudicatario deberá comprometerse a estudiar en profundidad las causas yproponer soluciones de diseño o sustitución de los equipos por unos más fiables.

Página 47 de 55

9.-) HITOS DEL PROYECTO. GARANTÍA Y MANTENIMIENTO

9.1.-) Plazo de ejecución

Para llevar a cabo las tareas especificadas al presente pliego se definen los siguienteshitos y plazos.

Debido a que las tareas de programación y fabricación se pueden hacer en paraleloel CTM designa un tiempo máximo de ejecución del contrato de 6 meses a partir dela adjudicación del presente concurso. Con los siguientes hitos parciales:

• Entrega de 1 piloto de un detector de matrículas a los 2 meses de laadjudicación del contrato.

• Entrega del resto de detectores a los 5 meses del contrato

• Entrega de la solución de identificación de vehículos a los 6 meses de laadjudicación

9.2.-) Garantía

La garantía para todos los suministros y servicios es de 2 años a contar desde laentrada en servicio del mismo.

9.3.-) Mantenimiento

El mantenimiento de segundo nivel para todos los suministros y servicios es de 2años a contar desde la entrada en servicio del mismo.

Página 48 de 55

DOCUMENTACIÓN

La empresa adjudicataria se compromete a documentar completamente todo elproyecto, esto incluye:

• Levantar planos de instalación de todo el equipamiento hardware, red decomunicaciones, red de potencia, etc. Esto incluye todos los esquemas deinstalación del equipamiento dentro los bastidores.

• Arquitectura de sistemas hardware de la solución ofrecida

• Especificaciones, documentación y manuales de acceso, control yprogramación de todos los elementos hardware. Esto incluye, manual deusuario, manual del programador, controladores software, drivers, part-numbers de todos los componentes y precios unitarios de los mismos.

• Especificaciones de las operaciones de mantenimiento(preventivas/correctivas) más comunes. Precio estándar de cada una de estasoperaciones de mantenimiento y precio/hora aplicado por el adjudicatario alCTM.

• Arquitectura de la aplicación, árbol de menús, protocolos, etc.

• Entrega del código fuente de toda la aplicación y módulos auxiliares.

• Manual y documentación de cualquier software instalado (controladores,librerías, sistemas operativos, etc.), así como el mismo software en apoyoóptico.

• Contrato de mantenimiento. Incluirá condiciones detalladas y periodo devalidez.

• Contrato de apoyo. Incluirá condiciones detalladas y periodo de validez.

• Y a entregar esta documentación al responsable del proyecto designado por elCTM antes de la finalización de la instalación

• Documento de precios unitarios de los recambios. Tiempo garantizado destock y suministro para cada tipo de repuesto. Costes unitarios de lasoperaciones más comunes de mantenimiento, cuantificadas en horas-hombrey precio-hora. Política de actualización de precios anual por los recambios ypor las horas-hombre.

Toda esta documentación se ha de entregar al CTM en soporte óptico y una copiaimpresa.

Página 49 de 55

PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD

A.- Propiedad intelectual

El CTM tiene la titularidad, tanto en el caso de finalización del contrato comode resolución anticipada, de la propiedad intelectual en exclusividad y a todos losefectos de todas las entregas, documentación, software y código fuente elaboradosen la ejecución del contrato, sin perjuicio del derecho inalienable de autoría quecorresponde al adjudicatario. En consecuencia, el CTM puede reproducir, modificar ydivulgar total o parcialmente, todas las entregas, sin que el adjudicatario se puedaoponer.

El adjudicatario acepta esta titularidad del CTM y se compromete a respetarlay no hacer ningún uso, comunicación o divulgación de ninguna de las entregas delcontrato (excepto el código fuente generado, que el adjudicatario podrá reutilizarcuando considere oportuno, siempre y cuando no implique divulgar informaciónconfidencial del CTM), ya sea de forma total o parcial, directa o indirectamente, sinla autorización expresa del CTM, y renuncia expresamente a cualquier acción oreclamación legal, profesional, económica o de cualquier otro tipo.

B.- Confidencialidad

De acuerdo con lo establecido en el artículo 124 y la disposición adicional 31 de laLCSP, el adjudicatario se compromete a la más estricta y absoluta confidencialidad yreserva sobre la información a la cual tenga acceso y conocimiento en virtud de laejecución del contrato y, en especial, sobre los datos de carácter personal, que nopuede copiar ni utilizar para otra finalidad diferente a la prevista en este pliego y quedebe devolver o destruir completamente a la finalización del contrato.

Página 50 de 55

10.-) ASPECTOS GENERALES Y CONDICIONES ECONÓMICAS

Los siguientes criterios generales se aplicarán a este contrato:

10.1.-) IMPORTE ECONÓMICO

El importe máximo del contrato no superará los 150.000€ IVA excluido.

10.2.-) FORMA DE PAGO

La forma de pago se describe en el pliego administrativo.

10.3.-) PERIODO DE GARANTÍA

El adjudicatario se compromete a un periodo de garantía de 2 años a partir de lacertificación por parte del CTM del tercer y último hito del proyecto, sin ningún tipode costes asociados, de todo el equipamiento y mano de obra de segundo nivel enlas instalaciones del CTM. El CTM acepta tener un stock de reserva de equipos yelementos auxiliares y que las reparaciones se realicen por el personal demantenimiento de primer nivel, siempre y cuando se cumplan las condiciones denivel de servicio (SLA’s). En este caso, todos los costes de envío del equipamientoserán a cargo del adjudicatario), y cubrirá durante este periodo todos los defectosde diseño, desarrollo e instalación. Se valorará la ampliación de este periodo degarantía.

Durante el periodo de garantía, el adjudicatario se compromete al mantenimiento desegundo nivel del hardware suministrado, y en caso de incidencia se compromete ala reparación o sustitución de cualquiera de los componentes objeto de avería,incluyendo todos los costes asociados (por ejemplo, el envío del equipo a lasdependencias del adjudicatario y si fuera necesario, al desplazamiento de técnicosdel adjudicatario). Durante el periodo de garantía, el adjudicatario se compromete almantenimiento de los programas y aplicaciones suministradas, y en caso deincidencia se compromete a la implantación de la solución de cualquiera de loscomponentes objeto sin coste asociado.

10.4.-) CONTRATOS DE MANTENIMIENTO

Los costes de mantenimiento de segundo nivel del hardware y softwaresuministrados durante los cuatro primeros años quedan incluidos dentro del contrato.A partir del cuarto año, se deberán indicar los datos relativos al servicio de

Página 51 de 55

mantenimiento y soporte de segundo nivel una vez acabado el periodo de garantíaofrecido:

• Número de años en que se compromete el suministrador a dar soporte ymantenimiento una vez acabado el periodo de garantía. Mínimo 10 años.

• Precio global del mantenimiento anual (de segundo nivel) y número de añosque se mantiene invariable el precio anterior, o en su caso, el coeficiente decrecimiento interanual.

• Tiempos de respuesta del servicio. SLAs que regirán los contratos demantenimiento. Nunca podrán ser inferiores a los explicitados en este pliegopara el período de garantía, excepto acuerdo por escrito con entre el CTM y eladjudicatario.

• Las condiciones ofrecidas por este concepto no obligarán al CTM a efectos decontratos de mantenimientos futuros, aunque una vez concluido el periodo degarantía la administración podrá contratar el servicio de mantenimiento deal adjudicatario.

• En la oferta se detallará un responsable del equipo de mantenimiento y elprotocolo de actuación por incidencias, así como su grado de disponibilidady, caso que no se encargue directamente la propia empresa adjudicataria, larazón y ubicación de la empresa de mantenimiento.

10.5.-) MÉRITOS ADICIONALES

Se valorarán especialmente las siguientes características:

• Ampliación de las características funcionales y técnicas del software y el hardware ofrecido

• Apoyo in-situ para el mantenimiento de los equipos de detección dentro el periodo de garantía.

• Ampliación del periodo de garantía y mantenimiento incluido.

• Facilidad por modificar y ampliar la funcionalidad del software desarrollado

10.6.-) MODELO NORMALIZADO DE LAS OFERTAS

En la valoración de las ofertas se tendrá en cuenta la claridad de la exposición,además de la calidad técnica y la adecuación a los objetivos deseados.

El licitador debe presentar una oferta adaptada al siguiente esquema de contenidos:

Capítulo I: Descripción general de la solución propuesta.

• Arquitectura de la solución.

Página 52 de 55

• Descripción de las características funcionales y técnicas del hardware ofrecido.

• Descripción de las características funcionales y técnicas del software ofrecido.

• Diseño de la solución propuesta tanto software como hardware

Capítulo II: Equipamiento y funcionalidades ofrecidos. Gestión y planificación de losservicios.

• Recursos humanos destinados al proyecto. Perfiles y organización.

• Propuesta de planificación del proyecto. Entrega de hardware y entrega desoftware.

• Plan de formación e implantación de los equipos.

• Propuesta garantizaba y mantenimiento incluido.

• Propuesta de mantenimientos posteriores.

Capítulo III: Prestaciones superiores o complementarias a las exigidas.

En este apartado se ha de incluir cualquier mejora sobre el Pliego y todas lasinnovaciones incluidas en la oferta y que se consideren destacables para la mejoradel proyecto en general.

Capítulo IV. Oferta Económica

El licitador ha de especificar, en euros, la cantidad total del proyecto, según elmodelo descrito en el Pliego de cláusulas administrativas.

Asimismo, de forma opcional, se podrá presentar un presupuesto detallado para cadauna de las partidas destinadas al proyecto.

10.7.-) CRITERIOS DE VALORACIÓN

En este apartado se muestra la tabla de criterios que seguirá el Servicio deInnovación Tecnológica del CTM para evaluar las ofertas, indicando el peso máximode cada criterio.

No se especifica un apartado de “Mejoras” porque las mismas se evalúan dentro dela calidad de la oferta técnica. A continuación se define el concepto “Mejora”.

Definición de “Mejora”

Se entiende por Mejora la ampliación de las funcionalidades, cantidades ocaracterísticas de los equipos, programas o servicios que cumplan los siguientescriterios:

Página 53 de 55

• Se hallen descritas en este pliego bajo el epígrafe de “se valorará”.

• No se hallen descritas en este pliego pero tengan un valor tangible, medible yobjetivo para el CTM.

Ninguna otra Mejora no incluida en los dos anteriores preceptos será valorada.

Criterio Puntuación

1 Estudio global de proyecto y de la arquitectura del hardware ysoftware a implementar. Valoración y calidad de los componentes ymódulos hardware/software presentados.

30

2 Oferta económica 60

3 Mejoras adicionales a las condiciones mínimas del hardware,software y servicios ofrecidos

10

Total criterios objetivos (2) = 60%.Total criterios subjetivos (1 + 3): 30 + 10 = 40%.

1.- Estudio global del proyecto y de la arquitectura del hardware ysoftware a implantar. (30 puntos)

Para la evaluación de la solución propuesta se tendrá en cuenta:

Funcionalidades ofrecidas.

Arquitectura propuesta y capacidad del hardware ofrecido.

Flexibilidad de crecimiento, modificación.

Solución a las demandas funcionales, técnicas y de accesibilidad

Características, capacidad de ampliación, facilidad de aplicación de nuevoselementos hardware y flexibilidad en la configuración del software ofrecido.

Documentación a entregar

2.- Oferta económica (60 puntos)

Comparación económica de las ofertas. Se otorgarán 60 puntos a lo mejor ofertaeconómica y al resto se las puntuará proporcionalmente aplicando la siguientefórmula:

Punto(i)= (%[VO*min+(VL*max-VO(i))]/VL*max)*60.

Siendo:

Página 54 de 55

iPunto la puntuación otorgada a la empresa “y”;

minVO el valor ofrecido mínimo de entre todas las empresas concursantes;

maxVL el valor máximo de puja;

iVO el valor ofrecido por la empresa “y”.

3.- Mejoras adicionales a las condiciones mínimas del software, hardware yservicios (10 puntos)

Mejoras aportadas según la definición de "mejora" de este pliego

Página 55 de 55