INDICE

CAPITULO PRIMERO 3

SUBSISTEMA DE CAMARAS DE SEGURIDAD ESTATALES

A. ESTÁNDARES TÉCNICOS DEL CENTRO

AUTOMATICO DE DESPACHO 3

I. Estándares técnicos que debe cumplir la aplicación (software) 3

II. Estándares de desarrollo de software CADI y servicio de integración. 3 7.1. Módulo de gestión de seguridad 9 7.2. Módulo de atención, despacho y supervisión 12 7.3. Módulo de administración de datos operacionales 17 7.4. Módulo de administración del mapa 21 7.5. Módulo de Análisis de Datos Gerenciales

Desempeño y reportes 22 7.6. Plataforma de integración 26 7.7. Módulo de monitorización y auditoria 27

III. Estándares del servicio de integración e implementación 27 IV. Otros ítems a considerar (especificaciones libres) 31

B. ESTANDARES TÉCNICOS DEL SISTEMA DE MONITOREO

Y VIGILANCIA 31

I. Estándares para Cámaras de video vigilancia IP PTZ, tipo DOMO y FIJAS. 31

II. Estándares para la Plataforma de Procesamiento y Almacenamiento de Video 33

III. Estándares para el TV WALL. 34 IV. Otros ítems a considerar (estándares recomendados) 35

C. ESTANDARES TÉCNICOS DE LA RED DE COMUNICACIÓN. 37

I. Redes Inalámbrica banda ancha. 37 II. LTE 4G 38 III. RED DE FIBRA ÓPTICA. 39 IV. Redes Hibridas del tipo inalámbrica banda ancha y fibra

óptica más cable FTP cat6a blindado o superior 39 V. Otros ítems a considerar (especificaciones libres) 39

D. ESTANDARES TÉCNICOS PARA RADIO COMUNICACIÓN

TRONCALIZADA Y MISIÓN CRÍTICA 40

I. Condiciones generales 41 II. Estándares mínimos para el diseño de la red. 42 III. Estándares funcionales de la red 46

IV. Estándares de terminales portátiles. 46 V. Estándares técnicas de terminales en vehículos. 47 VI. Entrenamientos. 48

E. ESPECIFICACIONES TÉCNICAS MÍNIMAS DE GARANTÍA

Y SOPORTE TÉCNICO 48

I. Implementación 48

II. Garantía 48 III. Soporte técnico 49

CAPITULO SEGUNDO

SUBSISTEMA DE CAMARAS DE SEGURIDAD PRIVADAS

A. ESTÁNDARES TÉCNICOS DE CÁMARAS DE VIDEO VIGILANCIA. 49

B. ESTÁNDARES DE PLATAFORMA DE PROCESAMIENTO Y ALMACENAMIENTO DE VIDEO. 50

ANEXO I 51

4

ESTANDARES PARA EL DESARROLLO DE TECNOLOGIAS DE

MONITOREO Y VIGILANCIA ELECTRÓNICA EN SEGURIDAD

CIUDADANA

CAPITULO PRIMERO

SUBSISTEMA DE CAMARAS DE SEGURIDAD ESTATALES

A. ESTÁNDARES TÉCNICOS DEL CENTRO AUTOMATICO DE DESPACHO I. Estándares técnicos que debe cumplir la aplicación (software)

1. Solución diseñada para la automatización y gestión eficiente del Centro

Automático de Despacho Integrado. 2. Sólida arquitectura abierta que proveerá flexibilidad única que se adaptará

a las necesidades específicas de la Policía Boliviana. 3. Cubrir necesidades de llamadas entrantes y marcación automática en todas

sus modalidades, e incorporar conectores y potentes API´s que facilitan la integración de aplicaciones y canales alternativos de comunicación, adaptándose ágilmente a las tecnologías y requerimientos de la Policía Boliviana.

4. Aplicaciones estables, de sencillo manejo para el usuario. 5. Garantía de dos 2 años, incluye actualizaciones y/o modificaciones

referidas a la integración de nuevos dispositivos. 6. Aplicaciones con código abierto para realizar modificaciones posteriores, de

preferencia que el software desarrollado sea libre. En caso que fuese software propietario, la licencia debe estar cubierta por la empresa proveedora con duración permanente.

7. Documentación de desarrollo para todas las aplicaciones (modelo relacional, UML, etc.).

8. Actualización automática de informaciones de sistemas, subsistemas y módulos. En caso de ser software propietario, la licencia debe permitir contar con actualizaciones permanentes.

II. Estándares de desarrollo de software CADI y servicio de integración.

1. Garantizar la integración de sistemas de seguridad existentes y futuros

independientemente del proveedor, marca, fabricante o tipo de licencia que haya sido desarrollado. Debe poseer funcionalidad geoespacial como una plataforma integrada, para monitorear, controlar y responder a alarmas e incidentes.

2. Para el desarrollo de software es importante consolidar una plataforma sólida en todos los casos. Es por eso que se debe incluir en los requerimientos la Prueba de Concepto, cuyo objetivo principal es la verificación y la comprobación de las características del sistema propuesto

5

y garantizar que este responda adecuadamente al requerimiento. La prueba de concepto viene adjunta en el Anexo 1.

3. Debe poseer funcionalidad de interacción con los siguientes sistemas y subsistemas: 3.1. Sistema de Atención y Despacho, con funcionalidad de mapa

integrado; 3.2. Integración de la plataforma del sistema integrado de monitoreo PSIM

con los sistemas ya existentes y nuevos sistemas que serán adquiridos en el futuro, incluso utilizando la plataforma de mapa integrado;

3.3. Sistemas de alarmas, incluyendo las alarmas de incendio y de sistemas de control de acceso;

3.4. Sistemas de detección de intrusión (perímetro); 3.5. Sistemas de gestión de video basados en IP y CCTV, con capacidad

de video analítico; 3.6. Sistemas de Notificación de Emergencia y dispositivos de recepción

de mensajes; 3.7. Sistemas de localización automática de vehículos (AVL), que incluyan

sistemas de equipos con GPS; 3.8. Bases de datos locales, nacionales como departamentales; 3.9. Sistemas de Atención y Despacho de agencias externas; 3.10. Sistemas de email con soporte MAPI; 3.11. Sistemas Móviles con funcionalidades de mapa. (IOS y/o Android) 3.12. Sistemas de semaforización; 3.13. Otras integraciones y sistemas existentes;

4. Incorporar tecnologías actuales y componentes de sistemas abiertos que están disponibles comercialmente para software y hardware, incluyendo gestores de bases de datos relacionales todos con licencia libre o licencia de propietario, la cual debe estar cubierta por la empresa proveedora con duración y actualizaciones permanentes

5. El sistema debe basarse en productos de aplicaciones comerciales. La solución debe trabajar soportada por uno o más firewalls y subredes en la estructura de red existente. Debe prever acceso remoto al sistema, con todas las funcionalidades de comandos y consultas, además de funcionalidad de monitoreo de estado de incidentes y recursos.

6. El Sistema de Comando y Control debe tener las siguientes características técnicas: 6.1. Sistema multi-jurisdiccional que provea apoyo a las operaciones de

multi-agencias, incluyendo la capacidad para compartir datos con los sistemas de atención y despacho de sitios externos.

6.2. El sistema debe proveer módulos integrados que ofrezcan una interfaz gráfica consistente y estandarizada, que reduzca los requerimientos de entrenamiento de los usuarios. Todas las aplicaciones que componen el sistema deben ser basadas en estándares GUI (Interfaz Gráfica de Usuario).

6.3. Permitir mayor eficiencia en las operaciones, eliminando la necesidad de reintroducir datos en más de un sistema o aplicación.

6

6.4. Capacidad de acceder múltiples sistemas a través de una única estación de trabajo.

6.5. Envío automático de datos para sistemas y bancos de datos externos, con los permisos de seguridad necesarios.

6.6. El sistema debe permitir la consulta en bases de datos internas y externas (SEGIP, RUAT, sistemas el OEP, Antecedentes Policiales, Antecedentes Judiciales y otros).

6.7. Capacidad de acceso remoto con los permisos de seguridad necesarios.

6.8. Permitir la distribución automática de información de un sistema, subsistema o módulo para todos los otros sistemas, subsistemas, o módulos.

6.9. El sistema debe poseer un formato de intercambio de datos estandarizado que permita la importación y exportación de datos para el propio sistema de comando y control o para sistemas relacionados;

6.10. Cambio y configuración de datos compartidos y sistemas involucrados previa asignación de roles.

6.11. Actualización automática de información de sistemas, subsistemas y módulos a través del módulo de gestión de seguridad;

6.12. Permitir la integración de sistemas GIS/Mapeo y Localización Automática de Vehículos (AVL), y equipos que cuenten con GPS en unidades de campo;

6.13. La presentación de datos e informaciones para los usuarios debe hacerse de una interfaz limpia, simple y fácil de usar.

6.14. Capacidad de generar informes de operación y de datos en formato especificado por el usuario y con los parámetros seleccionados por el usuario;

6.15. Permitir a los administradores del sistema personalizar y modificar las interfaces de usuario para adecuarse a los procedimientos operacionales estándar;

6.16. Debe estar preparado para operar con sitios redundantes (centro principal y centro de respaldo) para Failover remoto y recuperación de desastres;

6.17. El sistema debe ser modular y flexible, capaz de soportar expansiones futuras;

6.18. El sistema debe operar en la red de datos (LAN. WAN, WLAN y/o Internet) existente, sin afectar el desempeño de la red. En alternativa, el sistema podrá operar en una subred separada, con acceso a los hardware y software de terceros necesarios;

6.19. Poseer kit de desarrollo (SDK) o API que permita a los sistemas externos integrarse al módulo de gestión de seguridad. Las API o SDK deben ser compatibles con el sistema operativo instalado Windows/Linux;

6.20. El sistema debe garantizar una muy alta disponibilidad. Este nivel de disponibilidad y confiabilidad debe ser garantizado a través de redundancia y/o tolerancia a fallas (FAILOVER).

7

6.21. El sistema debe soportar seguridad en multiniveles para restricción de acceso y control de funcionalidades;

6.22. Todos los accesos al sistema deben ocurrir a través de autentificación de por lo menos en sistemas basados en algo conocido (usuario y contraseña). El sistema debe permitir que los operadores puedan modificar datos de autentificación.

6.23. Los administradores del sistema deben poseer control de reglas de complejidad de contraseñas;

6.24. El sistema debe tener seguridad para el usuario que controla el acceso a las funciones del sistema;

6.25. Todas las contraseñas del sistema deben ser guardadas de forma encriptada;

6.26. El sistema debe permitir que el administrador defina el código de usuario y contraseña inicial de cada operador;

6.27. El sistema debe permitir que el administrador cree, cambie y cancele códigos de usuarios, contraseñas y permisos de acceso al sistema;

6.28. El sistema debe registrar los Logs de los usuarios para contar con un la bitácora de las tareas, procesos, registros y por quienes fueron realizados.

6.29. El sistema debe haber sido desarrollado por capas. 6.30. El sistema debe proveer una interfaz integrada de mapa

georeferenciado en tiempo real, que debe soportar por lo menos: 6.30.1. Datos GIS (segmentos de vía con habilidad de generar

rutas); 6.30.2. Plantas de edificaciones (DWGs, DGNs, etc.); 6.30.3. Locales de interés (puntos en el mapa y datos); 6.30.4. Tablas de búsqueda para diversas referencias a locales o

áreas; 6.30.5. Ubicación en tiempo real de los equipos que cuenten con

GPS; 6.30.6. Capaz de administrar diferentes capas y tipos de mapas

(earth, satelital, maps, otros). 6.30.7. Debe ser capaz de clasificar áreas dentro los mapas de

acuerdo a las asignaciones de las EPIs y otros. 6.31. El sistema debe soportar representaciones gráficas inteligentes

definidas por los usuarios, para diferentes tipos de dispositivos (cámaras, sensores, lectores, botones de emergencia, puerta de seguridad, equipos que cuenten con GPS, etc.);

6.32. El mapa debe ser un archivo local, instalado en la misma computadora que las aplicaciones del sistema para un mayor performance y pronta respuesta, o en caso de sistema basado en web, el mapa debe estar instalado localmente en el servidor web; que garantice la continuidad del servicio y la rapidez. El sistema debe permitir la exhibición de archivos Raster, como fotos aéreas e imágenes de satélite, sobreponiendo la imagen original del mapa georeferenciado;

8

6.33. La interfaz de mapa georeferenciado debe ser totalmente integrada a los demás componentes del sistema, de forma a exhibir exactamente las mismas informaciones de catastro y otros sistemas de información geográfico de forma espacial en el mapa;

6.34. Los operadores deben poseer total interacción entre la pantalla de entrada del evento y presentación del mapa utilizando una única estación de trabajo;

6.35. La interfaz integrada del mapa georeferenciado debe permitir habilitar/deshabilitar detalles del mapa conforme se acerca o aleja el zoom, de forma automática, conforme reglas preestablecidas. El mapa debe poseer capacidad de aproximar hasta la exhibición de una planta de edificación, permitiendo la exhibición de todos los dispositivos monitoreados (como cámaras, alarmas, etc.);

6.36. El mapa georeferenciado debe soportar la exhibición automática de las unidades equipadas con dispositivos AVL, y equipos que cuenten con GPS, conforme estas posiciones sean enviadas por la integración con el sistema mencionado. El sistema debe permitir seleccionar la unidad en la lista de unidades y encuadrar automáticamente en el mapa el ícono representativo de la unidad, en la última posición enviada por el sistema;

6.37. El sistema debe poseer un menú de contexto en el mapa georeferenciado, el cual permita activar un menú en la interfaz de mapa u otra solución, que exhiba las principales funciones del sistema, relacionadas con la manipulación del mapa y de los recursos, como también de eventos monitoreados, como despachar una unidad, mostrar un evento, mostrar informaciones de un dispositivo, etc.;

6.38. El sistema debe permitir al usuario imprimir una visualización del mapa de eventos e incidentes acontecidos;

6.39. El mapa georeferenciado debe reflejar todos los estados actualizados de todos los eventos y unidades, a través de íconos representativos, con codificación de colores para identificar cada estado, según criterio de búsqueda y necesidad del usuario;

6.40. Todos los íconos representativos de eventos y unidades deben ser mostrados al mismo tiempo en el mapa georeferenciado y también filtrar por evento y dispositivo;

6.41. El sistema debe encuadrar la localización de un evento sobre el mapa georeferenciado en el momento de la verificación de la dirección en el registro de un nuevo evento o en el momento de la actualización de un evento existente;

6.42. En el momento de la verificación de la dirección en el registro de un nuevo evento, el sistema debe encuadrar el mapa georeferenciado en las proximidades del local y debe mostrar un indicador apuntando el local geográfico de la dirección informada;

6.43. El ícono representativo del evento debe ser colocado automáticamente en el mapa georeferenciado en el momento del

9

registro de un nuevo evento y así mismo este icono debe cambiar cuando el evento haya sido atendido;

6.44. El sistema debe permitir el registro de un nuevo evento utilizando la localización apuntada en el mapa como el local del evento;

6.45. El sistema debe permitir a los administradores configurar las tablas operacionales conforme sea necesario. El sistema debe soportar mostrar, actualización y adición de al menos, los siguientes tipos de registros: 6.45.1. Unidades y recursos; 6.45.2. Definiciones de seguridad; 6.45.3. Informaciones de alarmas; 6.45.4. Dispositivos de control de acceso; 6.45.5. Dispositivos de alarmas de incendio; 6.45.6. Cámaras de sistemas video vigilancia; 6.45.7. Informaciones de usuarios; 6.45.8. Tipos de eventos; 6.45.9. Parámetros de sistema; 6.45.10. Parámetro de unidad; 6.45.11. Equipos que cuenten con GPS

6.46. El sistema debe trabajar bajo una plataforma de banco de datos con procesamiento en tiempo real, o sea, cualquier cambio de parámetros de datos o de base de datos debe ser realizada mientras el sistema esté en operación (sin necesidad de parar la operación). Por ejemplo, si el administrador necesita añadir un nuevo código de estado de unidad, este registro debe ser realizado en el sistema en producción y todos las terminales deben mostrar esta alteración inmediatamente, sin necesidad del operador de salir y entrar nuevamente en el sistema;

6.47. El sistema debe generar una base de datos analizando el contenido (modismo, jerga y palabras claves) de las redes sociales (Facebook, twitter, otros), páginas web y otros que despierten sospechas con el fin de prevenir eventos delictivos.

6.48. Respetar los principales estándares de seguridad ISO 27000 y legislaciones

6.49. Implementación de un módulo de Backups de los eventos de mayor relevancia.

6.50. Dispositivos de almacenamiento externo para los Backups. 6.51. Asegurar la disponibilidad y escalabilidad del sistema para que el

dimensionamiento de equipamiento proyectado considere redundancia y escalabilidad en la red eléctrica y redes de datos tanto en terminales como en servidores.

7. Integración de dispositivos y sensores, creando y administrando cámaras de seguridad, alarmas y notificaciones, registrando y administrando eventos a través de una interfaz gráfica intuitiva e integrada a un mapa georeferenciado para ubicación de alarmas, eventos, dispositivos y recursos compuesto por los siguientes módulos:

10

7.1. Módulo de gestión de seguridad 7.1.1. Proveer una plataforma robusta, fácil de usar, segura y

eficiente para facilitar la video vigilancia, monitoreo de alarmas de seguridad y/o incendio, respuesta a incidentes y comunicación de campo (trasmisión de datos, voz);

7.1.2. Optimizado para administrar recursos, apoyar la toma de decisión, para extraer informaciones a partir de una variedad de fuentes y relatar informaciones para un usuario designado o conjunto de destinatarios;

7.1.3. Integración con los sistemas de gestión de video y de alarmas, enviando y recibiendo datos en tiempo real, sincronizando datos de todos los elementos comunes;

7.1.4. Integración con unidades móviles, enviando y recibiendo datos en tiempo real, sincronizando con todos los elementos comunes;

7.1.5. Acceso a múltiples sistemas, paquetes de software y funciones a partir de una única estación de trabajo, incluyendo el acceso a los software y sistemas pertenecientes al alcance de la Solución (Atención y Despacho, Seguridad, Sistemas Externos, etc.) y equipos de soporte (impresoras, dispositivos de seguridad, joysticks PTZ y softwares asociados, etc.);

7.1.6. Capaz de generar y modificar los informes estándar y personalizados, con base en parámetros flexibles y de almacenar y actualizar informes para uso futuro;

7.1.7. Flexibilidad para generar informes utilizando datos en relación a cualquier otro elemento de datos en el sistema, incluyendo intervalos de tiempo, y mostrando tendencias correspondientes. Los informes resumidos deben permitir al usuario navegar entre los resultados, para determinar el origen de los datos obtenidos;

7.1.8. Interfaz y sincronización con un Master Clock Service para garantizar que todas las estaciones de trabajo, unidades móviles, servidores y demás sistemas trabajen con un horario estándar;

7.1.9. Capacidad de definir una porción del sistema, aislado del ambiente de producción, que pueda ser usado para fines de entrenamiento, pruebas y mantenimiento del sistema. En la medida de lo posible, la parte de formación debe ser idéntica al ambiente de producción;

7.1.10. Capacidad de trabajar, soportar la comunicación en dos vías con sistemas de alarmas genéricos, configurados para crear y localizar dispositivos de alarma automáticamente, recibir y actualizar informaciones de accionamiento de las alarmas;

7.1.11. Dispositivos de seguridad con alarmas de intrusión, detectores de invasión de sistemas de control de acceso/perímetro, etc., deben estar representados automáticamente en el mapa

11

georeferenciado, reflejando los estados de los dispositivos. El mapa georeferenciado debe también permitir el control de los dispositivos directamente a través de sus íconos representativos, mostrando comandos de manipulación a través de menús de contexto;

7.1.12. Contener eventos creados a través del controlador del sistema de alarma; deben mostrar el estado indicado por un ícono representativo en el punto apropiado en el mapa. Después de la selección de un evento generado por un sistema de alarma, el mapa debe encuadrar automáticamente la visualización en la localización de la alarma;

7.1.13. La interfaz de alarma debe soportar el reconocimiento de la alarma, armar/desarmar dispositivos y otros comandos soportados por las API/SDK de los sistemas de gestión de alarmas;

7.1.14. Control de dispositivos de alarma, determinado por la capacidad de integración de los sistemas de gestión de alarmas. Debe poseer capacidades de control, incluyendo reconocimiento y cancelación de las alarmas, creación de eventos, etc.;

7.1.15. Los íconos representativos de los dispositivos de alarma deben ser exhibidos en el mapa georeferenciado indicando la condición del equipo y el estado de ejecución, a través del código de colores predefinido;

7.1.16. Monitoreo de alarmas tanto en la interfaz tabular como en la interfaz de mapa georeferenciado;

7.1.17. Seleccionar automáticamente la alarma en la interfaz tabular cuando se efectúa la selección del símbolo de la alarma en el mapa georeferenciado;

7.1.18. Creación de un nuevo evento a partir de una alarma; 7.1.19. Creación automática de un evento, en la generación de una

nueva alerta/alarma cuando sea aplicado una regla de negocio predefinida;

7.1.20. La integración entre el sistema de comando y control y los sistemas de control de acceso y de detección de intrusión deben ser bidireccionales. Cuando una alarma sea recibida, el módulo de gestión de seguridad debe crear un registro único de esta alarma y localizar las grabaciones de vídeo disponibles para el dispositivo. Si fuera necesario un evento debe ser generado para el tratamiento en el local, cuando todas las acciones sean concluidas, la alarma debe ser concluida tanto en el sistema de comando y control como en el sistema de control de acceso;

7.1.21. Las alarmas deben poseer prioridad. Las alarmas deben poseer informaciones sobre el local y hora de alerta, además de la prioridad de acción;

12

7.1.22. El mapa georeferenciado debe permitir la visualización de todas las cámaras, sensores y demás dispositivos monitoreados;

7.1.23. El sistema debe insertar automáticamente en el mapa georeferenciado un símbolo indicativo de la alarma accionada;

7.1.24. El módulo debe exhibir en el mapa georeferenciado íconos indicativos de los dispositivos monitoreados, mostrando a través del código de colores los estados y condiciones de los equipos;

7.1.25. Permitir la selección de equipos a partir del ícono representativo en el mapa georeferenciado, mostrando un menú de contexto dinámico conforme el tipo de dispositivo, mostrando opciones de comando disponibles de cada tipo de dispositivo;

7.1.26. Interfaz en dos vías que permita a los usuarios visualizar y controlar cámaras administradas por los sistemas de video vigilancia electrónica;

7.1.27. Poseer íconos indicativos de las cámaras monitoreadas en el mapa georeferenciado, de forma a exhibir el estado actual del equipo, a través de código de colores predefinido;

7.1.28. Todas las cámaras monitoreadas, internas y externas, fijas y con control PTZ deben ser manipuladas a partir del módulo de gestión de seguridad, tanto por la interfaz tabular como por la interfaz de mapa georeferenciado. El operador debe poder seleccionar, ejecutar comandos, y cualquier otra funcionalidad permitida por las API‟s de los sistemas video vigilancia electrónica;

7.1.29. La interfaz de mapa georreferenciada debe identificar las cámaras más próximas de una alerta, de un objeto rastreado o de la indicación manual de una localidad;

7.1.30. Permitir la selección de una cámara a través del click en la interfaz tabular o en el ícono de la cámara en el mapa georeferenciado. Al hacer click con el botón derecho del mouse, debe ser exhibido un menú de contexto dinámico mostrando las funcionalidades habilitadas para la cámara seleccionada u otros métodos de fácil acceso;

7.1.31. Todas las cámaras y demás dispositivos deben poseer íconos indicativos en el mapa georeferenciado;

7.1.32. La interfaz georreferenciada debe exhibir la indicación del campo de visión de las cámaras, tal como la dirección de visión de las cámaras equipadas con PTZ;

7.1.33. Permitir la visualización de al menos 16 (dieciséis) cámaras simultáneas, pero no limitado a este número, en el terminal de operación;

7.1.34. Permitir la reproducción de imágenes en vivo y archivadas, además de archivos de video en formato estándar de mercado;

13

7.1.35. Poseer interfaz de integración con Sistemas de Gestión de Alarmas de Incendio;

7.1.36. Exhibir detalles y estado de todas las alertas recibidas. Cuando la alerta se selecciona, el sistema debe replicar en la interfaz de alarmas todos los detalles mostrados en el panel de la alarma;

7.1.37. Permitir la creación de nuevos eventos a partir de alertas recibidas;

7.1.38. Interfaz que permita a los operadores enviar mensajes alfanuméricas, textos SMS, emails y WAP a los operadores designados;

7.1.39. Garantizar la calidad del servicio (QoS) y la calidad de la experiencia (QoE).

7.1.40. Las aplicaciones deben ser de código abierto para realizar modificaciones posteriores. Con preferencia el software desarrollado sea libre, en caso que fuese software propietario, la licencia debe estar cubierto por la empresa proveedora con duración permanente.

7.1.41. En caso de ser software propietario la Licencia del software de Desarrollo y Gestor de Base de Datos se recomienda deba ser propiedad del solicitante y contar con actualizaciones permanentes.

7.1.42. Las aplicaciones deben de contar con garantía de por lo menos 2 años el cual cubrirá actualizaciones y/o modificaciones que se refiera a la integración de nuevos dispositivos.

7.1.43. Todas las aplicaciones deben contar con la documentación de desarrollo (modelo relacional, UML, etc.).

7.1.44. Se recomienda que el sistema tenga incorporado reconocimiento facial destinado a la identificación automática de la persona a partir de la imagen de video y de las imagines capturadas por el detector de rostros comparándolos con imágenes de otras bases de datos (SEGIP, Padrón Biométrico Órgano Electoral Plurinacional).

7.1.45. Se recomienda que el sistema tenga incorporado el reconocimiento de placas de los vehículos el cual puede ser contrastado con base de datos del RUAT y otros.

7.2. Módulo de atención, despacho y supervisión

7.2.1. El módulo de despacho y supervisión debe soportar la

definición de múltiples unidades; 7.2.2. Clasificar dinámicamente el usuario en el login, definiendo sus

permisos de acceso conforme, definido y liberando el acceso a las funcionalidades permitidas;

14

7.2.3. Poseer diferentes perfiles de acceso (operador, despachador, supervisor, coordinador, etc.) y debe ser configurable por el administrador del sistema;

7.2.4. Las áreas de cobertura y responsabilidad deben ser configurables por el administrador del sistema para definir los grupos de despacho;

7.2.5. Prevenir la pérdida de cobertura de cualquier función de despacho.

7.2.6. Exhibir un alerta y no permitir que el usuario efectúe log off del sistema mientras hayan eventos pendientes, cuando la terminal sea la única responsable por una determinada área. También debe impedir el log off del operador cuando hayan mensajes no leídos y eventos incompletos en espera para registro;

7.2.7. Poseer una función equivalente a alterar operador. Esta función debe permitir fácilmente el cambio del operador de la terminal sin la necesidad de salir del sistema;

7.2.8. No permitir que un mismo operador acceda a más de una terminal al mismo tiempo;

7.2.9. La función de cambio de operador debe soportar el cambio del perfil, es decir, sí anteriormente estaba conectado un despachador y en el cambio del usuario se conecte un supervisor, la terminal debe ajustar las funcionalidades para un nuevo perfil sin salir del sistema;

7.2.10. Permitir al administrador actualizar parámetros de seguridad, aun con los operadores conectados (online);

7.2.11. Permitir a los usuarios autorizados acceder a los datos de actividad de login y logoff del sistema, de forma a determinar cuáles usuarios están en operación en el momento, tal como los intentos no exitosos de login;

7.2.12. Producir un histórico de auditoría de todas las modificaciones (como logins de unidades, cambios de estado, alteraciones de tipo de eventos, alarmas, etc.);

7.2.13. El histórico de auditoría debe poseer la data, fecha y hora del instante de la alteración, con la precisión de segundos;

7.2.14. El histórico de auditoría debe grabar los datos de código de usuario y terminal donde sea ejecutada cada actividad del sistema;

7.2.15. Una vez el dato de auditoría registrado en el sistema (de forma automática en la ejecución de cualquier acción en el sistema), este no debe ser alterado;

7.2.16. Proveer acceso a los datos del histórico de auditoría a los usuarios con perfil de seguridad apropiado;

7.2.17. Cualquier usuario con el perfil de seguridad apropiado debe poder acceder e imprimir las informaciones del histórico de auditoría;

15

7.2.18. Permitir a los usuarios lidiar con la variedad de tareas que deben ser tratadas casi simultáneamente;

7.2.19. El módulo de despacho y supervisión de despacho debe apoyar el uso de múltiples monitores como un único monitor lógico;

7.2.20. El usuario debe ser capaz de navegar fácilmente de una tarea para otra usando el mouse, comandos de teclado, o atajos parametrizados;

7.2.21. Proveer medios para el uso de líneas de comando y/o cajas de diálogo y permitir el control de las siguientes opciones: 7.2.21.1. Seguridad. definiciones de usuario 7.2.21.2. Eventos 7.2.21.3. Unidades 7.2.21.4. Monitores de estado 7.2.21.5. Mensajes 7.2.21.6. Locales de Eventos

7.2.22. Permitir el registro de informaciones sobre una llamada de notificación de una situación en un evento que puede ser creado, despachado, desplegado, actualizado, cerrado y/u otros;

7.2.23. Poseer capacidad de registrar informaciones sobre un evento creado. Todas las posiciones de atención, despacho y supervisión deben poseer capacidad de crear nuevos eventos;

7.2.24. Registrar en forma automática la hora de arribo de aquellos recursos con GPS (patrulleros, motos, agentes con radio digital, etc.) que lleguen al lugar del evento.

7.2.25. Soportar el registro de nuevos eventos a través de al menos los siguientes métodos: 7.2.25.1. Comando de línea; 7.2.25.2. Pantalla de creación de eventos de la interfaz

gráfica; 7.2.25.3. A través de dispositivo móvil (evento de campo); 7.2.25.4. Recibimiento de señal o mensaje de un sistema

externo enviando una condición de alarma o evento, por ejemplo, el sistema de control de acceso, panel de alarma de incendio, detector de humo, detector de movimiento, etc.;

7.2.26. Caja de diálogo con modelo de relleno de datos para ser utilizado en la creación de nuevos eventos;

7.2.27. Generar automáticamente, a través de reglas preestablecidas, una prioridad automática para cada evento generado. No obstante, el operador debe poder alterar esta prioridad en cualquier momento;

7.2.28. Permitir el registro de comentarios en los eventos, en campo específico para esta finalidad, con cantidad de ilimitada de líneas y caracteres;

16

7.2.29. Permitir la creación de nuevos eventos con el mínimo de información necesaria, rellenando solamente el local del hecho y el tipo de evento. Debe aún permitir el relleno posterior de las demás informaciones, mismo que el operador esté trabajando en el mismo registro;

7.2.30. Las informaciones de creación y actualización de eventos deben ser automáticamente actualizadas en las terminales apropiadas (que tengan acceso al área de actuación designada);

7.2.31. Poseer funcionalidad de colocar en espera un evento en proceso de registro, para que pueda ser completado y efectivamente generado en un momento posterior;

7.2.32. Permitir la alteración de la información de cualquier campo del evento antes de su generación, como la alteración de tipo del evento, etc.;

7.2.33. Durante el ingreso de un evento, el operador debe ser capaz de colocar en espera un evento incompleto, a fin de atender una llamada de prioridad más alta. La acción de espera del evento debe ser realizada a través de los eventos incompletos, hasta que sea recuperado por el operador;

7.2.34. Soportar un temporizador asociado con los "eventos en espera" para que los operadores sean notificados cuando un evento en la fila ha superado el tiempo máximo predefinido;

7.2.35. Una vez atendido y finalizado el evento los datos no podrán ser modificados salvo este sea realizado por un usuario autorizado;

7.2.36. Capacidad de recibir información para generación de eventos a partir de las siguientes fuentes: 7.2.36.1. Llamada telefónica; 7.2.36.2. Aplicación con telefonía móvil; 7.2.36.3. Integración con terminal móvil de datos; 7.2.36.4. Aplicativos móvil de distribución pública; 7.2.36.5. Integración con dispositivos de control de acceso; 7.2.36.6. Integración con dispositivos de alarma (incendio,

intrusión, etc.); 7.2.36.7. Integración con sistemas de video analítico; 7.2.36.8. Integración con terminales de voz (Handy) 7.2.36.9. Otros.

7.2.37. Poseer un mapa georeferenciado, que permita la localización del local del hecho a través de la indicación de uno de los siguientes métodos: 7.2.37.1. Indicación total o parcial del nombre de la calle y/o

número de la vivienda; 7.2.37.2. Indicación del cruce de dos vías; 7.2.37.3. Indicación de un punto de referencia previamente

registrado (como un shopping, hospital, etc.);

17

7.2.37.4. Indicación del sitio directamente en el mapa georeferenciado;

7.2.37.5. Indicación de coordenadas (latitud, longitud). 7.2.38. Capacidad de identificación de la localización con base al

recibimiento de alerta de un dispositivo de alarma; 7.2.39. Entrada de datos a partir de una coordenada geográfica

(latitud y longitud). Debe poseer una herramienta gráfica para facilitar el relleno;

7.2.40. Capacidad mínima de almacenamiento directo en el servidor principal por un periodo de 3 (tres) años de datos históricos de unidades y eventos. El sistema debe ser proyectado para soportar al menos el doble de esta cantidad de datos;

7.2.41. Exhibición del histórico completo de un evento, mostrando los históricos de auditoría de todos los procedimientos con datos del operador, terminal, fecha y hora de cada acción;

7.2.42. Funcionalidades de búsquedas y recuperación de datos históricos de eventos y unidades;

7.2.43. Búsqueda de datos históricos de toda la base almacenada en el servidor principal. La consulta puede ser filtrada por dato, fecha y hora, a través de la interfaz gráfica de operación;

7.2.44. Las búsquedas de eventos y unidades deben ser realizadas de forma que no impacte el desempeño y tiempo de respuesta del sistema en las demás áreas de producción;

7.2.45. Todas las búsquedas deben permitir la impresión, para usuarios autorizados;

7.2.46. Capacidad para despachar una o varias unidades para un evento;

7.2.47. Debe encaminar el evento para todas las posiciones de despacho que están definidas para la gestión del área de actuación del evento;

7.2.48. Generar una alerta visual y audible a los despachadores responsables para cada nuevo evento creado encaminado por la terminal responsable. La alerta debe permanecer activa hasta que el operador de despacho seleccione el nuevo evento;

7.2.49. Soportar la funcionalidad de “arrastrar y soltar” u otra opción para el despacho de unidades, tanto en la lista de eventos y unidades como directamente en el mapa georeferenciado u otro evento en más de dos operaciones;

7.2.50. Métodos de definición de áreas de actuación georeferenciadas, con soporte para múltiples agencias, inclusive con definiciones de áreas específicas;

7.2.51. Proveer un método para trasladar las áreas de actuación, a cualquier momento, y realinear el estándar de respuesta para una unidad;

7.2.52. Edición rápida de zonas georeferenciadas para la redefinición de los límites de respuesta de las unidades, de forma a

18

optimizar tiempo y facilitar el proceso de mantenimiento de las áreas de actuación;

7.2.53. Bandeja de incidentes dividida en diferentes estados (pendientes, en curso, cerrados y otros) de los eventos.

7.2.54. Capacidad de exhibir informaciones de interés de la localización, incluyendo informaciones históricas e informaciones sobre peligros del local;

7.2.55. Permitir la inserción de informaciones de premisas y peligros de una localización geográfica específica, de una región o de un punto de interés;

7.2.56. Capacidad de almacenar las grabaciones de las llamadas (telefónicas y radio comunicaciones) como mínimo de noventa días con su respectivo histórico.

7.2.57. El sistema debe registrar el inicio, fin y el operador que atendió las llamadas telefónicas.

7.2.58. Asignar vehículos y/o unidades más cercanas al incidente a través de una búsqueda georeferenciada, además de contralar sus estados, es decir si un vehículo ya se encuentra asignado a un evento o no.

7.2.59. Se recomienda que las aplicaciones deban ser de código abierto para realizar modificaciones posteriores. Con preferencia que el software desarrollado sea libre, en caso que fuese software propietario, la licencia debe estar cubierto por la empresa proveedora con duración permanente.

7.2.60. En caso de ser software propietario la Licencia del software de Desarrollo y Gestor de Base de Datos se recomienda deba ser propiedad del solicitante y contar con actualizaciones permanentes.

7.2.61. Todas las aplicaciones deben contar con la documentación de desarrollo (modelo relacional, UML, etc.).

7.2.62. Se debe respetar los principales estándares de seguridad ISO 27000 y legislaciones.

7.3. Módulo de administración de datos operacionales;

7.3.1. Debe contar con una Base de Datos normalizada puede ser

centralizada o Base de Datos Distribuida; 7.3.2. La base de datos debería ser en software libre, si fuera

software propietario debe contar con licencia permanente; 7.3.3. Se debe respetar las normas de Base de Datos como Primera

Forma Normal (1FN), Segunda Forma Normal (2FN), Tercera Forma Normal (3FN), Forma normal de Boyce-Codd (FNBC), Cuarta Forma Normal (4FN), Quinta Forma Normal (5FN);

7.3.4. Independencia de los Datos, es decir, que los datos no dependen del programa y por tanto cualquier aplicación puede hacer uso de los datos;

19

7.3.5. No debe contar con duplicidad de datos, al reducir ésta al máximo conseguimos un mayor aprovechamiento del espacio y además evitamos que existan inconsistencias entre los datos;

7.3.6. La base de datos debe ser integra, garantiza la calidad de los datos (Integridad referencial, Integridad de dominio, Integridad de entidad);

7.3.7. El SGBD debe permitir que tengamos un control sobre la seguridad de los datos;

7.3.8. Realizar un listado de la base de datos; 7.3.9. Permitir la programación a usuarios avanzados; 7.3.10. El software, para el manejo administración de la Base de

Datos debe ser libro o software o software propietario cuya licencia debe ser cubierta por el ofertante;

7.3.11. SGBD Datos debe permitir al administrador realizar consultas (Query) y modificaciones (Update) a la base de datos

7.3.12. Posibilidad de registrar datos operacionales distintos por unidades, como: numeración del evento, áreas de atención, vehículos, tipos de eventos, código de cierre;

7.3.13. Registrar/alterar áreas de actuación de las agencias; 7.3.14. Registrar/alterar vehículos con características asociadas,

como: código del vehículo, tipo, símbolo gráfico en el mapa, unidad relacionada, lista de equipos, lista de atributos, localización permanente, área de atención y grupo de despacho;

7.3.15. Atribuir una lista de recomendación de vehículos para la atención de cada tipo de evento, por lo menos con los siguientes criterios: tipo de vehículo, cantidad, atributos, lista de equipos y habilidades de persona embarcada para cada vehículo elegido;

7.3.16. Registrar/alterar códigos de tipos de evento debiendo ser integrado entre las unidades, o sea, un mismo tipo de evento puede estar relacionada con una o más unidades, similar a un sistema experto. Debe poseer por lo menos los siguientes atributos: 7.3.16.1. Dos niveles jerárquicos: tipo principal y subtipo de

evento; 7.3.16.2. Código; 7.3.16.3. Descripción literal; 7.3.16.4. Unidad de atención; 7.3.16.5. Prioridad por unidad; 7.3.16.6. Tiempo de alarmas para los siguientes estados de

evento: o Pendiente (tiempo desde la creación del evento

hasta la atribución del primer vehículo); o Despachada (tiempo en que el vehículo

permanece con el estado atribuido)

20

o En ruta (tiempo en que el vehículo permanece en ruta);

o En el local (tiempo en que el personal de la unidad permanece en el local).

7.3.16.7. Lista de recomendación de vehículos; 7.3.16.8. Período de búsqueda histórico de anteriores

eventos; 7.3.16.9. Radio de proximidad para búsqueda de situaciones

especiales y materiales nocivos; 7.4. Registrar códigos de salidas de servicio de vehículos, pudiendo ser

distintos para cada unidad, con los siguientes atributos: 7.4.1. Código; 7.4.2. Descripción literal; 7.4.3. Unidad asociada; 7.4.4. Tiempo máximo de duración de salida de servicio, alertando al

despachador cuando este excediendo el tiempo; 7.4.5. Estado que indica si el vehículo puede ser recomendado para

un evento. 7.5. Registro de personal operativo con los siguientes atributos:

7.5.1. Código de matrícula; 7.5.2. Nombre completo; 7.5.3. Dirección; 7.5.4. Teléfono; 7.5.5. Email; 7.5.6. Grupo Sanguíneo; 7.5.7. Unidad; 7.5.8. Habilidades; 7.5.9. Contacto para notificación de emergencia; 7.5.10. Grupo de usuarios perteneciente (Operador, Despachador,

Supervisor, Móvil, etc.); 7.5.11. Código y contraseña para acceso en el sistema; 7.5.12. Tiempo de validez de acceso; 7.5.13. Indicador sí el usuario está activo en el sistema o no. Ese

indicador permite que sean mantenidos los datos del usuario que no están operando en el sistema.

7.6. Registro de lista de turnos de servicios: 7.6.1. Código y descripción; 7.6.2. Unidad; 7.6.3. Fecha y hora de inicio; 7.6.4. Tiempo de duración; 7.6.5. Vehículos/personal asociados; 7.6.6. Posibilidad de crear nuevas listas utilizando otra lista como

modelo. 7.7. Registro de códigos de cierre de evento, con los siguientes atributos:

7.7.1. Código y descripción; 7.7.2. Unidad asociada.

21

7.8. Registro de fuerza de tarea, o sea, composición de vehículos específicos en un grupo;

7.9. Registro de tiempo estimado de llegada de vehículo para la atención de evento por hora del día y día de la semana;

7.10. Registro de servicios auxiliares de terceros para el atención de eventos con los siguientes atributos: 7.10.1. Unidad; 7.10.2. Recurso utilizado; 7.10.3. Teléfono; 7.10.4. Horario de atención.

7.11. Registro del modelo de operación de las unidades incluyendo la definición de las áreas de atención relacionadas con el grupo de despacho, tipo de evento, lista de recomendación de unidades y grupos de despacho de respaldo (en el caso que un grupo no esté disponible en el momento del registro del evento);

7.12. Registro de las estaciones de trabajo con los respectivos grupos de acceso (Operador, Despachador, Supervisor, Administrador) relacionados con los grupos de despacho y unidades.

7.13. Registro de direcciones especiales para identificación de locales de referencia (industrias químicas, hospitales, tiendas de artificio, gasolineras/estaciones de servicio, etc.), con las siguientes informaciones: 7.13.1. Dirección; 7.13.2. Nombre de referencia (pueden ser incluidos más de un

nombre); 7.13.3. Comentarios (deben aparecer en la pantalla del operador y

despachador); 7.13.4. Estado indicando que la dirección será consultada en la

búsqueda de situaciones especiales cuando no hay registro de nuevos eventos;

7.13.5. Área de actuación asociada (para el caso que la dirección especial sea direccionada por otra área de actuación).

7.14. Registro de códigos de alarmas con los siguientes atributos, en el caso que la dirección posea una alarma bancaria u otra integrada: 7.14.1. Código; 7.14.2. Tipo y subtipo de evento; 7.14.3. Dirección; 7.14.4. Compañía; 7.14.5. Instrucciones operacionales; 7.14.6. Lista de contactos con nombre, teléfono, orden de prioridad.

7.15. Registro de situaciones especiales para identificar eventos sociales con las siguientes informaciones: 7.15.1. Nombre; 7.15.2. Dirección; 7.15.3. Tipo de situación; 7.15.4. Mensaje de aviso; 7.15.5. Código y nombre del solicitante (usuario del sistema);

22

7.15.6. Fecha y hora del cierre del evento; 7.15.7. Estado que indica si debe ser notificado al operador, cuando

este cree un evento cercano a la ubicación de la situación. 7.16. El módulo de administración de los datos operacionales debe poseer

funcionalidad para auditoría de las modificaciones hechas en el sistema a través de la búsqueda por los siguientes criterios: operador, terminal, función, fecha/hora inicial y final de consulta, texto libre.

7.4. Módulo de administración del mapa

7.4.1. Creación y mantenimiento de segmentos de información (nombre,

numeración, barrio, posición geográfica y otros); 7.4.2. Creación y mantenimiento de las áreas de atención; 7.4.3. Actualizaciones constantes del mapa georeferenciado. 7.4.4. Datos de tránsito (dirección de avenidas, calles y otros, velocidades

y restricciones); 7.4.5. Simbología de representación (Estaciones Policiales Integrales,

unidades policiales, hidrantes, batallones, puestos de atención, hospitales, escuelas, bancos u otra característica cualquier de representación);

7.4.6. Creación y mantenimiento de ubicaciones comunes (puntos de referencia);

7.4.7. Mantenimiento de la conectividad de los segmentos de avenidas, calles y otros;

7.4.8. Consulta alfanumérica por atributos con resultado gráfico; 7.4.9. Consulta alfanumérica por nombres de ubicaciones con resultado

gráfico; 7.4.10. Consulta alfanumérica por dirección específica con resultado

gráfico; 7.4.11. Consulta de segmento gráfico sin registro en la base de datos; 7.4.12. Consulta de registro en la base de datos sin segmento gráfico. 7.4.13. Debe permitir consumir mapas de servicios online de bases

cartográficas (Ej: Google Maps; Bing Maps; Open Streetmaps; etc.) como una capa adicional de visualización.

7.4.14. El mapa debe contar con herramientas de trabajo como ser: Zoom, scroll, acercar, asignación de zonas y/o áreas de seguridad, simbología y otros.

7.4.15. Integrar e interpretar los protocolos de los equipos GPS que sean o estén instalados en los diferentes vehículos, considerando que actualmente soporta protocolo LIP.

7.4.16. Identificar los estados y asignaciones de los vehículos (en taller, en comisión u otras operaciones especiales).

7.4.17. Creación de rutas.

23

7.5. Módulo de Análisis de Datos Gerenciales, Desempeño y reportes

El módulo debe integrarse a todos los módulos especificados en este documento que permita la generación de análisis estático y dinámico, gráficos de indicadores de desempeño y mapas temáticos y mapas de calor en tiempo real (en línea) de acuerdo con la entrada de nuevos eventos. Las características del sistema deben permitir, por lo menos, la generación de los siguientes análisis: 7.5.1. Análisis Estático:

Creación de informes estáticos, o sea, consultas predefinidas y que no dependan de configuraciones del usuario final.

Las consultas pueden poseer parámetros de entrada a ser determinados por el usuario que filtren los resultados retornados por la consulta;

Posibilitar opción de “drill down” o profundizar de forma que se detallen mejor los resultados retornados en la consulta;

El administrador del sistema debe permitir la creación ilimitada de nuevos informes y poner a disposición para consulta;

Las consultas estáticas deben retornar resultados tabulares y/o gráficos, dependiendo de su configuración específica;

Posibilidad de exportación de los resultados de las consultas para archivos del tipo PDF, XLS, DOC, CSV y otros;

El sistema debe ser implementado inicialmente por lo menos con los siguientes informes estáticos: o Tipos de eventos por día de la semana y horario; o Tipo y cantidad de eventos atendidos por grupo de despacho; o Resumen detallado de eventos: Número de registro del evento; Tipo del evento; Ubicación detallada; Área de Atención; Grupo de despacho designado; Vehículos involucrados en la atención; Fecha y hora del despacho del vehículo; Fecha y hora de llegada al lugar de cada uno de los

vehículos; Fecha y hora del cierre del evento; Nombre del personal efectivo que tripulaban los vehículos;

Cantidad de eventos por hora y día;

Control de tiempo de los eventos: deben estar presentes tipo y cantidad de eventos, tiempo mínimo de atención, tiempo promedio de atención y tiempo máximo de atención;

Histórico del operador con listado de las atenciones de eventos registrados, en un período de tiempo especificado;

24

Tiempo promedio de respuesta por hora de día: proporcionando un resumen de los eventos recibidos y el tiempo promedio de atención, en un espacio de tiempo definido;

Carga del vehículo: proporcionando un listado de cada vehículo y el número de eventos a cual el vehículo respondió en un intervalo de tiempo especificado;

Tiempo de servicio: proporcionando para cada vehículo el tiempo que utilizo en el servicio y tiempo utilizado con situaciones de „salida de servicio‟, en un intervalo de tiempo especificado;

Áreas y zonas con mayores tasas de eventos con el fin de identificar zonas de riesgo.

7.5.2. Análisis Dinámico:

Creación de informes dinámicos, o sea, a través de tablas dinámicas provenientes del banco de datos;

Deben estar disponibles universos referentes a las informaciones de eventos, vehículos, performance de vehículo y performance de atención que ya deben estar estructurados para consulta del usuario final a través de la utilización de tablas dinámicas;

Posibilitar la utilización por el usuario de por lo menos las siguientes operaciones: Máximo, Mínimo, Media, Suma, Cantidad;

El administrador del sistema debe permitir la creación ilimitada de nuevos universos y respectivas dimensiones y ponerlas a disposición para consulta;

El sistema debe ser implementado inicialmente por lo menos con los siguientes universos y respectivas dimensiones;

Universo de Eventos, con las siguientes dimensiones: o Nombre del operador; o Fecha de creación; o Tipo del evento; o Subtipo del evento; o Dirección detallada del evento; o Unidad; o Grupo de despacho; o Prioridad.

Origen de la llamada: o Nombre del solicitante; o Dirección del solicitante; o Teléfono del solicitante; o Número del evento; o Vehículo despachado; o Fecha y hora de despacho; o Fecha y hora de llegada al lugar; o Fecha y hora de cierre; o Estado del evento; o Estado del Vehículo.

25

Universo de despacho, con las siguientes dimensiones: o Fecha de creación del evento; o Tipo de evento; o Subtipo de evento; o Dirección detallada del evento; o Unidad; o Grupo de despacho; o Nombre del despachador; o Fecha y hora de despacho; o Prioridad; o Número del evento; o Cantidad de vehículos despachados.

Universo de tiempos promedios, con las siguientes dimensiones: o Nombre del operador; o Fecha de creación; o Dirección detallada; o Unidad; o Unidad o grupo de despacho; o Nombre del despachador; o Fecha y hora de despacho; o Prioridad; o Tiempo promedio de llegada al lugar; o Tiempo promedio de cierre; o Tiempo promedio de respuesta; o Tiempo promedio total del evento;

7.5.3. Gráficos de indicadores de desempeño (dashboard):

Permitir la exhibición de gráficos de indicadores de desempeño a través de los siguientes tipos: gráfico de barra, gráfico de torta, gráfico de línea, y Gauge (velocímetro);

Posibilitar al usuario final seleccionar cuales gráficos desea visualizar en su panel (dashboard) tal como la disposición de los mismos;

Almacenar la configuración de la visualización de cada usuario de forma que toda vez que al entrar en el sistema la última configuración será automáticamente mostrada;

Los gráficos de indicadores de desempeño (dashboard) deben tener sus datos actualizados de forma automática sin necesidad de actualización manual de la página. El tiempo de actualización de los gráficos debe ser parametrizable en la aplicación;

El administrador del sistema debe permitir la creación ilimitada de nuevos gráficos de indicadores de desempeño (dashboard) y ponerlos a disposición para visualización;

El sistema debe ser implantado inicialmente por lo menos con los siguientes gráficos de indicadores de desempeño (dashboard): o Volumen de eventos por tipo; o Estado de las llamadas en atención; o Recursos designados por estado;

26

o Tiempo promedio de respuesta; o Tiempo promedio de atención; o Clasificación de las llamadas entrantes (eventos por llamadas

falsas). 7.5.4. Análisis Espaciales:

Debe permitir la creación y visualización de informes espaciales (informes en mapa digital georeferenciado) con datos de eventos y vehículos;

Debe ser posible que el operador especifique parámetros de entrada de los informes espaciales, que filtren los resultados retornados;

Debe ser posible utilizar en los informes espaciales bases cartográficas propias, inclusive utilizando bases de diferentes orígenes al mismo tiempo;

El sistema debe posibilitar el acceso a bases cartográficas con datos vectoriales estándar OGC (Open Geospatial Consortium);

Debe permitir consumir mapas de servicios online de bases cartográficas (Ej: Google Maps; Bing Maps; Open Streetmaps; etc.) como una capa adicional de visualización;

El administrador del sistema debe poder incluir o excluir bases cartográficas (o visualización de servicios online de bases cartográficas) para visualización de los usuarios;

Debe ser posible, al seleccionar un punto consultado en el mapa, visualizar las respectivas informaciones de este punto. El administrador del sistema debe tener la posibilidad de determinar cuáles informaciones serán exhibidas al crear un nuevo análisis espacial;

Debe permitir la creación de informes de zonas de concentración de calor (hot spots) de forma simple por el operador directamente en la interfaz web. Los gráficos de hot spot generados deben ser visualizados sobre la base cartográfica utilizada;

Debe permitir la creación de gráficos temáticos en diversos tipos de áreas, por el usuario directamente en la interfaz web;

El administrador del sistema debe permitir la creación ilimitada de nuevos informes espaciales y ponerlos en disponibilidad para visualización.

7.5.5. Administración del módulo de análisis de datos gerenciales y desempeño;

El administrador debe poder crear, editar y excluir usuarios que posean el acceso a este módulo;

El administrador debe poder definir cuáles informes y funcionalidades estarán disponibles para cada usuario;

El administrador debe poder permitir o restringir acceso a datos de unidades y grupos de despacho que cada usuario tendrá acceso;

27

El administrador puede deshabilitar temporariamente un usuario, restringiendo el acceso al sistema para el mismo;

Estas funcionalidades de administración deben estar disponibles en el mismo componente web.

7.6. Plataforma de integración

7.6.1. El sistema debe poseer una plataforma de integración de servicios,

de forma que pueda acoplar sistemas existentes y nuevas tecnologías en una única vía de integración;

7.6.2. Esta plataforma debe permitir la integración de aplicaciones de forma robusta, incorporando Web Services, gestores de faltas, informes e integración con servicios externos compatibles con Arquitectura Orientada a Servicio (SOA);

7.6.3. Todos los módulos compuestos del sistema de comando y control y demás sistemas y dispositivos que estén integrados, deben utilizar este módulo como base para integración e intercambio de mensajes;

7.6.4. Conexión con sistemas y dispositivos externos compatibles con la arquitectura SOA de una forma simple, sin necesidad de instalación de interfaces extras o desarrollo de personalizaciones, solo necesitando configuraciones de parámetros en la propia plataforma de integración;

7.6.5. La plataforma debe poseer un administrador de mensajes, que intercepte la información provista por el sistema de comando y control, u otro dispositivo integrado, y redireccione para el módulo específico de la solución. Este administrador debe permitir la conversión del mensaje recibido para el formato esperado por el módulo indicado, de forma automática y directa;

7.6.6. La plataforma de integración debe ser configurada de forma que su lógica interna consiga interpretar el origen de cada mensaje y redireccionar para el modulo correcto, realizando las conversiones de estándares y datos necesarios para el correcto recibimiento en el módulo destino;

7.6.7. Soportar integración y normalización de los datos, eventos y funciones de control de dispositivos, sistemas, aplicaciones y redes, conforme los protocolos de comunicación de los fabricantes. Debe aún, poseer estructuras para procesamiento de eventos y configuración de acciones con el sistema de comando y control, además de otros sistemas corporativos, bancos de datos, etc.

7.7. Módulo de monitorización y auditoria

El modulo debe permitir monitorizar la disponibilidad de hardware y software que componen el sistemas para detectar, advertir y corregir situaciones de error por ejemplo el espacio disponible en disco duro libre,

28

memoria RAM disponible, el tamaño de las bases de datos, operadores conectados al sistema, etc.

III. Estándares del servicio de integración e implementación

1. Realizar un relevamiento de informaciones básicas sobre la arquitectura,

sistemas existentes e integraciones que soportarán la configuración del sistema, identificando y posibilitando el registro de la información a través de software de recopilación de datos provisto, permitiendo agilizar y garantizar la integridad de datos y permitir que las informaciones posean relacionamiento en el momento que los datos sean incluidos, donde será posible por ejemplo decir que equipos posee un vehículo y a cual grupo, unidad y área este pertenece, el sistema debe poseer un módulo de ayuda y manual impreso para que las dudas sean resueltas en el momento del registro.

2. Debe identificar y registrar: 2.1. Todos las unidades integrantes de la Central de Comando y Control,

que formaran parte del sistema; 2.2. Otras agencias fuera de la esfera de actuación de la Central de

Comando Control que también pueden eventualmente formar parte del sistema;

2.3. Analizar y registrar las áreas de actuación o área de cobertura de cada unidad presente en la Central de Comando y Control;

2.4. Registrar grupos de despacho relacionados por área de actuación; 2.5. Registrar los vehículos relacionados con cada área de actuación y

correspondiente grupo de despacho en términos de: o Tipo; o Código; o Código de área de actuación; o Código de grupo de despacho; o Equipos embarcados; o Características del vehículo; o Localización permanente; o Simbología para representación en el mapa.

2.6. Registrar listas de respuesta de vehículos para atención de los eventos, utilizado en recomendaciones, con las siguientes informaciones: código de la clasificación y cantidad y tipo de vehículos necesarios para la atención;

2.7. Equipos necesarios en las unidades; 2.8. Habilidades del personal; 2.9. Registrar tipos de eventos para clasificación de las siguientes

informaciones: 2.10. Código y descripción del evento; 2.11. Prioridad para la atención (numeradas de 0 a 9); 2.12. Tiempos de alarma de situación (estado) para cada tipo de evento; 2.13. Registrar personal operativo de las unidades incluyendo las siguientes

informaciones:

29

o Nombre, dirección y número de matrícula del funcionario; o Grupo Sanguíneo; o Habilidades (ej.: buceador, tirador, bilingüe); o Grupo de usuario que está incluido; o Tipo de permiso de identificación de acceso al sistema.

2.14. Registrar códigos de cierre de eventos utilizados en el cierre del evento para atribución de un determinado resultado;

2.15. Registrar fuerza de tarea, o sea, caravanas de vehículos pre definidos para la atención de determinados eventos;

2.16. Registrar el TEL (Tiempo Estimado de Llegada) para mostrar, en la interfaz de la ventana de los operadores y despachadores, tiempos pre configurados que estiman la llegada de un vehículo al lugar;

2.17. Registrar informaciones de equipos o servicios de empresas utilizados en determinados acontecimientos, como: grúa, ambulancia.

2.18. Registrar el nombre, teléfono, equipos, área de actuación, días y horas de atención de la empresa;

2.19. Registrar informaciones complementarias proveyendo al despachador u operador acceso a estos datos, pudiendo ser con enfoque en la ayuda a la atención (ej. atención médica, descripción de manoseo de materiales peligrosos, etc.);

2.20. Registrar planes de utilización de cada unidad, incluyendo informaciones de áreas de atención relacionadas con tipos de eventos, listas de respuesta, nivel de alarma y grupos de despacho de respaldo (en el caso que el grupo de despacho de una determinada región no esté presente el sistema puede repasar el evento para otro grupo);

2.21. Registrar lugares comunes o puntos de referencia abarcando la provisión de direcciones específicas, como Centros Comerciales, Hospitales, Unidades, Escuelas, etc.;

2.22. Registrar direcciones especiales temporales referentes a eventos en direcciones específicas, como: comicios, congresos, construcciones, etc., donde se inserten mensajes de aviso a los despachadores;

2.23. Registrar informaciones sobre cámaras a ser integradas al sistema de comando y control, como: modelo, localización, tipo (fija o PTZ), etc.;

2.24. Registrar informaciones sobre dispositivos de alarma a ser integrados al sistema de comando y control, como: tipo, lugar de instalación, lista de estados del dispositivo, etc.;

2.25. Registrar informaciones de sensores y otros dispositivos que serán integrados al sistema de comando y control, como: tipo, lugar de instalación, fabricante, etc.;

2.26. Registrar situaciones especiales referentes a lugares que requieren operaciones y procedimientos especiales, como: industrias químicas, hospitales, tiendas de artificio, estaciones de gas/gasolineras, etc. Las siguientes informaciones pueden ser incluidas: o Nombre y dirección del lugar; o Tipo de situación; o Tipo de mensaje (ej.: planta, texto, archivo, imagen); o Turno;

30

o Período (fecha y hora inicial) y duración del turno; o Mensaje especial.

2.27. Respecto a la integración con los sistemas de comunicación se deberá coordinar para entregar la solución de hardware, software e información (APIs, SDK) que permitan a la empresa diseñar aplicaciones específicas bajo acuerdo de confidencialidad.

2.28. Implementación del sistema de Comando y Control, determinación de requerimientos, levantamiento de los datos, análisis y diseño del sistema, que servirá para la configuración del sistema y posterior integración, para satisfacer las necesidades con la solución.

2.29. Elaborar un plan de ejecución, donde serán definidas todas las etapas para la implementación de la Central de Comando y Control.

2.30. Se simularan casos donde se realizaran pruebas del sistema. 2.31. Entrenamientos para el personal, según los siguientes parámetros:

CONTENIDO DEL CURSO CANTIDAD DE PARTICIPANTES

RECOMENDADO

Administrador del sistema Como mínimo 01 (una) clase de 10 alumnos.

Administrador del mapa Como mínimo01 (una) clase de 05 alumnos

Administrador de datos operacionales

Como mínimo01 (una) clase de 10 alumnos.

Operador / supervisor de atención para replicadores del conocimiento

Como mínimo01 (una) clase de 20 alumnos.

Despachador / supervisor de despacho para replicadores del conocimiento

Como mínimo01 (una) clase de 20 alumnos

Planeación y respuesta de eventos para replicadores del conocimiento

Como mínimo01 (una) clase de 20 alumnos

Transferencia tecnológica y capacitación técnica sobre el sistema instalado

Como mínimo 01 (una) clase de 20 alumnos

3. Administrador del sistema

3.1. Arquitectura y funcionamiento del sistema; 3.2. Software/protocolos de comunicación; 3.3. Servicios disponibles (naturaleza, funcionamiento, facilidades,

tratamiento de errores); 3.4. Banco de datos (estructura de datos, tratamiento de datos, sistema

administrador); 3.5. Modelo de datos; 3.6. Rutinas de operación; 3.7. Gestión de seguridad: contraseña de acceso, clase de usuarios,

grado de autoridad y especialización;

31

3.8. Gestión de desempeño de sistemas y de servicios; 3.9. Respaldos y restauración; 3.10. Redundancia de las bases de datos; 3.11. Análisis de problemas; 3.12. Interfaces.

4. Administrador del mapa

4.1. Administración de la base cartográfica de segmentos de avenidas, calles

y otros; 4.2. Administración de puntos de referencia (simbología gráfica y textual); 4.3. Administración de las áreas de atención.

5. Administrador de datos operacionales

Instruir a los participantes sobre los procedimientos de administración y mantenimiento de los datos operacionales (unidades, vehículos, personal, listas de recomendación, tipos de eventos, escalas de servicio, etc.).

6. Operador / supervisor de atención Instruir a los participantes sobre los procedimientos de operación de atención de llamadas y proceso de registro de eventos del módulo de atención, despacho y supervisión, tal como funcionalidades adicionales de supervisión.

7. Despachador / supervisor de despacho Instruir a los participantes sobre los procedimientos de operación de despacho del módulo de atención, despacho y supervisión, tal como funcionalidades adicionales de supervisión.

8. Planeación y respuesta de eventos Instruir a los participantes sobre los procedimientos de operación, monitoreo y administración de planes de acción del módulo de planeación y respuesta de eventos.

9. Transferencia tecnológica y capacitación técnica sobre el sistema instalado Instruir a los participantes sobre las características generales y técnicas del sistema mediante curso teórico práctico que sean necesarios, que serán consistentes en soporte técnico preventivo correctivo, y configuración del sistema.

32

IV. Otros ítems a considerar (especificaciones libres) 1. Servidores de Aplicación y Almacenamiento: Es la plataforma IT que

soportara todo el sistema CADI y estará dimensionado acorde la cantidad de subsistemas y configuración de redundancia que se dimensione en el desarrollo del software, garantizando la función de Failover para garantizar la operatividad de al menos 95% durante los 365 días del año.

2. Estaciones de trabajo: Es la estación de trabajo que dependiendo de la cantidad de operadores, despachadores, administradores se dimensionara el número de monitores y el tipo de mueblería que necesitan de acuerdo al ambiente del CADI.

3. Central telefónica PBX O IPBX redundante: Es la unidad que se encarga de centralizar todas las llamadas telefónicas cuyo dimensionamiento dependerá de la cantidad de llamadas entrantes simultaneas en hora pico y la cantidad de operadores máximo que se tendrá en el centro de comando garantizando la función de Failover para garantizar la operatividad de al menos 95% durante los 365 días del año.

B. ESTANDARES TÉCNICOS DEL SISTEMA DE MONITOREO Y VIGILANCIA Todos los dispositivos de monitoreo y vigilancia debe contar con su respectivo API (Application Programming Interface), el cual debe ser proporcionado a la Policia Boliviana. I. Estándares para Cámaras de video vigilancia IP PTZ, tipo DOMO y FIJAS.

Las cámaras de vigilancia para aplicaciones de seguridad ciudadana son especiales para instalaciones exteriores e interiores y están diseñadas para implementación en zonas urbanas y rurales debiendo cumplir mínimamente con las características que a continuación se detalla: 1. CÁMARA TIPO DOMO IP PTZ HD de 360º

1.1. Cámara tipo domo IP PTZ HD de 360º para ambientes exteriores e

interiores con visión de día y noche incluye IR. 1.2. Sensor de imagen progresivo CMOS. 1.3. Resolución mínima de 1920x1080(2,0 MP) o superior. 1.4. Infrarrojo automático, con distancia de alcance de 100 metros o

superior. 1.5. Longitud Focal del Lente de 4.3 a 86.mm o mayor apertura. 1.6. Zoom óptico de 18X o superior y Zoom digital de 12X o superior. 1.7. Debe tener compartimiento para dispositivo de Almacenamiento Local

SD/SDHC card o similar mínimamente de 32GB. 1.8. Deberá tener 1 canal de entrada de audio y salida de audio. 1.9. Deberá contar compresión de audio G.711a/u, G.726 y G729. 1.10. Deberá contar con Compresión de video H.264 y MJPEG

mínimamente.

33

1.11. Deberá ser de Tecnología IP con puerto Fast Ethernet RJ45 base 10/100/ Mbps mínimamente.

1.12. Deberá contar con Accesorios de instalación/fijación en poste o pared. 1.13. Deberá necesariamente soportar el Protocolo de integración ONVIF y/o

SDK. 1.14. Deberá soportar mínimamente los Protocolos de red IPv4/Ipv6,

RTSP/RTP/RTCP, TCP/UDP, HTTP, DHCP, DNS, FTP, DDNS, PPPoE, SMTP.

1.15. Deberá contar mínimamente con Fuente de poder de 220V AC al voltaje DC correspondiente a la cámara.

1.16. Deberá contar con Nivel de protección mínimo IP66. 1.17. Debe soportar WDR, o su equivalente. 1.18. Debe soportar marca de agua digital. 1.19. Debe soportar Sensor de detección de movimiento. 1.20. En caso de que ya se cuente con una plataforma operativa de video

vigilancia en servicio, se recomienda considerar lo siguiente: o Cualquier dispositivo o software adquirido e implementado, deberá

necesariamente poder ser integrado a la plataforma operativa actual, tanto a nivel físico, como lógico, etc.

o Deberá contar con el certificado de la garantía (homologación) e integración provista por los fabricantes de las plataformas o del integrador de la aplicación (nueva y actual) que garantice la integración del modelo de cámara tanto a nivel físico, de sistema operativo y de plataforma actual de video vigilancia que se cuente.

o Deberá poder considerar la opción de expansión de las plataformas actuales como una alternativa que garantiza la compatibilidad en su totalidad

2. CÁMARA TIPO FIJA. 2.1. Cámara tipo fija HD para ambientes exteriores e interiores con visión

de día y noche incluye IR. 2.2. Sensor de imagen progresivo CMOS. 2.3. Resolución mínima de 1920x1080(2,0 MP) o superior. 2.4. Infrarrojo automático, con distancia de alcance de 100 metros o

superior. 2.5. Longitud Focal del Lente de 4.3 a 86.mm o mayor apertura. 2.6. Zoom óptico de 18X o superior y Zoom digital de 12X o superior. 2.7. Debe tener compartimiento para dispositivo de Almacenamiento Local

SD/SDHC card o similar mínimamente de 32GB. 2.8. Deberá tener 1 canal de entrada de audio y salida de audio. 2.9. Deberá contar compresión de audio G.711a/u, G.726, G729

mínimamente. 2.10. Deberá contar con Compresión de video H.264 y MJPEG

mínimamente. 2.11. Deberá ser de Tecnología IP con puerto Fast Ethernet RJ45base

10/100 Mbps mínimamente.

34

2.12. Deberá contar con Accesorios de instalación/fijación en poste o pared. 2.13. Deberá necesariamente soportar el Protocolo de integración ONVIF y/o

SDK. 2.14. Deberá soportar mínimamente los Protocolos de red IPv4/Ipv6,

RTSP/RTP/RTCP, TCP/UDP, HTTP, DHCP, DNS, FTP, DDNS, PPPoE, SMTP.

2.15. Deberá contar mínimamente con Fuente de poder de 220V AC al voltaje DC correspondiente a la cámara.

2.16. Deberá contar con Nivel de protección mínimo IP66. 2.17. Debe soportar WDR, o su equivalente. 2.18. Debe soportar marca de agua digital. 2.19. Debe soportar Sensor de detección de movimiento. 2.20. En caso de que ya se cuente con una plataforma operativa de video

vigilancia en servicio, se recomienda considerar lo siguiente: o Cualquier dispositivo o software adquirido e implementado, deberá

necesariamente poder ser integrado a la plataforma operativa actual, tanto a nivel físico, como lógico, etc., cumpliendo mínimamente el protocolo ONVIF.

o Deberá contar con el certificado de la garantía (homologado) e integración provista por los fabricantes de las plataformas o del integrador de la aplicación (nueva y actual) que garantice la integración del modelo tanto físico, de sistema operativo y de plataforma actual de video vigilancia que se cuente.

o Deberá poder considerar la opción de expansión de las plataformas actuales como una alternativa que garantiza la compatibilidad en su totalidad.

II. Estándares para la Plataforma de Procesamiento y Almacenamiento de

Video 1. Servidor de video de 2 procesadores del tipo Xeon E6 o superior, con RAM

32 Gb, fuente de alimentación Dual que soporte la cantidad de discos a ser instalados en su crecimiento total y cuente por lo menos con 2 puertos de red 10/100/1000 Mbps. (No NVRs que están orientados a hoteles y condominios). Debe incluir el software de video vigilancia para servidores y para PC‟s y soportar sistema operativo bajo Windows y/o Linux, con una garantía de fábrica de por lo menos 2 años.

2. Si fuera necesario, usar un sistema operativo de virtualización preferiblemente software libre.

3. Storage con Regulador Duro de Disco: 2 Encl Mgmt Modules, SAS Only; Que soporte hasta 10 discos duros o superior dependiendo a la cantidad de almacenamiento de 7.2K RPM Near-Line SAS 6Gbps 2.5in Hot-plug Hard Drive; Cables de conexión de 6Gb; Controlador de RAID Adapter for External JBOD, 1GB NV Cache, LPF; alimentación dual de por lo menos 600 W; garantía de 2 años mínimo de fábrica.

4. La plataforma debe ser de crecimiento modular, con la posibilidad de crecer con tan solo agregar más discos duros en cascada.

35

5. Con relación a la capacidad de almacenamiento, esta deberá ser dimensionada tomando en cuenta mínimamente los siguientes parámetros técnicos: 5.1. Resolución de Imagen mínimamente de 2,0 Mp (1920x1080) 5.2. Frames por segundo mínimo 30 FPS. 5.3. Compresión H.264. 5.4. Bit rate mínimo de 1968 kbps. 5.5. Tiempo de grabación 24 horas continuas.

6. Garantizar el almacenamiento de la información de acuerdo la resolución de imagen de la cámara, tiempo de grabación y otros factores, por 90 dias, considerando la escalabilidad en espacio de almacenamiento.

7. En caso de que se cuente con una plataforma operativa de video vigilancia, se recomienda considerar lo siguiente: 7.1. Cualquier dispositivo o software adquirido e implementado, deberá

necesariamente poder ser integrado a la plataforma operativa actual, tanto a nivel físico, como lógico, etc.

7.2. Deberá contar con una garantía de integración provista por los fabricantes de las plataformas o Integrador de la aplicación (nueva y actual) que garantice la integración del modelo de cámara con la plataforma actual de video vigilancia que se cuente y el CADI.

7.3. Considerar la opción de expansión de las plataformas actuales como una alternativa que garantiza la compatibilidad en su totalidad.

III. Estándares para el TV WALL.

Los TV WALL o matrices de pantallas varían según la dimensión que se escoja pudiendo ser 2x2. 3x2, 3x3, etc., acorde del tamaño del centro de monitoreo, dependiendo de cuantas columnas por cuantas filas se escoja, un aspecto muy importante es escoger pantallas de aplicaciones industriales que estén fabricadas al uso 24/7 y no pantallas comerciales que son de uso domiciliario, para esto deberán cumplir mínimamente con las características que a continuación se detalla: 1. Tamaño de la pantalla de 46 pulgadas o más dependiendo del espacio

disponible del centro de monitoreo. 2. Resolución de pantalla Full HD 1920 x 1080 mínimamente. 3. Tipo de pantalla LED para aplicaciones 24/7. 4. Tipo de señal PAL – NTSC. 5. Entrada USB con posibilidad de hacer actualizaciones de software. 6. Entradas HDMI, DVI, USB mínimamente. 7. Energía 220VAC 50-60Hz. 8. El sistema deberá estar compuesto mínimamente por las siguientes partes:

8.1. Hardware: CPU con chipset Intel, de alta velocidad, pantallas LED

profesionales; 8.2. Software: El controlador central es un programa destinado a gestionar

las fuentes de vídeo que se reciben del procesador central y mostrarlas en el video Wall de la forma que lo hayamos programado, para que

36

aparezca una imagen en todas las pantallas o diferentes imágenes en cada una de las pantallas. En una configuración final el policía administrador podrá realizar la distribución de imágenes en el todo el TV WALL dependiendo del incidente critico que este manejando.

9. Deberá contar con el certificado de la garantía (homologación) e integración provista por los fabricantes de las plataformas o del integrador de la aplicación (nueva y actual) que garantice la integración tanto a nivel físico, de sistema operativo y de plataforma actual de video vigilancia que se cuente.

10. Todos los dispositivos deben ser de marca reconocida.

IV. Otros ítems a considerar (estándares recomendados) 1. Estaciones de trabajo: Es la estación de trabajo que dependiendo de la

cantidad de cámaras que atenderán por la policía (se recomienda que no sean mayor a 9 imágenes, para lo cual se deberá utilizar un monitor de 42” LED mínimamente). A nivel de procesador se recomienda sea del tipo Core i5, similar o superior, con 8 Gb en RAM y 2 Tb en HD con fuente alimentación real de por lo menos 600 watts, deberá incluir tarjeta de video, no integrada de por lo menos 2Gb y con un buen sistema de refrigeración. Deberá incluir todo el mobiliario como ser escritorio tipo semiluna con cajonería y sillón ejecutivo con 5 rodapiés.

2. Deberá contar con un sistema operativo con licencia original y en caso de software libre contar con el servicio de soporte correspondiente, además de contar con un software de protección de tipo corporativo (antivirus) y garantía de al menos 2 años.

3. Joystick o network Keyboard: Es el control adicional para la estación de trabajo que reemplazo el uso del teclado y mouse por una unidad más profesional y de mejor manejo para el movimiento de cámaras PTZ.

4. VMS: Si es necesario se debe considerar de manera integrada el software de gestión de vídeo que permitirán la visualización de diferentes cámaras así también que múltiples usuarios puedan visualizar en diferentes modos como el de vista dividida, pantalla completa o secuencia de cámaras.

5. Rack cerrado: el tamaño del rack será variable de acuerdo a la cantidad de servidor que se cuente considerando la escalabilidad. Permite proteger los equipos como ser: Servidor de video, servidor de aplicación, Switch, y otros equipos para integrarlos en una sola ubicación, deberá contar por lo menos con un PDU de 6 salidas.

6. UPS. Los Sistema de alimentación ininterrumpida: UPS dimensionada en función a la cantidad de equipos que deberá soportar en VA Puerto de interfaz USB, visualizador de estatus LED, alarma audible, batería sellada de plomo sin necesidad de mantención. con una autonomía mínima de 2 horas al 100% de carga.

7. Gabinetes para exterior: Permiten contener en un solo lugar para la alimentación eléctrica más la protección y los equipos complementarios como ser Switch, PoEy regulador y estabilizador de voltaje. Estará construido en plancha de acero de 2mm cubierto por pintura al horno para uso en

37

intemperie fijado al poste preferentemente, con protección IP 65 mínimamente y contar con un elemento de seguridad.

8. Micro data center: Dependiendo del tamaño que se tenga o la proyección que se quiere llegar en la plataforma de video vigilancia y almacenamiento se debe considerar la cantidad de gabinetes donde se alojara toda la tecnología de información y comunicaciones, estos gabinetes deben contar con los requerimientos mínimos de acuerdo al estándar TIA-942 de un centro de datos que involucra: 8.1. Sistema de respaldo de energía como UPS, bancos de batería, 8.2. Sistema de refrigeración, 8.3. Control de alarmas, sensores de agua, fuego, notificaciones

automáticas por SMS en caso de no contar con un sistema de gestión de red

8.4. Ambiente libre de estática. 8.5. Techo falso y/o piso falso 8.6. Debe estar ubicado independientemente de la sala de monitoreo. 8.7. Se debe contar con un firewall, El firewall debe ser físico

preferentemente de software libre o con licencia ilimitada, con puertos RJ45 y SFP de fibra óptica de acuerdo a la cantidad de conexiones que se tenga.

9. Equipamiento de red y seguridad redundante: Dependiendo del tamaño que se tenga o la proyección que se quiere llegar en la plataforma de video vigilancia se debe escoger el tamaño de los Switches que se sugiere estén configurados en modo activo y de respaldo contra incidentes, en vista a que estas unidades articulan todo el equipamiento dentro del centro de datos y que protegen el sistemas de ataques piratas externos,

10. El cableado de la red LAN deberá ser mínimamente categoría 6a certificada. 11. Entrenamientos.

CONTENIDO DEL CURSO CANTIDAD DE PARTICIPANTES RECOMENDADO

Administrador del sistema Como mínimo 01 (una) clase de 10 alumnos.

Operadores del sistema Como mínimo01 (una) clase de 20 alumnos

Transferencia de tecnología y capacitación de soporte técnico y mantenimiento

Como mínimo01 (una) clase de 20 alumnos.

38

C. ESTANDARES TÉCNICOS DE LA RED DE COMUNICACIÓN.

I. Redes Inalámbricas banda ancha. 1. Wi Fi

1.1. Se recomienda utilizar la banda alta de 5.8 GHz u otra autorizada por

la ATT y el Viceministerio de Telecomunicación, respetando la normativa 802.11n o superior, quedando a cargo de las empresas contratadas el trámite de asignación de frecuencia y homologación de equipos.

1.2. Debe ser compatible con las normativas redes 802.11a/b/g, para los equipos dispositivos anteriores y asegurar su compatibilidad.

1.3. Deberá poder soportar un ancho de banda de 20 MHz mínimamente (garantizando un Throughput mínimo de 100 Mbps).

1.4. Deberá soportar la configuración de VLans para otras aplicaciones utilizando el mismo medio de transporte.

1.5. Deberá permitir la funcionalidad de manejador de ancho de banda y autentificación de usuarios.

1.6. La arquitectura mínima requerida es la siguiente: 1.6.1. Para un área que solo requiera un nodo de acceso, se

tiene: Nodo de acceso, donde se instalaran las antenas sectoriales del tipo MIMO 2x2 mínimamente en función a área de cobertura.(tipo celular) Terminal cliente la cual estará conectada la cámara de vigilancia y a su vez servirá para poder proporcionar otros servicios como ser HotSpot (Internet), VoIP y otros.

1.6.2. Para un área que requiera más de un nodo de acceso, se tiene: Red de distribución, compuesta por un nodo de acceso con antenas sectoriales del tipo mimo 2x2 y Terminal cliente la cual estará conectada la cámara de vigilancia y a su vez servirá para poder proporcionar otros servicios como ser HotSpot (Internet), VoIP y otros. Red de Backhault, para interconectar el nodo de acceso al centro de monitoreo, compuesta por una red inalámbrica del tipo Gigaland que garantice un ancho de banda mínimo de 200 Mbps reales en un área de cobertura punto a punto de hasta 10 Km (L.O.S.) mínimamente. La red debe ser modular y de fácil expansión

La red debe estar orientada a aplicación de datos, voz y video.

39

2. Wi Max 2.1. Se recomienda utilizar las bandas libres o bandas diseñadas para

seguridad publica como ser 2.5 Ghz, 3.5 GHz, ó 5,8 GHz respetando la normativa IEEE 802.16d, (WiMax fijo) quedando a cargo de las empresas contratadas el trámite de asignación de frecuencia y homologación de equipos.

2.2. Opciones de seguridad avanzada incluyendo autenticación AES, VLAN y posibilidad de filtrado MAC.

2.3. Deberá funcionar con las características principales WiMAX como ser tecnología OFDM, sub-canalización, antenas direccionales, diversidad transmisión/recepción, modulación adaptativa 64 QAM, o superior con un ancho de banda de 20 MHz mínimamente. Deberá soportar la configuración de QoS para otras aplicaciones utilizando el mismo medio de transporte.

2.4. Latencia entre 3 y 5 ms 2.5. La arquitectura mínima requerida es la siguiente:

2.5.1. Para un área que solo requiera un nodo de acceso, se tiene: Nodo de acceso o Punto de Acceso, donde se instalaran

las antenas sectoriales en función a área de cobertura. (tipo celular) mínimamente para 200 subscriptores.

Terminal cliente la cual estará conectada la cámara de vigilancia y a su vez servirá para poder proporcionar otros servicios como ser HotSpot (Internet), VoIP y otros. Con Throughpouts de 10 Mbps mínimamente.

2.5.2. Para un área que requiera más de un nodo de acceso, se tiene: Redes de Backhault, para interconectar el (los) nodos de

acceso al centro de monitoreo, compuesta por una red inalámbrica del que garantice un ancho de banda mínimo de 200 Mbps en un área de cobertura punto a punto de hasta 40 Km con línea de vista y/o sin línea de vista de parcial de hasta 5 Km (L.O.S. on L.O.S.).

La red debe ser modular y de fácil expansión, La red debe estar orientada a aplicación de datos, voz y video.

II. LTE 4G

1. Red inalámbrica profesional con frecuencia de trabajo de 1.8GHz TDD

específicamente (1785Mhz-1805Mhz) para uso de aplicaciones de seguridad ciudadana, quedando a cargo de las empresas contratadas el trámite de asignación de frecuencia y homologación de equipos.

2. Ancho de banda de 20Mhz en frecuencia privada (Para llegar a velocidades de 100Mbps de bajada y 50 Mbps de subida por sitio).

3. Aplicación de radio troncalizada, rastreo por GPS, internet y red de video vigilancia sobre una misma tecnología.

4. La arquitectura debe contar mínimamente con 5 elementos.

40

4.1. Radio base con cobertura celular y alta penetración (Sin necesidad de tener línea de vista entre la antena y el sitio remoto).

4.2. Central de conmutación que articule las radiobases. 4.3. Sistema de gestión de red que permita tener un control de todos los

elementos de red desplegados en una ciudad. 4.4. Terminales cuya cantidad y aplicación dependerá de a quien se la

provea. 4.5. Red de transmisión para interconectar radio bases al centro de

monitoreo que puede ser microondas o fibra óptica según la topografía del terreno.

5. La red debe ser modular y de fácil expansión. 6. La red debe estar orientada a aplicación de datos móviles y fijas. 7. La red debe estar orientada a aplicación de datos, voz y video.

III. Red de fibra óptica.

1. Se recomienda utilizar el cable de fibra óptica del tipo ADSS con 24 pelos

monomodo con capacidad de instalación aérea de hasta 120 metros de vano auto sustentada y dieléctrica.

2. A nivel del centro de monitoreo se deberá utilizar un Switch administrable capa 3 de por lo menos 24 puertos 10/100/1000 Mbps más 4 puertos SFP, que soporte módulo de 1,25 Gbps o superior.

3. Para la interconexión con la cámara de vigilancia se deberá utilizar un Media Converter externo con capacidad de soportar hasta 1,25 Gbps como entrada y deberá contar con un puerto de red 10/100/1000 Mbps como puerto de salida para interconectarse directamente a la cámara de video.

4. La topología de red a ser implementada deberá ser mínimamente punto a punto activo además de generar la redundancia correspondiente.

IV. Redes Hibridas del tipo inalámbrica banda ancha y fibra óptica más cable

FTP cat6a blindado o superior 1. Se recomienda utilizar esta arquitectura, cuando se tienen implementados

varios nodos de acceso, donde la red de distribución puede ser del tipo WiFi, WiMax o LTE-4G y la red de transporte principal (BACKHAULT) debe de garantizar un ancho de banda suficiente para transportar todas las señales sin tener cuello de botella, pudiendo utilizarse un ancho de banda de 10 Gbps en modo cascada mediante la implementación de Switches ópticos que interconecten cada nodo de acceso con el centro de monitoreo de manera transparente y segura garantizando el despliegue de las imágenes en vivo.

V. Otros ítems a considerar (especificaciones libres)

1. Torres: Dependiendo de los espacios disponibles que sean de propiedad

de la administración central, policía o las ETAs para evitar el pago de alquileres y aprovechar el tamaño de las edificaciones donde se proyecta la

41

instalación de un nodo de acceso (WiFi), WiMax o radio base (LTE-4G) se debe escoger el tipo de torre y el tamaño respectivo, este ítem puede ser desde una torre triangular de 30 metros auto soportada que nace desde el suelo hasta una torreta de 15 metros que puede estar instalado en el techo de un edificio.

2. Se debe garantizar la línea de vista y mayor cobertura 3. Estándares para alquiler de red con operador local: En caso de no optar por

adquirir una red de datos y comunicación propia se tiene la alternativa de terciarizar este servicio a los operadores de telecomunicaciones locales, las especificaciones mínimas son: 3.1. Acudir a operadores que cuenten con alquiler de red fija de cobre que

utilicen tecnología SHDSL o tecnología de acceso de fibra óptica Activa (No se acepta GPON por ser sus terminales para uso domiciliario y no soportan temperaturas mayores a 40ºC a la intemperie).

3.2. Se debe solicitar un estudio de factibilidad de los puntos donde se planea tener la cámara instalada, el operador analizara si cuentan con el nodo cerca para la habilitación de este servicio.

3.3. El ancho de banda mínimo que debe ser alquilado es de 2 Mbps simétrico por punto de conexión para cada cámara (justificación: para el despliegue en tiempo real de una imagen de 1,3 Mp con 15 fps, compresión H.264, calidad de visualización de imagen buena, se requiere un ancho de banda de 1.92 Mbps)

3.4. Definir el protocolo contra fallos de transmisión para realizar el reclamo correspondiente cuando un sitio no tenga imagen.

3.5. Deberá tener la conectividad directa desde el centro de monitoreo hacia cada una de las cámaras instaladas de manera transparente y segura, para evitar posibles interferencias de comunicación.

D. ESTÁNDARES TÉCNICOS PARA RADIO COMUNICACIÓN TRONCALIZADA Y

MISIÓN CRITICA Se recomienda coordinar con la ATT y Viceministerio de Telecomunicaciones, para la asignación de frecuencias únicas para Seguridad Ciudadana previa homologación de equipos. Se debe utilizar estándares abiertos de tecnología de radiocomunicación, que incluya todos aquellos elementos necesarios para su integración y compatibilidad a nivel de hardware y software con las diferentes soluciones que se implementen en el Centro Automático de Despacho Integral CADI, además también se recomienda que deba integrarse con la tecnología ya existente. En caso de ofrecer otra solución técnica, se deben realizar y comprobar la compatibilidad, que aseguren que estos equipos van a funcionar totalmente de manera integrada con toda el Centro Automático de Despacho Integral CADI. La solución debe incorporar, dependiendo de la infraestructura previamente existente en cada sitio de repetición, todos los componentes necesarios para la implementación de la Red Móvil Digital.

42

Para garantizar la máxima interoperabilidad con terminales de usuarios de varios fabricantes, la infraestructura propuesta debe haber pasado sesiones de test de interoperabilidad durante los últimos años, en los que haya obtenido certificado de interoperabilidad con terminales de usuario de otros fabricantes. Se debe prever la infraestructura (torres, shelters, etc.), sistemas de alimentación (soluciones solares, soluciones AC/DC, etc.), acometidas eléctricas, sistemas de puesta a tierra y sistemas de protección (AC, DC, líneas de transmisión, etc.), consolas y licencias si fuesen necesarias para permitir la entrada de las nuevas radios y repetidores al sistema. Toda la información contenida en este documento como tablas, notas, diagramas, apéndices y texto se constituyen como requisitos mínimos.

I. Condiciones generales

El sistema de radiocomunicaciones digitales que se implementara, se recomienda que esté basada en tecnologías estándar, que se integre a los CADI, digital, multi- fabricante interoperable entre estos, con asignación dinámica de canales, con un elevado nivel de prestaciones, un estado de maduración técnica suficiente. Tendrá capacidad para integrar, dentro de la misma infraestructura, distintas organizaciones de usuarios que tengan características operativas diferentes con total independencia unas de otras y que permitan su interconexión entre sí en un momento o situación de emergencia determinada. Para ello se considera imprescindible una configuración por unidades y grupos dentro de cada unidad. Con el fin de dar respuesta a futuras necesidades de los usuarios del sistema, tanto si se quiere una mayor cobertura o un aumento del tráfico, la solución técnica propuesta debe ser escalable, redundante y ofrecerá la capacidad de crecimiento permitiendo una fácil evolución. En cualquier caso y en aras de una adecuada capacidad de control sobre el sistema de comunicaciones, se considera requisito indispensable que las propuestas incluyan el suministro de un Nodo Central de Control con redundancia geográfica, con la cual la conmutación entre estos nodos deberá realizarse en el menor tiempo posible, manteniendo en las terminales el registro en la red en todo momento. Se valorará la posibilidad de que el sistema pueda reconfigurarse con la máxima flexibilidad, por ejemplo incorporando Estaciones Base no permanentes cuando se celebren eventos de carácter extraordinario. Asimismo, se deberá asegurar que sólo harán uso de la Red de Comunicaciones Móviles Digitales los usuarios autorizados. El sistema deberá permitir la definición del número de unidades policiales, adecuado a las necesidades y cada una de ellas deberá poder incorporar tantos grupos como sean necesarios para una correcta gestión operativa. A cada grupo de usuarios se le asignará un perfil de privilegios y prioridades donde quedan recogidas todas las prestaciones y posibilidades de funcionamiento, existiendo consecuentemente diferentes grupos con distintos privilegios y niveles de prioridad acordados.

43

No se aceptarán equipos no homologados, que sean prototipo o que alguno de sus módulos, subconjuntos o unidades no estén en condición operacional para una integración relativamente satisfactoria con otros sistemas. Por lo tanto, de cada equipo se debe informar y registrar marca, modelo ofertado, tipo y versión. Se recomienda abrir los protocolos de radio comunicaciones para integrar con centros automáticos de despacho (CADI). Se incorporará mecanismos de seguridad adicionales como por ejemplo: cifrado en el interface aire, soluciones de encriptación extremo a extremo y otros, para proporcionar un alto nivel de seguridad en las comunicaciones mismas que se recomienda sean administradas por el solicitante. El proponente entregara con la solución, el hardware, software e información (como API o SDK) que permita diseñar aplicaciones específicas que empleen la red para intercambio de información, se debe de tener acceso al código de fuente de los dispositivos. El intercambio de tal información estará sujeto a los correspondientes acuerdos de confidencialidad, garantizando que se limitará su divulgación y que se destinarán exclusivamente al uso de seguridad ciudadana. Se incluirá terminales de cliente en ordenador PC para poder realizar la gestión técnica y supervisión de la red. Se deberá garantizar explícitamente la interoperabilidad de la infraestructura, con los terminales de usuario, tanto los incluidos en la propuesta como con terminales de otros fabricantes, presentando los certificados de interoperabilidad (IOP). 1. Servicio. Asimismo, el ofertante estará obligado a disponer de todos los

medios técnicos y humanos que le permitan llevar a cabo la puesta en servicio de los elementos suministrados para la Red y de las terminales, los servicios de atención al Cliente (vía teléfono, e-mail, etc.) y soporte técnico.

2. Medio ambiente. A la empresa que se encargue de la implementación del sistema de radiocomunicación, se obligará a adoptar las medidas necesarias para minimizar el impacto medio ambiente. Los equipos deben contar con certificación ISO 1400 de medio ambiente

II. Estándares técnicos para el diseño de la red.

1. La conmutación deberá realizarse de una forma distribuida entre los

elementos del sistema, de forma que se obtenga una fácil escalabilidad del sistema y un alto nivel de redundancia.

2. La infraestructura propuesta deberá contar con un sistema de respaldo que permita realizar copias de seguridad del estado operativo y configuración de la red, con el fin de poder restaurar la configuración guardada en una copia de seguridad. Estas copias de seguridad incluirán tanto parámetros de configuración de los elementos y módulos de la infraestructura, como la configuración de grupos y terminales que hayan sido dados de alta mediante el Sistema de Gestión Técnica.

44

3. Deberá existir redundancia en el acceso de las Estaciones Base y del Nodo Central de Control a la red de transporte el cual deberá levantar de forma automática, con el fin de garantizar la comunicación.

4. Las interfaces de interconexión o gateways, son elementos que se recomiendan adquirir para la conexión a sistemas de analógica y/o convencionales lo cual permitirá la migración responsable y escalada

5. Garantizará reducidos tiempos de establecimiento de llamadas (<300 msg. para llamadas de grupo).

6. Permitirá comunicaciones a PABX (llamadas individuales, inclusión de una extensión telefónica en llamada de grupo y llamada de grupo con origen en extensión telefónica), transmisión de datos modo paquete (IP), permitiendo que las aplicaciones seleccionen uno u otro.

7. Existirá total flexibilidad para realizar las interconexiones entre los distintos elementos.

8. Cualquier actualización futura del sistema se realizará solamente mediante software, posibilitando que sea de forma remota. El sistema soportará actualizaciones de software multi-versión, siendo posible descargar de nuevas versiones desde el Sistema de Gestión Técnica, sin detener el funcionamiento de la red.

9. El sistema propuesto permitirá realizar llamadas individuales utilizando solamente recursos de las Estaciones Base.

10. La llamada de grupo podrá realizarse con cobertura de una, varias o la totalidad de las estaciones base.

11. Soportara el intercambio de información a través de voz y señales de datos a petición en tiempo real, cuando sea necesario y cuando esté autorizado.

12. La infraestructura, deberá contar con gran potencia en los elementos de control utilizados. Se valorara que el Controlador del Nodo Central utilice un sistema operativo de Tiempo Real.

13. Se incorporará obligatoriamente un módulo local en cada Estación Base que permita un funcionamiento autónomo con la base de datos de usuarios en caso de que la Estación Base quede desconectada del resto del sistema.

14. Se ofrecerá tanto servicios de voz, datos, como servicios de seguridad. 15. Cobertura

Para ello se realizará un estudio de cobertura de acuerdo a los siguientes parámetros de calidad: 15.1. Tipo de terminal utilizado para establecer la comunicación:

Terminal portátil colocado en cintura, a una altura de 1,5 mts aproximado.

Terminal móvil, instalado en vehículo, con antena exterior y altura de 1,5 mts. aproximadamente. o Margen por desvanecimientos, obtenidos para garantizar

estadísticamente una calidad de cobertura del 95% del tiempo y de las ubicaciones, en cada uno de las áreas discretas de cálculo.

45

15.2. Calidad de las comunicaciones Para las comunicaciones de voz, se deberá disponer de la calidad suficiente para que sea posible el reconocimiento de voz entre dos interlocutores, incluso en ambientes ruidosos. El grado de calidad subjetiva será superior al ofrecido por los sistemas analógicos. Debe contar con audio inteligible que permita comprender todas y cada una de las palabras, además de comunicaciones claras sin ruido ambiente ni ruido de fondo También con tecnología de anulación de ruido con micrófono en ambos lados, se adapta a las cambiantes condiciones de los entornos más ruidosos En conjunto, para cualquier tipo de transmisión, la Bit error rate (BER) objetivo será del 5%.

15.3. Arquitectura de red La arquitectura de la Red, su topología y su equipamiento será descrita detalladamente, aportando la información que permita valorar en los aspectos técnicos el conjunto de sus elementos. La arquitectura de la Red estará compuesta por: o Red de Acceso. o Nodo Central de Control. o Gestión Técnica de la Red. o Red de Transporte.

15.4. Red de acceso

La red de acceso se recomienda que sea compuesta por las Estaciones Base, las mismas estarán realizadas preferiblemente bajo un robusto diseño mecánico modular que permita un mantenimiento sencillo y económico. Las características que deberán detallarse de las estaciones base son las siguientes: o Parámetros radioeléctricos. o Número máximo de portadoras por Estación Base y/o por bastidor. o Equipos y tarjetas que componen la estación base. o Posibilidad de ampliación o sustitución de los elementos en

caliente (hotswapping) sin interrupción del servicio. o Elementos intermedios entre transmisor y sistema radiante, como

por ejemplo, filtros, duplexores, combinadores o multiacopladores. o Tipo y configuración de sistema radiante. o Tipo de suministro eléctrico y consumo energético. o Condiciones ambientales de funcionamiento de los equipos.

46

15.5. Características técnicas o Parámetros mecánicos y eléctricos: Rango de temperatura de funcionamiento (mínimo entre -10 y

+50º C). o Parámetros radioeléctricos: Las frecuencias deben ser coordinadas con la ATT y

Viceministerio de Telecomunicaciones.

Potencia del transmisor: 10 W ajustable por programación. o Soporta voz semi-duplex

15.6. Sistemas Radiantes

En cada Estación Base el sistema radiante estará compuesto por las antenas necesarias que aseguren la comunicación constante. En recepción se utilizarán, en el caso de más de una portadora en la Estación +Base, multiacopladores, de un mínimo de 4 salidas, que incorporaran filtros preselectores para filtrado de la señal. La empresa detallará las características de los filtros en recepción con curvas de atenuación. Para transmisión se recomienda utilizar, en función del número de portadoras, filtro de transmisión o elementos de combinación, preferentemente a cavidades con objeto de minimizar las pérdidas de acoplo.

15.7. BASTIDOR Se recomienda emplear bastidores de 19” de 33 U´s de altura sobre una profundidad de 600mm para las estaciones base y de 42 U´s de altura para los Nodos de Control. Los armarios incluirán ventilación forzada.

15.8. Nodo central de control El Controlador del Nodo Central deberá realizar las siguientes funciones: o Controlará al resto de elementos del sistema: o Asignación continúa de recursos para llamadas de tráfico. o Inicializará los parámetros de configuración de cada elemento del

sistema. o Ordenará la puesta en emisión y el mapeo de los canales lógicos

en cada Estación Base. o Monitorizará el funcionamiento del resto de los elementos del

sistema.

47

15.9. Red de transporte La capacidad de los enlaces por microondas. Se recomienda que la configuración básica del equipo radio estará formado por las unidades interiores (IDU), las unidades de exterior (ODU) y una sola antena así como los cables y accesorios para su instalación y puesta en servicio. Se recomienda que la conexión del Nodo Central con las estaciones base se realice a nivel Ethernet.

III. Estándares funcionales de la red

1. Modos de operación. La Red debe contemplar, al menos, los siguientes

modos de operación, tanto para transmisiones de voz como de datos 1.1. Modo Troncalizado. Una vez registrado y conectado al sistema

cualquier comunicación de voz y datos hará uso de la red, accediendo a todos los servicios permitidos, funcionando las terminales bajo el gobierno del canal de control.

1.2. Modo directo. Cualquier comunicación de voz será directa sin el uso de

la infraestructura fija de la red.

2. Garantía Técnica. La garantía técnica será de dos (2) años mínimamente, con los siguientes requisitos: o Se deberá remplazar cualquier equipo que tenga desperfecto de fábrica

de forma inmediata. o La garantía de los equipos y partes implica que estos sean remplazados o

reparados cuantas veces sea necesario para su normal funcionamiento o Los gastos de transporte, exportación, importación, impuestos y demás, a

que haya lugar durante el proceso de reparación de los equipos y partes en garantía, serán asumidos por el proveedor de la solución.

o El oferente debe certificar que dispone al menos de un centro de servicio técnico especializado con personal capacitado y avalado por el fabricante. En caso de requerirse asistencia técnica sobre el controlador maestro o las consolas de despacho deberá prestarse en sitio.

IV. Estándares de terminales portátiles.

1. Se recomienda coordinar con la ATT y Viceministerio de

Telecomunicaciones, para la asignación de frecuencias para seguridad ciudadana previa homologación de equipos.

2. Batería: de Litio de al menos 1800 mAh de capacidad. 3. Duración de batería: > 10 hrs 4. Peso: menor o igual que 350 g (batería incluida) 5. Pantalla: Pantalla LCD color de mapa de bits completo. 6. Luces indicadoras de estado: mediante LED

48

7. Ancho de banda de canal: Debe ser de acuerdo a la tecnología aplicada. 8. Potencia de salida de audio: al menos 0.5W 9. Cantidad de altavoces: 1 para auricular y 1 para altavoz. 10. Cantidad de micrófonos: 1 superior y 1 inferior. 11. Sensibilidad del receptor GPS Integrado para rastreo 12. Antena GPS: integrada a la antena de radio 13. Exactitud de GPS: Mínimo 10m 14. Temperatura de operación: entre -10°C y +50°C. 15. Temperatura de almacenado: entre -30°C y +70°C. 16. Grado de protección contra intrusión de sólidos y líquidos: IP67 contra

caídas, choques y vibración 17. Tipo de antena: Con patrón de irradiación omnidireccional. 18. Tipo de teclado: Alfanumérico, con al menos 4 teclas de navegación y

teclas programables de acceso rápido. 19. Cambio del grupo de operación a otro grupo sin tráfico 20. Los terminales portátiles deberán poder reprogramarse. 21. Los terminales deberán contar con soporte para voz y datos compatible con

accesorios manos libres estándar. 22. Interoperabilidad: Con estaciones base y terminales de diferentes

fabricantes.

V. Estándares técnicos de terminales en vehículos. 1. Se recomienda coordinar con la ATT y Viceministerio de

Telecomunicaciones, para la asignación de frecuencias para seguridad ciudadana previa homologación de equipos.

2. Ajuste de potencia: configurable independientemente para cada modo de operación.

3. Grado de protección contra intrusión de sólidos y líquidos: como minimo IP54.

4. Temperatura de operación: Entre -10°C y +50°C 5. Se deberá poder reportar la posición GPS de cada terminal. 6. Salida de audio: no menor a 7W, con capacidad para 2 parlantes. 7. Pantalla: LCD TFT de al menos 2,5” de diagonal, con capacidad de modo

nocturno. 8. Conector frontal o lateral: Para accesorios de audio y conector de datos y

programación 9. Luces indicadoras de estado. 10. Teclado programable 11. Funciones activadas por estado 12. Líneas de entrada/salida digitales de uso general: al menos 2 entradas y 1

salida 13. Capacidad de instalación de 2 o más consolas de comando por equipo de

radio, para instalación en vehículos que lo requieran, como camiones de bomberos

14. Alternativa de consola y accesorios de audio IP67 que puedan ser instalados en el exterior de vehículos (como carro hidrante para incendio).

49

VI. Entrenamientos.

CONTENIDO DEL CURSO CANTIDAD DE PARTICIPANTES RECOMENDADO

Administrador del sistema Como mínimo 01 (una) clase de 10 alumnos.

Operadores del sistema Como mínimo01 (una) clase de 20 alumnos

Transferencia de tecnología y capacitación de soporte técnico y mantenimiento

Como mínimo01 (una) clase de 20 alumnos.

E. ESPECIFICACIONES TÉCNICAS MÍNIMAS DE GARANTÍA Y SOPORTE

TÉCNICO I. Implementación

1. La empresa proponente deberá tener experiencia certificada en

implementación de estas soluciones en el país con una experiencia específica de por lo menos 2 años. y una experiencia general de 6 años en el ámbito tecnológico.

2. La empresa proponente debe ser especialista en soluciones tecnológicas (preferentemente de telecomunicaciones).

3. La empresa proponente deberá proveer un gerente de proyecto dedicado al despliegue de la solución y técnicos certificados por el fabricante de la marca que se esté proveyendo.

4. Todo el equipamiento involucrado debe ser exclusivamente para la solución del presente proyecto, de esta manera se garantiza el correcto funcionamiento.

5. La empresa debe realizar la instalación de la solución software y hardware de forma integrada realizando pruebas y actas de conformidad.

6. El ofertante deberá realizar la implementación de todos los equipos y/o dispositivos garantizando el funcionamiento integrado.

7. El ofertante deberá entregar las APIs de los dispositivos y/o hardware para su posterior uso.

8. En caso de incumplimiento la empresa se verá sujeto a sanciones de acuerdo a las leyes, normas y reglamentos vigentes de nuestro País.

II. Garantía

1. La garantía de todos los dispositivos (cámaras, alarmas, etc.) y hardware

(Computadoras, servidores, etc.) contra inconvenientes que detengan su funcionamiento será no menor a 2 años, cuya solución debe correr por el ofertante, tales como como ser remplazo de piezas previo diagnostico corroborado de la falla por el personal correspondiente.

50

2. El oferente debe proveer un stock de repuestos de las piezas más propensas a daños al solicitante, en caso de no utilizar el stock de repuestos el solicitante será propietario de los mismos.

3. El ofertante deberá brindar garantía de la solución lógica (software y/o aplicaciones) de por lo menos 2 años, con actualizaciones permanentes, además de integrar los nuevos dispositivos adquiridos en lapso mencionado (cámaras, alarmas, etc.) a la solución software.

4. La empresa deberá presentar un certificado de garantía. 5. Si la solución usa software propietario el ofertante deberá cubrir con los

gastos de licencia permanente. 6. En caso de ser software propietario la Licencia del software de Desarrollo y

Gestor de Base de Datos se recomienda deba ser propiedad del solicitante y contar con actualizaciones permanentes.

III. Soporte técnico 1. Se debe presentar una certificación del fabricante que autoriza la

distribución de los equipos en el país y que avalen la disponibilidad del soporte técnico por lo menos en los próximos 5 años.

2. Se debe contar con soporte local con atención 24-7 para reportar los incidentes y recibir soporte técnico oportuno.

3. Soporte técnico en sitio con un tiempo de respuesta de 24-7 para equipamiento crítico.

4. Tiempo del soporte técnico de las aplicaciones de 2 años como mínimo con posibilidad a extensión anual con renovaciones de contrato.

5. Debe de contar con soporte online Helpdesk.

CAPITULO SEGUNDO

SUBSISTEMA DE CAMARAS DE SEGURIDAD PRIVADAS

A. Estándares Técnicos de Cámaras de Video Vigilancia. 1. Resolución mínima de 1280x960 (1.3 MP) o superior. 2. La resolución de la cámara debe garantizar una buena calidad de imagen 3. Se debe considerar para ambientes exteriores e interiores con visión de

día y noche incluye IR, con distancia de alcance de manera que cubra el ambiente del local.

4. Contará con sensor de imagen progresivo CMOS. 5. Se recomienda que cuente con compartimiento para dispositivo de

almacenamiento Local SD/SDHC card. 6. Debe tener el diseño para las condiciones de iluminación y ambiente de

los bares, clubes y discotecas, considerando los focos potentes o luces destellantes y humo artificial.

7. Deberá contar con Accesorios de instalación/fijación.

51

8. Se recomienda que las cámaras cuenten con energía de respaldo y garanticen el funcionamiento y grabación del mismo en caso de cortes de energía eléctrica.

9. Se debe considerar cámaras para la puerta de ingreso y para interior del ambiente.

10. Las cámaras deberán ser instaladas de tal forma que no exista zonas negras.

11. Se recomienda que las cámaras cuenten con protección robo, golpes, polvo y humedad.

12. Se recomienda que soporte marca de agua digital.

B. Estándares de Plataforma de Procesamiento y Almacenamiento de Video. 1. El dispositivo de almacenamiento debe contar con un tamaño de disco que

garantice el almacenamiento de todas las cámaras instaladas en el ambiente.

2. El dispositivo debe contar con el almacenamiento de los videos de 12 meses.

3. La grabación de los videos será en compresión H264. 4. En caso de corte de energía eléctrica el dispositivo de almacenamiento

deberá contar con energía eléctrica de respaldo para asegurar la grabación de las cámaras.

5. Los Backups deben ser almacenados de forma ordenada e identificados por fechas y cámaras.

6. Los Backups deberán estar disponibles cuando se lo requiera previa formalidades necesarias por ley.

Juan Carlos Arraya Careaga

PROFESIONAL IX VICEMINISTERIO DE SEGURIDAD CIUDADANA

MINISTERIO DE GOBIERNO

52

ANEXO I PRUEBA DE CONCEPTO

1. OBJETIVO.

Las pruebas de concepto tienen por finalidad la verificación y comprobación de las características principales del sistema propuesto y si posee la capacidad a los requerimientos básicos establecidos en las especificaciones técnicas del proceso.

2. INFRAESTRUCTURA A SER PUESTA. Se deberá proveer todo el hardware y software necesario para la ejecución de todos los procedimientos previstos en esta prueba de concepto. El número de computadoras para la presentación de la prueba se encuentran descritas abajo: - 2 (dos) computadores para servidor de banco de datos y aplicación redundantes. - 1 (una) computadora para atención de llamadas. - 3 (tres) computadoras para despacho de patrullas. - 1 (una) computadora de supervisor de despacho. - 1 (una) computadora de servidor para el módulo de Geoinformación Criminal. - 1 (una) computadora cliente para consultas y análisis del módulo de Geoinformación

Criminal.

3. FORMAS DE PRESENTACIÓN. Deberán ser presentadas las funcionalidades del sistema propuesto, conforme descrito en este ítem, en operación real, no siendo permitido presentaciones en forma de archivos multimedia, así como en Power Point (MS) u otro aplicativo similar, ni por simulaciones en aplicativo tipo demo (demonstración), debiendo ser presentado obligatoriamente la herramienta de software propuesta, incluyendo banco de datos y demás recursos operacionales exigidos en esta prueba. 4. PROCEDIMIENTOS. Los ítems que serán evaluados por los procedimientos de esta prueba de concepto, se encuentran descritos adelante, siendo utilizados criterios objetivos y claros para la atención en cada uno de los ítems analizados:

¿Atiende?

Ítem Prueba Tipo Sí No

Sistema C2 (Ejemplo)

1.0 Funcionalidades

1.1 Deberá ser simulada la entrada de datos del solicitante en la interface del sistema en la posición de atención a través del accionamiento de un botón de comando. Los datos presentados serán la dirección y el número de teléfono.

Simulador PABX

1.2 Deberá ser simulado el disparo de una alarma y visualizar en la posición de monitoreo el alerta generado sin acción del operador, mostrando cual dispositivo generó la alarma

Sistema C2 /Alarma

53

y la identificación de la cámara más próxima, tal como la exhibición de la alarma en el mapa del sistema.

1.2.1 En los detalles de la alarma, la indicación de la cámara más próxima deberá ser un link para la imagen en vivo. Una vez clicado en el link, la imagen en vivo de la cámara deberá ser exhibida.

Sistema C2 / VMS

1.3 Accionar comando de reconocimiento de la alarma, alterando el estado de la alarma y su simbología en el mapa.

Sistema C2 /Alarma

1.4 Adicionar comentario a la alarma. Sistema C2 /Alarma

1.5 Exhibir los detalles de una alarma creada. Deben estar disponibles como mínimo las siguientes informaciones: código de la alarma, local, tipificación, prioridad, dispositivo alarmado, estado de la alarma, sistema que originó la alarma, fecha y hora de creación de la alarma, comentarios de la alarma e indicación visual del local de la alarma en un mapa georreferenciado.

Sistema C2 /Alarma

1.6 Ejecutar función de cancelación de la alarma, demostrando su retirada tanto de la lista como del mapa georreferenciado.

Sistema C2 /Alarma

1.7 Se debe generar una nueva alarma y después su exhibición en la lista y mapa georreferenciado, ejecutar función de reconocimiento de la alarma, demostrando la alteración del estado de la alarma en la lista y en el mapa.

Sistema C2 /Alarma

1.8 Seleccionando la alarma en la lista de alarmas, accionar comando para conversión de la alarma en un evento. El sistema deberá realizar la conversión automática de la alarma en evento, a través de relacionamiento de tipos de eventos/alarmas previamente definido. Los operadores de despacho definidos para atención en el área del local del dispositivo deben ser notificados automáticamente. Las informaciones de la alarma en lista y en el mapa deben ser retiradas automáticamente.

Sistema C2 /Alarma

1.9 Deberá ser demostrada la capacidad de verificarse la tipificación de eventos (incluyendo los subtipos), en la aplicación de atención, siendo que, una vez tipificado el evento, deberá ser demostrada la recomendación automática del área responsable por su atención.

Sistema C2 / Evento

1.10 El evento debe ser creado para las agencias responsables de acuerdo con la tipificación seleccionada y el local validado

Sistema C2 / Evento

1.11 Debe ser creado un evento en local no validado. En este caso el sistema debe sugerir las agencias predefinidas para el tipo seleccionado por el operador para selección

Sistema C2 / Evento

54

manual del área responsable.

1.12 Deberá ser demostrado el registro de evento generado en la posición de atención con visualización en lista y mapa.

Sistema C2 / Evento

1.13 Debe ser demostrado el registro de una llamada telefónica que no genera evento, con una clasificación (broma, llamada equivocada, etc.). En este caso el registro debe ser almacenado pero no exhibido en las interfaces de atención y despacho.

Sistema C2 / Evento

1.15 Deberá ser demostrada la creación de un evento registrado en una intersección de dos vías, a través de la marcación en el mapa y también de la digitación total o parcial de los nombres de las vías.

Sistema C2 / Evento

1.16 Deberá ser demostrada la exhibición del evento registrado en la interface gráfica en la posición de atención y en la posición de despacho que posee el área de atención del evento atribuido. Para tanto cada una de las posiciones de despacho deberá estar configurada para trabajo en un área específica

Sistema C2 / Evento

1.17 Exhibir los detalles de un evento creado. Deben estar disponibles como mínimo las siguientes informaciones: código del evento, local del evento, tipificación (en dos niveles), prioridad, estado del evento, origen de la llamada, área responsable, id del operador que generó el registro, agencias accionadas, fecha y hora de la creación del registro, informaciones del solicitante (nombre, dirección y teléfono), comentarios del evento e indicación visual del local del evento en un mapa georreferenciado en el caso de la dirección haber sido validada.

Sistema C2 / Evento

1.18 Transferir un evento para otra área de actuación de la misma agencia que está atendiendo al evento.

Sistema C2 / Evento

1.19 Copiar un evento para una segunda agencia que no esté atendiendo originalmente este evento. La agencia seleccionada debe recibir notificación (sonora y visual) del evento copiado. En los detalles del evento copiado deben ser exhibidas las informaciones de todas las agencias que lo están atendiendo.

Sistema C2 / Evento

1.20 Vincular dos eventos, demostrando que en los detalles de cualquiera de los dos eventos vinculados es posible visualizar su vínculo con el otro.

Sistema C2 / Evento

1.21 Demonstrar la posibilidad de configuración de sonidos distintos para alarmas referentes a eventos, vehículos y mensajes.

Sistema C2 / Evento

1.22 Crear un evento y demostrar generación de alerta visual en otro terminal de atención, sin acción del operador.

Sistema C2 / Evento

55

1.23 Deberá ser demostrado en la posición de monitoreo la exhibición de la imagen de la cámara seleccionada en el mapa.

Sistema C2 / VMS

1.24 La licitante vencedora deberá insertar observaciones en el evento registrado, a través de la posición de atención, siendo que las mismas deberán ser exhibidas en la atención y en el despacho, de la(s) Posición(es) de despacho correspondiente a aquel evento.

Sistema C2 / Despacho

1.25 Deberá ser realizado el despacho de un vehículo para el evento creado, a través de comando del menú del sistema, a través de menú de contexto en la lista de vehículos, menú de contexto en el mapa, arrastrar el evento de la lista de eventos y soltar en el vehículo de la lista de vehículos (drag and drop en la lista) y arrastrar el símbolo del evento en el mapa y soltar en el símbolo del vehículo en el mapa (drag and drop en el mapa).

Sistema C2 / Despacho

1.26 Deberá ser demostrada una funcionalidad de “generación de ruta”, donde la herramienta deberá establecer ruta llevándose en cuenta menor tempo, mínima distancia, menos curvas o menor cantidad de intersecciones. La ruta deberá exhibir una lista conteniendo el "paso a paso" de la trayectoria.

Sistema C2 / Despacho

1.27 A través de la posición de despacho, deberá ser alterado el estado del vehículo para algo como “En Ruta”, a través de comando del menú del sistema, a través de menú de contexto en la lista de vehículos y menú de contexto en el mapa.

Sistema C2 / Despacho

1.28 Será hecha una consulta a los datos de las operaciones realizadas anteriormente.

Sistema C2 / Despacho

1.29 Deberá ser insertada (conectada), un nuevo vehículos no conectado al sistema originalmente, teniendo atribuido a él un tipo de vehículo, área de actuación y su ícono (simbología) en el mapa georreferenciado.

Sistema C2 / Despacho

1.30 Deberá ser insertado el personal del vehículo conectado, seleccionando de una lista de funcionarios registrados, con indicación del comandante del vehículo.

Sistema C2 / Despacho

1.31 Todavía en el vehículo conectado se debe informar el kilometraje actual del misma, además de asociarla a un vehículo con como mínimo las siguientes características: ID de radio, equipos embarcados (seleccionados de una lista) y dimensiones físicas (altura, ancho y peso máximos)

Sistema C2 / Despacho

1.32 Alterar el estado de una unidad conectada para algo como "Fuera-de-Servicio", indicando su indisponibilidad temporaria, con selección del motivo de indisponibilidad

Sistema C2 / Despacho

56

en una lista registrada anteriormente, campo para informar el local donde el vehículo se encuentra y un campo para observaciones generales

1.33 Deberá ser creado un nuevo evento a través de la posición de atención, que deberá llegar a la posición de despacho automáticamente, sin intervención del operador. La posición de despacho deberá demonstrar las funcionalidades de ruteo por el criterio de menor distancia para el vehículo.

Sistema C2 / Despacho

1.34 Deberá ser demostrada la capacidad de la herramienta de seleccionar en el mapa georreferenciado el ícono representante del vehículo y arrastrarlo hasta el ícono del evento, despachando, de esta forma, el vehículo para el evento.

Sistema C2 / Despacho

1.35 Deberá ser demostrada la capacidad de alteración de la prioridad de un evento, sin alteración del estado de atención, de modo a alertar las máquinas de supervisión y la de despacho que esté acompañando el área de servicio.

Sistema C2 / Despacho

1.36 A través de la posición de despacho, deberá ser alterado el estado del vehículo para algo como “En el Local”, a través de comando del menú del sistema, a través de menú de contexto en la lista de vehículos y menú de contexto en el mapa.

Sistema C2 / Despacho

1.37 El evento deberá ser complementado, insertando datos de comentarios y cerrado, a través de comando como "Finalizar Evento". Una vez cerrada la atención, demonstrar la retirada automática del registro de la lista de eventos activos, del mapa georreferenciado y la alteración del estado del vehículo para algo como "Disponible".

Sistema C2 / Despacho

1.38 Demonstrar la capacidad de búsqueda de eventos ya finalizados, en la interface de despacho, seleccionando el registro finalizado en la etapa anterior. Demonstrar el almacenamiento de los datos históricos a través del registro de los horarios de creación, atribución, vehículo n ruta, vehículo en el local y cierre del evento.

Sistema C2 / Despacho

1.39 Deberá ser demostrada la característica de actualización automática, sin cualquier acción del despachador, operador o supervisor, de los eventos editados en otra máquina de despacho, atención o supervisión.

Sistema C2 / Despacho

1.40 Deberá ser demostrada la posibilidad de atribuirse más de un grupo de despacho para una misma posición de despacho

Sistema C2 / Despacho

1.41 Deberá ser demostrada la creación de un evento en un Sistema C2 / Evento

57

mismo local de un evento cerrado, creado anteriormente, verificando sí el sistema provee informaciones sobre el mismo.

1.42 Deberá ser demostrada, en los módulos de despacho y supervisión el cambio de color de un vehículo después de su atribución a un evento.

Sistema C2 / Evento

1.43 Deberá ser demostrada un alerta visual de un evento por la no atención del tiempo estándar de llegada del vehículo al evento para el cual fue accionado.

Sistema C2 / Evento

1.44 Deberá ser demostrada la capacidad del módulo de despacho de retirar un evento previamente asignado a un vehículo de forma a retornarlo automáticamente al estado de ‘pendiente’.

Sistema C2 / Despacho

1.45 Deberá ser demostrada la capacidad del módulo de despacho de programar la atención de eventos en una fila ordenada. De esta forma, en un vehículo ya asignado para un evento, el operador deberá asignar un segundo evento indicándolo como ‘despacho atribuido’.

Sistema C2 / Despacho

1.45.1 En este caso deberá ser demostrada la capacidad de efectuar la inserción de datos y observaciones en los diversos eventos, directamente de la interface de despacho

Sistema C2 / Despacho

1,46 Deberá ser demostrado el registro de informaciones adicionales del evento, como lo siguiente:

Sistema C2 / Despacho

1.46.1 Detalles de Personas Involucradas: Registro de detalles de las personas involucradas en la situación, como Nombre, Documento, Sexo, Color de Pelo, Edad, Peso, Etnia, Color de Ojos, Altura, Fecha de Nacimiento, entre otros. Se debe demostrar la integración con sistemas externos, ejecutando búsqueda por documento y llenando automáticamente otros campos.

Sistema C2 / Despacho

1.46.2 Detalles de Vehículos Involucrados: Registro de detalles de los vehículos involucrados en la situación, como Fabricante, Modelo, Año de Fabricación, Placa, Color, entre otros. Se debe demostrar la integración con sistemas externos, ejecutando búsqueda por Placa y llenando automáticamente otros campos.

Sistema C2 / Despacho

1.46.3 Detalles de Objetos Recogidos: Registro de detalles de los objetos recogidos por las autoridades en el evento, como Descripción del Objeto, Número de Serie, Valor, entre otros.

Sistema C2 / Despacho

1,47 Deberá ser demostrado el registro de turnos de servicio, definiendo nombre de turno y agencia, duración del turno, hora de inicio del turno, entre otras informaciones.

Sistema C2 / Despacho

58

1.48 Se debe demostrar la capacidad de vinculación de vehículos y personas para cada turno.

Sistema C2 / Despacho

1,49 Se debe demostrar la conexión (inicio de servicio) de un turno, conectando los vehículos y respectivo personal en el mismo. Demostrar la posibilidad de conectarse todos los vehículo del turno o seleccionar individualmente cuales vehículos entrarán en servicio. Se debe demostrar la actualización de la lista de vehículos y del mapa de forma automática, sin intervención del operador.

Sistema C2 / Despacho

1.50 Se debe demostrar la desconexión (término de servicio) de un turno, desconectando los vehículos y respectivo personal. Demonstrar la posibilidad de desconectarse todos los vehículos del turno o seleccionar individualmente cuales vehículos finalizarán el servicio. Se debe demostrar la actualización de la lista de vehículo y del mapa de forma automática, sin intervención del operador.

Sistema C2 / Despacho

1,51 Deberá ser demostrada una herramienta específica para extracción de informes. Esta herramienta deberá poseer al menos las siguientes funcionalidades:

Sistema C2 / Informe

1.52 Extracción de informes tabulares:

1.52.1 Histórico de Eventos: Exhibir una lista de los eventos, conteniendo al menos los siguientes datos: Código del Evento, Fecha de Creación, Tipo, Subtipo y Dirección. Deberá poseer forma de filtrar el informe al menos por fecha de creación y operador que creó el evento.

Sistema C2 / Informe

1.52.2 Tiempo de Respuesta por Hora del Día: Exhibir una lista de las eventos seleccionados, conteniendo al menos los siguientes datos: Código del Evento, Fecha de Creación, Tipo, Subtipo y Dirección, tiempo promedio entre la creación del evento y la llegada al local. Exhibir también gráfico representando el tiempo promedio entre la creación del evento y la llegada al local.

Sistema C2 / Informe

1.52.3 Tiempo de Respuesta por Operador: Exhibir una lista de los eventos seleccionadas, conteniendo al menos los siguientes datos: Operador, Código del Evento, Fecha de Creación, Tipo, Subtipo y Dirección, tiempo promedio entre la creación del evento y el despacho. Exhibir también gráfico representando el tiempo promedio entre la creación del evento y el despacho.

Sistema C2 / Informe

1.52.4 Acompañamiento de Productividad: Exhibir gráfico representando el cuantitativo de eventos creados por operador en un intervalo de tiempo.

Sistema C2 / Informe

1.52.5 Origen de los Eventos: Exhibir gráfico representando el Sistema C2 /

59

cuantitativo de eventos creados por origen de la información (teléfono, monitoreo, etc) en un intervalo de tiempo.

Informe

1.53 Extracción de informes espaciales: Sistema C2 / Informe

1.53.1 Localización de Eventos: Exhibir mapa georreferenciado, indicando los puntos de los locales de los eventos existentes. Deberá ser demostrada la capacidad de filtrar la búsqueda por al menos los siguientes criterios: "1 hora", "12 horas", "24 horas", "1 semana" y "1 mes".

Sistema C2 / Informe

1.53.2 Búsqueda de Eventos: Deberá ser demostrada la capacidad de la herramienta en generar una búsqueda de eventos por fecha de creación, tipo de evento, agencia y área de actuación.

Sistema C2 / Informe

1.53.3 Mapa Termal: Deberá ser demostrada la capacidad de la herramienta en generar una nube de concentración de eventos (mapa termal) a partir de una búsqueda de eventos previamente realizada. El análisis termal deberá ser exhibida en el mapa georreferenciado, redistribuyendo dinámicamente la concentración de los eventos conforme se manipula el nivel de zoom.

Sistema C2 / Informe

1.54 Extracción de informes tabulares dinámicos: Sistema C2 / Informe

1.54.1 Deberá ser demostrada la capacidad da herramienta de seleccionar un universo de datos previamente establecido y cargar los campos de este universo en la interface de la herramienta.

Sistema C2 / Informe

1.54.2 A partir del universo seleccionado, deberá ser demostrada la capacidad de "arrastrar y soltar" los campos en la estructura de la herramienta, de forma a permitir la relación entre los campos en la construcción de una tabla de consulta dinámica. Demonstrar la capacidad de definir diversos campos en línea y en columna. Demonstrar la capacidad de realizarse filtros de búsqueda a partir de cualquier campo del universo de datos seleccionado.

Sistema C2 / Informe

1.55 Dashboards dinámicos: Sistema C2 / Informe

1.55.1 Deberá ser demostrada la capacidad de la herramienta de exhibir panel de indicadores. Deberá ser demostrado al menos un indicador en gráfico de barras mostrando los cinco tipos de eventos más numerosos, un indicador en gráfico pizza mostrando los estados de los vehículos conectados y un indicador gauge (velocímetro) mostrando el tiempo promedio entre la creación del evento y el

Sistema C2 / Informe

60

despacho.

1.55.2 Demonstrar la actualización dinámica de los indicadores, sin intervención del operador. Para eso, se debe crear un nuevo evento utilizando uno de los 5 tipos de eventos más numerosos. El indicador de gráfico de barras debe ser actualizado automáticamente. En seguida, el evento debe ser despachado. Debe ser demostrada la actualización automática del indicador gauge con el promedio de tiempo entre la creación del evento y el despacho, además de la actualización dinámica del indicador de gráfico de pizza, mostrando el cambio de estado del vehículo.

Sistema C2 / Informe