LiNC-NXG Traducción

Guía de Especificacón A & E de Sistema de Administración de Seguridad
LiNC-NXG TM
Guía de Especificación A/E
Febrero 2009
Revisión 1.1
PCSC no hace representaciones o garantías con respecto a los contenidos aquí descritos y
se exime de cualquier garantía implícita de la operación para cualquier propósito en
particular. Más adelante, PCSC puede modificar éste documento sin obligación de notificar a
ningúna persona de ningúno de dichos cambios o revisiones.
PCSC
3541 Challenger St.
Torrance, California 90503
USA
Teléfono: (310) 303-3662
Fax: (310) 303-3662
e-mail: [email protected]
LiNC-NXG Guía de Especificación A/E
Guía de Especificación A&E de Sistema de Administración de Seguridad
Acrónimos
CAD
Diseño Asistido para Ordenador
DVD
Disco Digital Versátil
NXG
Próxima Generación
PIN
Número de Identificación Personal
RDNA
Arquitectura de Red de Trabajo Dinámica en Tiempo Real
SDK
Equipo de Desarrollo de Software
SMS
Software de Administración de Sistema
SQL
Lenguaje de Consulta Estructurado
UDF
Formato Universal de Disco
Guía de Especificacón A & E de Sistema de Administración de Seguridad
1. General
1 Introducción
1.1.1 Ésta especificación es utilizada para identificar los requerimientos para un control de
acceso integrado, monitoreo de alarma, control de salida, control de elevador y sistema de
video de circuito cerrado. La (s) Estación (es) de Trabajo del operador deben ser utilizada (s)
para programación de base de datos o desplegados de eventos de almacenamiento o
históricos. Todas las decisiones de control de acceso, alarma, salida y elevador deben ser
procesadas por los controladores inteligentes distribuídos.
2 El sistema especificado debe ser el LiNC-NXG desarrollado por PCSC.
2
Alcance de Trabajo
1.2.1 El proveedor del sistema debe diseñar, equipar, instalar y probar una
tarjeta electrónica integrada de control de acceso y un sistema de
monitoreo de alarma.
1.2.2 El proveedor del sistema debe ser responsable por el entrenamiento para
el producto y el software y hardware necesario para una solución de llave
de mano (turnkey) completa.
3
El proveedor del sistema también debe.
1.2.3.1 Entregar dibujos, especificaciones y archivos CAD del sistema en
un UDF compatible con DVD.
1.2.3.2 Al completara la instalación, probar el sistema para verificar que cumpla con las
especificaciones.
1.2.3.4 Entregar un reporte de prueba al propietario para su aceptación mostrando el
producto en operación. Cualquier equipo especial requerido para prueba debe ser señalado.
1.2.3.5 Garantizar el sistema completo por un período de un (1) año a partir de la fecha de
aceptación. La garantía debe incluir la reparación o reposición de producto defectuoso no
debido al resultado de uso normal ni razgado.
1.2.3.6 Suministrar tres (3) juegos de manuales de operador.
3 Descripción General del Sistema
1 El sistema suministrado debe comprenderse de lo siguiente:
1.3.1.1. Software de Aplicación de LiNC-NXG
1.3.1.1.1 Software de Administración del Sistema (SMS)
1.3.1.1.2 El sistema debe soportar un legado, actual y futuros controladores de
arquitectura
1.3.1.1.3 Debe soportar Arquitectura de Comunicación Puerto a Puerto
1.3.1.1.4 Suministrar SDK para mejoras en aplicación y sistema
5
Suministrar Software e interfases de aplicación de usuario basadas en
RED (WEB)
Guía de Especificacón A & E de Sistema de Administración de Seguridad
2
3
4
5
2 LiNC-NXG debe funcionar como un “Servicio de Sistema” bajo el sistema
operativo de Microsoft Windows.
3 El SMS debe automáticamente reiniciarse bajo una falla de energía y
reestablecer las comunicaciones con los controladores inteligentes sin la
intervención de ningun operador.
4 Propiedades de aplicación deben ser controladas por el Administrador de
Servicio de Microsoft.
5 El SMS debe ser configurado para utilizar una cuenta de sistema más que
una cuenta de usuario, minimizando riesgos de seguridad.
6 Utilizar Base de Datos SQL de Microsoft.
7 Compatible con IBM – Computadora personal basada en un procesador
Intel Dual Core
8 El SMS debe soportar los controladores inteligentes de Acceso, Alarma.
Salida y Elevador
9 Tarjetas y lectores de tarjetas de acceso
1.3.1.9.1 Los lectores deben soportar simultáneamente “Tarjetas de
Multi-tecnología”.
1.3.1.9.2 Los lectores deben ser “supervisados” y notificar al usuario
cuando un lector falla o se daña debido al vandalismo o falla
del lector.
1.3.1.9.3 Los lectores deben de soportar PIN
1.3.1.9.4 Tecnologías de Proximidad o Tarjeta “Inteligente” debe ser
soportado por el sistema
1.3.1.9.5 Debe soportar lectores biométricos industriales estándar
1.3.1.9.6 Las tarjetas deben tener la habilidad para soportar la impresión
de logos corporativos o fotos de empleados
El sistema debe ser diseñado para soportar simultáneamente arquitecturas de
“Anfitrión a Controlador” y “Anfitrión a Controlador Principal”.
El sistema debe soportar 3 niveles de Tolerancia a Falla.
1.3.3.1 Redundancia de Sistema Anfitrión como una opción
1.3.3.2 Controlador Principal de Tolerancia a Falla
1.3.3.3 Arquitectura de Autocuración o Red Dinámica en Tiempo Real (RDNA)
El Sistema debe soportar Comunicaciones Ethernet con los paneles de control
inteligentes.
El sistema debe estar respaldado con baterías por hasta un mínimo de 4 horas
para todos los aparatos de campo y 1 hora para las computadoras del anfitrión
y de estación de trabajo.
4 Presentaciones (Entregas)
1 Dibujos del Taller
1. Las presentaciones deben incluir dibujos detallando todos los dispositivos.
Los dibujos deben ser lo suficientemente detallados de modo que todas las
partes involucradas entiendan el alcance del trabajo. Los dibujos del taller
deben incluir la siguiente información como mínimo:
Guía de Especificacón A & E de Sistema de Administración de Seguridad
1.4.1.1.1. Un dibujo de alto-nivel mostrando completo el sistema de control
de acceso incluyendo las ubicaciones y descripciones de los
dispositivos.
Un plano (s) arquitectónico de piso mostrando el sistema completo con los
tipos de cable, requerimientos de conductos, distancias,
requerimientos de energía y cualquier detalle necesario para
asegurar el alcance de trabajo es entendido.
2. Información del Producto
1.4.2.1. El proveedor debe suministrar los panfletos a color necesarios, hojas
de datos técnicos, diagrámas de cableado de cada producto a ser
instalado.
1.4.2.2. El proveedor debe incluir al menos un (1) set de manuales de
instalación/o usuario para cada aparato a ser instalado.
1.4.2.3. El proveedor debe suministrar una cuenta de materiales indicando
los número de modelo y garantía de cada aparato a utilizar.
3.
Dibujos de Como Construído (As Built)
1.El proveedor debe mantener las especificaciones y dibujos del sistema en
un área segura para futuras actualizaciones y servicios.
2.Los dibujos deben definir el tipo y locación de cables, controladres de
acceso, lectores, REX, candados, puntos de alarma, salidas y
cualquier hardware asociado.
5 Garantía de Calidad
1.5.1. Calificaciones del Fabricante
1.El fabricante debe haber estado en el negocio por un mínimo de 15 años
diseñando, constuyendo, y probando sistemas relacionados con el control
de acceso.
6 Calificaciones del Proveedor
1.6.1. El proveedor del sistema debe haber estado en el negocio por un
mínimo de 3 años instalando y dando servicio a sistemas relacionados
con el control de acceso.
1.6.2. El proveedor del sistema debe mostrar un mínimo de 5 instalaciones de
control de acceso similares dentro de los úlitmos 2 años. Si se requiere,
las referencias deberán ser contactadas para revisar las calificaciones del
proveedor.
El proveedor del sistema del centro de servicio debe estar ocupado para
proveer servicio de emergencia dentro de 4 horas de ser notificado, 24
horas al día, 365 días del año.
Guía de Especificacón A & E de Sistema de Administración de Seguridad
2 Diseño y Caracterísiticas del Sistema
1 LiNC-NXG debe operar bajo Microsoft Windows XP Profesional, Microsoft Vista
Business (Negocio), Servidor Windows con Servidor Microsoft SQL o Edición
Expres de Microsoft SQL.
2 El sistema de seguridad debe conformarse bajo los Estándares de Windows para
operación de usuario y mantenimiento.
3 El sistema debe ejecutarse como un Servicio de Microsoft para asegurar un
sistema más robusto.
4 El sistema debe soportar un marco de trabajo Microsoft .NET y utilizar SQL como
su base de datos.
5 El sistema debe suministrar un diseño de “Arquitectura Abierta”.
6 El sistema debe estar escrito en una arquitectura multitarea. Cualquier sistema que
no permita el uso del sistema durante reportes, descargas de base de datos o
respaldos de base de datos no debe ser aceptado.
7 El sistema debe suministrar una capacidad de respaldo de base de datos en
tiempo-real sin limitar el rendimiento y operaciones del sistema.
8 El sistema debe soportar un 100% de la red de trabajo distribuida del controlador
inteligente. Cualquier sistema que requiera la intervención del Anfitrión para
acceso de tarjeta, expiración de tarjeta automática, control de apertura de puerta
automática o entrada/salida lógica no debe ser aceptado.
9 Protección de Password (Clave de Acceso)
9.1.Un password de usuario y password de estructura de nivel deben mantenerse
para poder entrar dentro del sistema. Los niveles de password deben
determinar los derechos para desplegar o modificar registros del operador en la
base de datos. El sistema debe proveer un número ilimitado de niveles de uso
del operador.
10Registro de Uso del Operador
2.10.1 El sistema debe proveer un registro histórico de las acciones del operador o
actualizaciones de base de datos por fecha y hora de cambio. Cada
modificación al registro debe incluir los contenidos de valor de datos antes y
después de la modificación.
11Segregación de Base de Datos
11.1.El sistema debe proveer un medio para “determinar” los datos específicos o
rango de datos que pueden ser desplegados o modificados por el operador.
Los rangos de datos deben estar disponibles con Propietarios de Tarjetas,
Períodos de Tiempo, Autorización de Grupos, Grupos de Piso, Control de
Puerta, Entradas y Salidas y monitoreo de alarma.
2.12 El sistema debe tener la habilidad de abrir simultaneamente múltiples ventanas.
2.13 Arquitectura de Comunicación
2.13.1 El sistema anfitrión debe constantemente mantener el estátus del sistema
así como los controladores, entradas, salidas, etc. El sistema notificará al
usuario de cualquier cambio en estátus o pérdida de comunicación.
2.13.2 La comunicación primaria ser el Ethernet. Métodos de comunicación
alternativos para soporte inalámbrico estará disponible como una opción.
2.13.3 El sistema anfitrión debe proveer soporte simultaneo para comunicación de
legado y arquitecturas de comunicación de “Tolerante a Fallas”.
2.13.4 Desplegado de Estátus de Comunicación consistirá en lo siguiente:
2.13.4.1 Nombre del Panel
2.13.4.2 Dirección de IP
2.13.4.3 Número de Puerto
2.13.4.4 Versión de Controlador Firmware
2.13.4.5 Estátus de comunicación
2.13.5 Todas las transacciones serán registradas en el anfitrión. Durante una
pérdida de comunicación, los controladores mantendrán la transacción y
automáticamente enviarla al anfitrión cuando la comunicación sea reestablecida. Las transacciones serán registradas con un mínimo de lo
siguiente:
2.13.5.1 Fecha y Hora de Suceso
2.13.5.1.1 mm-dd-aa hh:mm:ss
2.13.5.2 Tipo de Transacción
2.13.5.3 Nombre o Locación del suceso
2.13.5.4 Fecha y Hora registrados en el anfitrión
2.13.5.4.1 mm-dd-aa hh:mm:ss
14Sincronización de Base de datos desde el Sistema Anfitrión a Controladores
2.14.1 El sistema automáticamente descargará los cambios en la base de datos,
inmediatamente después de una solicitud de cambio válida.
2.14.2 El sistema debe proveer un comando de operador para descargar datos a un
controlador específico o un rango de controladores.
2.14.3 Si por algúna razón un controlador está “Desconectado” durante un cambio
de base de datos, el sistema mantendrá una notificación de “Actualización
de Sistema” y automáticamente descargará los cambios apropiados a los
controladores, una vez que la comunicación haya sido re-establecida.
4 El sistema debe permitir al usuario “Operar” el sistema durante la sincronización
de la base de datos.
2.15 Desplegado de Transacción de Conexión debe ser desplegado en la Ventana
Principal y proveer al usuario la habilidad para buscar el diario entero.
2.16 Capacidades del Sistema
2.16.1 Estaciones de Trabajo Ilimitadas
2.16.2 Lectores de Tarjeta Ilimitados
2.16.2.1 Debe soportar todas las teconologías para Tarjeta y
Biométrica
2.16.3 Propietarios de Tarjeta Ilimitados
2.16.3.1 Debe soportar números de tarjetas de hasta 24 dígitos
2.16.3.2 Debe soportar tarjetas CAC aprobadas para DOD
2.16.3.3 Debe soportar formato de tarjeta FIPS
2.16.3.4 Debe soportar formato de tarjeta TWIC
2.16.4 Transacciones Históricas Ilimitadas
2.16.5 Puntos de Alarma Ilimitados
2.16.6 Salidas Ilimitadas
2.16.7 Días Festivos Ilimitados
2.16.7.1 365 Días Festivos por año
8
9
Períodos de Tiempo Ilimitados
Grupos con Entrada Autorizada Ilimitados
Guía de Especificacón A & E de Sistema de Administración de Seguridad
17Autorización de Tarjeta
2.17.1 El sistema debe proveer el nivel más alto de autentificación de tarjeta y
autorización a propietario de tarjeta. La autorización de una tarjeta debe estar
determinada con un mínimo de lo siguiente:
2.17.1.1 Código Corporativo
2.17.1.2 Validez de Tarjeta
2.17.1.3 Ubicación de Puerta
2.17.1.4 Fecha, Día y Hora
2.17.1.5 Acceso Largo
2.17.1.6 Entrada y Salida – Edificio, Departamento y Estacionamiento
2.17.1.7 Acceso de Supervisor
2.17.1.8 Control de Evento
2.17.1.9 Requerimientos de Escolta
2.17.1.10
Salida de Acción de Tarjeta
2.18 Un Registro de Propietario de Tarjeta debe contener:
2.18.1 Número de Empleado
2.18.2 Nombre de Empleado (Nombre de Pila, Apeídos)
2.18.3 Compañía
2.18.4 División
2.18.5 Departamento
2.18.6 Afiliación
2.18.7 Sitio
2.18.8 Región
2.18.9 Número de Teléfono del Trabajo
2.18.10 Número de Teléfono de Celular
2.18.11 Número de Teléfono de Localizador
2.18.12 Número de Teléfono de Casa 1
2.18.13 Número de Teléfono de Casa 2
2.18.14 Acceso Largo
2.18.15 Capacidad de Escolta
2.18.16 Escolta Requerida
2.18.17 Supervisor
2.18.18 PIN
2.18.19 Capaz de Evento de Sobre-escribir
2.18.20 Activación de Salida de Propietario de Tarjeta
2.18.21 Fecha de Contratación de Empleado
2.18.22 Fecha y Hora de Activación de Tarjeta
2.18.23 Fecha de Terminación de Contrato del Empleado
2.18.24 Fecha y Hora de Expiración de Tarjeta
2.18.25 Datos del Vehículo – Ilimitados
2.18.25.1
Número de Licencia de Manejo
2.18.25.2
Modelo de Carro
2.18.25.3
2.18.25.4
2.18.25.5
Año de Carro
Fabricante del Carro
Color del Carro
Guía de Especificacón A & E de Sistema de Administración de Seguridad
2.18.26 Datos Personales
2.18.26.1 Número de Seguridad Social
2.18.26.2 Estátus Marital
2.18.26.3 Dependientes Económicos
2.18.26.4 Ciudadanía
2.18.26.5 Peso
2.18.26.6 Altura
2.18.26.7 Color del Cabello
2.18.26.8 Color de Ojos
2.18.26.9 Género
2.18.26.10 Dirección de Casa
2.18.27 Datos de Emergencia
2.18.27.1 Nombre de Pila, Apeídos
2.18.27.2 Relación
2.18.27.3 Número de Teléfono
2.18.27.4 Oficina, Celular, Localizador, Casa 1, Casa 2
2.18.27.5 Selección Primaria
2.19 Aplicaciones de Alta Seguridad y características
2.19.1 Control de Propietario de Tarejta de Supervisor
2.19.2 Anti-Passback
2.19.2.1 Tres tipos de Anti-passback, Suave, Indulgente y Estricto deben
ser soportados
2.19.2.1.1 Suave-Habilidad para automáticamente actualizar los estátus
de tarjetas y otorgar acceso
2.19.2.1.2 Indulgente-Habilidad para negar acceso basado en estátus,
automáticamente actualizar el estátus de tarjeta
2.19.2.1.3 Estricto-Mantener lógica de entrada y salida basado en los
estátus de Estacionamiento, Departamento y Edificio
2.19.2.2
Tres “zonas” de anti-passback serán soportadas
2.19.2.2.1 Estacionamiento
2.19.2.2.2 Departamento
2.19.2.2.3 Edificio
2.19.3 Control de Escolta/Visitante
2.19.3.1
Mantener la tarea de accesar tarjtas para Control de Visitante.
Cada visitante debe ser asignado un estátus de “Escolta Requerido”
requiriendo un empleado con estátus de “Capacidad de Escolta” para
otorgar una entrada válida. La decisión no debe depender en el anfitrión.
2.19.3.2
To d a s l a s i n s i g n i a s d e v i s i t a n t e d e b e n e x p i r a r
automáticamente en la fecha y hora basado en la expiración programada.
2.19.4 Regla de Ocupación Mínima de Dos-Personas (TPMOR) para
aplicaciones de alta seguridad.
2.19.4.1 La característica de TPMOR requiere que las primeras dos (2)
personas utilizen insignia dentro de un área al mismo tiempo antes de que
el acceso sea otorgado. Una vez que el área restringida tiene la ocupación
de las dos personas requeridas, los accesos “uso individual” subsecuentes
deben ser otorgados. El salir el área restringida debe requerir que los dos
Guía de Especificacón A & E de Sistema de Administración de Seguridad
(2) últimos ocupantes salgan al mismo tiempo. Un lector de entrada y
salida debe ser utilizado para la cuenta del área.
2.19.4.2 La característica de TPMOR debe tener la habilidad para
determinar la cuenta de ocupación apropiada durante el acceso por el
personal de Escolta Requerida y Capacidad de Escolta. Los últimos dos
(2) ocupantes no deberán de ser el personal de Escolta Requerida ni de
Capacidad de Escolta.
2.20 Administración de Alarma
2.20.1 El sistema debe tener la habilidad de definir tipos de entrada de alarma
2.20.2 Entradas de contacto Seco o Supervisor
2.20.3 Debe proveer 2 etapas de monitoreos de alarma
2.20.4 Direccionamiento de Alarma
2.20.4.1 La habilidad para “direccionar” mensajes de alarma para
especificar estaciones de alarma por alarma. Si las alarmans no son
“reconocidas” dentro de un tiempo específico de usuario deben tener la
capacidad de ser “direccionadas” a otra estación de trabajo disponible. El
tiempo de direccionamiento de alarma debe ser definido en “minutos”.
2.20.5 Las alarmas deben ser desplegadas en texto o en desplegado gráfico
como una opción.
2.20.6 Los mensajes de alarma deben ser provistos en 2 formas, mensaje
“corto” y “largo”.
2.20.6.1 Los mensajes cortos debe ser utilizados para una transacción de
conexión histórica
2.20.6.2 Los mensajes largos serán utilizados en desplegados de
reconocimiento de alarma por el operador.
2.21 Control y Monitoreo de Puerta
2.21.1 El sistema debe proveer estátus de transacción para detectar:
2.21.1.1 Puerta Cerrada
2.21.1.2 Puerta Mantenida Abierta por Largo Tiempo
2.21.1.3 Puerta Abierta a Fuerza
2.21.2 Estátus de Posición de Puerta debe ser supervisado para prevenir
manipulación
2.21.3 Solicitud a despositivo de Salida (REX) debe ser supervidado para
prevenir manipulación
2.21.4 Debe proveer una anunciación de puerta local para “Puerta Mantenida
Abierta”. Si la puerta no es cerrada después de una duración establecida por
usuario, un mensaje de “Puerta Mantenida Abierta por Largo Tiempo” debe ser
enviado al Anfitrión.
2.22 Control de Elevador
2.22.1 El sistema de Control de Elevador debe ser un controlador inteligente
distribuído al 100%. Todas las decisiones relativas al acceso al piso del elevador
deben ser logradas en el controlador. Ningúna decisión debe ser dependiente del
anfitrión.
Guía de Especificacón A & E de Sistema de Administración de Seguridad
2 En caso de una falla catastrófica debido a falla en la energía o falla del
controlador, el controlador de elevador debe automáticamente fallar al “Modo A
Prueba de Falla”, habilitando que todos los pisos sean accesados.
3 El sistema debe soportar hasta 999 grupos de piso único. Un grupo de piso por
definición consiste de una lista de piso válida y tiempo de acceso a piso válido.
Cuando el acceso es otorgado en un lector decabina de Elevador, el LED verde
de autorizado y la lista válida de dependencias será energizada por un tiempo
predeterminado, permitiendo al usuario seleccionar el botón del piso de destino
apropiado.
4 El sistema debe soportar 4 asignaciones de grupo de piso por propietario de
tarjeta.
5 El sistema debe requerir propietarios de tarjetas para tener acceso al lector de
cabina a través de grupos de autorización antes de activar cualquier asignación
de grupo de piso.
6 El sistema debe requerir la habilidad de habilitar y deshabilitar pisos basado en
activación manual, condición de Evento y períodos de tiempo seleccionados.
7 El sistema debe requerir la habilidad de imprimir reportes históricos de pisos
seleccionados por el propietario de tarjeta.
23
Reportes de Sistema
2.23.1 El sistema debe proveer reportes de todos los archivos de las bases de
datos excepto para los niveles de programa y password. Los reportes deben poder
imprimirse o para un archivo específico. Los reportes deben ser configurados por
usuario y deben tener la habilidad de tener un horario por día y hora.
2.23.2 Los Reportes Personalizados deben tener la capacidad del usuario para
utilizar constructores de reportes certificados SQL, como Reportes Cristal.
2.23.3 Reportes para:
2.23.3.1 Todos los Datos de Entrada de Usuario (Tarjeta, Grupo de
Autorización, Períodos de Tiempo, etc.)
2.23.3.2 Transacciones de Tarjeta
2.23.3.3 Transacciones de Alarma
2.23.3.4 Registro de Operador de Auditoría
2.23.3.5 Reportes Reunidos por Edificio o Departamento
2.23.3.6 Búsqueda por Identificación de Propietario de Vehículo
24Recuperación y Respaldo de Sistema
2.24.1 El sistema debe proveer un respaldo de base de datos “en línea”.
2.24.2 En el evento de una falla catastrófica, el sistema debe tener la habilidad
de “subir” (upload) información desde el controlador inteligente, de regreso a la
base de datos del sistema bajo solicitud del operador y su confirmación.