UNIDADES CENTRALES MAESTRAS PARA …lapem.cfe.gob.mx/normas/pdfs/f/G0100-14.pdf · remotos, ubicados en las instalaciones eléctricas y con ello formando la integración de un sistema

MÉXICO

UNIDADES CENTRALES MAESTRAS PARA CENTROS DE CONTROL DE DISTRIBUCIÓN Y TRANSMISIÓN

ESPECIFICACIÓN G0100-14

OCTUBRE 2016 REVISA Y SUSTITUYE A LA

EDICIÓN DE JULIO 2016

9AJJ8

Texto escrito a máquina

9AJJ8


9AJJ8


9AJJ8


9AJJ8


9AJJ8


9AJJ8


161021

9AJJ8



ESPECIFICACIÓN CFE G0100-14

120713 Rev 160720 161021

CONTENIDO

1 OBJETIVO ___________________________________________________________________________ 1

2 CAMPO DE APLICACIÓN ______________________________________________________________ 1

3 NORMAS QUE APLICAN _______________________________________________________________ 1

4 DEFINICIONES _______________________________________________________________________ 2

4.1 Acciones Interactivas _________________________________________________________________ 2

4.2 Aplicaciones _________________________________________________________________________ 2

4.3 Aplicaciones SCADA __________________________________________________________________ 3

4.4 Consola _____________________________________________________________________________ 3

4.5 Controlador de Comunicaciones ________________________________________________________ 3

4.6 Datos Crudos ________________________________________________________________________ 3

4.7 Función SCADA ______________________________________________________________________ 3

4.8 “Kernel” o Núcleo de un sistema Operativo (“Kernel” del SCADA) ___________________________ 3

4.9 Operador (del sistema) ________________________________________________________________ 3

4.10 Servidor SCADA _____________________________________________________________________ 3

4.11 Sistema _____________________________________________________________________________ 3

4.12 Sistemas Híbridos ____________________________________________________________________ 4

4.13 Tiempo Real _________________________________________________________________________ 4

4.15 Web ________________________________________________________________________________ 4

6 CARACTERÍSTICAS Y CONDICIONES GENERALES ________________________________________ 5

6.1 Configuración General de la UCM _______________________________________________________ 5

6.2 Acceso para Mantenimiento Remoto ___________________________________________________ 19

6.3 Programas del sistema y sistemas Operativos ___________________________________________ 22

6.4 Base de Datos ______________________________________________________________________ 26

6.5 Disponibilidad ______________________________________________________________________ 30

6.6 Tablas de Dimensionamiento y Expansión _______________________________________________ 37

6.7 Mantenimiento del Software ___________________________________________________________ 38

6.8 Requerimientos de SCADA ____________________________________________________________ 38

6.9 Requerimientos de la Interfaz del Usuario _______________________________________________ 59

6.11 Programas de Aplicación _____________________________________________________________ 82

6.12 Requerimientos de Hardware __________________________________________________________ 86



120713 Rev 160720 161021

6.13 Consolas de Operación y de Administración _____________________________________________ 88

6.14 Mobiliario (Opcional) ________________________________________________________________ 92

6.15 Equipamiento para la Visualización Magnificada del sistema Eléctrico (Opcional) ______________ 93

6.16 Tableros Mímicos (Murales de Visualización) ____________________________________________ 94

6.17 Capacitación________________________________________________________________________ 97

7 CONDICIONES DE OPERACIÓN________________________________________________________ 98

7.1 Función Servidor de Comunicaciones __________________________________________________ 98

7.2 Función Servidor “web” ______________________________________________________________ 98

7.3 Función del Servidor de Bases de Datos Histórica ________________________________________ 98

7.4 Dispositivos de Almacenamiento de Datos a Largo Plazo __________________________________ 98

7.5 Equipos Periféricos de Impresión (Impresoras Láser, blanco, negro y a color) _______________ 99

7.6 Características de los Dispositivos para la Comunicación con las UTR’S _____________________ 99

7.7 Requerimientos Físicos y de Diseño de los Equipos ______________________________________ 99

7.8 Desempeño ________________________________________________________________________ 100

8 CONDICIONES DE DESARROLLO SUSTENTABLE _______________________________________ 106

9 CONDICIONES DE SEGURIDAD INDUSTRIAL ___________________________________________ 106

10 CONTROL DE CALIDAD _____________________________________________________________ 106

10.1 Notificación y Documentación de las Pruebas ___________________________________________ 107

10.2 Pruebas de Aceptación ______________________________________________________________ 107

10.3 Pruebas Prototipo al Servidor SCADA _________________________________________________ 110

10.4 Puesta en Sitio ____________________________________________________________________ 111

11 MARCADO ________________________________________________________________________ 112

12 EMPAQUE, EMBALAJE, EMBARQUE, TRANSPORTACIÓN, DESCARGA, RECEPCIÓN,

ALMACENAJE Y MANEJO ___________________________________________________________ 112

13 BIBLIOGRAFÍA _____________________________________________________________________ 112

14 CARACTERÍSTICAS PARTICULARES __________________________________________________ 113



120713 Rev 160720 161021

TABLA 1 - Funciones principales de la unidad central maestra _______________________________________ 6

TABLA 2 - Equipamiento mínimo de las UCM´s para un centro de control _____________________________ 14

TABLA 3 - Clasificación del grado crítico de las funciones de la UCM _________________________________ 31

TABLA 4 - Clasificación de nivel de prioridad de la UCM ___________________________________________ 33

TABLA 5 - Requerimientos de mantenimiento del software __________________________________________ 34

TABLA 6 - Servidores de SCADA, de comunicaciones, Histórico, “WEB”, base de datos o de

aplicaciones ________________________________________________________________________ 87

TABLA 7 - Características de los murales de visualización __________________________________________ 95

TABLA 8 - Características de las pantallas de video ________________________________________________ 95

TABLA 9 - Periodicidad de funciones ___________________________________________________________ 100

TABLA 10 - Períodos para escenarios de prueba _________________________________________________ 101

TABLA 11 - Niveles de actividad _______________________________________________________________ 102

TABLA 12 - Tiempos de respuesta en las consolas _______________________________________________ 104

TABLA 13 - Utilización de recursos _____________________________________________________________ 105

TABLA 14 - Requerimientos de tiempos de recuperación __________________________________________ 105

FIGURA 1 - Arquitectura mínima de una UCM _____________________________________________________ 14

FIGURA 2 - Límites de movimiento del cursor _____________________________________________________ 63

APÉNDICE A _______________________________________________________________________________ 114

APÉNDICE B ________________________________________________________________________________ 140



1 de 154

120713 Rev 160720 161021

1 OBJETIVO

Establecer los requerimientos, capacidades y funciones de las Unidades Centrales Maestras para los Centros de Control de Distribución y Transmisión de la Comisión Federal de Electricidad (CFE).

2 CAMPO DE APLICACIÓN

En los Centros de Control de los niveles de operación de la Subdirección de Distribución y Transmisión.

3 NORMAS QUE APLICAN

Para la correcta utilización de esta especificación, es necesario consultar y aplicar las Normas Oficiales Mexicanas, Normas Mexicanas, Normas Internacionales y documentos normalizados vigentes.

NOM-008-SCFI-2002 Sistema General de Unidades de Medida.

NMX-I-240-NYCE-2015 Telecomunicaciones - Compatibilidad Electromagnética-Interferencia Electromagnética - Límites y Métodos de Medición de las Características de las Perturbaciones de Radio Frecuencia Nominal Producidas por Equipos de Tecnología de la Información.

IEC 60255-5-2000 Electrical Relays - Part - 5: Insulation Coordination for Measuring

Relays and Protection Equipment- Requirements - and Tests. IEC 60255-22-1 -2007 Measuring Relays and Protection Equipment - Part 22-1: Electrical

Disturbance Tests - 1 MHz Burst Immunity Tests. IEC 60255-22-2 - 2008 Measuring Relays and Protection Equipment - Part 22-2: Electrical

Disturbance Tests - Electrostatic Discharge Tests. IEC 60255-22-3-2007 Measuring Relays and Protection Equipment - Part 22-3: Electrical

Disturbance Tests - Radiated Electromagnetic Field Immunity. IEC 60801-1-1984 Electromagnetic Compatibility for Industrial - Process Measurement

and Control Equipment. Part 1: General Introduction. IEC 60870 PT 5-1-1990 Telecontrol Equipment and Systems, Part 5 , Transmission

Protocols. IEC 60870-5-101-2003 Telecontrol Equipment and Systems - Part 5-101: Transmission

Protocols - Companion Standard for Basic Telecontrol Tasks. IEC 60870-5-102-1996 Telecontrol Equipment and Systems - Part 5: Transmission

Protocols - Section 102: Companion Standard for the Transmission of Integrated Totals in Electric Power Systems.

IEC 60870-5-103-1997 Telecontrol Equipment and Systems - Part 5-103: Transmission

Protocols - Companion Standard for the Informative Interface of Protection Equipment.



2 de 154

120713 Rev 160720 161021

IEC 60870-5-104-2006 Telecontrol Equipment and Systems - Part 5 - 104: Transmission Protocols - Network Access for IEC 60870-5-101 Using Standard Transport Profiles.

IEC 60870-6-503-2014 Inter - Control Center Communications Protocol. IEC 61000-1-2008 Electromagnetic Compatibility (Emc) Part 1: General) Part 2:

Environment, Part 3: Limits, Part 4: Testing and Measurement Techniques, Part 5: Installation and Mitigation Guidelines, Part 6: Generic Standards, Part 9: Miscellaneous.

IEC 61968-2003 Application Integration at Electric Utilities – System Interfaces for

Distribution Management. IEC 61970-2005 Energy Management System Application Program Interface IEC 62351-2007 Power Systems Management and Associated Information

Exchange - Data and Communications Security. CFE G0000-45-2008 Simulador (SCADA). CFE L0000-32-2016 Manuales, Procedimientos e Instructivos Técnicos. CFE L0000-36-2005 Consideraciones económicas en la Supervisión del Montaje,

Pruebas y Puesta en Servicio. CFE L0000-51-2014 Procedimiento para la Elaboración, Revisión o Cancelación de

Documentos Normalizados. CFE L1000-11-2016 Empaque, Embalaje, Embarque, Transporte, Descarga, Recepción

y Almacenamiento de Bienes Muebles Adquiridos por CFE. CFE U0000-11-1991 Pruebas para Evaluar el Comportamiento del Equipo Electrónico

en Condiciones de Operación. CFE V7100-19-2010 Baterías Abiertas para Servicio Estacionario.

NOTA: En caso de que los documentos anteriores sean revisados o modificados debe tomarse en cuenta la edición en vigor en la fecha de la convocatoria de la licitación, salvo que la CFE indique otra cosa.

4 DEFINICIONES 4.1 Acciones Interactivas Sin importar que los equipos tengan físicamente un arreglo distribuido, las funcionalidades del sistema, están lógicamente conectadas y pueden ser administradas por medio de puntos sensibles, ligas, íconos u otros elementos que se muestren delegados desde una consola de operación. 4.2 Aplicaciones Software que complementa al software del SCADA de una UCM para extender sus alcances como son las funcionalidades de un sistema para la Administración de Energía (EMS), sistema para la Administración en Distribución (DMS) o web.



3 de 154

120713 Rev 160720 161021

4.3 Aplicaciones SCADA Software que conforma un sistema SCADA, incluyendo el “kernel” del SCADA y las aplicaciones que no son en tiempo real. Las aplicaciones de tiempo real deben funcionar con un respaldo de la información, las que no son de tiempo real, no necesariamente deben estar respaldadas. 4.4 Consola Interface hombre-máquina mediante la cual el usuario tiene acceso a los dispositivos remotos, configuración, administración del sistema y explotación de información para atender las funciones de la operación del sistema eléctrico. 4.5 Controlador de Comunicaciones Parte del servidor SCADA que tiene como función el manejo de las comunicaciones con sus protocolos de comunicaciones ya sea por puertos seriales o por la red LAN/WAN de la UCM y que interactúan con otros dispositivos de “hardware” como son los Switch, Routers o “firewall”/IPS. 4.6 Datos Crudos Información numérica binaria contenida en los mensajes de un protocolo de comunicaciones, que por lo general el valor decimal máximo analógico que se espera obtener, están referenciados al valor binario máximo que puede manejar el protocolo. Estos números binarios se le denominan “cuentas”, “cuentas brutas” o “datos crudos”. 4.7 Función SCADA Supervisar, controlar y adquirir datos necesarios para la operación y administración del sistema eléctrico. 4.8 “Kernel” o Núcleo de un sistema Operativo (“Kernel” del SCADA) Software responsable de facilitar a los distintos programas, acceso seguro al hardware de la computadora , gestiona recursos a través de servicios de llamada al sistema, también se encarga de decidir qué programa puede hacer uso de un dispositivo de hardware y durante cuánto tiempo multiplexándolo. 4.9 Operador (del sistema) Persona debidamente capacitada para ejercitar todas las funcionalidades de la Unidad Central Maestra a través de consolas o terminales de operador, que están dedicadas a la operación de un sistema eléctrico mediante dispositivos remotos, ubicados en las instalaciones eléctricas y con ello formando la integración de un sistema SCADA. Durante la instalación, puesta en sitio y puesta en servicio del sistema, el proveedor es responsable de realizar todas las actividades necesarias para su operación. 4.10 Servidor SCADA Hardware y software encargado de proporcionar los servicios relacionados con las funciones del “kernel” del SCADA. 4.11 Sistema Conformado por todos los componentes de hardware y software que interactúan para realizar las funciones necesarias para la operación y administración de un sistema eléctrico. En el cuerpo de este documento se emplea el término UCM o sistema en forma indistinta para referirse al mismo concepto.



4 de 154

120713 Rev 160720 161021

4.12 Sistemas Híbridos Se refiere al uso de otros sistemas operativos que no cumplen con lo indicado en el numeral 6.3 de la presente especificación, funcionando en servidores, consolas o terminales de operador y administrador, además del sistema operativo requerido para los servidores SCADA y de comunicaciones (para protocolos SCADA) que operan en una misma Unidad Central Maestra. 4.13 Tiempo Real Es el término empleado para indicar que la información que se recibe en un sistema es válida y actual para la toma de decisiones. 4.14 Web El sistema de documentos interconectados por enlaces de hipertexto, que se ejecutan en internet/Intranet. 5 SÍMBOLOS Y ABREVIATURAS AOR Área de responsabilidad (Área of Responsibility). CAD Diseño Asistido por Computadora (Computer Aided Design). CCT Centros de Control de Transmisión. CCD Centro de Control de Distribución. CFE Comisión Federal de Electricidad. DMS Sistema para la administración de distribución (Distribution Management System). DMZ Zona desmilitarizada (Demilitarized zone). DNP3 Protocolo de red distribuida versión 3 (Distributed Network Protocol). EMS Sistema de administración de energía (Energy Management System). GIS sistema de Información Geográfica (Geographical Information System). IPS Sistema de prevención de intrusos (Intrusion-Prevention System). LAN Red de área local (Local Área Network). MZ Zona militarizada (Militarized zone). NAS Sistema de almacenaje en red (Network Attached Storage). OJT Entrenamiento en el trabajo. (On the job training). RAID Arreglo de discos redundantes e independientes (Redundant Array of Independent Disks). SCADA Control supervisorio y adquisición de datos(Supervisory Control And Data Acquisition).



5 de 154

120713 Rev 160720 161021

TCP/IP Protocolo de control de Transmisión/protocolo de “internet” Transmission Control Protocol internet Protocol).

UCM Unidad Central Maestra. UI Interfaz de usuario (User Interface). UTC Significa en español “Tiempo Universal Coordinado” y es una variante de las siglas del inglés CUT y de

las siglas del francés TUC. UTR Unidad Terminal Remota. 6 CARACTERÍSTICAS Y CONDICIONES GENERALES La UCM está conformada por todos los componentes que interactúan para realizar adquisición de datos y utilizarlos para la operación y administración de un sistema eléctrico. En el cuerpo de este documento se emplea UCM o sistema en forma indistinta para referirse al mismo término. 6.1 Configuración General de la UCM 6.1.1 Características funcionales

El proveedor debe suministrar una UCM integrada y completamente funcional que cumpla con los requisitos de esta sección. Las funciones principales del sistema, para los centros de control se muestran en la tabla 1, las funciones que se indican como “M” deben ser mandatorias. Las funciones opcionales que se soliciten como mandatorias deben ser detalladas en un apéndice o una especificación adjunta a la presente que debe incluirse a la especificación.



6 de 154

120713 Rev 160720 161021

TABLA 1 - Funciones principales de la unidad central maestra

Funciones principales

Centro de control

CCT CCD

Análisis de red en modo de estudio y tiempo real M N/A

Aplicaciones pre-despacho y post-despacho M N/A

Simulador de adiestramiento del operador M O

Comunicación con sistemas externos (de la CFE o de otras empresas)

M M

Sistema de información histórica M M

Sistema de Ingeniería de Datos (Administración y Mantenimiento del sistema)

M M

“Kernel” SCADA M M

Interfaz de usuario (UI) M M

Otros servicios “web” M M

Aplicaciones SCADA M M

Switch, ruteador / (“firewall”) M M

IPS M O

TASE.2 y DNP3 M M

Servidor de comunicaciones M M

Interfaz con sistemas y aplicaciones fuera de línea utilizando al menos XML, ODBC, Data Provider y SQL

M M

Integración de desarrollos de la CFE para la administración de licencias y relatorio

M M

Procesador de topología N/A O

Flujos de potencia en línea para desbalanceo de 3 fases M O

Análisis de contingencia M O

Análisis en modo estudio M O

Continúa…



7 de 154

120713 Rev 160720 161021

…Continuación

Análisis de corto circuito O O

Administración de la tensión/potencia reactiva N/A O

Análisis de pérdidas O O

Monitoreo visual de equipos e instalaciones. O O

Detección de fallas, ubicación, aislamiento y restablecimiento del servicio

O O

NOTA: O = Opcional M = Mandatorio N/A = (No aplica)

6.1.1.1 Administración de la tensión y potencia reactiva Optimización de la distribución de potencia en las redes mediante el control de la tensión y la potencia reactiva para obtener beneficios económicos óptimos, con la reducción de reactivos, recorte de cargas máximas en las horas de máxima demanda, reducción de pérdidas y algoritmos para la operación del sistema eléctrico con valores bajos de tensión sin sobrepasar los límites mínimos permitidos con la finalidad de obtener ahorros de energía. 6.1.1.2 Análisis de contingencia Consiste en la reproducción de una falla o una serie de fallas ya ocurridas durante un evento climático o de otro tipo, que provocó situaciones en el sistema eléctrico, que requiere un análisis para tomar acciones preventivas o correctivas en el futuro para una mejor operación del sistema eléctrico. 6.1.1.3 Análisis de corto circuito Lleva un seguimiento de las fallas y el nivel de corto circuito en cada una de ellas, estableciendo las condiciones de buses de subestación enlazados, las aportaciones por generación y los factores que contribuyen para aumentar o disminuir los niveles de corto circuito en las subestaciones y redes de distribución, con la finalidad de poder tomar las acciones pertinentes en la planeación y reestructuración del sistema eléctrico. 6.1.1.4 Análisis de pérdidas Consiste en realizar los análisis que causan pérdidas en el sistema, debido a factores como los desbalances de carga en los equipos de distribución, por factor de potencia y pérdidas tanto técnicas como no técnicas, obtenidas de la medición. Las pérdidas técnicas son atribuibles a los equipos, las pérdidas no técnicas son atribuibles a robos y fraudes. 6.1.1.5 Aplicaciones de red en modo estudio y tiempo real Conjunto de funcionalidades consideradas dentro de un sistema SCADA-EMS, entre las cuales se puede mencionar principalmente: 6.1.1.5.1 Estimador de estado Tiene como funciones principales detectar mediciones erróneas y proporcionar una salida de mediciones consistente para las demás aplicaciones.



8 de 154

120713 Rev 160720 161021

6.1.1.5.2 Flujos de carga Herramienta utilizada para hacer simulaciones del sistema eléctrico con la salida proporcionada por el estimador de estado. 6.1.1.5.3 Análisis de contingencia Herramienta que permite realizar un conjunto de simulaciones programadas a partir de la salida del estimador de estado, permitiendo detectar en línea cuáles de las contingencias programadas son riesgosas para el sistema eléctrico. 6.1.1.5.4 Flujos óptimos de potencia Herramienta que utiliza algoritmos de optimización para determinar los valores que deben tomar las variables de control como pueden ser: tensión de generación, potencia de generación, posición del cambiador de derivaciones de transformadores (TAP), que permitan obtener mínimos costos de generación y menos valores en pérdidas, menos maniobras de control para que el sistema eléctrico opere dentro de límites.

6.1.1.5.5 Cálculo de fallas

Herramienta que permite determinar la severidad de una falla en un cierto punto del sistema eléctrico.

6.1.1.6 Análisis en modo de estudio

Utilizado para obtener una solución a una problemática presentada en el sistema eléctrico a partir de la información almacenada en el histórico del sistema SCADA con la posibilidad de complementarla con otras fuentes de información corporativa, por ejemplo la extrapolación de datos para observar hacia el futuro un crecimiento de población, de demanda, de instalaciones que pueden causar problemas con la calidad de la energía. 6.1.1.7 Control automático de generación Sistema autónomo encargado de controlar las características de la energía que se suministra al sistema eléctrico de un conjunto de generadores.

6.1.1.8 Detección de fallas, ubicación, aislamiento y restablecimiento del servicio

Este módulo utiliza algoritmos a partir de la información disponible en el sistema, para que una vez detectada una falla, ubique su localización, proceda al aislamiento de la misma y el restablecimiento de las secciones no falladas del circuito mediante el seccionamiento en la red de distribución, reduciendo con esto el tiempo de duración al usuario del servicio eléctrico. 6.1.1.9 Flujos de potencia en línea para desbalanceo de 3 fases

Como resultado de los altos costos de la infraestructura para el monitoreo remoto que generalmente se limita a los equipos dentro de la subestación y hasta el alimentador de distribución. El módulo de los flujos de potencia calcula y presenta de manera individual para cada fase, las tensiones, las corrientes y las pérdidas en toda la red de distribución, basándose en los perfiles de carga estimados en los puntos de suministro a los clientes de distribución, tensiones de barras y otras mediciones SCADA dentro de la subestación y alimentadores. Proporciona una herramienta para la detección de problemas del sistema eléctrico incluyendo el rebasamiento de límites de tensión, pérdidas en el sistema eléctrico y desbalance de las fases. Estos cálculos precisos de flujo de carga también proporcionan información para otras funciones de optimización y de recuperación de un DMS. Presentación de los cálculos de flujo de carga en despliegues geográficos y esquemáticos, los cálculos se llevan a cabo inmediatamente después de la ocurrencia de los eventos del sistema, permitiendo al operador, ver y evaluar rápidamente las situaciones críticas del sistema eléctrico. La baja tensión al final de los circuitos puede ser alarmada mediante este módulo de flujos de carga.



9 de 154

120713 Rev 160720 161021

6.1.1.10 “Kernel” del SCADA Programa que utiliza el usuario, para interactuar con el “Kernel” del sistema operativo para ejecutar las funciones que deben operar en tiempo real como son:

a) Adquisición de datos. b) Cálculos /Conversiones.

c) Monitoreo de puntos analógicos.

d) Monitoreo de puntos discretos.

e) Valores acumuladores.

f) Monitoreo de situación.

g) Control.

h) Despliegue de la información de tiempo real.

i) Procesamiento de alarmas.

j) Cálculos periódicos.

k) Procesamiento de eventos.

l) Registro y almacenamiento de la información Histórica.

m) Establecimiento de la comunicación con otros sistemas.

6.1.1.11 Simulador de adiestramiento del operador Equipamiento de “hardware” y “software” que presenta la misma interfaz gráfica que un sistema SCADA-EMS/DMS, pero que a diferencia de este último, varía con una cierta periodicidad los valores de carga y generación siguiendo un patrón determinado por el instructor, obteniendo como resultado un conjunto de mediciones consistente. Tiene las mismas funcionalidades que el sistema SCADA-EMS/DMS, de manera que al operador se le presenta una visualización lo más parecida al que utiliza en la operación diaria del sistema eléctrico de potencia, con la ventaja de que en éste, se pueden reproducir eventos que han sucedido o que se ha detectado que pueden poner en riesgo la integridad del sistema eléctrico. 6.1.2 Requisitos generales Cuando se solicite en Características Particulares se debe entregar el código fuente de todo el software empleado para realizar las funciones de la UCM o proporcionar las garantías solicitadas para permitir la continuidad en la operación de la UCM. La UCM debe estar basada sobre una arquitectura distribuida, que consiste en algunos o todos de los siguientes componentes:

a) Servidores SCADA redundantes. b) Los servidores de puertos seriales deben ser redundantes.



10 de 154

120713 Rev 160720 161021

c) Redes de Área Local (“LAN”) y área amplia (“WAN”) redundantes con equipos que soporten la funcionalidad de “Switch”, Ruteador/“firewall”/IPS, “Gateways”, “Bridges”, procesadores y equipos de comunicaciones, según sea requerido.

d) Sistemas de administración de la red.

e) Consolas de operador, administración o ingeniería con interfaz de usuario.

f) Interfaz de usuario para los servicios web.

g) Equipo periférico del usuario.

h) El Protocolo de internet debe cumplir con las versiones 4 (IPv4) y 6 (IPv6).

Todos los servidores y procesadores del sistema deben tener acceso de manera individual desde cualquier consola o terminal local o externa a éste, siempre que se cumplan con las condiciones de seguridad para su acceso, mediante la IP correspondiente. La falla de cualquier procesador no debe evitar el funcionamiento apropiado de cualquier ruta de datos o dispositivo conectado a otros procesadores. Las consolas deben estar lógicamente conectadas a cualquiera de los sistemas funcionales usando solamente acciones interactivas en las consolas como puntos sensibles en desplegados, ligas e iconos. El operador del sistema no debe de introducir ningún dato adicional para lograr el acceso que desea. El operador o usuario debe firmar únicamente una vez en la UCM y esta contraseña debe ser válida para todas las funcionalidades de sistema, aplicaciones SCADA y productos de terceros a los que esté autorizado “single sign on”. Se debe considerar lo siguiente para el diseño del sistema: Las principales funciones pueden ser distribuidas en diferentes procesadores según se requiera para cumplir con el desempeño y disponibilidad de acuerdo con el numeral 6.5 (Disponibilidad). Todos los componentes del sistema deben estar interconectados usando una red de área local redundante. La red “LAN” debe tener parte “MZ” (protegida por “firewall”) y “DMZ” (fuera del “firewall”). Las componentes del sistema necesarias para mantener la operación de las funciones críticas deben tener respaldo automático por medio de los siguientes métodos:

i) Sistema de componentes redundantes con respaldo en caliente (“Hot Standby”). En esta configuración, una unidad redundante es mantenida en estado (“Hot Standby”) y se realiza una transferencia automática sí la unidad primaria falla. Las unidades redundantes se mantienen en comunicación permanente (heart beat) para establecer el estado de salud de cada una. La configuración de este tipo de redundancia se debe tener al menos en: - Servidores. - “LAN” “switches”/Ruteadores/“firewall”s/IPS.

j) Utilización de capacidad de procesamiento de respaldo de otras componentes activas del sistema. k) Arreglo de discos duros redundante, en arreglos de cualquier tipo de configuración RAID

(1, 0+1, 1+0 y 5) conforme al diseño y propuesta del fabricante, garantizando el desempeño y seguridad en la operación del sistema, teniendo al menos la redundancia en donde reside el sistema operativo con los servidores SCADA y las bases de datos de información de tiempo real. El fabricante debe comprobar que el arreglo seleccionado cumple con lo solicitado en la presente especificación.



11 de 154

120713 Rev 160720 161021

l) Redundancia en fuentes de alimentación (al menos N+1):

- Cada unidad del sistema debe ser reemplazada, ampliada o actualizada por medio de un cambio sencillo o "plug-in" sin afectar el resto del sistema y sin requerir ninguna modificación de software.

- El reemplazo o actualización de cualquier unidad del sistema no debe afectar la

funcionalidad de los otros subsistemas que residen en los otros componentes. - La configuración del sistema, debe estar basado en estándares abiertos, con una

arquitectura que sea actualizable de manera vertical (actualizar el equipo existente) y horizontal (agregar más equipos).

- La falla de un procesador o cualquiera de sus periféricos asociados con una función crítica

no debe causar ninguna otra falla o cese de actividad en otro procesador. - Aunque la base de datos puede estar físicamente distribuida en todo el sistema, este debe

estar creado a partir de una sola versión lógica de la base de datos, en la cual toda la información definida en ella debe ser entrada solamente una vez. Para llevar a cabo las configuraciones del sistema, la carga de datos de la UCM y de sus aplicaciones, tratándose de una migración de un antiguo sistema al nuevo sistema adquirido, se acepta para el proceso de la transferencia de datos (poblar la base de datos), la utilización de archivos planos de texto, convirtiéndolos a tablas manejadoras de bases de datos comerciales para a su vez pasarla a la base de datos optimizada (de tiempo real) que utilice el sistema del proveedor. Además, el proveedor del nuevo sistema, debe proporcionar las herramientas de “software” a la CFE, que permitan la población de la base de datos de la nueva UCM, para lo cual la CFE debe entregar al proveedor los archivos de texto plano de la antigua UCM. Una vez que la UCM ya se encuentra en operación o producción, las configuraciones, actualizaciones o modificaciones a las bases de datos de la nueva UCM, no se acepta que éstas se hagan mediante archivos planos de texto, sino con tablas de manejadores de datos comerciales, que deben estar incluidas en la propia UCM. Esta información debe ser complementada y detallada en la ingeniería de datos que la CFE debe entregar al proveedor del sistema, en donde se detalla el trabajo diario de la administración de la base de datos.

- Las características de seguridad cibernética del sistema por medio de “hardware” y

“software” acorde con lo especificado deben estar incluidas para asegurar que solamente los usuarios autorizados pueden acceder al sistema, a sus datos y a sus funciones y la menor vulnerabilidad posible a ataques cibernéticos, siguiendo estándares de protección de infraestructura crítica de acuerdo a la referencia [1] del capítulo 13 de esta especificación y la norma IEC 62351 para la red de comunicación y sistema de seguridad.

- Todos los dispositivos de entrada/salida del sistema de tiempo real deben ser conmutables o

redundantes de tal forma que los dispositivos que fallen deben ser automáticamente reemplazados en sus funciones por los dispositivos de respaldo.

- La falla de cualquier procesador no debe resultar en la pérdida de ningún dato en virtud de

que el sistema es redundante y contiene los mecanismos de recuperación de información. - El equipo del sistema UCM, debe ser energizado desde diferentes fuentes de suministro de

energía , para ello cuenta con una infraestructura de UPS de emergencia, de tal forma que la pérdida de una fuente de energía no resulte en la pérdida de ninguna función crítica, ya que debe ser un sistema redundante en su equipamiento con fuentes de alimentación independientes.



12 de 154

120713 Rev 160720 161021

- El sistema debe estar diseñado para proveer una fácil detección de problemas y reparación a nivel de reemplazo de tarjetas por técnicos capacitados. El reemplazo de un elemento del sistema no debe causar que alguna función crítica quede indisponible durante o después del procedimiento de reemplazo.

- Los subsistemas deben ser capaces de comunicarse con los siguientes medios:

∙ Protocolos que empleen como transporte TCP/IP para comunicaciones internas al

sistema y comunicaciones con otros sistemas de computadores tanto locales como remotos utilizando “Gigabit ethernet” a velocidades de 10/100/1 000 Mbps, pudiendo ser cobre o fibra óptica.

∙ Comunicarse con aplicaciones de mensajes de TASE.2 referenciadas en la norma

IEC 60970-6-503 (Secure TASE.2). ∙ Protocolos de red que se comuniquen con concentradores de datos tanto locales

como remotos utilizando por lo menos protocolo DNP3 sobre TCP/IP y serial. El DNP3 debe cumplir con:

Las funcionalidades del perfil del protocolo requerido y con las reglas y recomendaciones del grupo de usuario. De acuerdo al Apéndice “A” de esta especificación.

En Características Particulares se debe indicar la tabla del dimensionamiento correspondiente a la cantidad de señales requeridas de acuerdo a la instalación referida.

∙ Los protocolos adicionales a los que se indican en la presente especificación, se debe indicar en Características Particulares, así como los requerimientos particulares para inicializar en toda la gama que permite el perfil solicitado o adaptar las comunicaciones ya existentes en campo, con las nuevas Unidades Centrales Maestras.

En la UCM se deben tener las herramientas para configurar, recibir, enviar, procesar e interpretar las siguientes funciones del DNP3:

Bandas muertas en los analógicos.

Diferentes formatos, según el perfil entregado. Banderas de calidad. Definir los límites de las señales analógicas y acumuladores para que reporten como eventos, cuando sean rebasadas. SOE en estados y analógicos. Poleos por tiempo, objeto o evento. Poleos por secuencia de dispositivos. Poleos para inicialización del sistema. Atender de manera automática las señalizaciones internas del protocolo (IIN).



13 de 154

120713 Rev 160720 161021

Después de la ejecución de un mando, automáticamente debe polear las señales asociadas a ese punto.

∙ La Unidad Central Maestra, debe tener los medios, herramientas y opciones en el

“software”, que le permitan al usuario de la UCM (persona encargada de la administración del sistema) realizar la configuración de los objetos, variaciones y calificadores así como de lo indicado en el perfil del nivel solicitado por la CFE, tanto a nivel maestro como esclavo.

∙ Cada interfaz “LAN” interna de cada procesador debe ser redundante y estándar , la

“LAN” debe operar a una velocidad de 1 000 Mbps para soportar los requerimientos de desempeño especificados. La falla de algún procesador o “LAN” en sí misma no debe impedir la operación apropiada del resto de los procesadores.

∙ Los dispositivos estándares de manejo de la red deben ser suministrados para

monitorear y manejar todas las “LAN” interconectadas del sistema vía el sistema de administración de la red de la UCM basado en el protocolo estándar internacional SNMP. Se deben proporcionar los MIBS necesarios para la administración.

∙ En caso de que se utilicen sistemas híbridos, en donde la presente especificación lo permita, en esos servidores distintos al SCADA y de comunicaciones de protocolos, se debe proporcionar la seguridad a los subsistemas, para lo cual debe contar con antivirus apropiado, el cual debe mantenerse actualizado en forma automática hasta el término del período de garantía. En caso de utilizarse otros productos de “software” de terceros, complementarios a las aplicaciones de la UCM tales como procesadores de palabras u hojas de cálculo entre otros, el proveedor de la Unidad Central Maestra debe considerar el suministro completo, aun cuando la CFE posea licencias o contratos corporativos.

∙ Lo anterior debido a la importancia que tiene el equipo SCADA para la operación del sistema eléctrico, por lo que no puede quedar detenido el proceso de puesta en servicio y en operación por un posible problema de versión de licencias y compatibilidad de “hardware” entre otros.

∙ El dimensionamiento de los equipos, debe ser establecido por el proveedor ya que a él le corresponde cumplir con los requisitos funcionales de desempeño y disponibilidad de la presente especificación.



14 de 154

120713 Rev 160720 161021

6.1.3 Configuración General de la UCM

La UCM debe operar en un ambiente de procesamiento distribuido, basando su arquitectura en una red de área local redundante (“LAN”) consistente en diversos nodos de los cuales deben estar conectados otros equipos de procesamiento tales como servidores y consolas entre otros. La configuración propuesta típica de una UCM se presenta en la figura 1. En cada UCM se deben incluir redes de alta velocidad de 10/100/1 000 Mbps. con base en “Gigabit ethernet” para interconexión de los servidores principales y los de respaldo, estaciones de trabajo así como sus periféricos.

FIGURA 1 - Arquitectura mínima de una UCM

El equipamiento mínimo para una estación maestra es el que se muestra en la tabla 2, sin embargo en caso de requerirse equipo adicional, se debe indicar en Características Particulares, así mismo en esa sección se debe indicar los requerimientos del “software” de aplicación relacionados con el sistema SCADA (EMS y DMS) que le permita al fabricante estimar y evaluar el dimensionamiento y el desempeño de los equipos que debe suministrar cada uno de los subsistemas de la UCM y el dimensionamiento de interfaces de comunicación de cada servidor de comunicaciones (primario y secundario) para los enlaces entre las UCM´s y las UTR’s.

TABLA 2 - Equipamiento mínimo de las UCM´s para un centro de control

Descripción Cantidad

Servidor SCADA, históricos y aplicaciones 2

Servidor “web” 1

Consolas de operación 2

Monitores por consola de operación 2

Consola de mantenimiento (con 2 monitores) 1

“Switch” y “firewall” 2

Impresora láser a color 1

Sistema estándar de tiempo y frecuencia sincronizado con GPS (2

relojes GPS y 2 antenas) 1

NOTA: 20 conexiones concurrentes de usuarios



15 de 154

120713 Rev 160720 161021

6.1.3.1 Servidores SCADA Estos servidores deben ejecutar funciones de supervisión, control, adquisición de datos, procesamiento, transferencia de información histórica y comunicaciones con otros sistemas y protocolos. Las principales funciones son el procesamiento de datos, la conversión de los datos crudos a unidades de ingeniería y la detección de cambios en los datos adquiridos. Cuando por razones del dimensionamiento del sistema sea necesario separar las funciones del servidor SCADA, se debe entregar dos servidores adicionales: primario y respaldo, para cumplir con los desempeños requeridos, el caso típico seria separar las funciones de comunicación (servidores de comunicaciones). La CFE puede solicitar en Características Particulares si requiere servidores de comunicación independientes a los servidores SCADA, debido a los requerimientos propios de la CFE.

6.1.3.2 Aplicación del servidor de comunicaciones de la UCM Las comunicaciones de la UCM deben ser redundantes y realizar las funciones que se enumeran a continuación:

a) Realizar la adquisición de datos, supervisión (mediciones y estados) y control de interruptores a través de UTR’s y otros elementos que realicen adquisición de datos y control. El servidor de comunicaciones debe realizar las funciones de empaquetamiento y desempaquetamiento de los protocolos usados para comunicarse con las UTR’s y dispositivos de campo. El empaquetamiento debe consistir en mapear los protocolos seriales a las capas necesarias del modelo OSI. En esta condición se tendrán funciones de “pooling”.

b) Disponer de las interfaces de comunicación para las funciones SCADA de UTR’s, dispositivos

electrónicos inteligentes (IED) y elementos finales (End Devices) con sus respectivos protocolos. c) Debe de proveer los puertos necesarios para conectar a los dispositivos de campo. Los puertos

deben soportar que el usuario les asigne el tipo de modem a usar (norma), el tipo de medio que puede ser analógico o digital, el protocolo, patrones de datos: bits síncrono, bytes síncrono o asíncrono, tiempo de pretransmisión y post transmisión, así como el resto de las señales de control. Los puertos suministrados deben ser del tipo servidor de puertos seriales (terminal server) de manera que para agregar puertos adicionales, solo debe agregarse otro servidor de puertos. En resumen, el puerto debe ser totalmente configurable. La cantidad y tipo de puertos se debe indicar en Características Particulares.

d) Conversión y procesamiento completo de todos los datos recibidos. e) De la información del protocolo maestro y esclavo, transferir fielmente hacia los niveles superiores,

la información recibida de los niveles inferiores, incluyendo las banderas de calidad. Estas banderas deben ser producto del procesamiento local o transmisión de las banderas recibidas desde los elementos primarios como pueden ser los IED´s y UTR´s.

f) Detección y reporte hacia niveles superiores de problemas con los elementos primarios de

adquisición de datos de forma que el sistema de control pueda estar informado de los problemas de estos elementos primarios. Esto debe incluir pero no estar limitado a: fallas de las UTR’s, fallas de los IEDs, fallas de concentradores remotos y fallas de comunicaciones.



16 de 154

120713 Rev 160720 161021

g) Debe contar con la función “modo escucha”, la cual tiene como propósito poner a prueba la base de datos del mapa de puntos de los dispositivos de campo o UTR´s en las puestas en servicio de una nueva UCM que debe operar en sustitución de otra ya existente. Su función es la de activar el canal o los canales de comunicación por la que la UCM original, se encuentra operando, de modo que la nueva UCM, esté receptiva a las solicitudes, respuestas y cambios que se registren en el sistema existente, activando las alarmas, mediciones, cambios de estado, eventos tal y como si la nueva UCM fuera la que estuviera haciendo las exploraciones, pero con la premisa de que no debe tomar ninguna acción activa hacia el campo.

h) Soporte para la adquisición, despliegue y distribución de la hora exacta recibida del reloj satelital

GPS a los otros nodos de procesamiento sobre la UCM de tiempo real del centro de control vía el software “Network Time Protocolo” (NTP) que corre en todos los servidores y estaciones de trabajo.

6.1.3.2.1 Requerimientos para el protocolo de comunicaciones DNP3

Todos los objetos, variaciones, calificadores, así como las distintas configuraciones que se solicitan en el perfil del protocolo DNP3 por la CFE o que sean aceptadas en la licitación, deben quedar accesibles para la administración del usuario de la UCM, tanto al nivel maestro como al nivel esclavo, de manera que no quede el protocolo limitado en su aplicación hacia el exterior de la UCM por falta de desarrollo del “software” de aplicación en las consolas de operación o de administración del sistema. La UCM debe tener en el software de aplicación, los accesos para la configuración de los distintos modos de exploración (barridos o poleos) hacia los dispositivos esclavos (UTR´s), permitiendo que para estas exploraciones:

a) Los equipos de campo puedan ser agrupados en secuencias. b) Ordenar la ejecución de las secuencias. c) Programar los tiempos de latencia entre exploraciones y entre secuencias. d) Realizar exploraciones por frecuencia. e) Programar tiempos de latencias entre secuencias y órdenes de secuencia para recepción de

mensajes no solicitados. f) Configuración de los tiempos de pre y post transmisión de manera general e individual por

dispositivo.

La UCM, debe llevar estadísticas de comunicaciones por hora, considerando que los mensajes deben ser exitosos bajo el criterio de que:

a) Los mensajes que son en un solo sentido (UCM-UTR tal como el de “Broadcast”), al salir del puerto (socket) de comunicación de la UCM son exitosos, sin importar que exista la confirmación de que el receptor haya recibido correcta o incorrectamente el mensaje.

b) Mensajes del tipo solicitud-respuesta en cualquier sentido (UCM-UTR o viceversa), son

considerados exitosos, solo cuando se ha completado el ciclo de comunicación desde el punto de vista de la UCM, incluyendo las confirmaciones que son obligatorias dentro de las reglas del DNP3 o porque son configuradas por el usuario.

En concordancia con el inciso b) anterior, se debe permitir la programación de criterios para discriminar de la exploración a dispositivos que presentan fallas de comunicación ya sea que se tengan canales de comunicación alternos o cuando no se tengan, como se menciona en el punto



17 de 154

120713 Rev 160720 161021

6.1.3.2.1 incisos b) y c), en el que la UCM debe dar aviso al operador mediante mensajes o eventos, cuando se presenten alguna de las siguientes:

- Falla de comunicación en dispositivo: Es configurable por el usuario y es el número de veces

que se interrogó a un dispositivo (UTR) y no respondió en ninguna de ellas (mensajes fallidos). Se considera que el restablecimiento de falla de comunicaciones en dispositivo es también un número de veces configurable por el usuario, en que el dispositivo remoto ha respondido a la solicitud de la UCM.

- Baja eficiencia de comunicación: Es configurable por el usuario y corresponde a un

porcentaje por dispositivo (UTR), del número de mensajes exitosos, entre el total de mensajes exitosos y fallidos acumulados por hora. Igualmente que en el inciso anterior, se debe considerar una eficiencia de comunicación recuperada cuando se ha alcanzado un nivel de eficiencia configurado por el usuario, mayor que el establecido como baja eficiencia.

Debido a que el cálculo de las eficiencias de comunicaciones es por hora, deben tomarse consideraciones para que los valores o los mensajes o eventos anunciados en la hora anterior, no se dupliquen, así como un nuevo cálculo por el cambio de hora o por arranque de la UCM considere la acumulación de cierta cantidad de mensajes, antes de anunciar el mensaje o evento.

La configuración de lo descrito anterior, debe aceptar también que no se activen estas funciones.

6.1.3.3 Consolas para el operador del sistema eléctrico

Las consolas de operador deben ser conectadas a la red de área local empleando el protocolo TCP/IP. Estos equipos deben tener la configuración para que cuando se realice un barrido sobre una UTR, una vez que la información es recibida en la UCM, el tiempo de espera para desplegar la información en pantalla, no debe ser mayor a 2 s. Cada consola debe estar preparada para la conexión de 4 monitores. La cantidad de consolas de operador y el número de licencias a suministrarse se debe definir en Características Particulares. Debe soportar la configuración de restricciones adicionales dentro del software del sistema con relación a qué funciones se permiten realizar en cada usuario de cada consola. Esta característica se denomina modos de operador. La función de modos de operador puede ser empleada para asignar las responsabilidades de un usuario que opera la consola, de modo que el puesto de la consola quede restringido a operaciones asociadas con su área de responsabilidad y no puede realizar funciones correspondientes a otras áreas. Además la función de modo de operador debe específicamente prohibir ciertas funciones en base a cada usuario.

6.1.3.4 Sistema de información histórica / servidor de base de datos

6.1.3.4.1 Sistema de información histórica El propósito primordial del sistema de información histórica, es el de almacenar toda o parte de la información de la base de datos de tiempo real de la UCM, y la de permitir que esta información esté disponible para su acceso desde otras computadoras y de otras disciplinas corporativas (por ejemplo, Distribución y Transmisión entre otros) que cuenten con los privilegios para ello. El sistema de información histórica debe utilizar tecnología de compresión y puede correr en un servidor independiente o en el mismo servidor SCADA cumpliendo con los desempeños que se indican en la presente especificación. Debe contar con un sistema de respaldo físico, y estar interconectado a la red local de la UCM.



18 de 154

120713 Rev 160720 161021

6.1.3.4.2 Servidor de base de datos La función primaria de la base de datos es almacenar y mantener los elementos de la base de datos fuente manteniendo la consistencia en una base de datos relacional que tenga activa la función de replicación de las cuales se deben generar las estructuras de la base de datos de tiempo real del sistema. 6.1.3.5 Servidor web Se debe suministrar un servidor para proporcionar servicios web. El servidor web debe ser el mecanismo de visualización de la información de tiempo real o histórica requerida por usuarios corporativos o usuarios externos autorizados, empleando herramientas de acceso con navegadores de “internet” comerciales. Los desplegados que se muestren en los navegadores web deben ser creados a partir de los mismos que usa el operador y ser consistentes en lo referente al diseño, colores y fuentes (no se deben crear desplegados específicos para el “web” en forma manual). Los botones de control, las ayudas de navegación, los mensajes de las ventanas, deben tener localización y diseño uniforme en todo el sistema. Se deben suministrar ayudas de navegación que permitan a los usuarios determinar con facilidad que tipo de desplegado que se está mostrando y permitir las facilidades de movilización en el desplegado actual y en otros desplegados. El servidor “web” debe soportar el acceso de clientes de los exploradores comerciales disponibles en el mercado. No deben existir restricciones en cuanto a emplear una versión específica del explorador u otras aplicaciones necesarias. Debe de soportar la configuración de restricciones de visualización por usuario y por desplegado que cumpla con la misma filosofía de las áreas de responsabilidad del sistema. 6.1.3.6 Arquitectura del sistema 6.1.3.6.1 Arquitectura para la seguridad del sistema Cada uno de los dispositivos del sistema suministrados, deben quedar dentro de áreas de seguridad claramente definidas a las que se le debe denominar “MZ” y “DMZ”. Todos los sistemas y equipos ubicados en estas áreas de seguridad, así como el equipo que limita esta área deben ser tratados y configurados como “activo ciber crítico”. El punto de acceso primario a través de este perímetro debe ser un “firewall” como se muestra en la figura 1. Todos los otros puntos de acceso, tales como módems de soporte deben estar protegidos o normalmente desactivados de tal manera que para activarlos se requiere de una intervención manual controlada. El proveedor debe proporcionar documentos y diagramas representando las áreas de seguridad, todos los componentes del sistema interconectados en el perímetro electrónico de seguridad y todos los activos ciber críticos usados o configurados para controlar y monitorear el acceso. El proveedor debe proporcionar asistencia en la instalación y configuración, así como en la determinación de los permisos mínimos de acceso requeridos para el “firewall”, que permitan una operación segura pero funcional del sistema, incluyendo acciones normales, de emergencia y de mantenimiento requeridas. En donde sea aplicable, el proveedor debe proporcionar arquitecturas de seguridad de red adicionales, incluyendo zonas “DMZ” y sistemas asociados, proporcionando a usuarios externos acceso a datos sin impactar el desempeño, confiabilidad o seguridad del sistema. El “firewall” debe ser implementado usando una filosofía de denegación inicial (default deny), permitiendo el acceso únicamente a aquellos usuarios, nodos y servicios que son específicamente permitidos. El “firewall” suministrado debe ser configurado para generar registros de entrada ante intentos fallidos y exitosos de acceso no autorizado. El perímetro electrónico de seguridad debe tener como mínimo las siguientes características:



19 de 154

120713 Rev 160720 161021

a) No tener conexión directa desde “internet” a las redes del sistema. El procedimiento para la actualización del antivirus se define en Características Particulares.

b) No tener acceso de la Intranet a ningún dato almacenado o procesos en la UCM, salvo lo indicado en Características Particulares para lo cual la CFE debe proporcionar en un anexo por separado, las información de la base de datos con la que debe intercambiar información la UCM.

c) Permitir en los puntos de acceso la implementación de reglas, indicando el tráfico requerido y

autorizado.

d) Permitir el registro del tráfico de la red con el propósito de detectar actividades no autorizadas, actividades no usuales, e intentos de traspasar su perímetro electrónico de seguridad.

6.2 Acceso para Mantenimiento Remoto Debe incluir el software para que los usuarios con facultades fuera de la red de la UCM, tengan acceso al sistema para realizar el monitoreo, análisis y mantenimiento. El acceso al sistema debe ser controlado, además debe incluir fuertes restricciones de acceso y encriptamiento. El proveedor debe proporcionar el soporte 7 por 24 tanto de hardware y software que se requiere para el uso de la tecnología de red privada virtual (VPN). El acceso para mantenimiento remoto debe tener las siguientes características:

a) El punto de acceso al sistema debe ser el “firewall”, todo el tráfico de la VPN debe ser enrutado a través del mismo. El punto de acceso debe hacer cumplir la autenticación de usuario y las políticas de seguridad.

b) El cliente de acceso software debe ser instalado en cada estación de trabajo remota con lo que

puede accesar al sistema. El cliente debe ser propietario de la tecnología VPN y no debe ser un cliente suministrado con el sistema operativo de las estaciones de trabajo.

El procedimiento de autenticación del usuario (login) debe incluir lo siguiente:

a) Identificación positiva del cliente que intenta acceder, tal como un nombre de grupo de trabajo y contraseña propio del cliente.

b) Verificación de dos factores del usuario intentando acceder, tal como una contraseña o un “token”

que varíe en el tiempo.

c) El administrador del sistema debe poder desactivar el acceso al mantenimiento remoto con una única acción o desconectar físicamente del sistema del punto de acceso.

d) Es responsabilidad del área usuaria en donde debe ser instalada la UCM, la tramitación y

adquisición de la comunicación por VPN, cumpliendo la normativa institucional, así como encargarse del buen funcionamiento y vigencia del al menos mientras dure el proyecto, período de garantía o contrato de mantenimiento con el fabricante.

6.2.1 Protección de infraestructura crítica (CIP)

Los requisitos de seguridad informática se deben basar en los estándares de protección de infraestructura crítica de acuerdo a la referencia [1] del capítulo 13 de esta especificación.



20 de 154

120713 Rev 160720 161021

6.2.1.1 Aplicabilidad de los estándares CIP del NERC Los procesos y sistemas suministrados por el proveedor deben cumplir, como mínimo, con los requisitos aplicables de los estándares CIP:

a) CIP-002 Activos ciber críticos. b) CIP-003 Controles de manejo de seguridad.

c) CIP-004 Personal y entrenamiento.

d) CIP-005 Área de seguridad electrónica.

e) CIP-006 Seguridad física.

f) CIP-007 Manejo de seguridad en sistemas SCADA.

g) CIP-008 Reporte de incidentes y planeamiento de respuesta.

h) CIP-009 Planeamiento de recuperación.

El software del sistema debe ser auditado inmediatamente antes de su entrega para asegurar que se satisfacen las siguientes iniciativas de seguridad cibernética. 6.2.1.2 Eliminación de servicios que no se utilizan Todas las aplicaciones, utilidades, servicios del sistema, archivos de configuración, bases de datos, cuentas de usuario y otro software no requerido para la operación del sistema deben ser eliminadas antes de su puesta en operación. Los elementos a ser removidos deben incluir específicamente, pero no estar limitados a:

a) Juegos. b) Controladores para dispositivos no entregados.

c) Servidores y clientes para servicios de internet no utilizados. d) Todos los compiladores de “software” excepto los propios de la UCM. e) Todas las suites de protocolos no utilizados. f) Utilidades administrativas, funciones de diagnóstico, manejo de red y manejo del sistema que no

son utilizadas.

g) Respaldos (Backups) de archivos, bases de datos y programas usados durante el desarrollo del sistema.

h) Bases de datos, archivos de configuración, programas y scripts usados para desarrollo y pruebas. i) Ayuda en línea que no soporte directamente aplicaciones o herramientas del sistema.

6.2.1.3 Actualizaciones de software y antivirus Deben instalarse todas las actualizaciones al sistema operativo y “software” de aplicación que direccionen la seguridad cibernética. Todas las correcciones y actualizaciones al sistema operativo y “software” de aplicación deben ser probadas.



21 de 154

120713 Rev 160720 161021

El software debe escanearse en relación a virus, gusanos, caballos troyanos y otro “software” contaminante durante las pruebas en fábrica y al inicio de las pruebas en sitio. 6.2.1.4 Libre de software activado de “autoayuda electrónica”

El software del sistema no debe contener fallas internas o mecanismos “back-door” que permitan al proveedor del software o a cualquier otra parte desactivar remotamente algunas o todas las funciones del “software”, afectar su desempeño o degradar su operación de alguna manera (también llamado “auto ayuda electrónica”).

6.2.1.5 Detección de modificaciones no autorizadas al software

El proveedor debe proporcionar un mecanismo para verificar periódicamente la integridad de los discos con el software del sistema para determinar si se han hecho modificaciones no autorizadas al software.

6.2.1.6 Antivirus y software de detección de programas malignos

Donde sea factible técnicamente y donde existan productos comerciales apropiados, el proveedor debe implementar antivirus, software de detección de programas espía y de programas malignos. Estos productos deben ser instalados y correr durante todo el desarrollo, prueba, puesta en servicio y aceptación del sistema para asegurar que su impacto en el desempeño es conocido y probado. El proveedor debe proporcionar procedimientos para la actualización segura de la configuración y certificación de archivos (signature files) para asegurar que las herramientas continúan actualizadas con las últimas actualizaciones y versiones. El software de antivirus debe realizar la verificación de cualquier medio, incluso aquel que se inserta de forma externa (con verificación automática) como memorias USB, CD/DVD, discos duros externos.

6.2.1.7 Monitoreo de seguridad

El sistema debe registrar todos los intentos de acceso, tanto a las aplicaciones como al área de seguridad. Debe mantener registros de los eventos del sistema relacionados con la seguridad con un nivel suficiente de detalle para crear seguimientos para auditorias históricas y permitir un análisis de causa raíz para un período de al menos 90 días calendario. Como mínimo, los registros deben capturar la siguiente información, tanto de usuarios como de solicitudes de aplicación:

a) Todos los registros de intentos de acceso, tanto exitosos como fallidos. b) Cualquier solicitud de cambio de privilegio, tanto exitosa como fallida.

c) Todas las acciones de usuario que afecten la seguridad, tal como los cambios de contraseña. d) Todos los intentos de acceder archivos para los cuales el usuario no tiene privilegios de acceso. e) Intentos de realizar una acción no autorizada por el esquema de seguridad. f) Detectar accesos no autorizados (intromisiones), e intentos de acceso no autorizados en los

puntos de acceso a las áreas de seguridad veinticuatro horas al día, siete días a la semana.

g) Para los propósitos de los requisitos anteriores, el término “usuario” se refiere tanto a usuarios humanos como a las aplicaciones ajenas al “software” del sistema.

h) Todos los registros de acceso deben ser almacenados en memoria auxiliar.

i) El sistema debe generar alarmas cuando la actividad de acceso puede indicar intentos no autorizado a los servicios del sistema o datos. Las alarmas deben ser generadas cuando el sistema detecte cualquiera de las siguientes actividades:



22 de 154

120713 Rev 160720 161021

- Repetidos intentos de registro desde una consola específica o puerto externo. - Repetidos intentos fallidos de acceso a un archivo. - Escaneo de puertos (intentos de acceder a puertos cerrados o a servicios).

- Como una medida adicional de seguridad, se debe contar con la funcionalidad de configurar

el máximo número de intentos fallidos de acceso al sistema.

6.2.1.8 Cuentas genéricas y por defecto

El proveedor debe remover, tanto como sea factible técnicamente, todas las cuentas genéricas, cuentas de invitado, cuentas de desarrollo, cuentas de mantenimiento y cuentas por defecto proporcionadas por “hardware”, sistema operativo, base de datos, programa de aplicación y otro “software” del proveedor. Cuando las cuentas genéricas o por defecto no puedan ser removidas, deben ser renombradas o desactivadas para prevenir accesos no autorizados.

6.2.1.9 Autenticación de usuario La UCM debe soportar métodos de manejo de cuentas para hacer cumplir la autenticación de acceso y responsabilidad de actividad de usuario, y minimizar el riesgo de acceso no autorizado. 6.2.1.10 Uso apropiado de banner Los usuarios que se registren en la UCM a través de acceso interactivo o de mantenimiento, deben ser presentados con un (“Appropriate Use Banner”), el contenido del cual debe ser proporcionado por la CFE. 6.2.1.11 Acceso seguro para el mantenimiento Debe proporcionarse acceso seguro para tareas de mantenimiento al ambiente operativo, tanto para usuarios remotos como locales. El acceso debe proporcionar autenticación de usuarios válidos sin transmitir contraseñas de texto plano en la red. Siempre se deben emplear mecanismos de encriptación. 6.2.1.12 Métodos de autenticación y construcción de contraseñas Todas las cuentas en el sistema deben requerir autenticación del usuario por medio de una contraseña asignada por el administrador de la UCM de la CFE. Para contraseñas, se debe usar una combinación de letras mayúsculas y minúsculas, números y caracteres especiales. La longitud mínima de la contraseña debe ser configurable e inicialmente establecida a 7 caracteres y el máximo, debe ser lo que permita el sistema operativo con la política de habilitar el uso de contraseñas con niveles bajos, medios y altos de seguridad. En Características Particulares se debe indicar si es necesario suministrar adicionalmente, otro nivel de seguridad, tal como un sistema biométrico o lector de tarjetas. 6.3 Programas del sistema y sistemas Operativos Se requiere que el proveedor entregue las herramientas con el que se desarrollaron las aplicaciones específicas que la CFE solicita en Características Particulares. El proveedor debe contar con una herramienta que controle los cambios de las versiones de los programas en la UCM. 6.3.1 Sistema operativo para servidores SCADA El sistema operativo que debe ser suministrado en los servidores SCADA debe cumplir con lo siguiente:



23 de 154

120713 Rev 160720 161021

a) Definiciones OSF/1 (Open Software Foundation), la última versión de LSB (Linux Standard Base) o sistemas operativos de plataforma Windows Server, según se indique en características particulares

b) Todas las interfaces y servicios proporcionados deben cumplir con las especificaciones de interfaz

de programación (Programming Interface Specification) (OSF/AES) o la última versión, lo anterior para el caso de LSB.

c) Debe considerar las recomendaciones de seguridad e interfaces, establecidos por el Centro

Nacional de Seguridad Cibernética (National Computer Security Center -NCSC) de la Agencia Nacional de Seguridad de los Estados Unidos de Norteamérica, para las Agencias Gubernamentales contra amenazas cibernéticas.

d) Para la portabilidad de las aplicaciones, debe cumplir con el nivel 1 de acuerdo a lo indicado en la

referencia [2] del capítulo 13 de esta especificación, en sus últimas versiones (DRAFTS) publicadas. Debe manejar la interfaz de transporte X/Open (XTI) para escribir aplicaciones portables para redes.

e) Para satisfacer los requerimientos de portabilidad en aplicaciones de tiempo real, debe cumplir con

las extensiones correspondientes de acuerdo a lo indicado en la referencia [3] del capítulo 13 de esta especificación.

f) Debe soportar diferentes interfaces para los programas de aplicación (API's) del sistema. g) En la parte correspondiente a redes, debe tener una completa interoperabilidad y proporcionar los

recursos necesarios para la conectividad entre LAN’s de acuerdo a lo indicado en la referencia [3] del capítulo 13 de esta especificación.

h) Para las disposiciones de “networking” debe incluir los protocolos normalizados ISO/OSI y la

familia de protocolos Inter-net TCP/IPl. Debe soportar las primitivas necesarias para la iniciación y control de movimientos de datos y programas de la red y primitivas de control de la propia red.

i) Debe manejar un sistema de archivos distribuidos.

6.3.2 Sistemas operativos para servidores históricos, consolas de operación, administración, mantenimiento y servidor “web”

En este apartado, se acepta además de los sistemas operativos indicados en el apartado anterior, otros sistemas operativos comerciales, que se desempeñen en tiempo real, multiproceso y multitareas en los servidores y en las consolas de operación, administración y mantenimiento. Lo anterior en las versiones más recientes que se encuentren disponibles en el mercado y probada por el proveedor. 6.3.3 Utilerías y herramientas de programación

Para el desarrollo y mantenimiento de la programación del sistema, se debe proporcionar las siguientes herramientas y facilidades de programación:

a) Ambiente y herramientas adecuadas para desarrollo de aplicaciones (TOOLKITS). b) Herramientas gráficas para la administración y configuración de los recursos de los servidores y

estaciones de trabajo, como discos, memoria, desempeño de CPU´s, entre otros.

c) Utilerías para el respaldo local y remoto (BACKUP) de la información y de los programas de aplicación.



24 de 154

120713 Rev 160720 161021

d) Utilerías para recuperación de la información (RESTORE) y de programas de aplicación. e) Conexión a la base de datos de tiempo real usando una hoja electrónica con facilidades de

definición de gráficas tipo barra, pastel (pie), radiales, tridimensionales, curvas. f) Conexión a la base de datos histórica usando un procesador de palabras y hoja electrónica. g) Todos los subsistemas residentes en los diferentes servidores deben contar con una bitácora que

registre la información correspondiente al acceso, explotación, actividad, fallas, definiciones, actualizaciones y modificaciones.

h) Tener acceso a los canales de comunicación de la UCM para diagnosticar y monitorear los equipos

de comunicación y UTR´s a través del “software” propietario de esos equipos.

6.3.3.1 Herramientas de desarrollo de aplicaciones

Se debe de proporcionar herramientas de desarrollo de aplicaciones que incluyan edición completa, depuración, mantenimiento de códigos (control de versiones del código) y documentación, compilación, encadenado, cargado y ejecución, para los diferentes sistemas operativos.

6.3.3.2 Interfaces de programas de aplicación

El proveedor debe implementar el protocolo TASE.2 seguro (Secure TASE.2 norma IEC 60970-6-503 de la última versión) de manera eficiente, obteniendo la integración completa con las funciones de la UCM, así mismo debe integrar los servicios del protocolo de acuerdo a estándares establecidos para asegurar la interoperabilidad entre diferentes productos y servicios de TASE.2 seguro de otros proveedores. Es responsabilidad del proveedor seleccionar e incluir las interfaces necesarias para la completa integración y operación eficiente de cualquier aplicación con la que tenga que operar el sistema. Es necesario que el poblado de la información se haga a través de las tablas en la base de datos y no a través de archivos de texto. Es necesario poner instrucciones en SQL para manejar gran volumen de datos y así poblar o modificar las tablas bilaterales.

6.3.3.3 Administración de recursos de servidores y estaciones de trabajo

El proveedor debe proporcionar todas las interfaces gráficas de usuario necesarias, a fin de satisfacer y asegurar una administración óptima de los recursos que integren la red. Se debe suministrar una herramienta para la administración y control global de recursos de servidores y consolas de operador, adicional a las utilerías incluidas en los sistemas operativos. Entre las funciones mínimas requeridas se tienen las siguientes:

De servidores y consolas de trabajo

a) Desempeño. b) Uso de disco.

c) Uso de CPU. d) Uso de memoria. e) Interfaces de red. f) Verificación de fallas.



25 de 154

120713 Rev 160720 161021

De procesos:

a) Porcentaje de uso del CPU por proceso. b) Verificación de que los procesos estén vivos o corriendo.

De dispositivos y equipos de red: a) Verificación de fallas. b) Monitoreo de porcentaje de uso de ancho de banda.

El sistema debe tener las siguientes funcionalidades: a) Envío de alarmas a bitácora e histórico cuando se violan límites definidos por el usuario. b) Debe proporcionar ambiente grafico amigable para una supervisión continua por medio de

desplegado mostrando claramente cuando una variable entró en violación. El usuario debe navegar en la información histórica de esta variable en un rango de tiempo seleccionable.

c) Debe contar con la funcionalidad de usar disparadores, que al momento de alguna violación de un

parámetro arranque un programa o capture las variables definidas por el usuario (como desempeño de CPU, porcentaje de carga por proceso, entre otros.) y se guarden en bitácoras e histórico para su análisis o consulta posteriores.

Es necesario que el muestreo de cada una de las variables sea configurable en base de datos. Esta función debe ser interactiva e integrarse a las herramientas de base de datos, desplegados, reportes, gráficas y estadísticas de la UCM. Debe contar con mensajes de alarma en el sistema antes de que alguno de los parámetros monitoreados alcance un nivel crítico.

6.3.4 Mantenimiento de comunicación con UTR´s

Debe suministrarse “software” con interfaz gráfica interactiva GUI (Graphical User Interface) para el monitoreo y mantenimiento de todas las comunicaciones con las UTR´s. Las características básicas mínimas que debe incluir son:

a) Acceso interactivo a todos los parámetros de las UTR’s. b) Facilitar la adición y modificación de elementos de las UTR’s.

c) Proveer detección de error y procedimientos de recuperación. d) Monitoreo y despliegue de estados de dispositivos de comunicación. e) Proveer estadísticas en tiempo real de entrada/salida (Input/Output), incluyendo el número de

errores, reintentos, bytes transferidos, porcentaje de error horario, diario y mensual de las UTR’s y canales de comunicación. Todas las estadísticas se deben almacenar en los archivos de información históricas.

f) Generación de valores de carga por cada canal de comunicación configurado en la UCM (cálculos

de carga de canal), especificando además en estos valores los tiempos de barridos por cada UTR en el canal de comunicación.



26 de 154

120713 Rev 160720 161021

6.3.4.1 Diagnóstico

Se debe proporcionar una herramienta (GUI) para el diagnóstico y monitoreo de los canales de comunicaciones que muestre las tramas enviadas y recibidas por los protocolos. Estas tramas deben almacenarse de acuerdo a criterios del administrador. En forma opcional cuando se solicite en Características Particulares, el proveedor proporcionará por cada UCM un simulador de protocolos portátil que permita simular en modo maestra, modo UTR y modo monitor los protocolos de comunicación especificados.

6.4 Base de Datos 6.4.1 General

Las funciones de la UCM y sus aplicaciones deben usar la misma base de datos, las mismas imágenes de desplegado y una estructura de diálogo uniformizada. Si el concursante incluye en su oferta una base de datos de tiempo real propietaria enlazada a la base de datos relacional comercial requerida, esta opción puede ser aceptada por la CFE siempre y cuando la actualización de ambas bases de datos se realice en forma simultánea y además proporcione un servicio de ODBC y Data Provider para conexión a la misma, de tal forma que las estructuras puedan ser vinculadas a herramientas con acceso a base de datos relacionales comerciales y desde ahí hacer el mantenimiento de la base de datos. La base de datos comercial así como la base de datos de tiempo real propietaria se debe entregar con el módulo de administración de las mismas. El sistema debe tener espacio para almacenar por lo menos el respaldo de 10 bases de datos completas generadas por la UCM. La base de datos debe soportar:

a) Interfaces con lenguajes de alto nivel SQL.

b) Construcción de base de datos con las siguientes tareas:

- Construir y mantener directorios de base de datos suficientes para describirla ampliamente.

- Construir una base de datos que incluya tanto tablas que contengan la información descrita como las entradas a la tabla.

- Base de datos y directorios de salida para almacenamiento masivo en memoria o cinta

magnética en un formato de entrada utilizable para la regeneración o recarga de la misma. - Desplegados de formatos que muestren los elementos aplicables de la base de datos.

c) El mantenimiento de la base de datos en línea y sin interrupción debe realizar lo siguiente: - Agregar / borrar / cambiar parámetros de la base de datos asociados a puntos telemedidos,

componentes de “hardware”, datos de entrada manual, puntos calculados.

- Adición / borrado / redefinición de puntos locales y remotos.

- Reasignación de terminales de entrada / salida.

- Reasignación de áreas de responsabilidad de un punto.



27 de 154

120713 Rev 160720 161021

- Redefinición de frecuencias de barridos.

- Redefinición de funciones a ser asignadas a un área de responsabilidad en particular.

- Edición de todas las tablas.

- Factor de conversión.

- Formato del valor analógico y acumulador.

- Inversión estado (abierto/cerrado).

- Inversión del control.

- Cambiar la forma de explorar hacia la UTR.

- Modificar los parámetros de los puertos seriales (comunicación a UTR, velocidad, protocolo de comunicación, tipo de canal).

- Agregar o borrar registros históricos.

- Habilitar o deshabilitar su actualización en Histórico.

- Definir nuevas UTR’s.

- Duplicar UTR’s con sus puntos asignados.

- Eliminar UTR´s con sus puntos asignados.

- Definir nuevos puntos de estado.

- Definir nuevos puntos analógicos.

- Borrar puntos de estado.

- Borrar puntos analógicos.

- Borrar UTR’s.

- Cambio de límites.

- Cambio de nombre del punto.

- Definir colores para el estado de las indicaciones o alarmas.

- Definir colores para cada límite de los estados analógicos.

- Definir colores para las banderas de calidad.

- Cambiar puertos de comunicación.

- Funciones de acceso a base de datos.

- Generación de reportes personalizados (generación de reportes a la medida y productos de

escritura de reporteadores de terceros).



28 de 154

120713 Rev 160720 161021

- Compilador de reportes.

- La actualización de la base de datos no debe afectar los datos telemedidos ni las acciones de control hacia campo por más de 30 s.

En Características Particulares se debe indicar la cantidad de señales requeridas para el mapa de puntos de la base de datos de la comunicación SCADA, entradas binarias, entradas analógicas, salidas binarias, contadores y el crecimiento en porcentaje requerido en el futuro inmediato, el cual debe considerarse por el fabricante para el dimensionamiento del equipo.

6.4.2 Ingeniería de datos Toda la información necesaria para definir las funciones con las que opera la UCM deben definirse una vez en la base de datos y ser diseminados a todas las funciones operacionales del sistema, la base de datos en tiempo real y las interfaces de usuario de herramientas de mantenimiento que requieran esta información. De igual forma debe contar con la herramienta que permita configurar los parámetros de los protocolos de comunicaciones y la relación que guarda con la información para intercambio y actualización de datos. No se aceptan configuraciones y poblado de base de datos a través de archivos planos o texto. 6.4.3 Ingeniería de desplegados 6.4.3.1 Características generales El editor de desplegados debe como parte del suministro, proveer la capacidad de construir nuevos desplegados así como modificar los existentes. El editor de desplegados debe cumplir con las siguientes características:

a) Ser completamente compatible con las funciones de generación y edición de base de datos. b) Ser completamente interactivo.

c) Proveer características de WYSIWYG, (“What you see is what you get¨). d) Mantener rastro auditable de la actividad de edición. e) Debe importar / exportar archivos CAD. f) Capacidad de intercambio de datos con sistemas GIS. g) Proveer la facilidad de construir nuevos desplegados a partir de desplegados existentes. h) Proveer la facilidad de construir nuevos desplegados a partir de plantillas disponibles en librerías y

poder ser modificados por personal de soporte. i) Contar con librerías de símbolos estándares y personalizados, o componentes a ser creados,

modificados y utilizados para facilitar el proceso de edición.

j) Validación instantánea a las referencias de la base de datos. k) Contar con varias utilerías de construcción que simplifiquen la creación y modificación de

desplegados, las cuales deben incluir como mínimo lo siguiente:

- Desplegados individuales.



29 de 154

120713 Rev 160720 161021

- Librerías de desplegados.

- Aplicaciones individuales.

- Sistema completo de aplicaciones.

- Facilidades de edición para copiar, mover, borrar, modificar, cortar, agrupar y pegar los grupos de información seleccionada y deshacer las acciones previas.

- Habilidad de edición o construcción de desplegados a cualquier nivel de amplificación

(zoom).

- Soportar apego a cuadricula (snap-grids) disponibles de forma visible o invisible, a incrementos específicos con apego a lugar (snap-to-placement) de un objeto en la cuadricula en una alineación deseada.

- Soportar diversidad de tipos y tamaños de letra, así como tipo y ancho de líneas.

- Habilidad para enlazar y definir símbolos gráficos a cualquier punto de la base de datos.

- Proveer menús de ventanas emergente (pop-up) que permitan la fácil selección de puntos

de encadenamiento de default.

- Habilidad para establecer diferentes símbolos o convenciones de desplegados para el mismo punto de la base de datos en el mismo o en diferente desplegado.

- Habilidad para definir enlaces dinámicos de desplegados a cualquier variable de sistema de

base de datos en cualquier sistema de desplegado.

- Habilidad de construir y modificar iconos de desplegados y almacenarlos en una librería de fácil acceso.

- Habilidad de proteger cualquier campo en un desplegado contra entrada manual del usuario

basado en el identificador de inicio de sesión “logon” (área de responsabilidad).

- Habilidad para crear puntos sensibles con ligas para llamar a archivos definidos comercialmente para hoja de cálculo, presentación, procesador de palabras, de dibujo vectorizado e imágenes entre otros.

- Debe de contar con capas (Layers) y Declutters.

- Un procedimiento sencillo para la activación de desplegados, el cual debe ser transparente

al usuario, y no causar interrupción en la actividad del sistema en línea.

- Proveer una función de validación que asegure que todas las definiciones de un desplegado que reside en localidades múltiples (consolas de HMI) sean consistentes y estén actualizadas.

- Posibilidad de editar cualquier desplegado desde cualquier consola con permisos y códigos

de autorización adecuados.

- Proveer la funcionalidad para la construcción de desplegados en los cuales se incluyan gráficas de tendencia de variables del sistema, en el cual una vez que se encuentren en línea sea posible cambiar los límites y el color, entre otros.



30 de 154

120713 Rev 160720 161021

- Proveer la funcionalidad desplegar ayuda en línea del sistema en español.

- Proveer la funcionalidad para la construcción de desplegados situacionales. Al menos suministrar desplegados situacionales genéricos, como de equipos de medición de variables propias de los sistemas SCADA (corriente, tensión, frecuencia, temperatura, entre otros.) y específicos sobre planos geográficos y topográficos , coloreo de áreas en función de la densidad de carga en las líneas eléctricas, coloreo por contorno, con sistemas de transmisión, coloreo de contorno y radar. Desplegados de mapas con coloreo de contorno y barras tridimensionales, desplegado con coloreo de contorno de tensión, entre otros.

6.5 Disponibilidad 6.5.1 Funciones críticas En la tabla 3 se describen las funciones que deben realizar las UCM´s y el grado crítico de las mismas y en la tabla 4 la clasificación del nivel de prioridad de los equipos que le corresponde realizar determinadas funciones en la UCM. 6.5.2 Disponibilidad de funciones críticas Las configuraciones de la red ofertada, deben proporcionar una disponibilidad (AVAILABILITY) del 99.95 % para las funciones críticas, debiendo demostrarse dicha disponibilidad durante las pruebas en fábrica. Asimismo, para las funciones no críticas se debe garantizar una disponibilidad del 99.5 %. En la propuesta técnica, se debe entregar las memorias de cálculo de disponibilidad que demuestre para su diseño el cumplimiento de los porcentajes antes indicados (99.95 % y 99.5 %, respectivamente). La memoria de cálculo debe mostrar la asignación de funciones a los diferentes nodos de procesamiento del sistema, presentando explícitamente las técnicas de respaldo utilizadas por cada nodo, y las funciones que deben estar respaldando para cumplir con los índices de disponibilidad especificados. La UCM debe tener la función de calcular su propia disponibilidad por medio de los datos de estado de los computadores adquiridos directamente por el sistema en tiempo real y de ecuaciones de cálculo aprobadas por la CFE. Los datos calculados deben ser almacenados en el sistema de registro histórico y deben poder ser modificados en caso de fallas de “software” que no involucren necesariamente problemas de “hardware” detectables por el sistema en tiempo real. Esta función debe probarse en fábrica antes del envío del sistema y debe ser utilizada como registro durante la prueba de disponibilidad del sistema. La UCM debe proporcionar todos los datos para el cálculo de la disponibilidad de la información en el sistema. En esta forma se debe tener los datos en tiempo real de la disponibilidad de los canales de comunicaciones y de acuerdo con un peso relacionado con la cantidad de información de cada canal, se debe calcular la disponibilidad de la información por UTR, por canal de comunicaciones y para el sistema como un todo. En este cálculo se puede tener en cuenta, a opción de la CFE, las banderas de la calidad de los datos que es enviada desde los elementos primarios de toma de datos. De esta forma se debe calcular la disponibilidad de esos elementos por medio de la información enviada por cada uno de ellos y las banderas de calidad de la información asociada a ellos. Detalles del cálculo de esta función deben ser finalizados durante la etapa del acuerdo de la reunión de ingeniería (declaración de trabajo “SOW”) del sistema entre el proveedor y la CFE.



31 de 154

120713 Rev 160720 161021

TABLA 3 - Clasificación del grado crítico de las funciones de la UCM

Función Crítica Media Baja

Adquisición de datos

Protocolos con UTR´s X -- --

Incluir y excluir UTR´s en el

monitoreo (SCAN) X -- --

Estadísticas de canal y por UTR -- X --

Procesamiento de entradas

binarias X -- --

Procesamiento de secuencia de

eventos X -- --

Procesamiento de entradas

analógicas X -- --

Fuentes alternas de datos para

mediciones X --

Procesamiento de acumuladores X --

Respaldos de la base de datos -- X

Pantallas para operador X --

Despliegue de datos X --

Pantallas y almacenamiento de

tendencias -- -- X

Aplicación para almacenamiento de

datos por un evento (Disturbance

Data Collection)

-- X --

Interfaces para explotación de

datos tiempo-real: API, ODBC/SQL,

DDE, XML

-- X --

Control supervisorio

Enlace de gráficos con el control de

salidas binarias X -- --

Ejecución de mandos (ON/OFF,

TRIP/CLOSE) X -- --

Ejecución de mandos (setpoint) X -- --

Cambiadores de tap´s X -- --

Inhibición de controles e

Indicaciones de los mismos X -- --

Etiquetado de puntos con la

inhibición de control configurables

por el usuario

X -- --

Control y cálculos periódicos

Cálculos generales -- X --

Máximos, mínimos y promedios -- X --

Tareas programadas con controles

secuenciales -- X --

Continúa…



32 de 154

120713 Rev 160720 161021

…Continuación

Cálculos eléctricos y verificación de

errores -- X --

Procesamiento de alarmas

Interfaz para visualización y manejo

de alarmas X -- --

Tipos de alarma y su severidad X -- --

Inhibición de alarmas (individual y

por grupo) X -- --

Reconocimiento de alarmas X -- --

Alarmas audibles X -- --

Borrado de alarmas X -- --

Información histórica

Periodicidad en el almacenamiento -- X --

ODBC -- X --

Generales

Mantenimiento de base de datos y

desplegados -- X --

Comunicaciones con otros

sistemas (ICCP y DNP3

modo UTR)

X -- --

Seguridad en adquisición de datos -- X --

Interfaz del usuario X -- --

Interface con otros programas -- X --

Impresión y reportes -- -- X

Mantenimiento del sistema -- X --



33 de 154

120713 Rev 160720 161021

TABLA 4 - Clasificación de nivel de prioridad de la UCM

Equipo Nivel prioridad

Critica Media Baja

SCADA/aplicaciones X -- --

Servidor de comunicaciones X -- --

Datos históricos -- X --

Base de datos -- X --

Tase.2 X -- --

“Web” -- X --

“Firewall” -- X --

Ruteador X -- --

Impresoras -- -- X

Sistema KVM de RACK -- X --

“Switch” X -- --

“Legible displays” -- X --

GPS X -- --

Video proyector -- X --

VPN X -- --

Consolas X -- --

6.5.3 Redundancia del medio físico de la red

El servidor SCADA y las consolas, deben disponer de un mínimo de dos interfaces independientes para su enlace a la red. Asimismo, se requiere indicar claramente en la oferta los protocolos y medio físico de la red “LAN” que se ofrece, debiéndose garantizar en forma expresa, la adecuada y eficiente operación en el ambiente de tiempo real de la aplicación, razón por la cual debe cumplir con la velocidad de transferencia de datos de 10/100/1 000 Mb/s, antes establecida.

6.5.4 Transferencia y reiniciación automática de funciones.

Se han identificado algunos servicios que requieren redundancia o respaldo en caliente. El concursante debe definir la redundancia de equipos que requieran el respaldo en caliente, no establecida en esta especificación, para aquellas funciones que considere relevantes para la continuidad operativa de la red en su conjunto y debe ofertarlas, justificando técnicamente con su propuesta y observando siempre las restricciones de disponibilidad establecidas por la CFE. El sistema debe reiniciar en caso de falla de software o hardware el proceso de adquisición de datos en un tiempo menor o igual a diez segundos , aun cuando la falla obligue al re-enrutamiento de ese proceso en algún servidor de respaldo. Así mismo la programación de la consola de operador, debe estar operativa completamente cinco segundos después de que el proceso de adquisición de datos se restablezca. El sistema ante caso de reconfiguración automática debe estar operativo completamente para todo el proceso de transferencia de información para los programas de aplicación en un máximo de 5 s.



34 de 154

120713 Rev 160720 161021

En la tabla 5 se establecen los tiempos máximos requeridos para el mantenimiento de algunos de los procesos y funciones de la UCM. Dados los posibles niveles de proceso, el proveedor debe explicar detalladamente la filosofía de reconfiguración automática (FAILOVER) para la UCM y en cada caso, ya sea, de falla de procesadores, de unidades de disco, de las comunicaciones de la red local y los que considere críticos el proveedor de la UCM para la continuidad del servicio. Asimismo, debe generarse un registro de la actividad indicando como mínimo, la fecha y hora de ocurrencia, la explicación del evento que inició el proceso de reconfiguración, la actividad de programación que se arrancó ante la falla y el escenario antes y después de la falla.

TABLA 5 - Requerimientos de mantenimiento del software

Actividad Máximo Tiempo

Transcurrido

Regeneración total de la base de datos 30 min

Construcción total del sistema (compilación y enlace de toda la programación fuente del sistema y reconstrucción del tiempo real del

SCADA) 2 h

Enlace e integración de un solo desplegado en todas las consolas 15 s

Enlace e integración de todos los desplegados 1 min

Disponibilidad de la información SCADA (adquisición de datos de campo) después de un re-arranque (restart) de un equipo o función

crítica 15 s

La compilación, encadenamiento e integración en línea, después de una modificación de un módulo de programación en el sistema

5 min

Realización de una actualización en línea de un parámetro de base de datos operacional, y propagación del cambio a los datos fuente

30 s

Supresión de una función para permitir la integración del cambio de un parámetro de la base de datos en línea

30 s

Agregar un equipo nuevo a la base de datos en línea. (Sin contar el tiempo de definición del equipo)

30 s

NOTA: 1. Un solo desplegado, se refiere a un cambio o modificación en la edición de unifilares que afecta a lo que se muestra en una

sola ventana. 2. Todos los desplegados se refiere a los cambios o modificaciones que afecta lo que se puede visualizar en varias ventanas (re-

arranque de la base de datos). El proveedor debe integrar en estos servicios de red todos aquellos aspectos comunes a estas características de configuración, tales como:

a) Todos los mecanismos eficientes para la detección y recuperación de fallas (equipos y

programación), necesariamente sobre todo y en aquéllas que sean críticas y que conduzcan a una transferencia o reiniciación automáticas.

b) Sincronizar adecuadamente la información y su respaldo. c) Controlar el estado de la configuración o su reconfiguración, tanto en condición normal o en caso

de una falla.

d) La función de transferencia debe implicar la “reasignación”, automática y manual, de equipos en línea y de respaldo.



35 de 154

120713 Rev 160720 161021

e) El proveedor debe explicar claramente cada uno de los tipos de reiniciación configurados, indicando si requiere o no la intervención del operador.

f) La estructura de programación de estos servicios debe proveer los mecanismos necesarios, para

asegurar una operación continua, segura y correcta de todas las funciones del sistema, aun en casos de falla en componentes críticos de la red de cómputo (equipos y programación), además de lo anterior, debe alertar al supervisor de la red con mensajes claros y sin ambigüedad que se deben conservar en un archivo histórico, además mantendrá la información necesaria de estados de equipos mostrados en un diagrama esquemático de la red del sistema desde el cual se efectúen reconfiguraciones manuales.

g) Para fines estadísticos se requiere de una herramienta de “software” que proporcione la

información concerniente a la disponibilidad de los componentes que forman el sistema (servidores, estaciones de trabajo y LAN’s), canales de comunicación (incluyendo uso y estado de canales de respaldo), tiempo fuera de servicio de UTR’s, en forma tal que permitan obtener reportes y gráficas que muestren el comportamiento de dichos elementos y de subsistemas tales como adquisición de datos y del sistema como un todo.

h) El proveedor, debe definir claramente los procedimientos necesarios para la seguridad (security) y

actualización (checkpoint) de la información de tiempo real, a fin de ofrecer un reinicio en caliente, en caso de una falla crítica en los equipos, y en particular los orientados a soportar la función de la administración de la base de datos. Se deben incluir los servicios de sincronización de tiempo de la red (time synchronization) que cumplan con la especificación más reciente del protocolo de tiempo de red (NTP).

i) Desde el punto de vista de seguridad, se deben proporcionar mecanismos para garantizar la

seguridad del sistema controlando el acceso y permisos de usuarios de la CFE diferentes a los de los centros de control y externos que accedan a la UCM. El concursante debe explicar en su propuesta los mecanismos de seguridad ofrecidos y debe incluir en su oferta corta fuegos “firewalls”.

6.5.4.1 Supervisión de las fallas y herramientas de diagnóstico

Todos los componentes del sistema, deben tener copia física de la base de datos y de sus estructuras, de tal forma que cuando el servidor primario falle, el sistema automáticamente debe solucionar la falla utilizando el servidor de respaldo. La conmutación del servidor primario y del de respaldo, se debe realizar automáticamente en caso de falla o manualmente a solicitud del administrador del sistema. Para el poleo de la UCM, debe permitir la definición de servidores de adquisición de datos “lógicos”. Del par, uno debe escanear activamente las UTR’s mientras que el otro espera. En el caso de una falla del servidor activo, el respaldo automáticamente debe tomar el mando. El sistema debe operar en tiempo real las 24 h del día, todos los días del año. Para lograr una alta disponibilidad del sistema, se deben utilizar únicamente productos tolerantes a las fallas ya probados que hayan sido diseñados con componentes que trabajen dentro de sus tolerancias operativas, disminuyendo así la probabilidad a la incidencia de fallas o errores por mal funcionamiento. El sistema debe ser diseñado para minimizar el efecto de las fallas simples en la operación del sistema y el tiempo de reparación en el caso de que ocurra. En caso de falla es esencial que el personal de mantenimiento de la CFE, tenga la capacidad y los recursos para diagnosticar y corregir la falla en el menor tiempo posible, para devolver el sistema a su estado operacional pleno, para lo cual el proveedor debe capacitar al personal de la CFE responsable de la operación del sistema. Para el mantenimiento del equipo se debe utilizar mediciones de error del sistema y programas de diagnóstico. La medición de errores del sistema debe ser supervisado continuamente y registrar los errores de los dispositivos por hora y por día. Se deben proveer las pantallas o visualizaciones para el operador con esta información.



36 de 154

120713 Rev 160720 161021

Adicionalmente cuando el sistema detecte que los errores en los dispositivos hayan rebasado los límites previamente configurados, se deben generar las alarmas y mensajes correspondientes para avisar al operador o al personal técnico encargado.

6.5.4.2 Inicialización y monitoreo de fallas El sistema debe proporcionar la supervisión del inicio y reinicio de las fallas de todos los componentes del sistema como una arquitectura integrada, para detectar la pérdida de cualquier componente de manera individual. 6.5.4.2.1 Beneficios de la iniciación y monitoreo de fallas

Los beneficios de la iniciación y supervisión de fallas del sistema deben incluir al menos:

a) Coordinación automática de la iniciación entre procesadores distribuidos. a) Re-inicialización automática del sistema ante la recuperación de energía. b) Configuración seleccionable de manera que el operador pueda levantar el sistema solo con los

componentes deseados.

c) Generación de información de depuración (Debug) del sistema en el caso de reinicio del procesador o proceso.

6.5.4.2.2 Funciones El proceso de iniciación tiene como función la de coordinar el comienzo y reinicio del sistema. El servidor primario debe supervisar la iniciación de cada una de las consolas que existan en la configuración de la UCM y enviar a la bitácora cualquier acción que realice. La iniciación debe manejar las siguientes funciones:

a) Acoplamiento directo con el sistema operativo, protegiendo el “software” de las aplicaciones de los detalles del inicio y reinicio.

b) Identificar el rol de los componentes para que haya un sólo servidor SCADA primario, en la

configuración redundante.

c) Monitorear las funciones que se realizan en cada procesador del sistema y en caso de que ocurra una falla, debe reiniciarse el proceso fallado y la recuperación si es necesario.

d) Coordinar la iniciación del software ejecutivo, el software de la base de datos y el software de las

comunicaciones.

e) Retener la información de depuración del sistema en caso de falla del procesador.

f) Proveer una interfaz con el administrador del sistema, para un reinicio o conmutación del procesador requerido manualmente.

g) Supervisar la iniciación de software de aplicaciones.

h) Supervisar y desintegrar las tareas o procesos que pongan en riesgo la integridad del sistema. Si el

proceso o tarea que pone en riesgo al sistema es crítico, debe tomar las medidas necesarias para mantener el sistema operacional, por ejemplo hacer un reinicio (restart). Si el proceso o tarea no es crítico, eliminar ese proceso o desintegrar la tarea.



37 de 154

120713 Rev 160720 161021

6.6 Tablas de Dimensionamiento y Expansión 6.6.1 Dimensionamiento para funciones básicas de la UCM En Características Particulares se muestran los volúmenes de datos a manejar para el dimensionamiento de recursos necesarios que deben implementarse para cumplir con la funcionalidad básica de los subsistemas de la UCM. 6.6.2 Dimensionamiento para aplicaciones complementarias de la UCM 6.6.2.1 Administración de puntos etiquetados Los puntos etiquetados deben ser registrados en resúmenes cronológicos clasificados por autoridad, el número de resúmenes son igual al de etiquetas posibles. Las capacidades de archivos para el manejo de información operativa de alarmas, licencias y bloqueo de comandos son indicadas en Características Particulares. 6.6.3 Dimensionamiento para servidor de datos históricos El servidor de base de datos histórico, debe de almacenar en línea al menos 2 años de información de toda la base de datos. En su dimensionamiento debe considerar que hay datos que se actualizan cada 0.5 s sin usar banda muerta y banda de compresión. Para realizar la explotación de la información almacenada en el servidor de históricos se debe proporcionar una herramienta capaz de permitir accesos a su base de datos para consulta, o para la generación, periódica o por demanda, de reportes vía un generador de reportes del servidor de históricos. El generador de reportes debe permitir el acceso simultáneo de al menos 10 usuarios para edición. La explotación o el acceso a la información del servidor histórico de datos, que está fuera de línea, debe tener un acceso tan rápido como si estuviera en línea. El explotador de la información que se usa para la información en línea, debe ser el mismo para la información que está fuera de línea, la habilitación de la información para consulta no debe ser complicada. 6.6.4 Dimensionamiento para crecimiento y expansión Con el fin de mantener el desempeño especificado a las dimensiones del software y hardware aproximados y proveer capacidad de computación más allá del tamaño final para funciones futuras y comunicaciones de datos no definidos actualmente, la UCM debe estar diseñada para habilitar la adición fácil y conveniente de unidades de procesamiento, memoria principal y memoria masiva. La memoria principal instalada en cualquier servidor de aplicación o en cualquier estación de trabajo usada para la ejecución de las funciones de aplicación, deben estar dimensionadas de tal forma que cumplan o excedan los requisitos de desempeño. La memoria principal de los servidores y estaciones de trabajo deben ser expandibles por lo menos a dos (2) veces del tamaño dimensionado para la entrega final. El procesamiento de cada uno de los componentes de la UCM en condiciones normales (estable) de operación debe estar en no más del 20 % de su capacidad total. El personal de la CFE debe estar en capacidad de realizar todos los cambios a las UCM´s y sus bases de datos, para dar soporte al crecimiento anticipado a través de procedimientos interactivos suministrados en los sistemas y sin necesidad de asistencia alguna por parte del proveedor. Ningún cambio lógico del programa debe ser necesario para implementar esta expansión. El proveedor debe proporcionar toda la documentación y capacitación relacionada.



38 de 154

120713 Rev 160720 161021

Debe cumplir con los requisitos de expansión indicados solamente con la actualización en campo de procesadores de servidores y estaciones de trabajo, memoria principal, memoria masiva, periféricos o equipo de interfaces de comunicación necesarias. El proveedor debe demostrar durante el entrenamiento en el trabajo (OJT), que los sistemas entregados cumplen con los requisitos indicados de expansión de hardware. 6.7 Mantenimiento del Software En la tabla 5 se incluyeron los tiempos máximos que pueden consumir las actividades más relevantes relativas al mantenimiento del software de los diferentes módulos de la UCM. 6.8 Requerimientos de SCADA

6.8.1 Distribución de funciones La aplicación de adquisición de datos en tiempo real, que forma parte de la UCM debe realizar las siguientes funciones como control supervisorio:

a) Enrutamiento y envío de comandos a las UTR’s.

b) Codificación/decodificación de mensajes.

c) Verificación de la ejecución satisfactoria del comando.

d) Identificación de errores en el proceso.

e) Envío de la respuesta adecuada al nodo generador del comando y actualización de la base de datos.

f) Colección de datos de disturbio.

g) Procesador de alarmas.

Control de mandos incluyendo: - Control de tiempo de vida.

- Facilidad de selección previa a la operación.

- Valores instantáneos de las salidas de control de tiempo real.

- Controles macrosecuenciales.

- Control de valor consigna.

6.8.2 Requerimientos del intercambio de datos en tiempo real

a) Telemedición de valores digitales, analógicos y acumuladores, incluyendo banderas de calidad y SOE.

b) Valores calculados analógicos, acumuladores, y digitales, incluyendo banderas de calidad. c) Parámetros de operación, incluyendo violación de límites y bandas muertas.



39 de 154

120713 Rev 160720 161021

6.8.3 Módulo de adquisición de datos y procesamiento básico del SCADA Las UCM´s en su módulo de adquisición de datos, deben realizar la adquisición, el procesamiento y la diseminación de datos en forma rápida, eficiente y segura. Este módulo debe de contar con las bitácoras necesarias para explotar la información proveniente de campo. Los tipos de datos que se incluyen son:

a) Binarios. b) Analógicos.

c) Acumuladores.

d) Secuencia de eventos (SOE).

La UCM debe registrar en una bitácora la hora de llegada de cualquier cambio binario o analógico, donde se muestre los datos del punto y la fecha con formato que incluya hasta milisegundos. Se debe registrar con el tiempo real (tiempo local). El usuario debe poder configurar, qué puntos desea que se registren en esta bitácora la cual se debe respaldar en archivos por día. 6.8.3.1 Adquisición de datos La UCM puede adquirir datos de dos fuentes diferentes (UTR´s y UCM´s) asignados a un punto resultante. El sistema debe soportar la conmutación automática de la fuente de adquisición de datos manteniendo la funcionalidad del punto fuente. La UCM debe procesar lo siguiente:

a) Exploraciones por cambios, periódicas y bajo demanda.

b) Diferentes grupos de exploración.

c) Diferentes períodos y prioridades de exploración.

d) Exploraciones secuenciadas (POLL SCHEME).

e) Exploración de UTR’s con diferentes protocolos en forma transparente al usuario.

f) Exploración de todos los datos (FULL UPDATE o de Integridad).

g) Exploración de puntos de estado exclusivamente.

h) Exploración de puntos analógicos exclusivamente.

i) Exploración por cambios en los estados (binarios y analógicos).

j) Exploración de contadores exclusivamente.

k) Detección de fallas de comunicación.

l) Cambio de canal de comunicaciones al detectar falla en el mismo.

m) Intentos automáticos de restablecimiento de comunicaciones.

n) Reporte y estadística de errores de comunicación.



40 de 154

120713 Rev 160720 161021

o) Codificación y decodificación de mensajes. 6.8.3.2 Datos binarios Los datos binarios que debe procesar y manejar la UCM, dependiendo del protocolo, son los siguientes:

a) Puntos binarios con control de un solo bit.

b) Puntos binarios de alarma exclusivamente.

c) Puntos binarios con control, con detección de cambio momentáneo (de 2 bits).

d) Puntos binarios solo control.

e) Puntos binarios de 2 bits (4 indicaciones).

f) Cambio de estado de puntos con control.

g) Cambio de estado de puntos de alarma exclusivamente.

h) Cambio de estado y detección de cambio momentáneo.

i) Alarmas con diferente severidad en modo disturbio.

j) Secuencia de eventos con estampa de tiempo (SOE).

k) Manejo y decodificación de las banderas de calidad de los datos que sean transmitidos por medio del protocolo.

El procesamiento de puntos digitales debe incluir la conversión de los datos coleccionados, de manera que su representación en la base de datos sea consistente para todos los puntos. Adicionalmente todo cambio de estado debe almacenarse en la base de datos histórica. Para los puntos con detección de cambio momentáneo, se deben verificar y procesar cambios de estado intermedios. En el procesamiento debe incluirse lo siguiente:

a) Desactivación automática.

Para los puntos binarios de indicación exclusivamente, es necesario detectar el número de cambios de ceros a unos en un período determinado, poniendo al punto fuera de exploración automáticamente si se excede un límite estipulado, haciendo la notificación correspondiente al operador a través del procesamiento de alarmas y etiquetándolo con un carácter especial. El restablecimiento de esta situación debe ser mediante la acción de poner el punto en barrido nuevamente. Este procesamiento debe permitir definir los límites (número de cambios) y la activación de esta funcionalidad por parte del usuario por punto binario en la base de datos fuente y en línea. Esta funcionalidad es opcional y debe ser incluida solo si se indica en Características Particulares.

b) Desactivación manual de exploración por punto.

Para las entradas binarias, se requiere que la UCM tenga la facilidad para que el operador pueda poner uno o varios puntos de una o varias UTR´s en estado fuera de exploración, debido a que se reciben cambios de estado continuos no deseados.



41 de 154

120713 Rev 160720 161021

c) Reconocimiento de eventos sobre un mismo punto (alarmas e indicaciones).

Debe tener la facilidad para que cuando se tengan eventos de indicaciones o alarmas que no han sido reconocidos por el operador, presente la opción de reconocer todos los eventos correspondientes a la misma entrada binaria simultáneamente.

d) Filtrado de eventos de alarmas binarias.

Se debe incluir un filtro para algunas alarmas binarias (seleccionables), de modo que una alarma sólo sea considerada como tal, si se mantiene un tiempo determinado.

6.8.3.3 Procesamiento de los siguientes datos analógicos:

a) Detección y corrección de desvíos en la conversión A/D.

b) Filtrado de datos.

c) Verificación de razonabilidad.

d) Conversión de datos analógicos a unidades de ingeniería.

e) Vigilancia de límites alto, alto-alto, bajo y bajo-bajo.

f) Vigilancia de límites de niveles de significancia.

g) Utilización de “bandas muertas” para retornos a normal.

h) Cálculo y vigilancia de la razón de cambio.

i) Etiquetamiento de eventos con el tiempo real.

j) Manejo de valores en 32 y 16 bits.

k) Manejo y decodificación de las banderas de calidad de los datos analógicos que sean transmitidos

por medio del protocolo.

l) Uso de banda muerta aplicable únicamente a datos enviados a otros centros de control.

m) Secuencia de eventos con estampa de tiempo (SOE). Las UCM deben de soportar al menos las siguientes características funcionales en el procesamiento de los valores analógicos:

a) Conversión de datos analógicos.

Los datos analógicos obtenidos de las UTR’s deben convertirse a unidades de ingeniería mediante alguna de las siguientes fórmulas:

- AX. - AX+B.

Dónde: A es el factor de conversión.



42 de 154

120713 Rev 160720 161021

B es el desplazamiento (OFFSET). X es el valor obtenido (RAW VALUE) del dato procedente de la UTR. - El sistema debe tener todos los factores de conversión y desplazamientos (OFFSETS)

diferentes que se requieran. Debe contar con la flexibilidad suficiente para agregar nuevas fórmulas, si así se requiere.

- Debe permitir configurar el punto analógico como bipolar o unipolar. Esto es, que sin

importar el formato del punto analógico, se le define si debe usar un bit para definir el signo. - El sistema debe representar los diferentes formatos de acuerdo a los perfiles de los

protocolos, y se deben soportar todos los formatos descritos en los perfiles de los protocolos.

b) Vigilancia de límites alto y bajo.

Después de cada exploración exitosa, se debe verificar las condiciones de violación de los límites y el regreso a la normalidad. Para aquellos puntos que violen sus límites se debe generar un evento, en el que debe incluir la fecha, hora, nombre de la estación, identificación del punto y valor actual. La verificación de regreso a normal debe incluir el uso de una banda muerta, para prevenir excesivos mensajes de eventos. Para cada punto analógico se debe seleccionar su banda muerta.

c) Niveles de significancia.

Se debe contar por cada punto analógico, por lo menos seis niveles de significancia que deben agruparse por pares. Si un punto analógico excede varios límites en el período de exploración, se debe generar una alarma por cada límite violado. Si un punto regresa a su estado normal, a través de uno o varios límites, se debe generar una alarma por cada límite rebasado. Estos niveles deben ser modificables a través de desplegados. Se acepta que los límites sean manejados como un porcentaje de los valores que sean tomados como referencia para los demás. Este porcentaje debe poderse modificar manualmente en línea y debe estar definido por punto de la base de datos. El sistema debe contar con la funcionalidad de definir 4 conjuntos de niveles de significancia por punto. Estos deben ser seleccionables manualmente por el operador. Esta funcionalidad de 4 conjuntos de niveles, es opcional y debe ser incluida si se indica en Características Particulares.

d) Vigilancia de la razón de cambio.

Se debe contar con una verificación que relacione la magnitud de cambio respecto al tiempo. Se debe calcular una pendiente que se pueda comparar a límites configurados y generar una alarma en caso de excederse, en forma sostenida, durante un cierto número predeterminado de exploraciones. También, se genera una alarma si la razón de cambio excede un determinado valor en forma repentina. Esta funcionalidad es opcional debe ser incluida solo si se indica en Características Particulares. Se debe realizar el etiquetamiento con el tiempo real de ocurrencia de violaciones de límites, niveles de significancia y razón de cambio, con resolución de 1 s.



43 de 154

120713 Rev 160720 161021

Los cambios en los valores analógicos deben ser almacenados en la base de datos histórica de acuerdo a las políticas de almacenamiento que deben ser configurables y pueden actualizarse en línea con el editor de base de datos.

6.8.3.4 Procesamiento de acumuladores a) Acumuladores sin registro temporal (buffer).

b) Congelamiento de acumuladores con registro temporal.

c) Acumuladores con registro temporal.

d) Conversión a unidades de ingeniería (punto flotante).

e) Vigilancia de límites.

f) Etiquetamiento de eventos con el tiempo real.

g) Acumuladores de equipos integradores (valores horarios, diarios mensuales de energía).

h) Manejo de datos en 16 bits y 32 bits.

i) Manejo y decodificación de las banderas de calidad de los datos analógicos que sean transmitidos

por medio del protocolo.

- Las UCM deben de soportar al menos las siguientes características funcionales en el procesamiento de los acumuladores.

- Adquisición.

j) Se requieren dos tipos de acumuladores:

- Acumuladores con registro de almacenamiento temporal (buffer).

- Acumuladores sin registro de almacenamiento temporal.

El formato de adquisición de los acumuladores debe ser definido por el usuario de acuerdo al perfil del protocolo con el cual sé este interrogando a la UTR, preferentemente debe ser un analógico de 32 bits y con estampa de tiempo del dispositivo que lo adquirió. La UCM debe tener la funcionalidad para que con los protocolos de comunicaciones y las UTR´s que manejan acumuladores y su congelamiento (“freeze”), le permita a la UCM la manipulación de esa información. Lo requerido para la explotación de los acumuladores es lo siguiente: Para la adquisición de la información de los acumuladores con registro de almacenamiento temporal, debe existir un comando de congelamiento programado a una hora determinada, para pasar los valores de los acumuladores a su registro temporal y su adquisición posterior mediante una exploración bajo solicitud específica del operador.

k) La adquisición de los acumuladores sin registro temporal debe ser: - Como parte de la exploración analógica. - Como acumulador (Running accumulator).



44 de 154

120713 Rev 160720 161021

El congelamiento, la adquisición y el procesamiento de los acumuladores deben estar sincronizados con el reloj del sistema si así lo desea el operador. Existiendo cuatro períodos de adquisición seleccionables para cada acumulador: - Cada hora. - Cada 30 min. - Cada 15 min. - Cada 5 min.

Se deben incluir mecanismos para asegurar que se obtenga la información de los acumuladores requeridos en los ciclos de tiempo especificados, tan cercano como sea posible al programado. En el caso de los acumuladores sin registro temporal, el usuario debe definir los tiempos de exploración o usar las formas de exploración que le permita el potencial del perfil del protocolo, lo cual debe de poder ser totalmente configurable.

l) Procesamiento.

Se debe procesar acumuladores relativos (delta) y absolutos. Un acumulador relativo se incrementa continuamente hasta llegar a su valor máximo y luego regresa a cero , para estos casos la cuenta acumulada se debe obtener restando del valor actual el valor anterior. En los acumuladores relativos se debe evitar la pérdida de una cuenta cuando el registro pase de la cuenta máxima a cero. Un acumulador absoluto se regresa a cero cada vez que es leído. La conversión a unidades de ingeniería, se debe hacer de acuerdo con la siguiente fórmula:

Valor = cuenta acumulada x factor de conversión

Se requiere contar con las siguientes funciones para acumuladores: - Entrada manual de valores. - Verificación de límites. - Cálculo de valores máximos y mínimos. - Cálculo de valores promedios. - Cálculos aritméticos.

m) Errores y recuperación.

Si un acumulador no se puede leer normalmente (por ejemplo, falla de comunicación), debe reintentarse un número predeterminado de veces configurable, inicialmente 3. Si no se logra su adquisición, el punto se debe marcar fuera y se debe generar una alarma. Cada período de exploración de acumuladores se debe realizar un intento de adquisición, si se lee exitosamente se debe reanudar su procesamiento y se debe generar un aviso al operador. Adicionalmente los cambios en los valores de los acumuladores deben ser almacenados en la base de datos histórica de acuerdo a políticas de almacenamiento que deben ser configurables y se pueden actualizar en línea con el editor de base de datos.



45 de 154

120713 Rev 160720 161021

6.8.3.5 Secuenciador de eventos SOE El sistema en general debe estar en disposición de manejar todos los eventos analógicos y binarios con etiqueta de tiempo como lo definen los perfiles del protocolo. El estampado de tiempo debe ser puesto por el equipo que procesó el evento (el equipo fuente). Los eventos que lleguen a la UCM deben ser almacenados en la base de datos del servidor de históricos para su posterior explotación en tablas o gráficos, filtrado o análisis. La estación maestra debe sincronizar al dispositivo remoto por medio del protocolo por el cual este siendo interrogando. Esta opción es configurable considerando que la sincronización con los elementos esclavos puede hacerse según sea el caso:

a) Si los dispositivos remotos son sincronizados por la misma UCM utilizando el tiempo UTC.

b) Si los dispositivos remotos tienen GPS, por lo que la UCM no debe sincronizar a los elementos esclavos.

c) Para los dispositivos remotos que no soportan la sincronización por UTC y se encuentran en

distinta zona horaria que la UCM, se debe permitir que desde la UCM se pueda ajustar la hora ya sea sumando o restando al estampado de tiempo recibido de campo para corregir esta deficiencia del equipo remoto.

Bajo ninguna circunstancia deben perderse o duplicarse los eventos SOE del sistema. 6.8.3.6 Valores Calculados El sistema debe de soportar las siguientes operaciones:

a) Suma y resta.

b) Multiplicación, tanto de valores positivos como negativos.

c) División, tanto de valores positivos como negativos.

d) Raíz cuadrada.

e) Exponencial.

f) Operadores relacionales (, ≥, =, ≠, ±, ≤, ˂).

g) Operaciones booleanas.

h) Operaciones con sentencias de control If, Then, Else.

i) Funciones trigonométricas y funciones matemáticas.

j) Redondeo (con y sin truncado de decimales).

k) Integración.

l) Valor absoluto.

m) Cálculos especiales.

n) Valores máximos y mínimos.



46 de 154

120713 Rev 160720 161021

Los cálculos pueden incluir uno, dos o más operandos, pudiendo ser algunos de éstos constantes. Se puede extender al resultado del cálculo, las etiquetas de los operandos. Se debe incluir alguna previsión para señalar como errores: la división entre cero, la raíz cuadrada de un número negativo y cuando alguna de las entradas del cálculo sea inválida. En el cálculo se debe soportar cualquier variable del sistema. Las modificaciones se deben realizar en línea vía el editor único de base de datos. Todos los cálculos deben de ser ejecutados siguiendo la periodicidad configurada, la cual debe ser de al menos un segundo o al ocurrir un cambio en cualquiera de los operandos. 6.8.3.7 Exploraciones periódicas Se debe proporcionar la facilidad de definir varios grupos de exploración, con ciclos y prioridades diferentes, de manera que se pueda jerarquizar la adquisición de datos de las UTR’s. Estos grupos de exploración definen bloques de datos, que pueden obtenerse de las UTR’s con una sola solicitud de exploración y cada grupo puede contener:

a) Datos binarios exclusivamente.

b) Datos analógicos exclusivamente.

c) Acumuladores.

d) Secuencia de eventos (SOE).

e) Bloques específicos por dirección, de cualquier combinación de ellos. Los puntos del mismo tipo que se definan en un grupo de exploración, pueden o no estar en bloques contiguos de dirección en la UTR y por consiguiente en la base de datos. Para cada grupo de exploración se define un período de adquisición diferente. Los períodos de adquisición deben ser configurables por el usuario. Además de la exploración periódica, el sistema debe realizar la exploración continua (POLL SCHEME). La UCM debe tener las facilidades para que realice la exploración de UTR´s en función del protocolo que se utilice, de tal manera que para los protocolos más avanzados debe soportar el potencial que le da el perfil para que el usuario configure la exploración hacia la UTR según su criterio. La UCM debe soportar e incluir el manejo de diferentes tipos de protocolos de comunicaciones con UTR’s, como mínimo TASE2.0, DNP3 maestro y esclavo, serial y sobre TCP/IP, en caso de requerirse un protocolo adicional debe indicarse en Características Particulares. De requerirse el perfil del protocolo adicional debe ser indicado en las bases de convocatoria. El perfil del protocolo DNP3 requerido para esta especificación se indica en el Apéndice “A” “Perfil del protocolo DNP3 maestro”. Cuando el área usuaria requiera el DNP3 esclavo se debe indicar en Características Particulares y además debe anexar el perfil del protocolo requerido. 6.8.3.8 Control de equipos, relacionados con este subsistema, en forma automática y a través de

desplegados, de acuerdo a lo siguiente:

a) Control de exploraciones.

El sistema debe contar con la opción para que el operador pueda controlar la exploración de UTR’s desde las consolas y realizar a través de desplegados las siguientes funciones:



47 de 154

120713 Rev 160720 161021

- Poner dentro/fuera de exploración a una o varias UTR´s.

- Poner dentro/fuera de exploración uno o varios canales de comunicación.

- Cambiar de canal primario/secundario.

- Solicitar exploraciones bajo demanda.

b) Cambios automáticos por falla de canal.

El sistema debe manejar solicitudes automáticas de cambios de configuración en caso de fallas de canal. La filosofía debe ser la siguiente: - Falla de canal primario.

Las UTR´s que se estén explorando por su canal primario, se deben cambiar automáticamente al canal secundario después de N1 fallas consecutivas, dando aviso al operador, independientemente de que se encuentre o no en canal compartido. El valor N1 debe estar definido en la base de datos.

- Falla de canal secundario, después de haber fallado el canal primario.

Si las UTR´s exploradas por el canal secundario, se debe declarar fuera, automáticamente después de N1 fallas consecutivas, dando aviso al operador. Las configuraciones que debe soportar son las siguientes:

Nodo A IP: A.B.C.X PTO: 20 000 Dirección DNP: f Nodo B IP: A.B.C.Y PTO: 20 000 Dirección DNP: g Nodo A IP: A.B.C.D PTO: 20 001 Dirección DNP: f Nodo B IP: A.B.C.D PTO: 20 002 Dirección DNP: g (Refiérase al párrafo 7.6)

c) Falla de UTR durante la exploración.

Si una UTR ha sido declarada automáticamente fuera de exploración por fallas, se debe intentar el restablecimiento de la comunicación con ella en forma periódica, con la filosofía siguiente: Si la UTR se declara fuera por fallas, se hace un reintento automáticamente cada N2 segundos tanto por el canal primario como por el secundario alternativamente. Si se logran N3 respuestas exitosas de la UTR por cualquier canal, ésta se debe declarar dentro. Los parámetros N1, N2 y N3 deben ser modificables en línea por el administrador de base de datos. Los eventos resultantes de la falla en la UTR por canal así como la declaración dentro de la UTR deben ser notificados al operador.

6.8.3.9 Disparador de programas El proveedor debe de proporcionar una aplicación que su función sea el disparo o arranque de programas desarrollados por el usuario o por el proveedor. Estos disparos se activarán de acuerdo a:

a) Violación de cualquier límite alto o bajo.

b) Con el cambio de estado condicionado de un punto binario.

c) Con la violación de límites de niveles de significancia.



48 de 154

120713 Rev 160720 161021

d) Con el cambio de cualquier bandera de calidad.

e) La combinación de cualquiera de las anteriores.

El proveedor debe de proporcionar la interface para configurar y relacionar los puntos analógicos, estados y acumuladores que deben disparar ciertos programas y la bandera, el límite o combinación debe ser la que active al disparador. 6.8.3.10 Banderas de calidad Las banderas de calidad son propiedad de los puntos almacenados en la base de datos que indican algunas condiciones que afectan estos puntos. Estas banderas de calidad deben ser configurables en la base de datos y deben ser accesibles para visualización en desplegados para el operador, inclusión en reportes y uso por las funciones del SCADA. Las banderas de calidad incluidas con los datos, provenientes desde las fuentes (UTR´s y DEI´s) utilizando protocolos estándares, como DNP3, deben ser mapeados con las banderas de calidad de la UCM. De igual forma, los datos transmitidos desde la UCM hacia otros centros de control mediante protocolo DNP3 o TASE.2, deben transmitir las banderas de calidad correspondientes. Las banderas de calidad deben ser accesibles en la base de datos como cualquier otro dato y deben estar disponibles como valores del tipo Booleano (verdadero/falso) para cálculos. Adicionalmente a las banderas de calidad del protocolo de comunicaciones se deben generar otras banderas de calidad para visualización en la UCM, siendo las mínimas las siguientes:

a) Adquisición suspendida.

b) Cálculo suspendido.

c) Error de telemetría o cálculo.

d) Imprecisión del convertidor A/D.

e) Violación de razonabilidad.

f) Resultado inconsistente.

g) Valor manual.

h) Control inhibido.

i) Alarma inhibida.

j) Punto etiquetado.

k) Punto seleccionado. Los valores sustituidos con una entrada manual deben ser considerados como válidos.



49 de 154

120713 Rev 160720 161021

6.8.4 Servicios de procesamiento de aplicaciones complementarias de la UCM Se requieren ciertas aplicaciones relacionadas con la función de SCADA. Entre estas aplicaciones se encuentran:

a) Tiro y restauración de carga.

b) Secuenciador de eventos (SOE).

c) Controles macrosecuenciales

d) Coloreo dinámico. 6.8.5 Módulo de control supervisorio En este módulo se describen las funciones directas de control y su interacción con las consolas de operador debido a la información que se recibe de campo (UTR´s y DEI´s). 6.8.5.1 Funciones directas de control Se deben ejecutar las siguientes funciones de control:

a) Controles sobre dispositivos

- Abrir/cerrar.

- Subir/bajar.

- Ajuste de valores analógicos (SET POINT).

b) Condicionamiento e indicaciones del punto

- Activar/desactivar la alarma.

- Poner/quitar licencia.

- Invertir la definición normal.

- Activar/desactivar control.

- Poner/quitar etiqueta informativa.

- Poner dentro/fuera de exploración.

- Cambio del valor del punto mediante entrada manual.

- Indicación fuera de exploración. 6.8.5.2 Controles sobre dispositivos El sistema debe tener la capacidad de dividirse en áreas de responsabilidad y estas áreas de responsabilidad deben ser asignadas a cada consola de la UCM y por usuario. El área de responsabilidad resultante de una consola es el resultado de la función lógica “Y” (AND) entre el área de responsabilidad del usuario y el área de responsabilidad de la



50 de 154

120713 Rev 160720 161021

consola. Esta partición puede ser funcional, por ejemplo, red de transmisión, generación, administración de energía y distribución. Cada consola y bitácora puede ser asignada a una o más áreas de responsabilidad. El sistema debe inhibir operaciones puntuales desde áreas de responsabilidad no autorizadas. Para evitar operaciones duplicadas de control desde diferentes consolas, el punto seleccionado debe ser presentado a todos los usuarios que estén accesando dicho punto como ocupado o en proceso. El usuario que haya hecho la selección inicialmente debe ser el único autorizado para controlar dicho punto, todos los intentos de selección que se hagan deben ser rechazados o mostrado inhibido, hasta que deje de hacerlo el usuario inicial. Se debe de indicar de manera adecuada en el desplegado al resto de los usuarios que un usuario está seleccionando y controlando el punto. La función geográfica jerárquica de control sobre dispositivos, de algún otro protocolo, debe permitir la acción de control, desde otro centro de control, sobre los puntos de las UTR´s que se encuentran bajo la UCM. Para que esta función sea operable apropiadamente, los sistemas deben garantizar los medios que eviten la duplicidad de la acción de control. Por lo anterior nunca se puede tener la opción de control sobre un mismo punto, dos controles supervisorios (UCM) al mismo tiempo. Un centro de control debe tener la opción de ceder o tomar el control con respecto a otro centro de control, en el entendido de que debe existir un etiquetamiento especial sobre el punto para ambos centros, indicando claramente quién tiene bajo su responsabilidad la acción del control.

a) Comandos abrir/cerrar.

Los comandos de abrir/cerrar deben cumplir con el esquema de dos pasos, que son armar y ejecutar o el de solo ejecutar.

- Debe aparecer un mensaje de verificación que indica el dispositivo seleccionado y la

operación a realizarse. Si el dispositivo tiene algún atributo que impide el control, debe aparecer un mensaje de alarma indicando esta restricción.

- Si la selección es válida, el sistema debe realizar la acción de ejecutar.

- Al recibirse el cambio desde la UTR, debe cambiar la representación del dispositivo y su

color en el desplegado y debe aparecer un mensaje que indique que el control se ejecutó. Se debe registrar además un mensaje del evento tanto en pantalla como en la bitácora indicando esta condición.

Al momento de la selección se debe iniciar un período de tiempo t1 s, que de expirar, debe ocasionar que el dispositivo se deseleccione automáticamente pudiendo generar un mensaje que indique que el punto de control ha sido desarmado. Así mismo, si no se recibe una confirmación exitosa del control en un período de t2 s después de la orden de ejecutar, debe aparecer un mensaje de evento, indicando esta condición de error. Mientras el dispositivo esté ocupado, no se puede seleccionar para otra operación. Los tiempos t1 y t2 deben ser configurables en línea desde el editor de base de datos. Este tipo de control, debe configurarse como de operación directa, de selección y operación, y debe ser configurable para cada punto. Los puntos con etiquetas de licencia, con controles desactivados o declarados fuera de exploración no deben ejecutar controles.

b) Comandos subir/bajar.

- Control de comandos subir/bajar (jogging).



51 de 154

120713 Rev 160720 161021

La secuencia de control de los comandos de subir/bajar, utilizado en los cambiadores de derivaciones de los transformadores y movimiento de compuertas en presas reguladoras, debe funcionar como el control abrir/cerrar con la diferencia de que la acción se debe llevar a cabo en forma continua el número de veces que se haya dado la orden de ejecutar, sin dejar de seleccionar el punto. La confirmación de la acción se observa por el cambio de la entrada analógica referenciada a ese control. El fin de la sesión de control se determina mediante el comando cancelar. Esta acción implica que se genere una demanda de exploración de analógicos que incluyan el punto afectado en un tiempo t3 s, que debe ser configurable. El punto se debe deseleccionar automáticamente si excede un período t2 s (configurable) o si se da la orden de cancelar. Para el manejo de los cambios de derivación de los transformadores (TAPs) se requiere código binario decimal (BCD), la cual debe ser convertida por la estación maestra a la posición de TAPs. Para esta función, se debe contar con manejo de hasta 48 posiciones. Estas posiciones de TAPs deben ser presentadas en los diagramas unifilares.

c) Ajuste de valores analógicos (set point).

Debe tener la funcionalidad de enviar comandos para el ajuste de datos analógicos a un valor determinado hacia un equipo remoto. El set point, debe seguir la misma técnica para conversión de datos analógicos con la diferencia que la fuente de la información debe ser la UCM y el destino el equipo remoto. El set point debe ser configurado de acuerdo a las necesidades del usuario y al potencial del perfil del protocolo.

6.8.5.3 Condicionamiento e indicaciones del punto Son funciones que permiten poner/quitar restricciones operacionales sobre algunos puntos que así lo requieran. Las funciones son: desactivar/activar la alarma, poner/quitar licencias, invertir la definición normal de un punto, desactivar/activar control, poner/quitar etiqueta informativa, poner dentro/fuera de exploración, cambio del valor del punto mediante entrada manual, indicación fuera de exploración. Estas operaciones serán registradas en la bitácora correspondiente.

a) Desactivar/Activar el procesamiento de alarma sobre un punto.

Cuando se desactive un punto de alarma, debe ser etiquetado automáticamente en los desplegados donde aparezca, y no debe generar alarmas. Esta funcionalidad debe ser configurable por el usuario. En esta condición, el punto debe continuar su actualización si es que se registra algún cambio y debe permitir su control (si lo tiene definido), pero debe desactivar su procesamiento de alarmas. La función de desactivar, debe permitir la entrada de un comentario del operador. Se deben crear sumarios cronológicos de puntos desactivados, organizados por categorías. Para activar un punto, se debe seleccionar en el diagrama unifilar, o tabular, y se solicita la acción a través del menú correspondiente.



52 de 154

120713 Rev 160720 161021

b) Poner/quitar licencias.

Mediante esta función se debe solicitar poner en licencia un dispositivo, se debe etiquetar el punto automáticamente con la bandera de licencia, se debe inhabilitar el control e inhabilitar el procesamiento de alarma de punto en cuestión.

c) Invertir la definición normal.

Usando esta función se debe invertir el estado binario definido como normal. Esta acción no debe generar ningún atributo al punto, sin embargo, si el punto aparece en el sumario de alarmas por estar en estado anormal, cuando se realice esta acción, debe desaparecer del mismo. Si al realizar esta operación, el estado actual del dispositivo es normal, entonces debe aparecer en el sumario como anormal.

d) Activar/desactivar control.

Esta función debe permitir deshabilitar la opción de control para los puntos sobre los que hay mando. Un control deshabilitado debe ser indicado por el sistema automáticamente y la operación de activar o desactivar un control, debe quedar registrado en el sumario de eventos. Cuando se intente realizar una operación de control sobre un punto desactivado, se debe bloquear la operación e indicar al operador que el control está desactivado.

e) Poner/quitar etiqueta informativa.

El sistema debe permitir asignar textos informativos a los puntos telemedidos. Este texto debe ser fácilmente accesible y la asignación del texto no debe bloquear ninguna función de procesamiento.

f) Poner dentro/fuera de exploración.

La función de declarar un punto “fuera” de exploración, debe detener el procesamiento de ese punto. Un punto bajo esta condición se debe presentar etiquetado de manera automática. Para habilitar nuevamente el punto, se debe seleccionar y declarar “dentro” de exploración mediante la función correspondiente. La etiqueta debe quitarse automáticamente con esta acción. Cuando se declare un punto fuera de exploración, si éste se encuentra alarmado, debe desaparecer del sumario de alarmas correspondiente y actuar como si estuviera desactivado. Esta funcionalidad debe ser configurable.

g) Cambio del valor del punto mediante una entrada manual.

Todos los puntos deben permitir el reemplazo manual. Este estado debe ser fácilmente identificable por el usuario con un color distintivo y el valor introducido debe ser procesado por los diferentes módulos como son manejados los valores adquiridos por el sistema.

h) Indicación fuera de exploración.

Si una UTR sale de exploración, todos los puntos telemedidos deben ser marcados con una etiqueta y con un color distintivo de esta condición y debe conservar la información obtenida en la última exploración. De igual forma, cuando exista una configuración diferente en el sistema respecto a la de la UTR y algunos puntos no estén siendo adquiridos mediante las exploraciones, el procesamiento debe ser el mismo.

Todos los caracteres utilizados en las funciones descritas anteriormente deben ser configurables, de tal manera que sean claros y referenciados al idioma español.



53 de 154

120713 Rev 160720 161021

Deben suministrarse resúmenes cronológicos de puntos con etiquetas de licencia, fuera de exploración, reemplazo manual, desactivado y anormal, en los que se vayan registrando por categoría, todos y cada uno de los puntos que se encuentren en alguna de estas condiciones. 6.8.5.4 Tiro y restauración de carga (opcional) El tiro y la restauración de carga es un módulo de “software” que contempla, el tiro manual/rotativo de carga y la restauración de carga y es opcional para un sistema básico de una UCM por lo que para suministrarlo por el proveedor debe ser solicitado en Características Particulares. Tiene su operación en grupos de interruptores de una o de diferentes UTR´s al mismo tiempo ya sea abriendo o cerrando los interruptores. Cada grupo de tiro de carga debe ser identificable por medio de una numeración secuencial o denominación específica y debe tener un punto de control en la UCM para ejecutar la acción de tiro y restauración de carga, así como un punto de medición calculada que sume el total de las cargas individuales de cada interruptor del grupo. En el mismo desplegado donde aparezca el grupo debe aparecer el estado en que se encuentra cada punto del grupo con las etiquetas (símbolos de calidad) definidas en la UCM. Debe tener como facilidad adicional que se pueda programar el tiempo de duración del tiraje de carga para que una vez transcurrido este tiempo, se restablezca la carga automáticamente. Los controles que se encuentren fuera de exploración, control inhibido y control en proceso, deben ignorar los mandos de un programa de tiro y restauración de carga. Debe permitir la programación del inicio del tiraje de carga para cada grupo. En caso de que el tiempo programado de restablecimiento de la carga se exceda (no ocurrió el restablecimiento de carga), la UCM debe alarmar al operador para indicarle que ese grupo de carga no fue recuperado, quedando a criterio del operador el restablecimiento manual del grupo. Dentro del desplegado del grupo, el operador debe tirar o restablecer carga de manera anticipada de algunos puntos según sea la necesidad de sus acciones. Debe haber un registro de la información de la fecha y duración de los tiros así como la cantidad de carga tirada debiendo quedar en el Histórico para su explotación gráfica y estadística. Esta función de tiro y recuperación de carga debe consistir de tres paquetes:

a) Tiro manual de carga.

b) Tiro rotativo de carga.

c) Restauración. 6.8.5.4.1 Tiro manual de carga La función de tiro manual de carga debe permitir a los operadores deslastrar bloques de carga a través de mandos interactivos con el desplegado. Se deben suministrar los desplegados para la definición interactiva y revisión de bloques de carga para ser deslastrados. Esta función también debe monitorear la carga total del sistema, los bloques de carga, las cargas individuales (interruptores) dentro del bloque de carga de tiro y el estado de la carga. Los bloques de tiro de carga debe constar de alimentadores, dispositivos asociados y clientes afectados. El operador debe estar en capacidad de deslastrar manualmente un bloque entero de carga seleccionando el bloque y ejecutando un comando de tiro de carga. La función de tiro manual de carga debe enviar automáticamente un mando de los interruptores en secuencia. Debe estar disponible una opción para escalonar la apertura de interruptores involucrados en un bloque de tiro. La cantidad de tiempo utilizado en el escalamiento debe ser definible por el usuario. Los operadores deben estar en capacidad de tirar un bloque entero o cargas individuales dentro del bloque.



54 de 154

120713 Rev 160720 161021

Se deben suministrar los desplegados que presentan la carga total del sistema, los bloques de carga, cargas individuales (interruptores) dentro del bloque de carga, los clientes afectados y el estado de la carga. 6.8.5.4.2 Tiro rotativo de carga A cada carga que esté sujeta a tiro, se le asigna uno de los bloques de carga marcados como a, b, c. A los alimentadores individuales dentro de cada bloque se les asigna una prioridad y se debe mantener en una lista ordenada de los alimentadores de acuerdo a su prioridad para cada uno de los bloques. El usuario debe preparar con anterioridad una tabla con una columna para cada día de la semana, con secciones horizontales correspondientes a los diferentes rangos de tiro de carga. Actualmente existen tres rangos que representan los diferentes rangos de tiro de carga en MW. Cada uno de estos rangos posteriormente se subdivide en rangos de tiempo no traslapados. Las células formadas por una sección cruzada de un intervalo de tiempo y un día de la semana, y para cada rango de tiro de carga, contienen una lista de uno o más bloques (por ejemplo, a, o a y d, o a, d y l) sujeta al tiro de carga en ese momento, en ese día y para la demanda de tiro de carga dada. Se requiere que el proveedor entregue desplegados interactivos para mantener estas listas y para desplegar y priorizar los alimentadores individuales dentro de los bloques. Los desplegados también deben presentar la carga total del sistema, un estimativo de la carga no atendida, la duración de la salida de la carga para cada alimentador, los flujos reales de MW a través de los alimentadores que comprenden cada bloque, los MW totales de cada bloque, los clientes afectados y un indicador de alarma cuando la carga disponible para tiro en el intervalo de tiempo actual y para que el día actual este por debajo del rango de tiro de carga requerido. El estimativo de la carga no atendida debe ser consistente con la carga real del sistema y en conformidad de la carga del alimentador. La función de tiro de carga rotativo debe proveer los desplegados y la funcionalidad adecuada para permitir al operador ingresar los requisitos de tiro de carga en MW, en lo cual el programa debe encontrar el rango de tiro de carga aplicable, la hora del día y el día de la semana, y posteriormente identificar el bloque o bloques elegibles para el tiro. Dentro de los bloques elegibles, el programa debe identificar los alimentadores para el tiro procediendo en orden de prioridad, iniciando desde el último alimentador donde anteriormente se había realizado un tiro de carga. El programa debe compilar una lista de alimentadores cuyos flujos de MW acumulados concuerden con el tiro de carga requerido, y con la aprobación del operador debe iniciar los comandos de control para abrir los alimentadores seleccionados. Si el operador elige no abrir ninguno de los alimentadores de la lista, el programa debe automáticamente seleccionar el siguiente alimentador o alimentadores candidatos bajando la lista hasta que se alcance la cantidad requerida de MW. Los alimentadores aprobados deben automáticamente ser abiertos bajo el control del programa y mediante escalamiento abrir los interruptores, cuando se especifique un retraso de tiempo opcional entre las operaciones sucesivas. Los requisitos de tiro de carga deben ser expresados según el requisito absoluto de MW, es decir, el programa debe restar de este requisito cualquier carga no atendida y seleccionar los nuevos bloques de carga para cubrir solamente lo restante. 6.8.5.4.3 Restauración de carga

El programa de tiro de carga debe incluir una función de restauración que permita al operador restaurar la carga que haya sido cortada por la función de tiro de carga. El operador debe estar en capacidad de restaurar la carga ya sea individualmente o por grupos a través de mandos interactivos en el desplegado. Los desplegados para presentar la carga no atendida deben ser suministrados con una utilidad de ordenamiento según el estimativo de MW no atendidos, duración de la salida, por bloques o por prioridad. Estos desplegados deben también presentar la carga total del sistema y un estimativo de la carga total no atendida.



55 de 154

120713 Rev 160720 161021

6.8.5.5 Procesador de alarmas Debe procesar alarmas de tal manera que las filtre en orden de importancia para el operador del sistema eléctrico. Para lo anterior se debe permitir que a las alarmas se les configure el nivel de importancia. En condiciones anormales o de emergencia donde se presente una avalancha de alarmas en la UCM, las alarmas deben ser reportadas de manera ordenada de acuerdo al nivel de importancia. Al menos se requiere la siguiente funcionalidad:

a) Alarmas clasificadas por orden de importancia. b) Alarmas clasificadas funcionalmente y por área de responsabilidad.

c) Utilización de coloreo dinámico para identificar alarmas entre las diferentes severidades.

d) Filtrado de alarmas generadas a raíz del cambio, por el mismo equipo eléctrico, interruptor,

transformador, línea, subestación o instalación.

e) El formato de la presentación de todas las alarmas en los desplegados deben ser configurables mostrando al menos: fecha y hora, descripción, usuario que ejecuto una acción como son ejecutar, inhibir, reconocer, entre otras.

f) Cuando una alarma sea borrada por el sistema debido a que llega al número máximo de alarmas

estas deben ser enviadas a las diferentes bitácoras, especificando claramente que fue borrada por el sistema.

6.8.5.6 Controles macrosecuenciales Los controles macrosecuenciales son una lista de operaciones dirigidas por el usuario para realizar la conexión/desconexión de elementos del sistema eléctrico. El sistema debe permitir generar estas macrosecuencias de forma manual y permitir su ejecución a solicitud del operador , debe también desplegar la configuración de las mismas a través de desplegados en los que fácilmente se pueda cambiar su configuración , adicionalmente estas macrosecuencias deben ser guardadas en archivos para su análisis fuera de línea. El sistema debe permitir establecer retardos de tiempo entre operaciones y debe permitir salvar las macrosecuencias generadas. 6.8.5.6.1 Creación manual de macrosecuencias El manejador de secuencias debe contar con procedimientos simples donde el operador pueda definir y almacenar secuencias. Esta aplicación debe estar basada en funciones de tipo “DRAG and DROP” para minimizar la utilización de nombres de dispositivos y claves. Debe contar con desplegados tipos sumarios, que permitan fácil acceso a secuencias previamente almacenadas. Con el fin de reducir el tiempo y esfuerzo en la creación de secuencias, algunos campos deben contar con valores iniciales. Las nuevas secuencias deben crearse automáticamente por el operador, seleccionando acciones gráficamente en los desplegados en línea de la red. Una secuencia debe contener por lo menos la siguiente información:

a) Título.

b) Número de procedimiento.

c) Fecha y hora de creación.



56 de 154

120713 Rev 160720 161021

d) Fecha y hora de modificación.

e) Código (diario, semanal, mensual, especial, entre otros).

f) Autor.

g) Aprobado por.

h) Estado (en uso, en desuso, cerrado).

i) Entradas múltiples consistentes en:

- Acción (etiqueta, control, actualización).

- Equipo asociado con la acción.

- Desplegados asociados.

- Notas. Debe proveer un sistema administrador con funciones que permitan almacenar, restaurar, seleccionar, copiar, ordenar y revisar las secuencias. Por medio del sumario, las secuencias deben ser ordenadas de acuerdo al número, período de tiempo, estado y código. Además debe permitir acceso de un paso a secuencias individuales. Los controles macrosecuenciales deben permitir la capacidad de definir condiciones como parte de los pasos de la secuencia. Estas condiciones deben incluir el estado actual del interruptor y valores de puntos analógicos las que, junto con el estado del control, sirven de criterio para determinar el éxito o la falla del paso anterior de la secuencia, que puede originar que la secuencia continúe o sea abortada dependiendo de la definición de la secuencia. Un control macrosecuencial debe ser iniciado manualmente por el operador. La función de control macrosecuencial debe controlar la iniciación de los pasos de la secuencia, la cual debe utilizar el éxito de los pasos anteriores, la definición de la secuencia y los retardos de tiempo ajustables por el operador para determinar cuándo deben salir los controles subsecuentes. Utilizando estas características, deben permitir enviar controles de forma paralela o serial. Las secuencias de control deben permitir ser iniciadas con un solo paso sin más interacción con el operador o el operador debe poder ir determinando en cada paso si la secuencia debe proceder. 6.8.5.6.2 Mantenimiento de macrosecuencias Una vez que una macrosecuencia ha sido ejecutada, el sistema debe permitir la opción de guardarla para su uso posterior. Debe mantener un directorio de macrosecuencias, organizadas por área de responsabilidad. El usuario puede revisar el directorio, copiar, renombrar, imprimir y borrar macrosecuencias, así como llamarlas para su revisión y modificación. Durante la ejecución de cualquier secuencia, todos los errores y eventos relacionados deben ser documentados a través de mensajes al operador o mensajes a bitácoras. 6.8.5.7 Coloreo dinámico La UCM debe proporcionar la capacidad de mostrar en sus desplegados él coloreo dinámico de los elementos compuestos por elementos básicos como son líneas, círculos, rectángulos y textos que usualmente representan líneas de transmisión, transformadores, y demás elementos eléctricos. Las características mínimas que debe incluir el coloreo dinámico son:

a) La referencia que determine el estado de los elementos con coloreo dinámico asignado debe ser cualquier valor que exista en la base de datos del sistema, como pueden ser puntos analógicos,



57 de 154

120713 Rev 160720 161021

puntos estado, valores de las aplicaciones del SCADA. Estos valores deben ser asignados utilizando consultas SQL o mediante un código identificador del sistema.

b) El coloreo debe permitir agrupación de elementos, cambiar de color, tipo y grosor de línea e intermitencia.

c) El coloreo debe ser configurado sobre los mismos elementos del desplegado “normal”, es decir el coloreo dinámico se asigna a los elementos ya dibujados.

6.8.5.8 Comunicaciones

6.8.5.8.1 Supervisión de comunicaciones Debe proporcionarse la programación que genere bitácoras del intercambio de mensajes entre la UCM y cada una de la UTR’s conectadas a él, incluyendo información para el análisis de errores de comunicación, estadísticas de disponibilidad de canales y eventos relevantes de los dispositivos involucrados en el proceso de comunicación entre remotas y maestra. Se deben cubrir los siguientes conceptos:

a) Registro de fallas de comunicación en los mensajes de la UCM a los elementos esclavos. b) Registro de códigos para analizar errores detectados en los mensajes de la UCM a los elementos

esclavos.

c) Registro de dispositivos en uso y cambios realizados en los equipos involucrados en la comunicación de la UCM a los dispositivos esclavos.

d) Registro estadístico de disponibilidad de canales y dispositivos para comunicación. e) Generar automáticamente y bajo demanda, un reporte diario de errores de comunicaciones

almacenados en la bitácora.

f) Contar con una herramienta que permita explotar registros de todos los mensajes de comunicación entre la UCM y las UTR’s almacenados (a nivel byte) por un mínimo de una semana, la consulta debe permitirse por UTR, por canal y por periodo de tiempo.

6.8.6 Requerimientos funcionales para un enlace de red para sistemas externos (opcional) Los enlaces de red para sistemas externos, son funciones opcionales y en caso de requerirse deben ser solicitados en Características Particulares en dónde se debe anexar además, la información necesaria para que el proveedor pueda desarrollar lo solicitado en este punto. El ambiente de tiempo real debe ser un exportador de datos en línea para los usuarios y las aplicaciones en los ambientes fuera de línea. Para los usuarios de ambiente de tiempo real, los ambientes externos son de apoyo operativo, se espera recibir, eventualmente o periódicamente resultados de aplicaciones de planeación operativa , pero principalmente, esperando tener las facilidades para establecer sesiones interactivas como clientes de los servicios externos de apoyo administrativo de la operación. Se requieren al menos tres tipos principales de tráfico de operación con los ambientes externos:

a) Transferencias de información entre procesos relacionados con ambos ambientes.

Esto corresponde a la actualización de datos en ambos sentidos, activándose periódicamente o por demanda de los usuarios de ambos ambientes.



58 de 154

120713 Rev 160720 161021

b) Transferencias de información resultantes del acceso interactivo de los usuarios del ambiente de tiempo real a los servidores de aplicaciones de los ambientes externos, interactuando con las facilidades de los sistemas operativos en red en una arquitectura cliente - servidor.

Es requerimiento mandatorio que el proveedor suministre el “software” básico y funcional para realizar diversas funciones como son:

- Nodo cliente del ambiente de tiempo real.

- Servidor de base de datos, de exportación a los ambientes externos y de importación para el ambiente de tiempo real.

- Funciones de conversión de las estructuras de archivos de la base de datos histórica del ambiente de tiempo real a estructuras normalizadas de un ambiente común y utilización de protocolos normalizados para la transferencia de archivos.

Es importante mencionar que no se indicaron modos de transferencia, frecuencia y tipos de datos específicos para los enlaces seriales, por considerar que estos corresponden a transferencias eventuales por demanda y con poco volumen de datos. La transferencia de datos debe considerarse para el nivel operativo del centro de control en base a la disponibilidad de los datos que se manejan en cada nivel.

c) Sesiones interactivas de usuarios del ambiente de tiempo real con las aplicaciones de apoyo

administrativo de la operación, que corren en la red corporativa. Estas sesiones se aplican en los tres niveles operativos con un mínimo de tres sesiones estimadas por cada turno de operadores, considerando tres turnos por día. 6.8.7 Servicios de comunicación y conversión de protocolos Se deben utilizar las conectividades de acuerdo a lo indicado en la referencia [4] del capítulo 13 de esta especificación y otras que la CFE defina en Características Particulares para satisfacer las necesidades específicas del proyecto. Muchas de estas funciones se deben apoyar en las primitivas del sistema operativo, a fin de administrar eficientemente los flujos de datos (DATA STREAMS), en el ambiente de procesamiento distribuido propuesto por el proveedor. El proveedor debe exponer ampliamente el mecanismo utilizado para la definición de los grupos de datos que deben ser transmitidos entre los controladores de comunicaciones, lo mínimo aceptable es que el usuario debe tener la capacidad de definir diferentes grupos con diferentes tiempos y prioridades. Esta actividad debe ser hecha a través del editor de base de datos, sin interferir con el proceso continuo de servicio hacia los operadores, ofreciendo adicionalmente los servicios de seguridad, redundancia, integridad y sincronización de las nuevas definiciones que se hayan hecho. 6.8.8 Información de administrador de red La información de administración de red debe ser enviada entre centros de control, utilizando el protocolo estándar SNMP sobre TCP/IP y el software (management information) bases.



59 de 154

120713 Rev 160720 161021

6.8.9 Seguridad en adquisición de datos Los servidores de comunicaciones deben servir como “firewalls” protegiendo a la UCM de intentos de comunicaciones no autorizadas o inapropiadas desde dispositivos de campo. Esta protección debe ser implementada para protocolos serie tradicionales y para protocolos enrutables sobre TCP/IP. Todos los eventos sospechosos deben ser reportados al sistema. Deben existir registros del tráfico de todas las comunicaciones con el propósito de detectar actividad no autorizada, actividad inusual e intentos de vulnerar la seguridad del sistema en el perímetro de seguridad de la UCM. El proveedor debe discutir cualquier mejora de la seguridad, tal como la encriptación o autentificación adicional que estuvieren disponibles para mejorar la integridad de los datos telemedidos. 6.9 Requerimientos de la Interfaz del Usuario 6.9.1 Diseño de la interfaz de usuario y demostración del software al cliente El sistema debe contar con ayuda en línea de su propio funcionamiento y de sus aplicaciones. Debe tener integrada la documentación técnica de todo el sistema. La CFE debe construir solamente un desplegado una vez, que debe operar sobre cualquier consola. El usuario no debe desarrollar múltiples versiones de desplegados para cada tipo de consola o para cada tipo de “software” de interfaz. 6.9.2 Menús tipo pop-up El número de opciones en cada menú debe ser variable y configurable por el usuario. Cada función del menú se debe definir mediante un texto o un símbolo gráfico (icono), el cual se debe construir mediante el editor de desplegados. 6.9.3 Estructura de desplegados Toda la información presentada en una pantalla se debe manejar y almacenar en la propia consola, bajo el concepto de mapas globales geo-referenciados (que se usa como sinónimo de desplegados). Este concepto permite la creación de desplegados de mayores dimensiones que la pantalla o ventana y su visualización por partes. Estos desplegados deben generarse en un solo mapa global que contenga todos ellos. El sistema debe soportar los desplegados que a continuación se describen:

a) Diagramas: Mapas globales, unifilares de entorno (contexto), unifilares de subestación o imágenes que se utilizan para representar la red eléctrica, con un mínimo de 16 planos de detalles (CLUTTERING / DECLUTTERING), características de movimiento de desplegados en ventanas de menor tamaño (PANNING) y amplificación/reducción (ZOOMING).

b) Gráficas: Utilizadas para la presentación de variables. Utiliza uno, dos o tres planos según el caso,

el movimiento de desplegados y amplificación/reducción.

c) Listas: Para presentar listas de información (resúmenes, por ejemplo) en un solo plano y con la característica de movimiento hacia arriba y hacia abajo (SCROLLING), o de paginado (atrás, adelante).

d) Formas: Para representar desplegados tabulares que son más largos y anchos que la ventana.

Utiliza un solo plano y tienen características de movimiento de desplegados a través de ventanas de menor tamaño.



60 de 154

120713 Rev 160720 161021

Cualquier desplegado puede contener caracteres alfanuméricos y gráficos. Dispondrá de diferentes tipos de caracteres alfanuméricos, en cuanto a tamaño, forma y estilo (FONTS). Los desplegados pueden crearse o modificarse a través de un editor de desplegados en línea y deben formarse mediante una máscara estática y datos dinámicos. Los desplegados son normalizados, previendo áreas para:

a) Comandos, título, hora/fecha, mensajes del operador incluyendo llamadas de atención (por ejemplo, mensajes pendientes), número y página de desplegado.

b) Los datos desplegados (valores, leyendas, símbolos, grids) deben presentarse con las etiquetas que relacionen sus atributos o condiciones. La manera en que se colocan las etiquetas es selectiva, dentro de una gama completa de posibilidades. Por ejemplo: sin etiquetas, alrededor del dato, en línea junto al dato, diferentes etiquetas en el mismo espacio manejando prioridades de traslape.

c) Las etiquetas, deben ser configurables, representativas de la función que manejan y referidas al

idioma español. Deben existir cuatro tipos de desplegados de datos de tiempo real asociados con cada unifilar de una subestación generados automáticamente por el sistema y actualizados ante cambios en la base de datos. Estos cuatro desplegados deben incluir un desplegado para cada tipo de punto, como son los puntos de estados, analógicos, acumuladores y de estados controlables. Para cada punto implementado, el nombre de la instalación (subestación, equipo), nombre de punto, valor actual con coloreo y símbolos anexos deben ser desplegados en el formato tabular. Además, los desplegados tabulares de analógicos deben desplegar los límites de los puntos. Las operaciones y entradas manuales de los puntos de tiempo real deben estar disponibles desde estos desplegados de igual manera que los desplegados unifilares y unifilares de contexto (situacionales). Debe incluir la funcionalidad de mostrar en un desplegado la información del punto seleccionado, en el cual se deben mostrar los parámetros definidos en la base de datos, así como la funcionalidad de búsqueda y ordenamiento de desplegados. Los eventos SOE deben ser desplegados en páginas con el mismo diseño a las de alarmas y deben ser almacenados en la base de datos histórica desde donde se pueden generar los reportes correspondientes. Los eventos que se deben reportar al sistema, provenientes de la exploración mediante un protocolo SCADA, deben ser almacenados y reportarlos al operador, en el orden como fueron adquiridos de campo y adicionalmente el sistema puede desplegarlos en orden cronológico, mostrándose al operador de igual manera en que se muestran las alarmas. 6.9.4 Utilización de atributos en video Dentro de los atributos de vídeo se deben proveer la configuración de estados diferentes por punto de la base de datos tales como normal/anormal, alarma reconocida y no reconocida, entrada manual, habilitar/inhabilitar alarma. La presentación en vídeo de los datos analógicos, acumuladores y digitales debe utilizar los distintos colores, el vídeo inverso y la intermitencia de forma consistente con los atributos de condición. Bajo ciertas condiciones, los atributos de vídeo de los datos dinámicos a través de acrónimos y valores de datos deben ser reemplazados por atributos definidos en una tabla de la base de datos. Esta tabla es determinante en el desplegado del color de un punto. Otras tablas separadas son para la invalidación de datos de estado, valores de datos analógicos y valores de datos de los acumuladores. La invalidación del código de color ocurre para una o la combinación de las siguientes condiciones:



61 de 154

120713 Rev 160720 161021

- Error de Telemetría.

- Desactivación.

- Entrada manual.

- Alarma sin reconocer.

- Alarma.

- Alarma inhibida.

- Selección (El operador ha seleccionado el punto para iniciar algún proceso).

- Etiqueta 1 (prevención de abrir).

- Etiqueta 2 (prevención del cerrar).

- Etiqueta 3 (solo información).

- Etiqueta 4 (prevención de control).

- Control en progreso.

- Punto controlable.

- Cambio autorizado.

- Violación de límites.

- Punto seleccionado. Para cada conjunto de condiciones el color que se despliegue en un punto es configurable, especificado por el usuario y modificable en línea. Las condiciones se deben mostrar en la tabla por prioridad o severidad para que la condición más importante se muestre todo el tiempo. Símbolos anexos se pueden utilizar para mostrar puntos con una o la combinación de condiciones que soporten código de color. Cuando el desplegado se construya, la cantidad y tipo de símbolos deben ser configurables por el usuario y pueden ser especificados para cada punto. Un símbolo anexo (etiqueta) debe ser un carácter que normalmente se agrega a la derecha de un punto dinámico en el desplegado y puede ser posicionado en cualquier lugar por el constructor de desplegados. El carácter, color y prioridad de un símbolo anexo y la condición que representa son especificadas en la base de datos. Cuando existen más condiciones del número de símbolos que pueden ser desplegados, las condiciones con más alta prioridad son las que se deben mostrar. 6.9.5 Formatos de datos en desplegados y estructura de mensajes Durante la creación de los desplegados, se deben asignar los formatos deseados para la presentación de los datos en pantalla. Dentro de estos formatos deben estar previstas entre otras características, las siguientes:

a) Analógicos, acumuladores y calculados. Seleccionar el ancho/tipo de campo. (Entero, punto flotante, hexadecimal).



62 de 154

120713 Rev 160720 161021

b) Binarios y calculados. Seleccionar la pareja de símbolos gráficos y parejas de leyendas (DESCRIPTORS), deben tener una correspondencia con cada estado y la base de datos en línea. Las leyendas se deben seleccionar directamente de la base de datos en línea.

Los mensajes, en general, que se presenten en pantalla y se direccionen a los impresores (alarmas, eventos) deben ser diseñados aplicando una normalización de estructura de mensajes, indicando entre otros: fecha, hora, descripción del punto, condición, valor y consola. 6.9.6 Selección de desplegados y funciones Los desplegados deben ser seleccionados por alguna de las siguientes opciones: a través de teclas de función dedicadas y configurables por el usuario, por enlace desde otro desplegado (menús, puntos sensibles, pestañas) o por entrada de clave alfanumérica en la línea de comandos de la pantalla. Los desplegados deben permitir incluir puntos de enlace para el control y ejecución de funciones. Por ejemplo:

a) Control de la configuración del sistema.

b) Arranque manual del sistema.

c) Control de las comunicaciones con UTR’s, nodos de adquisición de datos e interfaces de usuario.

d) Control de los enlaces entre maestras.

e) Asignación de áreas de responsabilidad de consolas/impresores. 6.9.6.1 Teclas de función Es necesario contar con un medio de acceder a la información y ejecutar algunas funciones de uso muy frecuente. El acceso o ejecución debe ser rápido y simple, sobre todo en condiciones de emergencia. Una forma de lograr lo anterior, es mediante el uso de teclas de función. A continuación se presenta una lista para las teclas de función con las cuales debe cumplir el sistema:

a) Alarmas: presentar el resumen de alarmas. (seleccionadas).

b) Silenciar audio: callar la señal audible de la consola.

c) Adelante/atrás: mover página adelante o atrás.

d) Estado previo: regresar la pantalla a las condiciones anteriores.

e) Índice general: presentar el menú maestro.

f) Imprimir página: enviar el desplegado a una impresora asignada.

g) Elegir la pantalla:(seleccionada).

h) Limpiar pantalla: cerrar ventanas de la pantalla actual.

i) Amplificación o reducción: permitir en desplegados la característica de variar la escala de presentación (zooming).

j) Selección de la característica de mover un desplegado de mayor tamaño a través de una ventana

menor (panning).



63 de 154

120713 Rev 160720 161021

k) Navegación: activar/desactivar la ventana de navegación. Las funciones que no se realicen a través de tecla de función, se deben efectuar siguiendo un proceso interactivo a través de menús, que deben aparecer en forma espontánea al seleccionar algún punto y guían al operador mostrándole sólo las opciones que son válidas para la operación que se esté realizando. La interacción con dichos menús puede realizarse usando el teclado y el apuntador del ratón (mouse) en forma indistinta. 6.9.6.2 Funciones de consola Para una consola con múltiples monitores, tanto el teclado alfanumérico, el ratón o dispositivo localizador están activos para todos los monitores de esa consola. Cualquier ventana de los monitores de la consola puede ser seleccionada como la activa moviendo el cursor hacia el monitor en donde se encuentra esa ventana. En consolas que tengan más de un monitor, el cursor debe avanzar de un monitor a otro en forma lineal. Los límites de movimiento del cursor deben ser:

a) El límite izquierdo del primer monitor.

b) El límite derecho del último monitor.

FIGURA 2 - Límites de movimiento del cursor Al arrancar el sistema, el primer monitor de cada consola debe ser el monitor activo. 6.9.7 Áreas de responsabilidad

Para el acceso a las funciones y capacidades del sistema, los usuarios deben registrarse y ser manejados por grupos de áreas de responsabilidad asignados en cada consola y a cada usuario. No deben existir restricciones en la asignación de múltiples áreas de responsabilidad a consolas y usuarios. Cada asignación de área de responsabilidad debe ser definida ya sea como de “solo lectura” o de “lectura y escritura”. Un acceso de “solo lectura” debe impedir la interacción del usuario con el sistema y solo debe permitir el llamado de desplegados. Por otro lado, el acceso de “lectura y escritura” debe permitir completa interacción del usuario con los desplegados, funciones, datos y dispositivos de la UCM. El número mínimo de áreas de responsabilidad se definen en Características Particulares. Cada área de responsabilidad debe ser definida por conjuntos de asignaciones de subsistemas. Un conjunto de asignaciones identifica subsistemas que deben ser incluidos en el área de responsabilidad para propósitos de intervención o presentación. Cada desplegado debe tener una vista asignada que permita clasificar a diferentes usuarios de la misma área de responsabilidad.



64 de 154

120713 Rev 160720 161021

6.9.8 Autoridad de consola La funcionalidad de una consola de operador será determinada por las áreas de responsabilidad que le sean asignadas, por ejemplo:

a) Control y entrada de datos de un objeto. b) Inicio de una función. c) Presentación y reconocimiento de alarmas. d) Selección de imágenes. e) Presentación de listas. f) Otras.

6.9.9 Validación del área de responsabilidad El procedimiento de validación para el acceso debe seguir una jerarquía de áreas de responsabilidad de la siguiente forma:

a) Desplegados: Cada desplegado debe ser asignado a una sola área de responsabilidad y a una vista correspondiente. La presentación de cada desplegado debe estar limitada a las consolas asignadas a esta área de responsabilidad.

b) Funciones: Cada función debe ser asignada a un área de responsabilidad. El acceso a las

facilidades de cualquier función está limitado para las consolas seleccionadas, aun cuando se puede permitir el acceso a los despliegues desde los cuales se pueden ejecutar tales facilidades. Los medios mediante los cuales los despliegues, reportes de bases de datos son definidos y modificados deben ser consideradas como funciones, así como las funciones que manejan la configuración del “software” del sistema. Estas funciones y acciones de las áreas de responsabilidad deben estar sujetas al mismo procedimiento de validación.

c) Elementos de base de datos: Cada elemento de la base de datos debe ser asignado a un área de

responsabilidad. Se debe denegar cualquier intento para manejar elementos de la base de datos, si estos no cumplen con las áreas de responsabilidad definidas para cada consola.

Los elementos de la base de datos regulados por el esquema operativo de las áreas de responsabilidad deben incluir:

- Habilitar y suspender la adquisición, cálculo y procesamiento.

- Inhibir y deshabilitar el procesamiento de alarmas.

- Sustitución manual de un valor.

- Omitir un límite.

- Manejo de alarmas, incluyendo reconocimiento y borrado de alarmas.

d) Control de Dispositivos: Cada elemento de base de datos para el cual el control ha sido definido debe ser asignado a un área de responsabilidad. En forma similar a los controles de acceso de los elementos de base de datos, los intentos de iniciar acciones de control deben ser denegadas si tales acciones no cumplen con las áreas de responsabilidad asignadas a la consola y al usuario. El



65 de 154

120713 Rev 160720 161021

acceso a las funciones de control deben incluir no solamente el control, sino también el acceso a funciones de etiquetas. El control de la configuración del “hardware” del sistema debe ser considerado como un procedimiento de control.

La función de validación de acceso debe asegurar que cada consola de operación que haya iniciado una sesión tenga asignada área de responsabilidad. 6.9.10 Consolas de operadores de respaldo Para cada consola de operador se debe definir una consola de respaldo. Cuando una consola de operador falla, las áreas de responsabilidad que tenía asignada esa consola deben ser transferidas automáticamente a una consola de respaldo previamente definida en la base de datos. A medida que la consola fallada vuelve a ser nuevamente operable debe tener su antigua asignación, pero cualquiera de las áreas añadidas (por la función “o” lógica) a la consola de respaldo no se pueden eliminar automáticamente, solo de manera manual. Las asignaciones de consola de respaldo deben ser definidas interactivamente a través del desplegado de control de asignación de responsabilidad. 6.9.11 Operación de registro del usuario Además de la limitación de responsabilidad asignada a cada consola, cada usuario registrado debe tener un área de responsabilidad asignada. Cuando un usuario empieza a trabajar en una consola, se debe identificar, tecleando su nombre de usuario y contraseña (password) y el sistema le debe dar acceso al área de responsabilidad que tiene asignada. La contraseña no debe ser visible en la pantalla. Las entradas y salidas del operador deben quedar registradas en la lista de eventos la consola y el operador. Una lista de todos los usuarios y las áreas de responsabilidad que se asignen a cada uno de ellos debe estar disponible en un desplegado. Un usuario puede tener autoridad para cambiar la responsabilidad de otro en línea desde el desplegado de control, mediante la entrada manual de datos. 6.9.12 Refresco de datos en desplegados

Los datos de los desplegados deben ser refrescados periódicamente. La función de refresco del subsistema, debe cumplir o mejorar lo siguiente:

a) Refrescar sólo los datos dinámicos.

b) Refrescar datos por petición repetida de presentación del mismo desplegado.

c) Refrescado de datos como consecuencia de una petición de actualización de los mismos en pantalla.

d) Refrescar datos en pantallas para evitar inconsistencias debidas a la entrada de datos o alteración

de atributos en otras.

e) Cuando en un monitor existan varias ventanas con diferentes desplegados, cada una de ellas se actualiza a la frecuencia establecida.

f) Debe actualizar el coloreo dinámico en desplegados de SCADA.

g) Debe actualizar los desplegados de contorno (situacionales).



66 de 154

120713 Rev 160720 161021

h) Actualización de desplegados, máximo cada 2 s. NOTA: Para aplicaciones con protocolo DNP3 esta periodicidad debe ser realizada de acuerdo con la funcionalidad y

características que proporciona el mismo protocolo.

6.9.13 Entrada de Datos

Deben proporcionar las facilidades que permitan la entrada de datos a través de los desplegados, cuidando los aspectos de seguridad, facilidad de interacción debe cumplir con lo siguiente:

a) Verificaciones

- Datos definidos en desplegado con opción a modificación.

- Razonabilidad. Límites especificados durante la creación de los desplegados o dependientes de la base de datos.

- Autoridades. Relacionados con los vínculos responsabilidad-categoría.

b) Procedimientos de actualización

- Entrada de datos por página. Para modificar grupos de datos (por columna, parte de la página, página completa), ejemplo: vistas administrativas de la base de datos, vistas de captura de atributos de puntos.

- Entrada individual de dato. Para modificar los valores de los puntos dinámicos. Un dato bajo entrada manual ya no debe ser actualizado en su base de datos y se etiquetará para señalar su condición.

c) Facilidades interactivas.

Diversas facilidades de interacción, ejemplo:

- Ingresar el valor usando libremente todos los campos definidos para cada elemento.

- Aprovechar las capacidades de edición y selección, para la modificación de caracteres, como inserción, borrado y agregado.

- Emplear colores (configurables por el usuario) para distinguir campos seleccionados y valores introducidos.

d) Consistencia de información.

Cuando un punto se ponga bajo entrada manual o regrese a su condición normal, se deben procesar todas las implicaciones que aseguren consistencia en la información. Estos cambios se deben distribuir en forma inmediata a todos los lugares donde resida la base de datos y su refresco en los monitores correspondientes.



67 de 154

120713 Rev 160720 161021

6.9.14 Comentarios de usuarios 6.9.14.1 Comentarios sobre los desplegados En general el usuario puede teclear sus comentarios referentes a cualquier desplegado del sistema en un campo especial para tal efecto. Estos comentarios una vez entrados deben ser desplegados en todas las consolas que soliciten este desplegado. Los comentarios pueden ser borrados o modificados por cualquier usuario que tenga el área de responsabilidad con los permisos necesarios. La entrada de información debe ser libre en todo el campo, validando los nuevos mensajes mediante la tecla entrar (enter). Esta opción puede ser accedida mediante un botón programado para tal efecto. Se requieren 2 tipos de comentarios:

a) Texto del comentario visible, en el cual el tamaño y tipo de letra deben ser configurables para cada texto que sea declarado. Cada comentario debe aceptar como mínimo 256 caracteres. El texto debe ser visible y mostrar el conjunto de caracteres que se teclee siempre y cuando los ajustes de tamaño y amplificación lo permitan.

b) Comentario accesible mediante un acceso directo, útil en el caso en que se requiera hacer un

comentario largo en un espacio reducido. El sistema debe contar con un mínimo de 16 símbolos. Cuando el cursor sea posicionado encima del símbolo, debe ser visible la información del comentario y mediante otra operación, ya sea doble click o mediante un menú debe ser visible el contenido completo del comentario. Estos símbolos deben ser editables por el usuario.

6.9.14.2 Comentarios de operador en el relatorio (opcional) El operador puede insertar un comentario en el relatorio (método desarrollado por la CFE) que en caso de requerirse se debe indicar en Características Particulares, incluyendo una línea de texto, el tiempo y la fecha de creación del comentario usando la funcionalidad copiar o pegar. 6.9.15 Seguimiento de variables (trending)

Se puede desplegar en las pantallas de vídeo, cualquier variable de la base de datos, permitiendo una visión similar a la producida por un registrador gráfico. Debe tener la opción de presentar las variables en pantalla mediante diagramas de barras, pasteles, gráficas de radar, gráficas de 2 y 3 dimensiones con orientación programable y definición dinámica de variables por pantalla , incluyendo su impresión. El operador debe ser capaz de poder escoger de un menú, un archivo que contenga información recabada por el programa de recolección de datos de disturbios, para su presentación gráfica. El operador puede seleccionar la información de un punto o un grupo de puntos analógicos, los cuales se grafican en un mismo cuadro de referencia, teniendo la facilidad de determinar sobre esa gráfica el momento en que exista un cambio de estado de un punto de interés del archivo del disturbio. Se pueden programar en línea:

a) Variables, períodos de muestreo, número de gráficas en pantalla, orientación y relleno. La variable con periodo más rápido de muestreo determina la frecuencia de refresco de información en pantalla.

b) Visualizar mediante la presentación de estos diagramas en cualquier tipo de desplegados y

modificar estas definiciones en línea.



68 de 154

120713 Rev 160720 161021

c) La definición de la escala para cada gráfica individualmente.

d) Las variables que el operador requiera desplegar (modo gráfico, o en diagramas de barras), seleccionar desde los diagramas unifilares o tabulares.

6.9.16 Control de alarmas

Las alarmas deben manejarse de acuerdo a su severidad, tratando de brindarle al operador un mejor control y claridad de interpretación de las situaciones anormales que se presenten. Los niveles de severidad deben ser al menos de 8 y el usuario debe definir en Características Particulares si requiere más. 6.9.16.1 Sumarios de alarmas

Clasificados por categoría y por severidad:

a) Presentación de sumarios de alarmas.

Presentación de los sumarios de alarmas con la misma tecla de función, según las prioridades y consideraciones siguientes:

- Alarmas no reconocidas. Todas las alarmas deben permanecer en este sumario, hasta que sean reconocidas por el operador, a menos que cambien las condiciones al suscitarse algún evento prioritario,

- Categoría.

Considerar el vínculo responsabilidad-categoría, cuando la consola tenga vínculos múltiples se debe recurrir a su orden de presentación que tenga establecido, determinando cuál es el sumario que se debe presentar.

- Severidad. Después de los criterios anteriores, el siguiente nivel de decisión es la severidad.

- Alarmas reconocidas. Si sólo existen alarmas reconocidas la visualización de los sumarios de todas las categorías, vinculadas con una consola, se debe llevar a cabo ejercitando repetidamente la tecla de alarmas, de acuerdo a las mismas reglas de prioridades anteriores.

- Las alarmas misceláneas no se deben presentar mediante la tecla de resumen de alarmas. Estas, al igual que los otros sumarios, se pueden demandar a través de menú.

b) Notificación de nuevas alarmas

La notificación de la ocurrencia de nuevas alarmas debe ser de la siguiente manera:

- Cuando ocurra una nueva alarma se debe notificar ésta a la(s) consola(s) correspondiente (s), cuidando los vínculos responsabilidad-categoría. Además de registrar las alarmas en los archivos y de enrutar esos mensajes al logger o bitácoras y se debe activar en cada consola que tenga relación con las mismas, una señal acústica y se debe iluminar la tecla de presentación de alarmas.



69 de 154

120713 Rev 160720 161021

- Con la señal sonora se pueden distinguir los niveles de severidad, cuidando que las alarmas misceláneas no causen sonido. Es necesario usar tonos diferentes , y que sólo las alarmas de extrema emergencia mantengan el sonido hasta que sea inhibido por el operador. Deben ser aceptable la activación repetida de la señal acústica, en lugar de usar tonos diferentes.

- Deben estar implementados filtros para el manejo de las señales audibles, por ejemplo:

No activar la señal audible cuando se tenga en pantalla la página de alarmas correspondiente y haya eventos de alarmas no reconocidas que están llegando de campo.

. No activar la señal audible relacionada con la responsabilidad-categoría cuando un

evento ya fue reconocido sobre un desplegado. La señal audible se debe volver a generar, si transcurrido un tiempo determinado (configurable por el usuario) nuevamente se genera un cambio que active la señal audible.

. Cuando se tenga en pantalla una página de alarmas y se genere un nuevo evento de

alarma, se debe refrescar el sumario con las alarmas más recientes en la parte superior o inferior, de acuerdo a como lo configure el usuario.

. Cuando ya no haya alarmas sin reconocer, se debe apagar la señal luminosa de la

tecla, si es que el teclado cuenta con esta funcionalidad. De nuevo las alarmas misceláneas no deben ser causantes del encendido o apagado de la luz.

. Cuando se desactive la alarma de un punto y esté en un sumario de alarmas, se debe

eliminar del mismo , en cambio, si se activa y su situación es anormal, debe implicar el procesamiento de la alarma.

6.9.17 Funciones de bitácora Las bitácoras son archivos de tipo texto y se debe contar con un mínimo de cuatro bitácoras. Cada área de responsabilidad operativa debe contar con uno o más bitácoras designadas, la asignación de bitácoras se debe realizar a través de un menú, en el cual se define la bitácora por omisión y bitácoras alternas, hacia donde se enrutan todos los mensajes del sistema correspondientes a las categorías vinculadas con las consolas de cada área. El sistema debe soportar situaciones degradadas, que impliquen incluso la pérdida de todos los dispositivos de salida, sin que se impacten los tiempos de respuesta del resto del sistema. El sistema debe soportar dos formas de manejo de bitácora: de línea sencilla o de página de reporte. Las bitácoras de línea sencilla son generadas por eventos de operador y mensajes de alarma. Cada línea debe contener el mismo formato e información de un evento. Cada evento de alarma debe ser almacenada separadamente y enviada en una o varias colas (spool) donde su tamaño debe ser configurable. Estas colas deben ser enviadas a las bitácoras. Todos los mensajes de línea sencilla y los reportes deben ser asignados a colas. Una cola puede ser configurada para recibir mensajes de ciertas funciones, modos y áreas de responsabilidad. Cada cola debe tener una bitácora primaria y hasta dos alternas. El número máximo de mensajes de línea sencilla que pueden ser enviados al buffer para cada cola de bitácora debe ser seleccionable independientemente. La cola es almacenada bajo una o más de las siguientes circunstancias:

a) Automáticamente cuando el número mínimo de mensajes de línea sencilla hayan sido encolados. b) Automáticamente al final de la hora. c) Automáticamente a media noche.



70 de 154

120713 Rev 160720 161021

Los mensajes de línea sencilla y los reportes pueden ser enviados a la misma bitácora. Las colas de línea sencilla pueden ser configuradas para almacenar o retener mensajes en una cola circular donde los mensajes más antiguos son remplazados por los más recientes. Una vez almacenados, los mensajes son borrados automáticamente de las colas. El contenido actual de la cola de mensajes de línea sencilla debe ser desplegable en el monitor. El mensaje debe ser desplegado en una lista donde los mensajes más nuevos aparezcan en la parte superior del desplegado. Se debe soportar la funcionalidad de desplazamiento (scroll) a través de los mensajes en ambas direcciones. Al agregar los nuevos mensajes a la cola, los mensajes más antiguos deben ser empujados hacia abajo para hacer espacio al inicio. Si la cola está llena, los mensajes más antiguos, deben desaparecer. Los mensajes de la cola de almacenamiento deben ser borrados de la lista a medida que se guardan. Una falla de una bitácora durante el almacenamiento va a ocasionar que se almacene el mensaje en la bitácora alterna. Una bitácora se debe considerar como fallada cuando cualquiera de los siguientes eventos ocurre:

a) La bitácora no está lista después de almacenar.

b) La bitácora esta inhibida por el operador.

c) Se detecta alguna falla en el archivo.

d) Se apaga el almacenamiento de la bitácora.

Todas las condiciones antes mencionadas deben ser monitoreadas por el software y alarmar apropiadamente. Si todas las bitácoras alternas fallan, los mensajes de línea sencilla deben ser enviados al buffer hasta que estos se llenen. Se generan alarmas cuando de las bitácoras fallen, con el fin de notificar al operador de esta condición anormal. El formato de las alarmas deben ser configurables por el usuario e independiente de la configuración del procesador en que sea instalada la aplicación. 6.9.18 Administración de puntos etiquetados en la base de datos Debe proveer un resumen de puntos con etiqueta para todo el sistema conteniendo todas las etiquetas activas y un resumen de puntos con etiqueta removida. Ninguno de estos desplegados debe permitir la acción del operador. Estos desplegados son solo de consulta. Debe haber un resumen para cada tipo de etiqueta para los puntos con etiqueta y con etiqueta removida. En cada uno de estos resúmenes, solamente deben aparecer los puntos con etiquetas asociadas a la asignación del modo de la consola. En los resúmenes de consola de puntos con etiqueta y del tipo de etiqueta, el operador puede editar o copiar mensajes de texto a las etiquetas o eliminar etiquetas. Se deben proveer al menos los siguientes resúmenes de puntos etiquetados:

a) Resumen de puntos etiquetados a través del sistema (todas las etiquetas). b) Resumen de puntos etiquetados por consola (puntos con etiquetas activas para el AOR de la

consola).

c) Resumen de puntos con etiqueta de prevención de control (puntos con etiqueta tipo 1 para el AOR de la consola, pasada a través de TASE.2).

d) Resumen de puntos con etiqueta de prevención de cerrado (puntos con etiqueta tipo 2 para el AOR

de la consola). e) Resumen de puntos con etiqueta de información (puntos con etiqueta tipo 3 para el AOR de la

consola).



71 de 154

120713 Rev 160720 161021

f) Resumen de puntos con etiqueta de licencia (puntos con etiqueta tipo 4 para el AOR de la consola).

g) Resumen de puntos con etiqueta removida por consola (puntos con etiquetas inactivas para el

AOR de la consola). h) Resumen de puntos con etiqueta de prevención de control eliminada (puntos con etiqueta tipo 1

inactiva para el AOR de la consola, pasada a través de TASE.2). i) Resumen de puntos con etiqueta de prevención de cerrado eliminada (puntos con etiqueta tipo 2

inactiva para el AOR de la consola). j) Resumen de puntos con etiqueta de información eliminada (puntos con etiqueta tipo 3 inactiva para

el AOR de la consola). k) Resumen de puntos con etiqueta de licencia eliminada (puntos con etiqueta tipo 4 inactiva para el

AOR de la consola). La funcionalidad de etiquetado por grupo de puntos debe ser soportada. Esta función debe permitir al operador seleccionar el tipo de etiqueta y posteriormente seleccionar uno o más puntos que tendrán esta etiqueta agregada a ellos. Esta función debe ser realizada desde un unifilar de una subestación y cada punto debe cambiar de color de acuerdo al código para estado seleccionado a medida que se van seleccionando. Únicamente se le solicita al operador que proporcione el tipo de etiqueta y el texto asociado. Cada punto etiquetado debe aparecer en el resumen de puntos etiquetados con el mismo mensaje, el cual se debe editar por el usuario que debe hacer el mensaje único para cada punto. Una vez que el operador haya iniciado con la selección de los puntos para ser etiquetados, puede cancelar la secuencia en cualquier momento hasta que la acción de etiquetado sea confirmada. 6.9.19 Funciones relacionadas con el control de la UCM (opcional) A continuación se describen algunos procedimientos operativos que en caso de requerirse se debe indicar en Características Particulares. 6.9.19.1 Control de libranzas y licencias El control y manejo de licencias implica:

a) La posibilidad de manejar diez licencias por punto del sistema eléctrico, como valor típico. b) Al solicitar poner en licencia un dispositivo, permitir la entrada de un comentario y de una clave

alfanumérica para su control. c) Se debe crear un resumen de licencias controlado por categoría para registrar la información sobre

cada licencia, incluyendo la identificación completa del punto, la fecha, la hora y la clave de control. Estos resúmenes son cronológicos con las últimas licencias en el tope. Se utiliza un solo registro para contener la información de ambas licencias, incluyendo la fecha y la hora en que se registró.

d) El retiro de licencias por parte del operador requiere introducir la clave alfanumérica de la licencia

en cuestión. Usando una clave maestra, se evita la entrada de la clave de la licencia, pero debe retirarse cada licencia individualmente.

e) Existe la opción de eliminar del proceso de alarma los puntos que se encuentren en licencia, con el

fin de no incluir en alarmas las maniobras de prueba del equipo.



72 de 154

120713 Rev 160720 161021

6.9.19.2 Bloqueos de comando de cierre Esta función es utilizada para verificar que previo a la demanda del cierre de un interruptor, no ocurrió una alarma (operación de una protección) de alguno de los puntos vinculados con éste. Se debe satisfacer con esta función:

a) El bloqueo no debe inhibir totalmente la función de control y sólo tiene que ver con el cierre. Es necesario, señalar al operador, durante la confirmación de la selección del comando cerrar que el interruptor está relacionado con una anormalidad, identificando al punto bloqueador. Sin embargo, se puede evitar la restricción a través de la función ejecutar con bloqueo.

b) Los interruptores pueden vincularse hasta con tres puntos digitales (protecciones). Por ejemplo, los

interruptores de un banco de transformadores se deben bloquear cuando se libre por protección primaria, protección de respaldo o protección diferencial de barras.

c) Los bloqueos automáticos se deben registrar en archivos cronológicos. Cuando el punto digital que

ocasionó uno o varios bloqueos regrese a su condición normal, se deben eliminar los bloqueos que éste haya ocasionado.

Se requiere que se pueda presentar, a petición del operador, mediante la selección de un botón, una ventana que muestre todos los bloqueos existentes para el punto seleccionado.

6.9.19.3 Desplegados en “web” Los desplegados que se muestran en los navegadores “internet”, deben tener los menús configurables y el desplegado mantener la misma presentación que en las consolas con todas sus funcionalidades de botones como alejamiento o acercamiento y malla de referencia (zoom, grid). Debe tener un ajuste automático del tamaño del desplegado en el navegador de “internet” utilizado, los puntos dinámicos se deben mostrar con el mismo formato y color asociados a las banderas de calidad. Pueden obtener su información del Histórico, por lo que debe contener los elementos necesarios para que el usuario solicite una fecha o período específico con el fin de realizar una reproducción (play back) en dicho periodo. Debe contar con la funcionalidad de desplazamiento y acercamiento continuo (panning y zooming). El uso de múltiples ventanas y el deslizamiento de ventanas (scroll). Debe manejar un acceso restringido por medio de claves de acceso y respetar las áreas de responsabilidad asignadas. Estos desplegados se deben generar al momento de construir la base de datos de la UCM. 6.10 Funcionalidad del sistema de Información Histórica 6.10.1 Funcionalidad general

La función del Histórico debe ser almacenar la información de tiempo real en una base de datos separada, destinada al almacenamiento Histórico, que permita el acceso restringido a los programas de aplicación de tiempo real y operar también como servidor de la base de datos histórica. El Histórico debe incorporar los medios de seguridad adecuados, para que el sistema restrinja el acceso únicamente a grupos de personal autorizado a través de ID de usuario y contraseña, así como la utilización de “firewalls”. El Histórico debe estar soportado en una base de datos capaz de manejar estructuras cliente-servidor y cliente-aplicación-servidor. Debe poder capturar valores de la base de datos de tiempo real, realizar cálculos sobre ellos y almacenar los valores resultantes , así como también mostrar la información en desplegados y generar un archivo con los reportes y datos correspondientes.



73 de 154

120713 Rev 160720 161021

EL Histórico debe de soportar conectarse a la base de datos en tiempo real. La consulta de datos puede seguir el último estándar SQL y contar con un cliente ODBC compatible con las herramientas comerciales. El proveedor debe proporcionar el conjunto de “software” necesario para el acceso a los datos históricos desde el ambiente corporativo de la CFE. En el sistema Histórico, el término datos “en línea” se refiere a la información de datos históricos que deben ser accedidos directamente de los servidores históricos sin requerir montar información almacenada en otro tipo de dispositivo. Los datos archivados en otros dispositivos son considerados datos “fuera de línea”. Histórico arreglo de discos duros accesibles vía red (SAN) y DVD. 6.10.1.1 Recolección de datos Histórico El Histórico debe almacenar al menos los siguientes tipos de datos:

a) Eventos con sus banderas de calidad para cada punto binario y analógico. b) Eventos binarios y analógicos tipo SOE con sus estampados de tiempo (el de campo y el recibido

por la maestra). c) Valor en unidades de ingeniería y su bandera de calidad correspondiente para cada punto

analógico. d) Valor del punto de acumulador y bandera de calidad correspondiente para cada acumulador. e) Los cambios de valores en unidades de ingeniería para puntos calculados deben ser identificados

para ser mantenidos por programas de aplicación. f) Variables de desempeño de la UCM los CPU´s, uso de disco, uso de memoria y red. g) La estampa de tiempo del SOE recibida de campo en ms debe ser registrada idénticamente en la

base de datos del Histórico. En casos de variaciones de intervalos de tiempo en los que el acceso a la información se vea comprometido debido a las fallas del sistema o a errores humanos, el sistema debe etiquetar la información para reflejar esta condición, almacenar la información en archivos temporales y cuando la falla desaparezca, actualizar la información del servidor Histórico conservando de esta manera su integridad. 6.10.1.2 Cálculos realizados por el sistema Histórico El sistema Histórico debe permitir realizar operaciones de cálculos sobre cualquier valor adquirido en la periodicidad especificada, cuando sea requerido, ya sea por el usuario o bien por un programa de aplicación. También debe permitir tomar como variables de entrada valores previamente calculados y el uso de constantes. La definición de estos cálculos debe realizarse mediante un sistema de manejo de base de datos. Cuando los valores sean adquiridos periódicamente, debe ser posible realizar la ejecución del cálculo al final del periodo de adquisición. El sistema debe soportar al menos las siguientes operaciones:

a) Suma y resta. b) Multiplicación, tanto de valores positivos como negativos. c) División, tanto de valores positivos como negativos.



74 de 154

120713 Rev 160720 161021

d) Raíz cuadrada. e) Exponencial.

f) Operadores relacionales (, ≥, =, ≠, ±, ≤, ˂). g) Operaciones Booleanas. h) Operaciones condicionales y de control de flujo. i) Funciones trigonométricas y matemáticas. j) Redondeo (con y sin truncado de enteros).

El sistema debe permitir el cálculo de funciones estadísticas sobre un conjunto de muestras tomadas en al menos los siguientes intervalos de tiempo:

- 5 min usando valores de tiempo real.

- 15 min usando valores de tiempo real.

- Media hora usando valores de tiempo real.

- 1 h, usando valores de tiempo real.

- Periodos am y pm, donde la CFE define las horas en cada periodo.

- Diariamente usando muestreos de 15 min.

- Semanalmente usando muestreos de 15 min.

- Mensualmente usando muestreos de 15 min y de 1 día.

- Anualmente usando muestreos de 1 mes. El software de explotación también debe mostrar la tendencia de una suma de variables. La tendencia presentada en una ventana debe modificar su tamaño si el usuario decide modificar el tamaño de la ventana. Todos los valores calculados deben incluir la bandera de calidad de los valores usados como datos de entrada. 6.10.1.3 Horario de verano

El sistema Histórico debe estar configurado para soportar el cambio de horario de verano, diferentes zonas horarias y año bisiesto. La fecha y hora debe ser ajustada automáticamente en los desplegados y reportes. En el día cuando entra en vigor el horario de verano, deben ser mostradas solo 23 h y cuando finaliza deben ser mostradas 25 h. El cálculo de totales y promedios no debe presentar pérdida de datos en estos días. 6.10.1.4 Archivado de datos Histórico El período de información en línea mínimo requerido es de 2 años. Los datos más antiguos deben ser transferidos automáticamente al sistema de archivado. También debe ser posible archivar la información manualmente. El sistema debe proporcionar un listado de la información que ha sido archivada. El sistema debe permitir cargar los datos archivados y accederlos sin afectar la recolección de la información, el almacenamiento y la recuperación de los datos que están en línea, todo ello sin que sea necesario remover la información que está en línea. Esto quiere decir que los datos archivados deben ser cargados en un área de trabajo.



75 de 154

120713 Rev 160720 161021

La capacidad mínima del área de trabajo debe ser de 5 años o lo indicado en Características Particulares.

6.10.2 Base de datos, desplegados y reportes históricos 6.10.2.1 Base de datos del Histórico Para la creación y mantenimiento de la base de datos histórica se debe utilizar el editor único de base de datos. La recolección de información de puntos de datos de estado o análogos se debe definir en la base de datos y no deben requerir una definición adicional para el Histórico. Debe ser posible especificar cualquier dato de la UCM y permitir configurar los tiempos de recolección. El proveedor debe suministrar una biblioteca de interfaces de programación que permitan a cualquier función del sistema adicionado por la CFE, el envío de información al Histórico para su almacenamiento. La información almacenada no debe ser afectada por cambios subsiguientes a la base de datos. Toda la información del Histórico debe permanecer recuperable, sin importar su contenido o cambios de estructura a las bases de datos del Histórico o de la UCM. 6.10.2.2 Desplegados del Histórico Los datos del Histórico deben ser accedidos de manera tabular y gráfica, haciendo uso de las capacidades del sistema para la gestión de la base de datos, incluyendo consultas personalizadas. El proveedor debe proporcionar las herramientas para construir estas consultas, gráficas y desplegados, las cuales deben ser del tipo GUI y basadas en “web”, de tal forma que permitan al usuario observar el reporte durante su generación. Cualquier valor, etiqueta, o bandera almacenados deben ser desplegables en las herramientas proporcionadas. La herramienta para desplegar la información debe incluir como mínimo:

a) Selección de datos a través del menú.

b) Conjuntos pre-formateados de desplegados para diferentes tipos de datos.

c) Selección de datos basados en:

- Fecha y hora de adquisición, ya sea absoluta o relativa (por ejemplo +1 h).

- Operaciones comparativas (por ejemplo: igual a, mayor que, menor que, mayor o igual a) sobre los valores almacenados en variables como:

∙ Subestación.

∙ Nivel de voltaje.

∙ Valor mayor a un límite.

∙ Tipo de punto (analógico, estado, acumulador).

d) Conjuntos de rutinas de acceder genérico, predefinido para consultas típicas de valores, tales

como puntos analógicos en un tiempo específico, valor máximo, mínimo y promedio de un punto en un periodo, todos los puntos en un intervalo de tiempo.

e) Consultas personalizadas sobre cualquier valor que presente características similares sobre determinado tiempo.



76 de 154

120713 Rev 160720 161021

f) Control de acceder a información confidencial mediante permisos de usuario.

La información del Histórico debe poder ser presentada en gráficas de tendencias utilizando la funcionalidad de hoja de cálculo y el software de explotación del Histórico. La funcionalidad estándar de hoja de cálculo debe proveer una cantidad de formatos gráficos para su presentación, incluyendo: gráficos de área, barras, columnas, lineales y de pastel en dos y tres dimensiones, así como de donas, radar y XY (scatter). El “software” de explotación del Histórico debe proveer numerosos formatos, flexibilidad para manejar hasta ocho tendencias sobre un mismo desplegado, tendencias de tiempo real y tendencias históricas. Algunas de estas funciones de tendencias fundamentales deben ser:

- Pan y zoom.

- Rango re-escalable.

- Tendencia de tiempo absoluto.

- Tendencia de tiempo delta.

- Tendencia de tiempo relativo.

- Tendencias compuestas.

- Orientación de tendencia (vertical u horizontal) definible por el usuario. Debe existir correspondencia entre los datos del Histórico y el de tiempo real que maneja el sistema para asegurar que se pueda hacer una comparación entre la información que guarda y procesa cada uno. Al llamar un desplegado, deben ejecutarse los cálculos adicionales en caso de que sean requeridos. Estos últimos deben ser valores permanentes (almacenados en el Histórico) o valores temporales (solo existen durante el tiempo que se consulta el desplegado). Una vez desplegada la información, el usuario debe editar datos en el desplegado y guardar los cambios. Si el usuario intenta salir sin antes salvar los cambios, debe ser generado un mensaje de alarma informando que los cambios no han sido guardados. 6.10.2.3 Reportes del Histórico El proveedor debe proporcionar herramientas para la generación de reportes personalizados, así como reportes periódicos y sobre demanda. Estas herramientas deben ser GUI y basadas en “web”. El acceder a la base de datos del Histórico para reportes solo debe ser de lectura y debe permitir agrupamientos, funciones algebraicas, lógicas y aritméticas como las usadas en hojas de cálculo para permitir la creación de reportes. Debe ser un “software” comercial capaz de generar reportes complejos y permitir al usuario configurar los reportes. El usuario debe programar la impresión de reportes por fecha y hora o sobre demanda, además, de especificar la impresora sobre la que se van a generar los reportes. 6.10.3 Capacidades del usuario del Histórico El Histórico debe acceder a la información de la base de datos histórica a los usuarios de la UCM y a los usuarios de ambientes externos.



77 de 154

120713 Rev 160720 161021

6.10.3.1 Productos de la base de datos y licencias Todas las licencias para el uso del “software” del sistema Histórico deben ser “uso completo”, es decir, el “software” no debe tener limitaciones y debe permitir el desarrollo de aplicaciones y base de datos por parte del usuario, así como el uso de herramientas de administración por parte del Histórico. El número de usuarios concurrentes del sistema Histórico se define en Características Particulares:

a) El número de usuarios concurrentes se refiere a los usuarios que pueden estar usando recursos del Histórico (incluyendo base de datos y funcionalidades no incluidas en esta especificación) a un mismo tiempo.

b) El número de cuentas se refiere a la cantidad de usuarios que deben usar recursos del Histórico en

cualquier periodo.

c) El número de usuarios de desarrollo, se refiere a los usuarios que desarrollan o mantienen la funcionalidad del Histórico y su base de datos.

6.10.4 Recursos de integración del Histórico con otras aplicaciones de la CFE 6.10.4.1 Ambiente de desarrollo e integración del Histórico Tomando en cuenta los criterios de los sistemas abiertos, el proveedor debe proporcionar una biblioteca de APIs específicas que permitan que el hardware de múltiples fabricantes pueda conectarse sin afectar la continuidad con el servidor y los clientes del Histórico. El Histórico debe ser entregado con herramientas de integración. Las herramientas de integración deben soportar tecnología ActiveX, COM, DCOM, ODBC. La automatización y control ActiveX debe habilitar la integración de objetos externos a los desplegados generados por la interfaz de usuario del cliente. Además, debe incluir una interfaz de programas de aplicación (API) para algunos de los lenguajes más populares (C, C++ y Java), que permita el intercambio de información entre el Histórico y aplicaciones corriendo en otras plataformas. 6.10.5 Aplicaciones específicas 6.10.5.1 Colección y presentación de datos de disturbio para la UCM El objetivo de este subsistema es recrear en las consolas de la UCM y desde la base de datos histórica, datos predefinidos, antes y durante la ocurrencia de un disturbio. Estos datos deben ser salvados para poder observarlos mediante un reporte impreso, a través de desplegados y por tendencias gráficas (Trending). Las herramientas de programación necesarias para lograr estas funciones, deben estar incluidas en este suministro. Las características mínimas de esta función son:

a) Soportar grupos de colección de datos.

b) Recolectar y salvar datos antes y durante del disturbio.

c) Reportes impresos de tendencias gráficas (trending) y de unifilares.

d) Respaldo y recuperación de la información de los diferentes casos de disturbio para su revisión y análisis.

e) Las alarmas y eventos deben ser capturados como parte del caso guardado.



78 de 154

120713 Rev 160720 161021

Este sistema debe permitir obtener información de los valores máximo y mínimo, de las variables colectadas durante el período, así como del cálculo de las mismas. El sistema debe contar con la posibilidad de obtener los datos relativos a los diferentes casos de disturbio en forma impresa y a través de desplegados. Cada reporte de un caso de disturbio, se debe separar en una sección de datos analógicos y una sección de información digital. Los datos analógicos se deben agrupar en dos secciones:

a) Datos pre-disturbio.

b) Datos post-disturbio. Los datos se deben presentar en forma cronológica por subestación e incluir la hora, fecha y estado o valor, así como las indicaciones de reemplazo manual y punto fuera. Se debe incluir la información referente al disparador del disturbio. 6.10.5.2 Almacenamiento de alarmas y eventos (logger) en minuta Con el fin de eliminar la impresión de las alarmas y eventos del sistema, se requiere que estas sean almacenadas en disco, en un esquema redundante, con una confiabilidad de almacenamiento del 99.95 % y con capacidad de almacenar hasta 2 años de información en línea. Se requiere tener una herramienta, que escriba a un disco duro de manera alterna al del sistema (fuera del baseline) en formato texto, con la finalidad de que se puedan hacer consultas SQL, en un manejador de base de datos comercial facilitando estas consultas y mantener la información de manera confiable en el disco del sistema. Este módulo debe estar disponible para todas las consolas del sistema, de tal manera que cualquier usuario autorizado pueda ver, manipular e imprimir la información almacenada. El almacenamiento de las alarmas y eventos debe ser en forma secuencial, sin posibilidad de alteración, con el fin de contar con una secuencia fiel de lo ocurrido en tiempo real. Debe contar con una herramienta de consulta en línea, así como mecanismos de respaldo y restauración de información. 6.10.5.2.1 Filtrado de alarmas y eventos Para el filtrado de alarmas, se requiere una herramienta de consulta en línea, en un ambiente amigable, con interfaz gráfica, para búsqueda tipo SQL, que permita la combinación de uno o varios parámetros de filtrado cuyo resultado pueda a su vez ser filtrado de nuevo o simplemente ser presentado en pantalla, enviado a impresión o a una herramienta auxiliar tipo procesador de palabras u hoja de electrónica. Entre los parámetros de filtrado están:

a) Por fecha.

b) Por período de fecha/hora a fecha/hora.

c) Por tipo de alarma.

d) Por entidad o dispositivo.

e) Por área de responsabilidad.



79 de 154

120713 Rev 160720 161021

f) Por centro de control.

g) Por subestación (seleccionar un conjunto de alarmas o eventos de una, varias o todas las subestaciones).

h) Por severidad.

i) Por evento.

j) Por usuario que reconoce o emite el comando.

k) Por descripción (seleccionar un conjunto de alarmas o eventos basados en pedazos de textos

dentro del mensaje). 6.10.6 Almacenamiento de secuencia de eventos – SOE

Los datos SOE obtenidos por interrogación deben almacenarse en orden cronológico en la base de datos histórica para el despliegue, implantación de datos, generación de reportes y archivo. El sistema Histórico debe ofrecer facilidades para el ordenamiento, búsqueda, desplegado e impresión de los datos SOE almacenados. El usuario debe poder consultar los datos SOE mediante el ordenamiento o la búsqueda de los siguientes parámetros:

a) Subestación: Realizar la búsqueda de datos SOE para una, varias o todas las subestaciones.

b) Tipo de equipo: Realizar la consulta de datos SOE para uno varios o todos los tipos de equipos.

c) Equipo: Realizar la consulta de datos SOE para uno, varios o todos los equipos.

d) Periodo: Deben ser soportados los períodos y relativos (por ejemplo, 12 h antes de la Hora actual). El proveedor debe suministrar un reporte en hoja de cálculo para la secuencia de eventos la cual debe ser accesible desde el menú de reportes del Histórico. El reporte SOE debe proporcionar al usuario la capacidad de extraer información de SOE de la base de datos histórica, de fecha y duración específica. Así mismo, el usuario debe poder extraer datos analógicos de un período determinado con etiqueta de tiempo a la que los datos del SOE fueron registrados. Los datos analógicos y del SOE se presentan en orden cronológico, por tiempo creciente ordenado en formato tabular con una columna adicional indicando la diferencia entre eventos de tiempo consecutivos. La información del SOE debe poder ser representada en formato gráfico e incluye la habilidad de incrementar o disminuir el tiempo representado. 6.10.7 Estadística de equipos del sistema eléctrico Tres tipos de estadísticas de equipo se manejan para minimizar los gastos de mantenimiento de los interruptores y otros equipos eléctricos. Se deben proveer estadísticas del funcionamiento individual de los interruptores y de las horas de operación, por ejemplo, de transformadores y generadores. Por lo tanto, el mantenimiento debe poder realizarse de acuerdo al desgaste del equipo. Las mediciones de los puntos de estado y analógicos requeridos para la elaboración de los siguientes reportes deben ser almacenados en el Histórico. Los reportes deben ser emitidos bajo demanda, periódicamente o ambos. 6.10.7.1 Tipos de estadística El sistema debe proporcionar dos tipos de sistemas de estadísticas:



80 de 154

120713 Rev 160720 161021

a) La evaluación de horas es una función cíclica especialmente diseñada para equipos con carga, tales como transformadores.

b) Una contabilización del tiempo que una medición sale de sus límites de operación.

Estos dos reportes deben ser generados diariamente, mensualmente y anualmente. 6.10.7.2 Evaluación de cambios de estado Este reporte debe ser requerido bajo demanda por el usuario, especificando la fecha de inicio y la duración de la evaluación. El usuario debe seleccionar vía una ventana de dialogo, el interruptor para el cual debe realizar la evaluación de cambios de estado. La utilización principal de este reporte es determinar el número de cambios de estado que ocurrieron en un interruptor específico en el período especificado. La función debe distinguir entre dispositivos controlables y no controlables, donde el primero se controla desde la UCM. Para cada interruptor seleccionado, se debe calcular el número de operaciones que cambiaron del estado abierto a cerrado (on a off). En los dispositivos controlables se mantienen dos contadores, uno para la pérdida de carga (PDC) y otro para el cortocircuito (CC). El cambio de posición por procedimiento manual incrementa el contador de pérdida de carga (PDC). El sistema debe distinguir entre PDC y CC de la siguiente manera:

a) El contador PDC debe ser incrementado si el cambio de estado fue un requerimiento de control por el operador, o si ocurrió el cambio de estado cuando el interruptor tenía una etiqueta de licencia asociada. Se debe incrementar también si el estado del dispositivo fue cambiado manualmente por un operador (entrada manual).

b) El contador CC debe ser incrementado si hubo un cambio de estado sin intervención del operador

o si el dispositivo no tiene una etiqueta de licencia asociada.

c) El uso real (UR) es calculado:

- UR = PDC + n * CC

Donde:

n es un factor de peso y es único para cada punto. d) Dispositivos no controlables. Para los dispositivos sin control, todos los cambios de estado

incluyendo aquellos ingresados manualmente, se deben contabilizar en el contador de control de pérdida de carga (PDC). El uso efectivo (UR) es equivalente a la evaluación de pérdida de carga.

6.10.7.3 Contabilidad de horas de operación El sistema debe registrar la cantidad de tiempo que un dispositivo se encuentra en un estado definido. Este estado, “on”, “off” o alarma debe ser adquirido directamente desde el mismo dispositivo o medición respectivamente. Por ejemplo, un transformador es definido como “off” cuando el interruptor fue reconocido como “off”, o las mediciones asignadas están por debajo del 20 % del valor nominal. Este reporte debe ser requerido por el usuario especificando la fecha de inicio y la duración de la evaluación. El usuario debe seleccionar, vía una ventana de diálogo, los puntos de estado y analógicos que determinan las horas de operación de un dispositivo. Cuando el reporte sea requerido, el sistema debe determinar las horas en las que el dispositivo estuvo en “on” (con una resolución de 3 min) y las horas en las que estuvo en “off” durante el período



81 de 154

120713 Rev 160720 161021

específico de evaluación. Los cálculos se deben realizar mediante búsquedas en el Histórico de los puntos seleccionados durante el período especificado. 6.10.7.4 Contabilidad de tiempo de mediciones fuera de límites de operación El sistema debe permitir la selección de mediciones para agregar la funcionalidad estadística de contabilizar el tiempo que dura la medición fuera de sus límites alto y bajo operativos y los considerados de prevención o advertencia. El sistema debe proporcionar un reporte que especifique la cantidad de tiempo en la cual una medición estuvo fuera de rango con respecto a cada uno de los límites. Para cada tipo de violación de límite, debe calcular subtotales. El sistema debe contar con registros diarios para la emisión del reporte mensual. 6.10.7.5 Presentación de estadísticas de equipo Debe proporcionar tablas de inspección, tanto específicas para la subestación como generales para todos los dispositivos. Cada protocolo creado de esta manera debe contener la siguiente información:

a) Descripción del dispositivo (texto).

b) Evaluación actual.

c) Solicitud de libranza.

d) Fecha de finalización de la libranza.

e) Fecha de la última inspección.

La descripción del dispositivo debe señalar tanto al dispositivo remoto como al dispositivo relacionado. Todos aquellos dispositivos que han violado uno de los límites definidos deben estar aquí listados. Información adicional para los protocolos son: Para todas las formas de estadísticas se definen pautas de decisión

a) Solicitud de libranza: valor límite que anuncia la necesidad de la operación de mantenimiento preventivo en un plazo inmediato.

b) Día de vencimiento de la libranza: valor límite que indica la necesidad inmediata de mantenimiento.

c) La fecha de la última libranza del dispositivo.

Además de las estadísticas actualizadas existe una evaluación permanente que brinda información sobre todas las evaluaciones realizadas desde el comienzo de la grabación de ese objeto. No existe este caso límite para las evaluaciones. Después de la libranza o el mantenimiento de un dispositivo, el sistema debe permitir generar las evaluaciones correspondientes y deben ser extraídas por procedimiento manual por un operador. Después de reemplazar un dispositivo, la evaluación permanente debe ser extraída. La extracción de la evaluación permanente debe eliminar automáticamente los valores actuales.



82 de 154

120713 Rev 160720 161021

En caso de pérdida de la información, por ejemplo, falla de UTR, el sistema debe permitir al operador hacer correcciones en forma manual. Al modificar un valor manualmente debe ser actualizada automáticamente la “evaluación permanente”. 6.11 Programas de Aplicación 6.11.1 Introducción

En esta sección se describen los programas de aplicación requeridos para la UCM. Se incluye una descripción general de características requeridas en un sistema para un centro de control, esta descripción incluye:

a) Descripción general de los programas de aplicación. b) Características generales de los programas de aplicación. c) Requisitos de la interface del usuario. d) Requisitos de la base de datos. e) Requisitos generales.

f) Programa de cálculo.

g) Tendencias de datos.

h) Aplicación PLC.

i) Comunicaciones con otros sistemas API.

Estas descripciones son adicionales a las características básicas del SCADA. 6.11.2 Descripción general de los programas de aplicación Los programas de aplicación requeridos son base de datos, bases de datos históricos e interconexión con otros sistemas SCADA. La interface de usuario, para estas funciones, debe estar diseñada para el personal del despacho, con el fin de solucionar los problemas operacionales en una forma altamente interactiva. 6.11.3 Características generales de los programas de aplicación Todos los programas de aplicación que se suministren en el sistema y que sean parte de funciones SCADA y base de datos deben de cumplir con la redundancia de servidores (Hot-Standby) para en caso de falla del servidor principal, el redundante entre en operación continuando con la comunicación con los otros sistemas, debe realizar las funciones siguientes:

a) La verificación y validación de los datos se debe realizar en la interface de usuario o en el editor de base de datos.

b) Todas las funciones deben ser diseñadas e integradas para una ejecución rápida y confiable.

c) El sistema debe permitir agrupar por zonas (o áreas de responsabilidad) los elementos del sistema

eléctrico.



83 de 154

120713 Rev 160720 161021

6.11.3.1 Base de datos histórica (BDH) Para el servidor de históricos se permite el uso de un manejador de base de datos comerciales. Esta base de datos debe de compartir y proveer acceso a la colección de datos en tiempo real, así como sus datos históricos, para su uso en reportes, análisis o su posterior respaldo en medios externos de almacenamiento. 6.11.3.1.1 Archivado y grabado de datos Como funcionalidad básica de la base de datos históricos se contemplan las características de extraer y guardar los datos definidos por el usuario en un tiempo que se determina en minutos, horas, días, semanas o años. La base de datos históricos debe de soportar el almacenamiento de datos por un periodo mínimo de 2 años en línea. Un “hardware” del tipo (RAID) debe de ser usado para salvaguardar la integridad de los datos. En Características Particulares se indica el espacio requerido por el área usuaria para el almacenamiento de esta información en línea, la cual puede ser menor conforme al método de compresión utilizado y que debe ser comprobado por el usuario en las pruebas de fábrica. El hecho de que la información pudiera estar comprimida no debe dificultar ni retrasar el tiempo de manipulación de la información almacenada en disco. Los datos que son almacenados por la BDH pueden ser del tipo de telemetría, datos calculados, resultados de programas calculados, mensajes de operación. BDH tiene la funcionalidad de proveer al administrador del sistema el acceso a los datos, a la inserción de datos, así como su modificación. También debe de proveer al administrador la modificación de los códigos de acceso a los datos para la elaboración de reportes, esto se debe realizar con herramientas de conectividad estándar (ODBC) para acceso a la información de la base de datos. Se prefiere que el acceso a los datos se pueda realizar usando algunas de las herramientas, como manejador de base de datos u hoja de cálculo comercial, para la presentación de los datos así como su actualización. El proveedor debe suministrar la licencia de uso de dichos programas. 6.11.4 Intercomunicación con otros sistemas SCADA 6.11.4.1 Intercomunicación entre UCM´s Se debe proveer un sistema de comunicación que sea capaz de enviar y recibir información, debe funcionar como cliente o servidor con otras UCM´s independientemente del tipo, modelo del sistema o fabricante del mismo, mediante protocolo ICCP y el sistema debe estar preparado mediante “hardware” y “software” para cumplir con los requisitos mínimos y nivel de implementación especificados en Características Particulares donde el área usuaria debe indicar el alcance del suministro de enlaces y el número de puntos requeridos por cada enlace. El sistema debe permitir el crecimiento sin necesidad de pagar licencias adicionales, ni expansión de “hardware” o “software”. El protocolo ICCP debe estar residente en los servidores encargados de la comunicación con los sistemas remotos. El software de intercomunicación debe tomar de la base de datos la definición de los puntos a ser enviados o recibidos al sistema remoto, sin tener que configurar otros puntos para lograr esta comunicación. Es decir, no se debe redefinir o configurar adicionalmente estos puntos en otras bases de datos o servidores. Esta aplicación debe cumplir con la redundancia de servidores de respaldo en caliente (Hot-Standby) para que, en caso de falla del servidor principal, el servidor redundante entre en operación en forma automática restableciendo la comunicación con los otros sistemas. La red de intercomunicación debe cumplir con los estándares para redes “ethernet” sobre TCP/IP sin que existan restricciones particulares para el número de enlaces que se puedan conectar.



84 de 154

120713 Rev 160720 161021

6.11.4.2 Procesador de topología o conectividad (opcional) El sistema debe manejar un procesador de topología o conectividad para redes, el cual no se debe programar la lógica manualmente por el usuario, es decir, solo con la definición de tipo de equipo (por ejemplo: interruptor, cuchillas, transformador) y sus conexiones periféricas se debe reflejar la coloración y el estatus de los circuitos de la red, definiendo al menos los siguientes estados: energizado, desenergizado, parcialmente desenergizado, circuito en paralelo y en anillo o cualquier combinación de las mismas. El procesador de topología o conectividad debe realizar análisis de red por fase (flujos trifásicos) y de manera independiente, para poder identificar y representar el estado de la red cuando se utilicen dispositivos de operación o protección (tanto telecontrolados como manuales) y que puedan operar cada fase independientemente (por ejemplo, fusibles y seccionadores o restauradores monofásicos). El sistema debe manejar para la interfaz gráfica, al menos 200 capas (layers) que se deben activar o desactivar a solicitud del operador. Lo anterior para visualizar de manera independiente además de la base geográfica de las áreas urbanas, las características de cada circuito de la red. En Característica Particulares se indica si esta funcionalidad es requerida. 6.11.4.3 Analizador de protocolos El sistema debe de contar con el “software” para analizar las tramas enviadas y recibidas por los diferentes protocolos, esta utilería debe tener la habilidad de monitorear las comunicaciones en cada canal de comunicaciones (puertos) incluyendo transmisiones y respuestas. Se debe incluir una función configurable por el usuario de la UCM, para que las tramas por canal de comunicación, puedan ser enviadas a un archivo para su posterior análisis. El momento de inicio, duración del registro de monitoreo y el tiempo que debe durar el archivo guardado en la UCM, son parámetros de configuración por el usuario. El análisis se debe llevar a cabo en línea, sin tener que desconectar ninguna parte de las líneas de comunicación, ni detener las operación de envió o recepción de mensajes. 6.11.4.4 Requisitos de la base de datos Los programas de aplicación deben usar el sistema de mantenimiento y construcción de la base de datos del SCADA, empleando un método común para la estructura de datos, acceso a la base de datos, edición de datos, población del área de datos, mantenimiento de la base de datos, validación de datos y reportes de error. El método debe ser idéntico al usado para todas las otras funciones del SCADA. La información y datos que sean comunes entre las funciones de SCADA y programas de aplicación deben ser ingresados una sola vez. Se deben cumplir los siguientes requisitos para todas las aplicaciones:

a) Se deben generar archivos en formato común de la IEEE y CIM para el intercambio de soluciones.

b) Es mandatorio que el proveedor describa las potencialidades reales y los esquemas utilizados para permitir que las aplicaciones de tiempo real, (performance) en los accesos concurrentes a la base de datos, en adición a las facilidades de acceso lógico en SQL. (Ej.: API con utilización de acceso directo a datos, entre otros).

c) Las aplicaciones deben de cumplir con todos los requerimientos definidos en el capítulo interfaz de

usuario.

d) Se debe contar con una biblioteca de API's, normalizadas para el ambiente de aplicaciones de tiempo real, que permitan un acoplamiento simple dentro del código de los programas. Este soporte común de conexiones para todos los programas deber permitir una organización modular del “software” de aplicaciones.

e) Todos los elementos modelados deben ser cargados una sola vez en la base de datos, para que

puedan ser manejadas por los programas de aplicación.



85 de 154

120713 Rev 160720 161021

6.11.4.5 Puntos calculados Se debe proveer la capacidad para poder definir cálculos generalizados. Los cálculos pueden usar los valores de la base de datos de tiempo real como argumentos y funciones aritméticas simples para realizar las operaciones. Se debe de proveer cuando menos los siguientes grupos de funciones:

a) Operaciones algebraicas.

b) Operaciones aritméticas +, -, *, /.

c) Modulo.

d) Exponencial.

e) Sen, cos, tan, arc sen, arc cos, arc tan.

f) Raíz cuadrada.

g) Valor absoluto.

h) Exponenciales.

i) Redondeo.

j) Suma, promedios, máximos y mínimos.

k) Operaciones Booleanas.

l) Estructuras de control.

m) if, then, else.

n) Operadores lógicos (<, >, <=, >=, !=). Los nombres anteriores pueden diferir, pero la esencia del proceso que realiza debe ser la misma. 6.11.5 Tendencia de datos

El sistema debe de proveer la funcionalidad de graficar la tendencia de todos los datos que son capturados, guardados, estos deben ser visualizados en una gráfica de tendencia. Como mínimo, la funcionalidad de la tendencia de datos debe proveer al usuario con las siguientes características:

a) Captura continua de información de hasta 400 valores de datos seleccionados.

b) Soporte a gráficas verticales y horizontales.

c) Seleccionar cualquier valor del sistema de tiempo real o calculado.

d) Selección de tiempo de muestreo de datos con un mínimo de 2 s.

e) La gráfica de la tendencia se debe mantener hasta que el usuario la desactive.

f) Desplegado de variables simultaneas en la gráfica.

g) Tener un manejo de escalas automáticas dependiendo de los valores graficados, así como muestra de unidades.

h) Selección de colores para cada variable que es graficada.

i) Impresión de las gráficas.



86 de 154

120713 Rev 160720 161021

j) Exportar los datos a hojas de cálculo o archivos CVS.

k) Un mínimo de 3 gráficas por consola.

l) La actualización de la información debe de ser en tiempo real.

m) Retrocede y adelantar en la gráfica. 6.11.6 Impresión de reportes Con el fin de satisfacer las funcionalidades requeridas por la CFE, el sistema debe proveer una serie de reportes autogenerados en demanda o por un periodo del sistema de tiempo real o del sistema de históricos. Las herramientas que se deben utilizar para dichos reportes deben usar el estándar ODBC y SQL como acceso a los datos para ser usados en reportes y registro. Se prefiere el uso de hojas de cálculo o reporteadores comerciales para proporcionar esta herramienta. Los reportes personalizados deben ser diseñados y construidos en conjunto con la CFE, los cuales deben estar predefinidos. 6.11.7 Comunicaciones con otros sistemas El sistema debe de proveer una ambiente de desarrollo. Las herramientas provistas deben de incluir una herramienta para el control de versiones, un compilador de C, C++ o Java, así como su analizador de errores. Como mínimo la herramienta de desarrollo debe de ser provistas con el compilador, enlazadores, API, SQL, Java y XML, así como su soporte. Las siguientes características mínimas deben de ser proveídos con la API, mas no son limitativas.

a) Acceso a la base de datos, incluyendo todos los puntos, sus valores, descripción y parámetros.

b) Se debe de generar alarmas y eventos.

c) Se debe de enviar y recibir mensajes entre programas.

d) Poder realizar cálculos con los puntos.

e) Poder programar calendarizar los programas para su ejecución. El “software” del sistema debe de ser fácilmente actualizable, requiriendo poco o nulo soporte de parte del proveedor. La nueva versión del “software” debe de ser documentada, además debe indicar cual archivo o parte del programa ha sido cambiado desde la última liberación. 6.12 Requerimientos de Hardware En esta sección se realiza la descripción técnica de los equipos y dispositivos que forman parte del suministro. A continuación, se indican las características distintivas de diversos equipos, las que representan, capacidades o parámetros que se deben satisfacer. Todo el “hardware” debe ser fabricado, ensamblado, terminado y documentado con parámetros de calidad adecuados, debe cumplir con todos los estándares de control de calidad aplicables tanto del fabricante original de los equipos como del suministrador del sistema. Todos los componentes de “hardware” deben ser nuevos, de la tecnología más moderna y reciente, apropiados para los propósitos especificados.



87 de 154

120713 Rev 160720 161021

En la sección siguiente de este apartado, se muestra la tabla 6 que corresponde al ofrecimiento de equipamiento en los servidores para la UCM, sin embargo, en Características Particulares el área licitante puede incluir la misma tabla, indicando los requerimientos necesarios esperados. 6.12.1 Servidores en general Los servidores deben ser de los modelos más recientes para lograr una operación eficiente y deben estar diseñados para soportar un sistema en tiempo real de alto rendimiento. Los procesadores deben incluir capacidades para parar y reiniciar ordenadamente su operación en caso de pérdida y subsiguiente retorno de la alimentación. No deben existir restricciones en cuanto a la asignación de la memoria que se deba utilizar como área para el intercambio de memoria (overlay), área residente de la memoria principal y área de base de datos global. Todos los procesadores deben tener relojes de alta precisión que no requieran de un reinicio después de una falla en el sistema eléctrico. Estos relojes se deben poder sincronizar por medio de señales de reloj del procesador maestro o desde un reloj maestro externo sincronizado por señal satelital. Las siguientes características se deben cumplir en los diferentes servidores del sistema:

a) Montaje en rack de 48.26 cm (19 pulgadas).

b) Discos duros en arreglos RAID tal como se indicó en el inciso 6.1.2 y (Hot Swap).

c) Fuente de alimentación redundante.

d) Doble tarjeta de red 100/1 000 Mbps.

Para la UCM se requiere:

- Una computadora industrial, con pantalla plana, a color, de 43.18 cm (17 pulgadas), 1 440 x 900 para montaje en rack, teclado en español y ratón (mouse) integrado.

- Unidad de cinta para montaje en rack. En la propuesta, del licitante debe acompañar la tabla 6 con los componentes ofertados para las funciones contenidas en los servidores. En el encabezado de la tabla 6 se debe indicar el nombre de las funciones que hace el servidor.

TABLA 6 - Servidores de SCADA, de comunicaciones, Histórico, “WEB”, base de datos o de aplicaciones

Características ofertadas Servidor:_____________________________________________

CPU

Sistema operativo

Velocidad de reloj

Memoria RAM

Montaje en rack de 48.26 cm (19 pulgadas)

Discos duros

DVD/CD +/-RW

Arreglo RAID

Red ethernet

Puerto de administración

Otro(s) dispositivo(s)



88 de 154

120713 Rev 160720 161021

El “hardware” requerido, es un servidor redundante para las funciones SCADA y un servidor para la “web”. En estos servidores se pueden realizar otras funciones como el de históricos, aplicaciones, comunicaciones, manejador de bases de datos, y los indicados en la presente especificación. El proveedor debe dar cumplimiento a los sistemas operativos solicitados, las funciones y desempeños requeridos en la presente especificación, debe suministrar tantos servidores como sea necesario. No se acepta que se utilice en un mismo servidor plataformas de “software” que permitan virtualización de los recursos de “hardware” con varios sistemas operativos. 6.13 Consolas de Operación y de Administración 6.13.1 Consolas de operación Las consolas de operación deben ser de tipo (full-graphic) y son la interfaz primaria para los operadores. Cada una de las consolas de operación debe comprender:

a) Estación de trabajo con uno o más procesadores. b) Monitores a color: cada consola debe permitir la conexión de hasta cuatro (4) monitores, cada

monitor debe ser de aspecto ancho (Wide Screen) de 68.58 cm (27 pulgadas) en diagonal o lo que se indique en Características Particulares, LCD y sus características técnicas deben ser las más actuales.

c) Una unidad de teclado en español. d) Un mouse óptico.

e) Un dispositivo externo e independiente de alarma audible.

f) La memoria de la tarjeta de video debe de ser independiente de la memoria RAM.

Se requieren consolas de trabajo modernas equipadas con multimedia y para el soporte de despliegues gráficos con procesadores adecuados para este tipo de aplicación. Los monitores deben estar libres de parpadeos y equipados con controles de ajuste y calibración necesarios para la presentación de formatos de despliegue (full-graphic) y de alta calidad. Las consolas deben incluir un generador de tonos o melodías para alarmas audibles con capacidad de producir al menos 8 diferentes tonos configurables por el usuario. Los niveles de amplitud, frecuencia y pulsación deben ser programables. El volumen de cada alarma debe ser ajustables por el usuario por lo menos en tres (3) pasos: alto, medio o apagado hasta un nivel de salida máximo de 90 dB. Debe incluir un interruptor para deshabilitar totalmente el generador de tonos. La alarma audible de cada consola debe poder responder a señales que la afecten según las áreas de responsabilidad asignadas a la consola y el tipo de usuario que esté operando la misma. 6.13.2 Consolas de administrador Esta consola debe tener potencialidad total, y contar con la capacidad funcional completa equivalente a las consolas de operación. Esta capacidad funcional debe ser configurable de modo que se les puedan asignar diferentes áreas de responsabilidad que no permitan la ejecución de controles. La cantidad de monitores a suministrar debe ser de una pieza y no es requerido el dispositivo externo e independiente de alarma audible. 6.13.3 Interfaces de red “LAN” y “WAN” Los cables de red utilizados para conectar los equipos de la UCM deben ser de nivel 5 o superior y deben usar un estándar de colores ANSI.



89 de 154

120713 Rev 160720 161021

6.13.4 Especificaciones generales de equipos periféricos de impresión En Características Particulares se define los requerimientos específicos de los equipos de impresión. Características básicas de los equipos de impresión:

a) Dispositivos programables, por medio de panel integrado y por comandos.

b) Interfaces de red de 10/100/1 000 Mbps, normalizadas y adecuadas a las condiciones físicas con los correspondientes dispositivos, derivados del tipo de configuración de red ofrecida. Con capacidad de operación en forma concurrente, recibiendo solicitudes de impresión por cualquiera de sus puertos.

c) Medios de impresión con características y calidad adecuada para satisfacer las exigencias del tipo

de trabajo pesado y de uso continuo. 6.13.4.1 Impresoras tipo láser blanco y negro al servicio de la red Todas las impresoras láser deben cumplir con las características técnicas de alta resolución, memoria, tipos de papel y velocidad más recientes en el mercado. 6.13.4.2 Impresora láser a color Todas las impresoras láser deben cumplir con las características técnicas de procesamiento, alta resolución, memoria, tipos de papel, interfaz de programación y velocidad más recientes en el mercado. No se aceptan tecnologías de impresión llamadas tipo láser que utilicen como sistema de impresión cera o inyección de tinta. 6.13.4.3 Características de conectividad de los dispositivos de entrada y salida local de datos

6.13.4.4 Sistema estándar de tiempo y frecuencia Se deben suministrar las interfaces digitales que permitan el acoplamiento de periféricos locales para salida y entrada de datos en línea. Estos tipos de datos deben ser:

a) Señales duales de receptor de reloj sincronizado por satélite (“satellite sychronized clock receiver”).

b) Datos de referencia para supervisión de tiempo y desviación de frecuencia (“time & frequency”).

Se debe incluir en la oferta base el equipamiento redundante del sistema de control de tiempo (sincronización de tiempo por satélite, relojes receptores, medición de tiempo y frecuencia) y sus respectivas interfaces. El equipamiento debe incluir herrajes para montaje de todos los dispositivos suministrados, así como el “software” de configuración. Este equipo debe incluir el receptor de señal (que capte la señal de 8 satélites), repetidor de señal y protección contra descargas. El receptor de satélite síncrono requerido es del tipo GPS (“Global Positioning System”).



90 de 154

120713 Rev 160720 161021

6.13.4.5 Documentación de ingeniería La documentación de ingeniería se debe entregar por el proveedor como lo marca el cronograma del proyecto y algunos de los requerimientos básicos que debe incluir son los que se describen a continuación:

a) Dimensiones.

b) Peso.

c) Consumo de energía.

d) Requerimiento de temperatura.

e) Diagramas de red.

6.13.5 Características eléctricas en general 6.13.5.1 Alimentación de potencia eléctrica La alimentación de potencia eléctrica donde se deben instalar los equipos, tienen las siguientes características: 127/220 V c.a. ± 10 % a 60 Hz ± 1 %. El proveedor debe proporcionar los consumos eléctricos de cada uno de los equipos por suministrar. 6.13.5.2 Conexión a tierra (grounding) Los sistemas de tierra locales en los diferentes centros de operación y control satisfacen las recomendaciones correspondientes, sin embargo, se requiere del proveedor, la garantía de un buen funcionamiento y seguridad de sus equipos en estas condiciones o de lo contrario, las recomendaciones de su parte para mejorar el esquema de conexión a tierra. 6.13.5.3 Características mecánicas 6.13.5.4 Gabinetes Los equipos de cómputo y de redes deben estar alojados en gabinetes metálicos, que deben cumplir con el grado de protección NEMA 1 o NEMA 12, de la norma NEMA 250, descrita en bibliografía. Las consolas deben estar en mobiliario especial para centros de control. El acceso al gabinete debe ser mediante puertas frontales y posteriores, desmontables y abatibles lateralmente. El gabinete debe estar preparado para conectarse al sistema de tierra local, con cable desnudo en un solo punto. Deben contar también con contactos polarizados, con alimentación de 127 V c.a., para la conexión de equipos de prueba, si éstos lo requieren. En aquellos casos en que los equipos requieran ventilación forzada, deben incluir filtros renovables. Cada gabinete debe contar con al menos dos multicontactos polarizados que debe ser alimentados de UPS´s independientes. Las fuentes redundantes de los servidores y los equipos con una sola fuente de alimentación pero que cuentan con redundancia, como los interruptores (“switches”), deben conectarse a cada multicontacto para garantizar la confiabilidad de la alimentación por fallas de cualquiera de las UPS´s.



91 de 154

120713 Rev 160720 161021

6.13.6 Otras características 6.13.6.1 Unidad de fuerza ininterrumpible UPS (opcional) El proveedor debe suministrar dos UPS´s en “hot swap”, para proporcionar una autonomía de al menos 4 h de respaldo, sin embargo en “Características Particulares” se deben indicar los requerimientos propios del área licitante. Cada UPS´s suministrada debe estar dimensionada para soportar la carga de todo el sistema (UCM y sus periféricos).

6.13.7 Mantenimiento El proveedor debe proporcionar toda la documentación correspondiente para el arranque o paro del sistema, total o parcialmente, según se requiera, incluyendo dispositivos necesarios de almacenamiento masivo de datos, lo mismo que las herramientas de programación y circuitería para modificar la configuración de los diferentes elementos de la red. Debe quedar incluido en el suministro, el “software” básico que permita monitorear y registrar en forma automática el comportamiento de los equipos que componen la red, así como de los diferentes procesos que conforman el sistema. 6.13.8 Equipos de prueba Tratándose de equipos especiales de prueba necesarios para el diagnóstico de fallas, el proveedor debe indicarlos e incluirlos en la oferta, así como el entrenamiento en el uso del mismo y los manuales correspondientes. Otros equipos de prueba recomendables deben ser también descritos y especificados. El proveedor debe proporcionar él o los equipos necesarios para un simulador de protocolos, con los protocolos incluidos en la UCM. 6.13.9 Diagnósticos de equipos El sistema debe contar con todas las facilidades para probar en forma local todos los componentes del mismo , los procesadores, los canales de comunicación y las redes locales. Los diagnósticos de los equipos deben poder ser ejecutados tanto en línea como fuera de ella , cuando se realicen en línea, se deben ejecutar sin que se degrade el comportamiento del sistema. Los reportes deben ser lo más claros posible para interpretar el funcionamiento, pudiéndose correr por separado o en conjunto secuencialmente. 6.13.10 Seguridad Las prácticas y procedimientos de operación de cada una de las funciones, los métodos de verificación de los mensajes de información operativa y las características de diseño del equipo “hardware”, de la programación “software”, programación en PROM’s (“firmware”), deben ser los más adecuados para que estos sistemas tengan la habilidad de reconocer y manejar condiciones operativas no apropiadas o no deseables, de tal manera que causen una alarma oportuna, una salida de operación, o ambas.

6.13.10.1 Detección de errores de programación Estos errores se deben detectar y reportar a través de una terminal del operador o de una impresora asignada, los mensajes de error deben ser almacenados en un archivo para su posterior análisis, estos mensajes deben incluir: hora, fecha, tipo de error, módulo de programación, donde ocurrió y la función que lo originó.



92 de 154

120713 Rev 160720 161021

6.13.10.2 Detección de errores de equipos El sistema debe detectar, desplegar e imprimir sus fallas, ayudado por la programación correspondiente. Cuando un equipo falle, el sistema debe continuar operando y se debe reconfigurar con los recursos disponibles, almacenando en ellos la información relativa a la falla. El sistema debe contar con un dispositivo de almacenamiento masivo, el cual debe contener la base de datos actualizada en forma periódica con el objeto de que, en la eventualidad de una falla, los programas para recuperar la base de datos sean capaces de reconstruirla. Cuando se detecten fallas intermitentes, se debe indicar el número de intentos y la operación fallada. 6.13.11 Partes de repuesto (opcional) El licitante en su oferta debe cotizar un lote de repuestos, si es posible a varios niveles, tales como tarjetas y componentes por equipo, describiendo número de parte y nombre del fabricante. Los repuestos a ser ofrecidos deben ser de dos tipos:

a) Un equipo completo de cada tipo y modelo propuesto, por ejemplo, adaptador de alimentación de energía: 10 % del suministro, mínimo uno.

b) Repuestos que se desgastan tales como lámparas, fusibles y elementos que deben ser usados en

el mantenimiento rutinario de los sistemas por un período de cinco (5) años. Todos los repuestos deben ser nuevos, sin uso y estrictamente intercambiables con las partes que deban reemplazar y deben cumplir con las especificaciones pertinentes. Deben ser obtenidos fácilmente por un mínimo de diez (10) años después de la puesta en servicio del equipo. El licitante debe incluir una descripción detallada de los repuestos de partes que se deterioran, individuales, e incluidos como grupos completos. En el proceso de licitación se debe revisar la lista de partes y se debe decidir si procede la adquisición en base a la importancia y el número de elementos.

6.14 Mobiliario (Opcional) De acuerdo a lo indicado en las Características Particulares el mobiliario suministrado debe ser de diseño específico para centros de control, debe ser de línea y con las características siguientes:

a) Para uso intensivo de 24 x 7 x 365 con diseño en su construcción para una duración de vida útil de al menos 10 años.

b) Estructural con armazón de perfil tubular calibre 11 soldado de acero.

c) Postes flotantes que permiten flexibilidad para el montaje del equipo para ajuste individual por

usuario para la altura de la mesa.

d) Patas de nivelación con tableros de base flotante.

e) Sistema estructural auto soportado. f) El mobiliario debe estar diseñado para adaptarlo a las necesidades del sistema, sin cajones,

gavetas o repisas. g) La textura del equipo es de laminado plástico.



93 de 154

120713 Rev 160720 161021

h) Con compartimientos para ocultar el CPU del equipo de cómputo, pero sin obstruir la ventilación o con los aditamentos para proporcionar ventilación forzada silenciosa, cableado de alimentación voz y datos.

i) Soportes de aluminio extruido de primera calidad para el acomodo de hasta cuatro monitores en

arreglos de 1x4 y 2x2 con ajustes para inclinación y orientación hacia el usuario u operador de manera individual para cada monitor.

j) Los requerimientos particulares de espacio y dimensiones de las mesas para las consolas se

indican en Características Particulares.

k) Sillas de diseño ergonómico con ajustes para la columna para uso continuo (24x7) de asiento y respaldo con material tipo malla y congruente con las características de las mesas.

6.15 Equipamiento para la Visualización Magnificada del Sistema Eléctrico (Opcional) Los centros de control y otras áreas operativas de las diferentes Subdirecciones de la Dirección de Operación, pueden contar de manera opcional, cuando así se indique en Características Particulares con el equipamiento para la visualización de forma magnificada y detallada de lo que ocurre en el sistema eléctrico y sus clientes. El suministro de este equipamiento debe incluir todo el “hardware” y “software” necesario para realizar las funciones que sean solicitadas. Para el desempeño del equipo, se requiere que cualquier solicitud de imagen que se haga al controlador, no debe demorar más de 1 s en desplegarse totalmente, en el sistema de visualización que se tenga. 6.15.1 Controladores de video Los controladores de video o servidores de video, deben tener las siguientes características y funcionalidades:

a) Alta Disponibilidad de 7 días de la semana x 24 h del día.

b) Tecnología más reciente.

c) Almacenamiento en discos duros proporcional al dimensionamiento que se debe manejar y que se indica en las Características Particulares del sistema SCADA y de los sistemas con los que debe intercambiar información.

d) Arreglo de discos redundantes como lo que se describe en el punto 6.1.2, inciso k.

e) Redundancia de fuentes en esquema redundante n+1 así como la alimentación debe ser de

fuentes distintas.

f) Teclado y ratón inalámbricos con alcance de 10 m como mínimo.

g) Tarjeta dual de red UTP 10/100/1 000 MB para conexión directa a red de datos local.

h) Unidad de almacenamiento óptico: DVD-RW.

i) Licencias del sistema operativo o “software” de aplicación.

j) Función para tomar el control del servidor desde cualquier computadora que se encuentre en la red de datos local.

k) Entradas de video: al menos de 4 puertos DVI con resolución mínima de 1 920 x 1 080 pixeles y 1

entrada S-Video.



94 de 154

120713 Rev 160720 161021

l) Salidas: puerto tipo DVI para interconectar y entregar señal de video simultánea a todos los elementos de visualización a la resolución nativa de los mismos.

m) Incluir los adaptadores y cables requeridos para las conexiones del servidor de video al sistema de visualización.

n) La transmisión de video debe ser digital.

o) Facilidad de insertar, remover o reemplazar módulos, cuando aplique.

Debe incluir el software que permita realizar las siguientes funciones como mínimo:

a) Administración de imágenes provenientes de diversas fuentes de video o aplicaciones aun cuando estas se encuentran minimizadas, para ser enviadas a la salida de video.

b) Las señales de video deben ser desplegadas en ventanas libremente escalables y posicionales a lo largo del sistema de visualización que se haya solicitado en Características Particulares.

c) Función para realizar el ajuste y la calibración automática de color y brillo en la(s) pantalla(s) de

visualización, logrando la uniformidad en todo el conjunto de visualización.

d) Configuración, operación y mantenimiento de la salida de visualización, (cuando sean módulos para formar una sola imagen), permitiendo el ajuste de brillo, contraste y color de cada módulo de forma individual o de todo el panel en su conjunto.

e) Funcionalidad de creación de escenarios para guardar varias configuraciones del panel, estos

escenarios predefinidos pueden ser guardados y lanzados posteriormente en cualquier momento, volviendo de este modo la visualización a la configuración definida en dicho escenario.

f) Debe incluir las licencias necesarias que permitan la modificación de los escenarios desde al

menos 5 equipos diferentes de la red local, mediante aplicación que cuente con la facilidad de arrastre y colocación de imágenes (drag and drop) utilizando el ratón.

g) Simular ventanas abiertas desde el procesador de cualquier computadora de la red local.

h) Programación del movimiento de los desplegados que se muestran en el mural.

6.15.2 Elementos de visualización En Características Particulares se define el tipo de visualización que debe ser requerido con el suministro del equipamiento para visualización, que debe ser, mediante tableros mímicos, pantallas de video o video-proyectores. 6.16 Tableros Mímicos (Murales de Visualización) Sistema formado por cubos de video de proyección posterior, con tecnología DLP-LED, que permita proyectar imágenes de una o varias consolas del operador, con capacidad de realizar funciones de tablero mímico y de funcionar como mural de visualización. Con operación de manera continua (7x24), con despliegue de contenidos de un sistema SCADA y con despliegue de otras fuentes de video. Elementos para cubos de video que forman el mural con al menos las siguientes características y especificaciones ver tabla 7:



95 de 154

120713 Rev 160720 161021

TABLA 7 - Características de los murales de visualización

Característica Especificación

Tecnología Retro-proyección con lámpara de LED-RGB no utilice rueda de color

Tamaño de diagonal 1.78 m x 1.83 m (70 a 72 pulgadas)

Resolución Al menos 1 920 x 1 080 nativa

Razón de contraste Mínimo 1 400:1

Razón de aspecto 16:9 ó 16:10

Brillantez (cd/m2) Mínimo 170

Voltaje de línea 110 o 220 V c.a., @60 Hz

Gama de colores Mayor a 100 % norma EBU

Uniformidad de color Mayor o igual a 90 %

Temperatura de operación 10 °C - 35 °C

Interfaces Mínimo una entrada DVI

Tiempo de vida de la fuente de luz Mínimo de 60 000 h

Vida útil Mínimo de 5 años

Espaciamiento entre paneles de cubos de video adyacentes Menor o igual a 2 mm horizontal y vertical

Rango de humedad de operación De 20 % a 80 % no condensada

6.16.1 Pantallas de video Sistema formado por pantallas LCD o LED con capacidad de realizar funciones de tablero mímico y de funcionar como mural de visualización. Con operación de manera continua (7x24), con despliegue de contenidos de un sistema SCADA y con despliegue de otras fuentes de video, ver tabla 8. Debe incluir una funcionalidad que permita que las imágenes no queden marcadas en la pantalla después de al menos 2 000 h de operación continúa.

TABLA 8 - Características de las pantallas de video

Característica Especificación

Tecnología LCD

Tamaño de la diagonal Mínimo de 1.16 m (46 pulgadas)

Resolución Mínimo de 1 366 x 768 nativa

Razón de contraste Mínimo de 3 000:1

Brillantez (cd/m2) Mínimo de 500

Tensión de línea 110 o 220 V c.a, @ 60 Hz

Gama de colores Mayor a 100 % norma EBU

Uniformidad de color Mayor o igual a 90 %

Temperatura de operación 10 °C - 35 °C

Control remoto de funciones Control remoto para configuraciones individuales.

Interfaces de video DVI, VGA, BNC Y PC

Tiempo de vida de la fuente de luz Mayor o igual a 60 000 h

Vida útil Mayor o igual a 5 años

Espaciamiento entre pantallas adyacentes

Menor o igual a 3.3 mm horizontal y vertical

Rango de humedad de operación De 10 % a 80 % no condensada



96 de 154

120713 Rev 160720 161021

6.16.2 Video proyectores Sistema formado por uno o dos videoproyectores con tecnología DLP3 con capacidad de realizar funciones de tablero mímico y de funcionar como mural de visualización. Con operación de manera continua (7 x 24), con despliegue de contenidos de un sistema SCADA y con despliegue de otras fuentes de video. Con al menos las siguientes características técnicas: ANSI LUMENS 10 600, Resolución WUXGA 1920X1200, Aspecto 16:10, Contraste 10 000:1, Lámpara doble al menos 355 W c/u, Entradas HDMI, DVI-D, SDI, RGB1, SVIDEO, tecnología DLP 3 CHIPS. 6.16.3 Estructuras para montaje Para el montaje de los videoproyectores o de las pantallas de video en la sala de operación correspondiente se debe considerar una estructura para conformar el mural de visualización. Ésta estructura, en su caso, debe seguir la curvatura del muro de la sala de operación donde debe ser instalado. Debe ser considerada una estructura metálica de acero o de aleación de aluminio con características de peso y dureza que garanticen el correcto soporte de los videoproyectores o pantallas y debe quedar fijada o anclada al piso o al muro o techo más cercano. También se debe incluir el rack o accesorios necesarios para colocar el servidor controlador de videoproyección, en la parte posterior del mural si se tiene espacio disponible. Adicionalmente y de acuerdo a las condiciones de la sala de operación, se debe incluir un marco para cubrir el perímetro del mural de visualización, de alucobond gris metalizado anti-inflamable o similar, que permita la colocación de otro tipo de pantalla (display) para mostrar información alfanumérica como frecuencia, la hora (GPS), entre otros. También se debe incluir el acabado de la base del mural de visualización de acuerdo a las condiciones de la sala de operación de la instalación. 6.16.4 Panel de control para la proyección

El sistema debe contar con un “software” de aplicación para el control del despliegue de imágenes y para la administración de la configuración del mural de visualización, que cumpla las siguientes características:

a) Debe incluir la funcionalidad de tomar el control de éste “software” desde al menos 5 consolas distintas conectadas en la red local.

b) Software para simular ventanas abiertas del procesador en cualquier computadora de la red local. c) Para el caso de los cubos de video, el software debe realizar el ajuste y la calibración automática

de color y brillo en los cubos. En caso de requerirse para esta función, se debe incluir el “hardware” necesario.

d) Las señales de video deben ser desplegadas en ventanas libremente escalables y posicionables a

lo largo del mural de visualización. e) Incluir el software necesario para la configuración, operación y mantenimiento del mural de

visualización permitiendo el ajuste de brillo, contraste y color de cada módulo de forma individual o de todo el mural en su conjunto.

f) Software para programar el movimiento de los desplegados que se muestran en el mural. g) Funcionalidad de creación de escenarios para guardar varias configuraciones del mural. h) Estos escenarios deben ser guardados y recuperados posteriormente en cualquier momento,

volviendo de este modo el mural a la configuración definida en dicho escenario.



97 de 154

120713 Rev 160720 161021

6.17 Capacitación

Se pueden considerar distintas etapas de capacitación de acuerdo a las alternativas siguientes:

a) En fábrica.

b) En aula de capacitación.

c) En sitio en la puesta en operación.

d) En operación del sistema.

La capacitación pude estar enfocada hacia:

- El administrador del sistema.

- El operador del sistema eléctrico.

- En ambos casos se deben contemplar los siguientes temas:

. Actividades prácticas avanzadas en fábrica, (OJT) On the job training.

. Adiestramiento en el “hardware” y “software” suministrados.

. Ingeniería de base de datos y construcción en tiempo real.

. Familiarización con los procedimientos de la Interface de usuario.

. Familiarización con las funciones del SCADA y sus aplicaciones.

. Familiarización con el sistema de potencia eléctrico de la C.F.E.

. Operación del sistema de potencia.

. Desplegados en las consolas de operador y de mantenimiento.

. Funciones básicas.

. Editor.

. Sistema de administración.

. Reportes.

. Manejo de las funciones SCADA.

. Protocolos de comunicación DNP3/ICCP.

. Diagnósticos y corrección de fallas del sistema.

. Funciones automáticas.



98 de 154

120713 Rev 160720 161021

7 CONDICIONES DE OPERACIÓN

7.1 Función Servidor de Comunicaciones La función del servidor de comunicaciones debe ser redundante y debe cumplir los siguientes requerimientos:

a) Manejo del protocolo que se adecue a los dispositivos remotos y que cumpla totalmente con los perfiles propuestos.

b) Determinación de los direccionamientos que se envían.

c) Verificación de los direccionamientos que se reciben.

d) Iniciación de retransmisión, (de requerirse).

e) Manejo de la redundancia entre procesadores y arranque autónomo de las unidades de forma que siempre se tenga un procesador con el control del proceso y el redundante no interfiera en la operación normal.

f) Diagnóstico, reporte de fallas de módulos y canales de comunicación.

Cada servidor de comunicación debe estar conectado a las dos (2) redes LAN de la UCM. Deben tener conexión a cada uno de los módems seriales o enlaces digitales a través de dispositivos que permitan compartir el acceso a éstos (“Modem Sharing Devices”, MSD o equivalentes), los cuales deben estar incluidos en el alcance del suministro propuesto. Los MSD se deben monitorear. Los servidores de comunicaciones deben tener respaldo conmutado, por lo que deben realizar la recolección de información de manera periódica o bajo demanda. 7.2 Función Servidor “web” El sistema debe acceder y publicar información en la “web” por medio de este servidor. El objetivo del servidor “web” es permitir el intercambio de información de tiempo real o histórica requerida por usuarios corporativos o usuarios externos autorizados, empleando herramientas de acceso a “internet” estándar (navegadores de “internet”). 7.3 Función del Servidor de Bases de Datos Histórica Se debe suministrar espacio en disco duro para almacenar la información recolectada por la UCM por un período de 2 años por lo menos en línea. 7.4 Dispositivos de Almacenamiento de Datos a Largo Plazo Los dispositivos para almacenamiento de datos a largo plazo (“File Storage”) deben ser usados para realizar el respaldo de los datos y del “software” del sistema y para el archivo de la información almacenada en la base de datos histórica. Estos dispositivos deben ser accesibles por todos los procesadores. El medio de almacenamiento debe tener la capacidad suficiente para un respaldo completo de los datos y software del sistema, sin requerir de acciones del usuario para reemplazar el medio de almacenamiento lleno. Se requiere un cambiador de medio que acepte comandos estándares de administración de medios. El equipo de almacenamiento debe ser una solución integral y estar basado en un sistema de manejo de almacenamiento jerárquico.



99 de 154

120713 Rev 160720 161021

El medio de almacenamiento debe ser un servidor NAS con acceso a través de la red TCP/IP de la UCM para que desde cualquier consola se pueda compartir el mismo espacio de almacenamiento a la vez. Debe tener almacenamiento redundante, con un arreglo RAID de los descritos en el punto 6.1.2. 7.5 Equipos Periféricos de Impresión (Impresoras Láser, blanco, negro y a color) Las impresoras para registros de alarmas, eventos e impresión de desplegados deben estar asociadas a las consolas de interface de usuario, y por tanto deben ser usadas como recursos de impresión de cualquiera de las estaciones de trabajo o servidores de la misma red o de redes distintas dentro del ambiente de tiempo real.

Para tener mayor flexibilidad en la utilización de las impresoras, se deben conectar directamente a la red LAN de la UCM.

7.6 Características de los Dispositivos para la Comunicación con las UTR’S Los dispositivos utilizados en la comunicación con las UTR´s deben soportar velocidades configurables de 600 baudios hasta 38 400 baudios y deben manejar las señales para interactuar con equipos de comunicación por radiofrecuencia (señales seriales RS-232, RTS, CTS, CD, entre otros).

En lo referente a enlaces sobre TCP se debe configurar IP por remota y por puerto y debe ser configurable para que más de una UTR tenga la misma IP y se configuren en campo con un socket diferente cada una de ellas. Lo antes descrito debe permitir lo redactado en el punto 6.8.3.5 en el inciso b). 7.7 Requerimientos Físicos y de Diseño de los Equipos 7.7.1 Generalidades

Todo el equipamiento, local o remoto, que conforman los sistemas objeto de esta especificación, debe estar acorde con la referencia [5] del capítulo 13 de esta especificación, además de los requerimientos específicos establecidos en el presente documento. 7.7.2 Condiciones ambientales 7.7.2.1 Para equipos locales

Los equipos deben operar en forma continua bajo las siguientes condiciones ambientales:

a) Temperatura de operación: +5 ºC a +40 ºC.

b) Variación de temperatura: 10 ºC/h.

c) Humedad relativa: 10-90 % sin condensación.

d) Altitud: 0 m a 2 700 m s.n.m

7.7.2.2 Disipación de calor El proveedor debe indicar la disipación de calor en kcal/hr para cada uno de los equipos que componen el suministro. 7.7.3 Interferencia y compatibilidad electromagnética

Los equipos no deben ser fuentes de emisiones radiadas que excedan 1V/m/MHz, medidas a un metro del gabinete de acuerdo a la norma mexicana NMX-I-240-NYCE. En general, los equipos deben operar en ambientes con campos de radiación del orden de 1V/m/MHz, sin daños ni fallas.



100 de 154

120713 Rev 160720 161021

Para el caso de elementos como cintas magnéticas y discos, deben soportar al menos campos del orden de 50 x 10-4 teslas (weber/m2). 7.7.4 Protección contra descargas atmosféricas (“lightning protection”) Los equipos deben contar con los dispositivos de protección contra descargas atmosféricas en todos los elementos que forman el sistema de control, particularmente los elementos terminales y de acoplamiento de los cables físicos de datos que deben enlazar a la estación maestra con las estaciones de trabajo y los medios de comunicación. Los equipos electrónicos deben soportar las pruebas de aislamiento y de perturbación oscilatoria amortiguada a 1 MHz, que se estipulan en las normas IEC 60255-5 e IEC 60255-22-1. Adicionalmente todos los equipos electrónicos deben cumplir con lo estipulado en la norma IEC 61000 y en la norma IEC 60801 y soportar las pruebas de descarga electrostática y de perturbaciones de campos electromagnéticos radiados que se estipulan en las normas IEC 60255-22-2 e IEC 60255-22-3 respectivamente. Las alimentaciones de fuerza al equipo terminal deben incluir clavijas polarizadas para referencia de las tierras lógicas, además de contar con la tierra física del gabinete. 7.8 Desempeño 7.8.1 Periodicidad de funciones y transferencia de datos En la tabla 9 se muestran los tiempos máximos que debe soportar el sistema en condiciones con las máximas capacidades que se indican en Características Particulares de canales de comunicación hacia UTR´s, puntos binarios y analógicos, enlaces de comunicación utilizando los protocolos ICCP, DNP3 y los solicitados.

TABLA 9 - Periodicidad de funciones

F u n c i o n Periodicidad

Tiempo máximo para la exploración de estados de tiempo real de UTR´s

1.5 s

Tiempo máximo para la exploración de valores analógicos de tiempo real de UTR´s

a) 2 s para MW enlaces y frecuencia

b) 4 s para MW de unidades, estado de interruptores y de protecciones

c) 4 s para las mediciones restantes

Exploración de acumuladores de tiempo real de UTR´s

(5, 15, 30, 60) min

7.8.2 Escenarios para la determinación del cumplimiento del desempeño de la UCM. 7.8.2.1 Protocolo de comunicaciones DNP3 El fabricante o su representante legal, deben demostrar que el protocolo cumple con el 100 % de su implementación y funcionalidad, de acuerdo a lo solicitado en Características Particulares y lo establecido por el grupo de usuarios del DNP3 de la versión de febrero de 2010 o la versión más reciente al momento de la licitación. El proveedor debe entregar las configuraciones necesarias del sistema SCADA para poder generar cada uno de los objetos de este perfil, también debe entregar las tramas en DNP de transmisión-recepción de cada una de las pruebas. El fabricante o su representante legal, debe proporcionar en pruebas de aceptación en fábrica (FAT) todos los medios y recursos del “escenario de pruebas” que permita ejercitar, mostrar y analizar el flujo de información del protocolo para comprobar el cumplimiento de la implementación solicitado. El método y criterio de evaluación que deben ser aplicados en estas



101 de 154

120713 Rev 160720 161021

pruebas, deben ser similares a las que se detallan en la documentación del grupo de usuarios del DNP3 de la versión más reciente llamada “intelligent electronic device (IED) certification procedure subset level 2”, en estas pruebas un representante técnico de la CFE debe estar presente para entregar constancia y evidencia de las tramas del protocolo que se ejercitaron con la aceptación o rechazo conforme a la reglamentación y procedimientos vigentes de la CFE. 7.8.2.2 General Se debe medir el comportamiento funcional de los equipos y la programación, bajo diferentes niveles de actividad y utilización de recursos del sistema. Así, usando las diferentes bases de datos definidas por el usuario, se tienen a continuación dos escenarios de prueba mostrados en la tabla 10.

TABLA 10 - Períodos para escenarios de prueba

Escenario Actividad y uso de recursos Período de prueba

Normal Estable o normal 1 h

Pico Intensa en emergencia 1 h

Los escenarios están definidos en el apartado siguiente de esta especificación. Cuando no estén especificados los parámetros necesarios para realizar las pruebas de desempeño en los dos escenarios propuestos, que afecten los valores de carga de cómputo, utilización de memoria, de disco, entre otros, deben ser propuestos por el proveedor estos escenarios y claramente explicados. 7.8.3 Actividad base de los escenarios de prueba Las siguientes condiciones se aplican para definir los niveles de actividad base de los escenarios normal y pico:

a) La base de datos de la UCM y todo su “software” deben estar dimensionados a las definiciones de tamaño especificadas, y deben estar pobladas y probadas con datos reales de instalaciones de la CFE.

b) Los barridos hechos a las UTR’s por la UCM y los datos de intercambio entre los centros de

control, deben estar a su tasa de interrogación definida y condicionada a las características funcionales del protocolo de comunicaciones bajo prueba.

c) Se deben ejecutar las funciones a las periodicidades especificadas, incluyendo los programas de

aplicación. d) Todas las funciones se deben completar dentro del tiempo especificado.

e) Todas las consolas deben estar en línea, funcionalmente normales, y cada monitor de consola de

operador debe tener al menos cuatro (4) ventanas abiertas de actualización siendo una de ellas un desplegado unifilar con al menos 60 valores de estado y 100 analógicas.

f) Las ventanas restantes de cada consola deben presentar cualquier desplegado de la UCM

seleccionado por la CFE para esta prueba. Todos los monitores de consola deben ser actualizados a la velocidad especificada.

g) Todas las ventanas llamadas durante la prueba, excepto aquellas que se necesiten para ejecutar

funciones de aplicación para propósitos de prueba, contendrán un mínimo de sesenta (60) valores de estado actualizados y un mínimo de cien (100) valores análogos actualizados.

h) Todas las alarmas deben generar información en los archivos de eventos y alarmas.



102 de 154

120713 Rev 160720 161021

i) Cuando la hora llegue a la medianoche (programable su activación), se deben ejecutar todas las recolecciones de datos y cálculos asociados con las funciones de la UCM, para la generación de la información del reporte correspondiente.

j) Se deben ejercitar las funcionalidades de desplazamiento y acercamiento continuo (“panning y

zooming”) debiendo ejecutarse los movimientos solicitados en cada consola simultáneamente, en un tiempo no mayor a 1 s.

7.8.4 Nivel de actividad en los dos escenarios

En la tabla 11 se presentan los niveles de actividad y los tiempos de ejecución de aplicaciones para los dos escenarios de prueba definidos.

TABLA 11 - Niveles de actividad

ACTIVIDAD Normal Pico

Interfaz gráfica del usuario

Peticiones de desplegados por consola. Entrada manual de datos por consola (todas las consolas). Acciones de control/consola (todas las consolas).

Cambios de posicionador de Taps

Arranque de unidades generadoras (cuando aplique). Controles de capacitores/reactores (cuando aplique). Bloque de operaciones. Cambio de asignaciones de video-tendencias. Utilización del coloreo dinámico de la red.

1 por min

1 cada 5 min 1 cada 4 min

10 3 1 - 1 Si

5 por min 1 por min 2 por min

15 5 6

1/min 3 Si

Reportes

Impresión de todos los reportes diarios. Peticiones del operador para imprimir bitácoras. Cambios manuales de valores. Impresión de eventos adicionales por entrada manual de datos del operador.

a) Impresión de reportes programados. b) Impresión de reportes a solicitud del operador.

Si 1 5

50

Si 5 10 225

Continúa…



103 de 154

120713 Rev 160720 161021

…Continuación

Programas de adquisición de datos

-Porcentaje del total de puntos que requieren procesamiento

30 %

50 %

Programas de procesamiento de alarmas/eventos

Condiciones de la prueba

La colección de secuencia de eventos debe estar activa todo el tiempo, y se interrogan a 4 UTR´s simultáneamente, reportando eventos tipo SOE y realizando también el envío de éstos datos a otro centro de control mediante protocolo ICCP* Velocidad de procesamiento mínimo de alarmas. Ocurrencia de la colección de datos para la prueba de disturbio. Reconocimiento de alarmas. Violaciones de límites de mediciones. (Todas las alarmas son reconocidas).

50/s

200 eventos

Cada 15 min

Cada 15 min 50

50/s

200 cada minuto y avalancha de 3 000

Cada 6 min

Cada 15 min

500

Histórico

Ejecución de una reconstrucción de eventos (playback) sobre un diagrama unifilar con 100 puntos analógicos y 50 puntos de estado.

Un evento cada 10 s durante 1 h

Un evento cada 2 s

durante 1 h

Servidor “WEB”

Se deben tener 3 sesiones abiertas con diferentes desplegados cada una el cual será elegido por la CFE. La actualización de los datos dinámicos debe ser:

Cada 5 s

Cada 5 s

En la tabla 12 se encuentran los tiempos de respuesta de la consola de operador que deben ser cumplidos para las UCM´s.

NOTA: 1. Se consideran peticiones de desplegados del tipo resumen de alarmas no reconocidas, unifilares, y cuando aplique: resumen de control de generación, desplegados de servicios de transmisión.

2. (Cada bloque puede operar un máximo de 20 dispositivos). (Tiro y restauración de carga). 3. (información proveniente de campo, con cambios en la base de datos) completo por barrido.



104 de 154

120713 Rev 160720 161021

TABLA 12 - Tiempos de respuesta en las consolas

Acción

Tiempo de respuesta máximo Notas

Actividad normal

Actividad pico

Respuesta al llamado de un desplegado 0.5 s 1 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Respuesta a alarmas y eventos 1 s 1.5 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Desplegados debido a cambios de estado provenientes de UTR´s

1 s 2 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Desplegados debido a cambios en mediciones provenientes de la UTR´s


Respuesta a una solicitud a nivel local: (reconocimiento de alarma, entrada manual de datos, inhibición de alarma)

0.5 s 1 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Solicitud de información para desplegar en la consola, proveniente de la base de datos histórica


Desplazamiento en la ventana (“Panning”) 1/8 de pantalla

en 0.5 s 1/8 de pantalla

en 0.5 s

La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición. No se debe presentar un parpadeo visible o discontinuidad a esta velocidad

Acercamiento o alejamiento de imagen (“Zoom”)

1 paso por cada 0.5 s

1 paso por cada 0.5 s

La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Todas las otras respuestas relacionadas con desplegados tales como distintos tipos de menús (“pop-up, pull-down”) cajas de diálogo, entre otros

0.5 s 1 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

Registro de usuario (“Log-on”) 5 s 10 s La respuesta no debe exceder del 150 % del tiempo bajo cualquier condición

7.8.5 Utilización de recursos en los dos escenarios

Los niveles de utilización de los recursos muestran la disponibilidad que pudiera haber en caso de requerirse una expansión del sistema, así como también se muestra el margen de seguridad que se dispone al cargarlo con esos recursos. Aunque el uso de los recursos es dependiente de la configuración y el método de distribución de funciones en la UCM, en la tabla 13 se presentan los niveles máximos solicitados de utilización de recursos en los dos escenarios.



105 de 154

120713 Rev 160720 161021

TABLA 13 - Utilización de recursos

R e c u r s o Normal Pico

Carga de computadoras

Para la ejecución de las funciones asignadas. - Pre-procesadores de adquisición de datos. - Servidore. - Estaciones de trabajo.

20 % Máx. 20 % Máx. 20 % Máx.

30 % Máx. 30 % Máx. 30 % Máx.

Almacenamiento de datos

Cualquier dispositivo o controlador de memoria masiva.

30 % Máx.

40 % Máx.

Servidores de comunicación

Utilización en línea de cualquier servidor de comunicación (“gateway”, “router”, “bridge” o procesador de la red de comunicación).

30 % Máx.

40 % Máx.

Carga en redes

Carga promedio de utilización del ancho de banda en las redes “LAN” de las UCM´s

5 % Máx.

10 % Máx.

7.8.6 Tiempos de recuperación de fallas para algunos procesos o funciones de la UCM

En la tabla 14 se establecen los tiempos máximos de recuperación de fallas de diferentes procesos y funciones de la UCM. En caso de que el sistema realice rearranques, el proveedor debe garantizar que cuando sean en tibio (“warm”) o caliente (“hot”) la información de entradas manuales, banderas, alarmas inhibidas, controles inhibidos y límites de operación deben mantenerse en la misma posición después del rearranque. En caso de que el rearranque deba ser en frío (“cold”), el proveedor debe de proporcionar una herramienta que permita el cargado manual de la información anterior. Los tiempos presentados en la tabla 14 deben entenderse como requisitos a ser proporcionados. El proveedor debe

presentar una tabla con los tiempos máximos comprometidos para la recuperación de fallas descritas.

TABLA 14 - Requerimientos de tiempos de recuperación

Función Tiempo

Respaldo de base de datos residente en memoria en un medio de memoria masiva

No menos frecuente a cada 30 s

Entradas del usuario y solicitudes pasadas a la base de datos de respaldo (“User entries and requests passed to backup database”)

Bajo ocurrencia, completado dentro de los 5 s

Transferencia de todo el procesamiento de funciones críticas de un servidor a otro

Dentro de los 30 s

Detección de falla de hardware Dentro de los 5 s

Continua…



106 de 154

120713 Rev 160720 161021

…Continuación

Detección de falla de software Dentro de los 5 s

Reinicio (“restart”) de subsistemas de software de una aplicación individual Dentro de los 15 s

Rearranque del sistema total Caliente (“Hot”)

Dentro de los 30 s

Tibio (“Warm”) Dentro de los 30 s

Ordenado por el sistema operativo Dentro de los 5 min

Arranque en Frío (“Cold”) Dentro de 1 min

Detección y “switcheo” automático de canal de comunicaciones fallado informando al operador

Dentro de los 5 s

Recuperación de falla de la red “LAN” Dentro de los 5 s

8 CONDICIONES DE DESARROLLO SUSTENTABLE

El proveedor debe considerar desde la etapa del diseño, construcción e instalación del equipo, las condiciones de protección ambiental como parte de un desarrollo sustentable que se establece en las normas nacionales e internacionales vigentes y que se debe acatar en los lugares de trabajo durante las maniobras de entrega del equipo, el almacenaje, el montaje, las pruebas, la operación y el mantenimiento, esto debido a que los residuos que se pudieran generar, por lo que le corresponde al proveedor, deben documentarse y aplicar la legislación correspondiente a la generación de los residuos peligrosos. Lo que queda sujeto a ser verificado por el personal asignado por la CFE. Si derivado de las actividades que desarrolle el proveedor, por la aplicación de esta especificación, genera alguna contingencia o incumplimiento ambiental, la CFE lo debe subsanar, pero con cargo al proveedor. Si se generan residuos peligrosos, de manejo especial o sólidos urbanos, el proveedor tiene la obligación de manejarlos con estricto apego a la normativa ambiental vigente establecida para cada tipo de residuo. Es política de la CFE, la protección al ambiente, por lo que en todas las actividades que desarrolla, evita o reduce, en la medida de lo posible, los impactos que de ellas resulten, y dentro de las funciones de la Gerencia de Protección Ambiental, está la de asesorar y supervisar las acciones de protección ambiental, encaminadas a evitar, o minimizar los impactos negativos al ambiente, que puedan causar sus instalaciones, por lo que todas las actividades que generen residuos peligrosos, no peligrosos y de manejo especial, deben cumplir con la normativa ambiental vigente.

9 CONDICIONES DE SEGURIDAD INDUSTRIAL No aplica. 10 CONTROL DE CALIDAD

La CFE representada por el LAPEM o persona física o moral que la misma designe, tendrá en todo momento el derecho de inspeccionar y probar los bienes a fin de verificar su conformidad con las especificaciones del contrato y pliego de requisitos.



107 de 154

120713 Rev 160720 161021

Los equipos deben ser diseñados y construidos para operar sin presentar fallas ocasionadas por influencias electromagnéticas. El diseño se debe haber comprobado a fin de evitar consecuencias de errores en el mismo. Las condiciones de transporte deben ser consideradas a fin de evitar mal funcionamiento debido al mismo. Es requisito indispensable la seguridad de operación de cada una de las funciones que se asignen al sistema, evitando cualquier posibilidad de falsa operación, inadecuada aplicación de funciones y fundamentalmente de operación autónoma o errónea de telecontroles por interpretación de mensajes erróneos o fallas de equipamiento (“hardware”). Por lo tanto, se requiere que el sistema cuente con los elementos necesarios de seguridad y verificación a nivel de programación y componentes. 10.1 Notificación y Documentación de las Pruebas Previo a la construcción del sistema, el proveedor debe entregar a la CFE los planos de la arquitectura para su aprobación por la Coordinación de Distribución y el área usuaria. Una vez que se tenga esta aprobación, el proveedor en conjunto con personal de la CFE, se debe establecer el programa de pruebas a efectuar, cuyo documento se debe presentar por lo menos con 20 días naturales de anticipación a éstas, para la aprobación final por la Coordinación de Distribución y área usuaria. Al término de las pruebas en fábrica se debe presentar el reporte con todas las condiciones, características y resultados obtenidos. Cada prueba se debe reportar conteniendo:

a) Identificación del equipo sometido a pruebas.

b) Descripción de la prueba.

c) Resumen de resultados incluyendo descripción de los eventos y fallas.

d) Descripción de todas las intervenciones, correcciones, modificaciones y pruebas llevadas a cabo en los equipos.

Los informes son responsabilidad del proveedor y deben ser entregados con original y 2 (dos) copias a la CFE en formato electrónico, una copia debidamente autorizada es devuelta al proveedor y otra copia se debe enviar al área usuaria. Los procedimientos de prueba deben ser acordados por el fabricante y la CFE antes de efectuar las mismas. 10.2 Pruebas de Aceptación Para las pruebas de aceptación deben cumplir con los desempeños y requerimientos que se indican en la presente especificación, además lo que se indica a continuación: 10.2.1 En fábrica Previo a las pruebas de aceptación en fábrica por parte de la CFE, el proveedor debe realizar todas las pruebas de rutina al 100 % de los equipos a suministrar. Requerimientos mínimos que debe de cumplir el proveedor para efectuar las pruebas de aceptación:

a) El proveedor debe proporcionar el personal y equipo necesario para la realización de las pruebas en fábrica, así como las instalaciones y áreas de pruebas adecuadas y seguras. Así mismo debe proporcionar los planos y la base de datos aprobados por la CFE.

b) Las pruebas e inspección deben ser efectuadas en presencia del personal de la CFE o un

representante debidamente autorizado por ésta. Dicha participación no limita la responsabilidad del proveedor de la calidad satisfactoria de los equipos.



108 de 154

120713 Rev 160720 161021

c) Los equipos de medición y pruebas que intervengan en el escenario deben de contar con

certificado de calibración vigente.

d) El sistema integrado debe ser probado a plena capacidad.

e) Los informes de los resultados de las pruebas realizadas en fábrica. El personal de la CFE debe participar en:

a) Preparación anticipada de los programas de cada prueba. b) Desarrollo de la prueba. c) Reuniones para interpretación de los resultados de las pruebas, así como las medidas a tomar en

caso de fallas. d) Decisiones sobre nuevas pruebas, derivadas de los resultados obtenidos en la implementación del

programa establecido. Las pruebas de aceptación, deben incluir:

a) Inspección visual.

Para detectar defectos de manufactura y asegurar que el sistema se fabrique de acuerdo a lo indicado en la presente especificación y normas de referencia proporcionadas por el fabricante.

b) Pruebas a la UCM.

Verificar las características funcionales y técnicas de cada uno de los elementos del sistema.

c) Pruebas e inspecciones. Verificar que los distintos componentes electrónicos y eléctricos proporcionen una operación segura, correcta y confiable. El proveedor debe proponer un programa de pruebas, el cual debe incluir las siguientes, no siendo limitativo a las mismas:

10.2.2 Pruebas funcionales y comunicaciones

a) Funcionamiento de cada red de comunicación y concentración de datos en la UCM.

b) Comunicación de la UCM hacia nivel inferior y nivel superior.

c) Comunicaciones de la UCM al simulador con el protocolo especificado en los canales de comunicación respectivos.

d) Pruebas funcionales (verificación, entradas digitales, mediciones, controles) a través de los DEI’s y

UTR’s.

e) Integración de mediciones y estados procedentes de campo a la información del SCADA.

f) Programación de los tipos de entradas digitales.

g) Deshabilitación o habilitación de salidas de control para pruebas.



109 de 154

120713 Rev 160720 161021

h) Desplegado y procesamiento de alarmas y eventos.

i) Sincronización del sistema.

j) Registro de eventos y alarmas.

10.2.2.1 Pruebas de los programas de aplicación

a) Generación de informes periódicos automáticos por tiempo, por evento o por solicitud (Históricos de mediciones, demandas y operación de interruptores).

b) Prueba del sistema en condiciones de respaldo o contingencia para verificación del "hot stand-by" (en caso de falla de uno de los CPU´s).

c) Entrada del sistema de respaldo por falla principal y viceversa.

d) Falla puerto de comunicaciones, falla de la red.

e) Monitoreo de la UPS. 10.2.2.2 Bases de datos

a) Validar las transacciones a otras bases de datos relacionales.

b) Pruebas de configuración del sistema.

c) Configuración (capacidad y definición de puntos digitales de medición y control).

d) Edición de diagramas unificares.

e) Edición de circuitos sobre bases geográficas. f) Programación de funciones lógicas tipo PLC, edición y compilación.

10.2.2.3 Pruebas de rendimiento

a) Tiempos de actualización en pantalla de entradas digitales, mediciones y puntos calculados, tiempos de ejecución de control desde estación local o desde estación maestra.

b) Avalancha de eventos al 100 % de la capacidad total.

10.2.2.4 Verificación de autodiagnóstico

a) Simular fallas y verificar. b) Autodiagnóstico global, periféricos, redes y fuentes de alimentación. c) Informe de los diagnósticos.

10.2.2.5 Procedimiento a seguir en caso de fallas Cualquier falla que origine la suspensión de la prueba en curso, esta se debe reiniciar ésta desde el primer paso. En caso de una interrupción causada por una avería sólo se deben repetir las pruebas que involucren a la componente defectuosa. Al producirse una falla, se deben tomar las acciones siguientes:



110 de 154

120713 Rev 160720 161021

a) Suspensión de la prueba. b) Identificación y análisis de falla. c) Corrección de la falla.

El inspector de la CFE pueda requerir la repetición de la prueba completa de acuerdo a su criterio, determinado si la falla es crítica y es el resultado de un mal diseño. 10.3 Pruebas Prototipo al Servidor SCADA

10.3.1 Generalidades

Todo el equipamiento, local o remoto, que conforman los sistemas objeto de esta especificación, debe cumplir con lo establecido en la referencia [5] del capítulo 13 de esta especificación, además de los requerimientos específicos

establecidos en el presente documento. 10.3.1.1 Condiciones ambientales 10.3.2 Para equipos locales

Los equipos deben operar en forma continua bajo las siguientes condiciones ambientales:

a) Temperatura de operación +5 ºC a +40 ºC.

b) Variación de temperatura 10 ºC/h.

c) Humedad relativa 10-90 % sin condensación.

d) Altitud 0 m a 2 700 m.

10.3.3 Disipación de calor El proveedor debe indicar la disipación de calor en kcal/hr para cada uno de los equipos que componen el suministro.

10.3.4 Interferencia y compatibilidad electromagnética Los equipos no deben ser fuentes de emisiones radiadas que excedan 1V/m/MHz, medidas a un metro del gabinete de acuerdo a la norma mexicana NMX-I-240-NYCE-2000 la cual cumple con la norma internacional CISPR-22. 10.3.5 Protección contra descargas atmosféricas (lightning protection) Los equipos deben contar con los dispositivos de protección contra descargas atmosféricas en todos los elementos que forman el sistema de control, particularmente los elementos terminales y de acoplamiento de los cables físicos de datos que enlazan a la estación maestra con las estaciones de trabajo y los medios de comunicación. Los equipos electrónicos deben soportar las pruebas de aislamiento y de perturbación oscilatoria amortiguada a 1 MHz, que se estipulan en las normas IEC 60255-5 e IEC 60255-22-1. Adicionalmente todos los equipos electrónicos deben cumplir con lo estipulado en la norma IEC 61000 y en la norma IEC 60801 y soportar las pruebas de descarga electrostática y de perturbaciones de campos electromagnéticos radiados que se estipulan en las normas IEC 60255-22-2 e IEC 60255-22-3 respectivamente.



111 de 154

120713 Rev 160720 161021

Las alimentaciones de fuerza al equipo terminal deben incluir clavijas polarizadas para referencia de las tierras lógicas, además de contar con la tierra física del gabinete. La puesta en servicio del sistema son todas aquellas actividades para dejar en condiciones operativas comerciales a la UCM, considerando todos los protocolos de comunicaciones solicitados. Esto incluye: montaje, alambrado, ajustes y pruebas de aceptación en campo. Si la CFE decide ejecutar los trabajos de puesta en sitio y puesta en servicio, el proveedor debe tener un supervisor quien debe ser responsable de éstos trabajos. El proveedor debe de proporcionar el material requerido para la instalación y funcionamiento de la UCM. Si la CFE decide que el proveedor es el responsable de la puesta en sitio y puesta en servicio la supervisión, la mano de obra y los materiales deben ser proporcionados por el proveedor. Así mismo, si así lo solicita la CFE en Características Particulares, el proveedor debe realizar todas las actividades para el reemplazo y migración de un sistema existente al nuevo, incluyendo los ajustes y adecuaciones de los medios de comunicación existentes. Es responsabilidad del proveedor, el obtener de los fabricantes correspondientes, la información de los protocolos propietarios y las respectivas licencias. Durante esta etapa, la CFE dispondrá como mínimo de un residente quien la debe representar en estos trabajos. Las pruebas de aceptación en campo del sistema forman parte de este concepto. 10.4 Puesta en Sitio Durante la instalación, puesta en sitio y puesta en servicio del sistema, el proveedor debe realizar todas las actividades necesarias para su operación. Se deben incluir al menos las actividades siguientes:

a) Verificación de las instalaciones físicas del sitio de acuerdo a los documentos de ingeniería entregados por el proveedor.

b) Entrega del reporte del resultado de la verificación de las instalaciones físicas del sitio.

c) Instalación física e interconexión de todo el equipamiento del sistema.

d) Suministro e instalación de etiquetas de identificación de todo el equipo, así como del cableado.

e) Conexión, encendido del equipo y pruebas funcionales. 10.4.1 Puesta en servicio

a) Configuración del “hardware” y “software” de todos los dispositivos que forman la UCM. b) Configuración y verificación de las bases de datos.

c) Configuración y verificación de diagramas unifilares y pantallas.

d) Configuración y verificación de impresora.

e) Pruebas de validación de las bases de datos.

f) Pruebas operativas con simulador.

g) Pruebas de comunicación con los equipos de campo "estadísticas del sistema".



112 de 154

120713 Rev 160720 161021

h) Configuración y pruebas operativas con los equipos remotos instalados en las subestaciones y redes de distribución. Este punto debe incluir la configuración y prueba del 100 % de la base de datos configurada en los servidores SCADA.

i) Pruebas del servidor de históricos.

j) Pruebas del servidor de proyección.

k) Pruebas del servidor “web”.

l) Pruebas del “firewall” y niveles de seguridad y acceso.

m) Pruebas de redundancia en equipos de servidores de aplicaciones y redes.

n) Pruebas de redundancia de alimentación eléctrica.

En Características Particulares se debe indicar si la CFE requiere que el proveedor integre en la UCM la totalidad de la información geo-referenciada del sistema eléctrico, incluyendo los mapas con las calles, los recorridos de los alimentadores y todos los elementos de conexión y desconexión automatizados y manuales con los que cuenta en el sistema eléctrico. Todo esto además de lo incluido en los diagramas unifilares de cada una de las subestaciones del sistema. 10.4.2 Puesta en servicio del sistema La puesta en servicio del sistema, es aquella etapa en donde el personal operativo de la CFE efectúa conjuntamente con el proveedor, las pruebas definitivas necesarias para garantizar la confiabilidad operativa del sistema y así proceder a su puesta en operación. La puesta en servicio se considera concluida con la entrada en operación del sistema. 11 MARCADO No aplica.

12 EMPAQUE, EMBALAJE, EMBARQUE, TRANSPORTACIÓN, DESCARGA, RECEPCIÓN, ALMACENAJE Y MANEJO

Debe cumplir con lo indicado en la especificación CFE L0000-11 Si así lo solicita CFE en Características Particulares, las actividades de instalación, puesta en sitio y puesta en servicio son responsabilidad del proveedor. 13 BIBLIOGRAFÍA [1] NERC (CIP002 a CIP009) Estándar de Protección de Infraestructura Crítica [2] Norma IEEE 1003.X, POSIX 1003.4. A y B. [3] ISO, IEEE 802.x, EIA/TIA-x, ANSI X3T9.5FDDI). [4] IEEE 802.X (ISO 8802X)



113 de 154

120713 Rev 160720 161021

[5] ANSI C37-1-2007 Standard Definition, Specification, and Analysis of Systems Used for Supervisory

Control, Data Adquisition, and Automatic Control. [6] NEMA Standards Publication 250-2003, “Enclosures for Electrical Equipment (1000 Volts Maximum)”.

14 CARACTERÍSTICAS PARTICULARES Las Características Particulares que la CFE debe proporcionar al solicitar Unidades Centrales Maestras para Centros de Control son las contenidas en la forma CPE-474, anexa a esta especificación.



114 de 154

120713 Rev 160720 161021

APÉNDICE A (Obligatorio)

PERFIL MÍNIMO REQUERIDO DEL PROTOCOLO DNP3

A.1 DOCUMENTO DE PERFIL DEL DISPOSITIVO DNP3 PARA CFE

Este documento expone las capacidades mínimas en la implementación DNP3 modo maestro para la unidad central

maestra.

A menos que se indique lo contrario, en las tablas A.1.1 a A.1.6, las múltiples casillas en la segunda columna se

deben seleccionar para cada parámetro e indicar las capacidades o requerimientos. Los parámetros no marcados en

las casillas de la segunda columna no tienen las capacidades e incluyen el valor actual que debe ser mostrado en la

tercera columna.

Los objetos listados en las capacidades de las columnas deben ser configurables en cualesquiera de las opciones

seleccionadas o ajustarse a valores fijos cuando el dispositivo es diseñado. Ya que algunos parámetros no pueden

acceder por cada uno de los métodos soportados, una abreviación para la configuración de los métodos soportados

por cada parámetro debe ser mostrada en la cuarta columna de la siguiente tabla.

Este documento debe ser usado para mostrar las capacidades de los dispositivos, los valores actuales de cada

parámetro o ambos. Si esto es usado para mostrar los valores actuales, se debe definir en la tercera columna aún si

un parámetro fijo es seleccionado en la sección de capacidades No Aplica (NA) debe ser utilizado para parámetros

que no son aplicables).

Si este documento es usado para mostrar los valores actuales de cada parámetro, la columna “valor actual” aplica una

sola conexión entre la maestra y la conexión remota.

Si el dispositivo tiene múltiples conexiones de respaldo hacia otros dispositivos DNP y se desea mostrar en el

documento de perfil del dispositivo, duplique el documento completo de perfil del dispositivo para cada enlace de

comunicación hacia un dispositivo DNP 3 físico o lógico.

Las primeras dos columnas son las que fueron llenadas con la información del requerimiento.

UNIDADES CENTRALES MAESTRAS PARA CENTROS DE CONTROL DE DISTRIBUCIÓN Y TRANSMISIÓN ESPECIFICACIÓN

CFE G0100-14

115 de 154

120713 Rev 161021

TABLA A.1.1 – Propiedades del dispositivo

Identificación del dispositivo Capacidades Valor Actual

Si es

configurable,

listar los

métodos

Función del Dispositivo:

Las Maestras envían peticiones DNP, mientras las

remotas envían respuestas DNP. Si un dispositivo

físico puede realizar ambas funciones, un

Documento del Perfil de Dispositivo deber ser

proporcionado para cada función por separado.

- Maestro

- Estación Remota

- Maestro

- Estación Remota

--

Nombre del Proveedor:

El nombre de la organización que produce el

dispositivo. (En este caso es el requerimiento de

CFE).

--

-- --

Nombre del Dispositivo:

El modelo y el nombre del dispositivo, suficiente

para distinguirlo de cualquier otro dispositivo de la

misma organización.

--

Requerimiento de CFE

para Unidades Centrales

Maestras en Centros de

Control del CENACE

conforme a la

Especificación G0100-14

--

Continúa…


CFE G0100-14

116 de 154

120713 Rev 161021

…continuación

Versión de “hardware” del dispositivo del fabricante: -- -- --

Versión de “software” del dispositivo del fabricante: -- -- --

Número de la Versión del Documento del Perfil del

Dispositivo:

La Versión del Documento del Perfil del Dispositivo se indica mediante un número entero y se

incrementa con cada nueva versión. Esto debe coincidir con la versión más reciente que se muestra

en el historial de revisión al principio de este documento.

--

-- --

Niveles de DNP soportado para:

Indica cada nivel del DNP3 para el cual el dispositivo cumple totalmente. Para dispositivos maestros, las

solicitudes y respuestas se pueden ser independientemente.

Solamente Maestros Solicitudes Respuestas

Ninguna

Nivel 1

Nivel 2

Nivel 3 Solamente Remotas Solicitudes y Respuestas

Ninguna

Nivel 1

Nivel 2

Nivel 3

-- --

Continúa…


CFE G0100-14

117 de 154

120713 Rev 161021

…Continuación

Bloques de Funciones Soportados:

Reservación para Direcciones propias

Objeto 0 – Atributo de objetos

Conjunto de Datos

Transferencia de Archivos

Terminal Virtual

Mapeo de objetos a los modelos IEC 61850 definido en un archivo XML DNP3

Código de Función 31, configuración de activación

-- --

Características Adicionales:

Una breve descripción para que el lector pueda identificar rápidamente las características más

evidentes que el dispositivo soporta además del más alto nivel de DNP soportados. La lista completa de

características está descrita en las tablas de Implementación.

-- -- --

Métodos para ajustar los parámetros configurables:

XML – Carga de archivos de Transferencia vía DNP3

XML – Carga vía otros mecanismos de transportes

Terminal – Terminal de línea de comando ASCII

“software” – “software” del fabricante llamado _______

Carga de archivos propietario vía transferencia de archivo DNP3

Carga de archivos propietario vía otros mecanismos de transporte

Directo – Teclado en panel frontal del dispositivo

Fábrica – Especificado cuando el dispositivo es ordenado

Protocolo – Ajuste vía DNP3 (ej. Asignación de clases)

Otra – explicar _______________________

-- --

Continúa…


CFE G0100-14

118 de 154

120713 Rev 161021

…Continuación

Archivos DNP3 XML disponibles en línea: Los nombres de los archivos de configuración XML que pueden ser leídos o escritos a través de los archivos de transferencia DNP3 hacia el dispositivo. La configuración que actualmente se está ejecutando en el dispositivo es devuelto a través de un archivo de lectura XML por DNP3 desde el dispositivo en comunicación. El archivo de escritura XML que debe actualizar la configuración del dispositivo cuando la Configuración Activa (Código de Función 31) sea recibida por DNP3 desde el dispositivo en comunicación.

Rd Wr Nombre del Archivo Descripción de Contenidos dnpDP.xml Perfil del dispositivo Completo

dnpDPcap.xml Perfil de las Capacidades del dispositivo

dnpDPcfg.xml Perfil de los valores de configuración del Dispositivo

_______*.xml ___________________ * El Documento completo del perfil del dispositivo contiene las capacidades, valores actuales y columnas de los métodos de configuración. * Las Capacidades del perfil del dispositivo contiene solo las capacidades y las columnas de los métodos de configuración. * La configuración del perfil del dispositivo. Contiene valores solo de la columna del valor actual.

-- --

Continúa…


CFE G0100-14

119 de 154

120713 Rev 161021

…Continuación

Archivos externos DNP3 XML disponibles fuera de línea: Los nombres de los archivos de configuración XML que pueden ser leídos o escritos desde un sistema externo, típicamente desde un sistema que mantiene la configuración de la remota. Los archivos de lectura externos XML, sin comunicación, permite una definición XML de la nueva configuración a suministrar desde las herramientas de configuración mientras esta sin comunicación. Los archivos de escritura externos XML, sin comunicación, permite una definición XML de una nueva configuración a suministrar desde las herramientas de configuración mientras esta sin comunicación.

Rd Wr Nombre de archivo Descripción del contenido

dnpDP.xml Perfil Completo del Dispositivo

dnpDPcap.xml Perfil de las Capacidades del Dispositivo

dnpDPcfg.xml Perfil del Dispositivo de los Valores de Configuración

_______*.xml ___________________ * El Documento completo del perfil del dispositivo contiene las capacidades, valores actuales y las columnas de los métodos de configuración. * Las Capacidades del perfil del dispositivo contiene solo las capacidades y las columnas de los métodos de configuración. * La configuración del perfil del dispositivo. Contiene valores solo de la columna del valor actual.

-- --

Conexiones Soportadas:

Serial (Sección Completa)

IP Networking (Sección Completa 0)

Otra, explique________________________

-- --


CFE G0100-14

120 de 154

120713 Rev 161021

TABLA A.1.2 – Conexiones seriales

Conexiones seriales Capacidades Valor Actual

Si es configurable

listar los métodos

Nombre del Puerto

Nombre usado para referenciar el puerto de

comunicación definido en esta sección.

COM o /dev/tty

-- --

Parámetros de Conexión Serial:

Asíncrono - 8 Bits de datos, 1 Bit de arranque, 1 Bit de paro, Paridad Ninguna

Otro,explique___________________________

-- --

Baud Rate:

Configurado a _______

Configurable, rango _______ a _______ Configurable, seleccionado desde_9 600, 19 200, 38 400, 57 600

Configurable, otro, describir_______________

-- --

Continúa…


CFE G0100-14

121 de 154

120713 Rev 161021

…Continuación

Control de flujo del “hardware” (Handshaking):

Describe los requerimientos de señalización del “hardware” de la interface.

Cuando un transmisor o receptor es inhibido hasta

que una señal de control dada es activada, se considera que es necesaria la señal antes de enviar

o recibir caracteres.

Cuando una señal se activa previamente a la transmisión, esa señal se debe mantener activa

hasta después de finalizar la transmisión.

Cuando una señal se activa para habilitar la recepción, cualquier dato enviado hacia al

dispositivo, cuando la señal no está activa puede ser descartado.

Opciones RS-232 / V.24 / V.28: Antes de Tx, Validado: Antes de Rx, Validado Siempre validado: Antes de Tx, Requiere: Validado No Validado CTS DCD DSR RI Antes de Rx, Requiere: Validado No Validado CTS DCD DSR RI Siempre Ignora:

-- --

Continua…


CFE G0100-14

122 de 154

120713 Rev 161021

…Continuación

Permitir habilitar/deshabilitar la funcionalidad de las lineas RTS, CTS, DCD de manera independiente. Permitir configurar los tiempos de pre-transmisión y post-transmisión en milisegundos, con un rango en 0 mseg y 10 000 mseg. Permitir configurar el timeout de espera por las líneas CTS y DCD en milisegundos con un rango de 10 mseg a 10 000 mseg.____________ RS-422 / V.11 Opciones:

RS-485 Opciones :

Otro, explique ____________

-- --

Intervalo para Solicitar el Estado del Enlace: Indica que tan frecuente envía la solicitud del estado de la Capa del Enlace de Datos sobre una conexión serial. Este parámetro es independiente del temporizador TCP Keep-alive.

No se Admite

Fijo en_________ segundos

Configurable, intervalo _____ a ______ segundos

Configurable, seleccionable en ___,___,___segundos

Configurable, otro, describir________________

-- --

Continúa…


CFE G0100-14

123 de 154

120713 Rev 161021

…Continuación

Soporta Anti colisiones DNP3 Indica si un dispositivo utiliza un algoritmo anticolisiones. La documentación del proveedor debe proporcionar información sobre el esquema anticolisiones.

No

Si, explicar ________________________ -- --

Receptor de Tiempo de espera Entre-caracteres: Cuando la interface serial con tramas de caracteres asíncronas es usada, este parámetro indica si el receptor hace una verificación para intervalos entre caracteres (ej. extensión de tiempo del bit de parada de un caracter anterior del bit de inicio de los siguientes caracteres dentro de un mensaje). Si el receptor realiza esta comprobación y el tiempo de espera es excedido entonces el receptor descarta la trama de enlace de datos actual. Un receptor que no descarta tramas de enlace de datos en base a los espacios entre caracteres es considerado para no desarrollar esta verificación. Cuando no es configurada la interface serial asíncrona, este parámetro no es aplicable. En este caso ninguna de las opciones debe ser seleccionada.

Sin Activar

Ningun espacio permitido

Fijo en _____ veces el bit

Fijo en _____ ms

Configurable, de ____ a ____ veces el bit

Configurable, de ____ a ____ ms

Configurable, Seleccionable desde ___,___,___veces el bit

Configurable, Seleccionable desde ____, ____, ____ ms

Configurable, otro, describir __________________

Variable, explicar ____

-- --

Continúa…


CFE G0100-14

124 de 154

120713 Rev 161021

…Continuación

Intervalos entre caracteres en transmisión Cuando la interfaces serial con trama de caracteres asíncronos son usadas, este parámetro indica si el retardo extra es aún introducido entre caracteres en el mensaje, y si es así, la máxima amplitud de los intervalos. Cuando las interfaces seriales asíncronas no son configuradas, este parámetro no es aplicable. En este caso ninguno de las opciones deben ser seleccionada.

pacio

entre-caracter)

NOTA: 1. Que la UCM pueda solicitar el Objeto 0 con objetos atributo y que genere reporte con la información obtenida, depositándolo en el sistema local. 2. Que la UCM pueda solicitar el archivo XML mediante el objeto File Transfer y lo deposite en el sistema local.


CFE G0100-14

125 de 154

120713 Rev 161021

TABLA A.1.3 – Redes IP

Redes IP Capacidades Valor Actual

Si es configurable,

listar los métodos

Nombre del Puerto

Nombre que se utiliza para hacer referencia al puerto

de comunicación referidos en esta seción.

RJ45

-- --

Tipo de Puerto:

TCP Iniciando (Solo Maestra) TCP De Escucha (Estación Remota Solamente) TCP Doble (necesario para Maestras) UDP Datagrama (se requiere)

(lista de todos los activos) --

Dirección IP de este Dispositivo:

-- -- --

Máscara de Subred:

-- -- --

Dirección Gateway:

-- -- --

Acepta Conexiones TCP o Datagramas UDP de:

Permiten todos (mostrar cómo *.*.*.* in 0)

Limites basados en una dirección IP Limites basados en una lista de direcciones IP

Limites basados en una dirección IP comodín

Limites basados en una lista de direcciones IP comodines

Otra validación, explicar_________________

-- --

Las direcciones IP a partir de conexiones TCP o

datagramas UDP son aceptadas:

-- -- --

Continúa…


CFE G0100-14

126 de 154

120713 Rev 161021

…Continuación

Puerto de escucha TCP:

Si la remota o la maestra con doble puerto, número de puerto sobre el cual escucha las solicitudes de

conexión entrantes por TCP. Requiere ser configurable para Maestras y se recomienda ser

configurable para Remotas.

No Aplicable (Maestra con/sin punto final dual)

Fijo en 20 000 Configurable, rango 5 000 a 100 000

Configurable, seleccionable desde ____,____,____

Configurable, otro, describir ________________

-- --

Número de puerto de escucha del dispositivo remoto:

Si la Maestra o remota con doble puerto, el número de puerto en el dispositivo remoto con el cual inicia la conexión. Requerida para ser configurable por

Maestras y se recomienda ser configurable por las Remotas.

No Aplicable (Estación Remota con/sin doble punto final)

Fijo en 20 000

Configurable, rango 5 000 a 100 000

Configurable, seleccionable desde ____,____,____


-- --

Temporizador TCP Keep-alive

El periodo de tiempo para el temporizador Keep.alive en las conexiones activas TCP.

Fijo en ___________ ms

Configurable, rango 60 000 (1 min) a 36 000 000 ms (10 h)

Configurable, seleccionable de ____,____,____ms


-- --

Puerto Local UDP:

Puerto Local UDP para el envío o recepción de datagramas UDP. La Maestra puede permitir al

sistema elegir un puerto disponible. La Remota debe utilizar uno que sea conocido por la Maestra.

Fijo en 20 000

Configurable, rango 5 000 a 100 000

Configurable, seleccionable de ____,____,____

Configurable, otro, describir _______________

Dejar que el sistema elija (solo Maestra)

-- --

Puerto UDP Destino para solicitudes DNP3 (solo Maestra):

-- -- --

Continúa…


CFE G0100-14

127 de 154

120713 Rev 161021

…Continuación

Puerto UDP Destino para iniciar respuestas no

solicitadas (UDP solo Remotas):

Solo para una Estación Remota, el puerto UDP Destino para el envío inicial de las respuestas no

solicitadas.

Ninguno

Fijo en 20 000

Configurable, rango _______ a _______



-- --

Puerto UDP Destino para respuestas:

Para una Remota UDP, el puerto UDP Destino para el envío de todas las respuestas que no sean la

inicial de las respuestas no solicitadas.

Ninguno

Fijo en 20 000

Configurable, rango _______ a _______



Utilizar el número de puerto de origen

-- --

Multiples Conexiones de Remota (Solo Maestra):

Solo maestra. Indica si son soportadas las conexiones múltiples de la Remota.

Soporta múltiples estaciones Remotas (solo

Maestras) -- --

Multiples conexiones de Maestra (Solo Remota):

Solo Remota. Indica si las múltiples conexiones de las maestras son soportadas y los métodos que

pueden ser usados para establecer las conexiones.

Soporta múltiples maestras (Solo Estaciones Remotas) Si soporta, los siguientes métodos pueden ser usados:

Método 1 (según la dirección IP) - requerido

Método 2 (basado en el número de puerto IP) - recomendado

Método 3 (búsqueda de datos estáticos) – opcional

-- --

Tiempo se sincronización soportado:

Nota: Tiempo de escritura DNP3 para comunicación serial.

DNP3 LAN procedimiento (código de función 24)

DNP3 escribir tiempo (no se recomienda a través de LAN)

Otro, explicar _________________________

No Soportado

-- --


CFE G0100-14

128 de 154

120713 Rev 161021

TABLA A.1.4 – Capa de enlace

Capa de enlace Capacidades Valor Actual

Si es configurable, enlistar los métodos

Datos de la Dirección de Enlace:

Indica si la dirección de enlace es configurable en todo el rango válido de 0 a 65 519. La Dirección de

los datos de Enlace 0xFFF0 a través de 0xFFFF están reservados para la transmisión o para otros

propósitos especiales.

Fijo en ____________

Configurable, intervalo de 0 a 5 535


Configurable, otro, describir ________________ -- --

Validación de la Dirección Origen DNP3

Indica si el dispositivo filtrará los mensajes externos que no provengan de una dirección específica.

Nunca

Siempre, una dirección permitida

Siempre, cualquiera de las multiples direcciones permitidas

Algunas veces, explicar________________

-- --

Dirección (es) Origen DNP3 esperadas cuando la validación es habilitada.

Seleccione la dirección(es) Origen permitida.

Nota: La UCM debe validar la dirección esperada de la UTR en

las respuestas, según la configuración de la UCM.

Configurable para cualquier valor de 16 bit DNP Dirección de Enlace de Datos

Configurable, intervalo de _______ a _______



-- --

Continúa…


CFE G0100-14

129 de 154

120713 Rev 161021

…Continuación

Auto diagnóstico de direcciones utilizando

direcciones 0xFFFC.

Si una remota recibe un mensaje con una dirección destino de 0xFFFC este debe responder

normalmente con su propia dirección Origen. Debe ser posible desactivar la característica si es

compatible.

Si (solo se permite si es configurable)

No

-- --

Envío Confirmado de Trama de Datos de Usuario:

Una lista de condiciones bajo las cuales el dispositivo transmite la confirmación de los servicios

de capa de enlace (TEST_LINK_STATES, RESET_LINK_STATES,

CONFIRMED_USER_DATA).

Siempre

Algunas veces, explicar _Configurable__________

Nunca -- --

Confirmación del Tiempo de Espera de la Capa de Enlace de Datos:

Este tiempo de espera se aplica a cualquier mensaje

secundario de la capa de datos que requiere una confirmación o respuesta (link reset, link status, user

data, entre otros)

Ninguna

Fijo en ______ ms

Configurable, intervalo de 100 a 60 000 ms

Configurable, seleccionable de ___,___,___ ms


Variable, explicar _______________________

-- --

Reintentos Máximos del Enlace de Datos:

El número de veces que el dispositivo retransmitirá una trama que solicite la confirmación de la Capa de

Enlace.

Nunca Reintentos

Fijo en ___________

Configurable, intervalo de 0 a 10


Configurable, otro, describir ______________

-- --

Máximo número de octetos Transmitidos en una Trama de Enlace de Datos:

Esta número incluye a los CRCs. Con un campo de longitud de 255, el tamaño máximo podría ser 292.

Fijo en ___________

Configurable, intervalo 1 a 292



Continúa…


CFE G0100-14

130 de 154

120713 Rev 161021

…continuación

Número máximo de octetos que pueden ser Recibidos en una Trama de Enlace de Datos:

Esta cifra incluye a los CRCs. Con un campo de

longitud de 255, el tamaño máximo podría ser 292. El dispositivo debe ser capaz de recibir 292 octetos

para ser aceptado.

Fijo en 292

Configurable, intervalo de ________ a ______



TABLA A.1.5 – Capa de aplicación

Capa de aplicación Capacidades Valor actual


Máximo número de octetos Transmitidos en un Fragmento de la Capa de Aplicación que no sea de Transferencia de Archivos: Este tamaño no incluye ningún transporte o trama de octetos. Maestras deben proporcionar un ajuste menor o igual a 249. Remotas deben proporcionar un ajuste menor o igual a 2 048.

Fijo en ___________

Configurable, intervalo de 1 a 249



-- --

Número máximo de octetos Transmitidos en un fragmento de la Capa de Aplicación conteniendo un Archivo de Transferencia.

Fijo en ___________

Configurable, intervalo de 1 a 2 048



-- --

Continúa…


CFE G0100-14

131 de 154

120713 Rev 161021

…Continuación

Número máximo de octetos que se pueden ser recibidos en un fragmento de Capa de Aplicación: Este tamaño no incluye ningún transporte o trama de octetos. Las Maestras deben proporcionar un valor mayor o igual a 2 048. Las Remotas deben proporcionar un valor mayor o igual a 249.

Fijo en ___2048________

Configurable, intervalo de ________ a _______



-- --

Tiempo de Espera para el Fragmento Completo de la Capa de Aplicación: Tiempo de Espera si todas las tramas de un fragmento de mensaje no son recibidos en el tiempo especificado. Medición del tiempo desde que se recibe la primera trama de un fragmento hasta que la última trama es recibida.

Ninguno

Fijo en ______ ms

Configurable, intervalo de 1 000 a 600 000 ms




-- --

Número máximo de objetos permitidos en una solicitud de control única para CROB (grupo 12):

Fijo en 1 (escriba 0 si los controles no son compatibles)

Configurable, intervalo de _________ a _______




-- --

Número máximo de objetos permitidos en una solicitud de control única para Salidas Analógicas (grupo 41):


Configurable, intervalo de _______ a _________




-- --

Continua…


CFE G0100-14

132 de 154

120713 Rev 161021

…Continuación

Número máximo de objetos permitidos en una solicitud de control única para Ajustes de Datos (grupos 85,86,87):






-- --

Admite el uso de grupos de objetos (AOBs, CROBs and Data Sets) en la misma solicitud de control.

No se aplica – los controles no son compatibles

Si

No

TABLA A.1.6 Solo para Maestras

Llene los siguientes partidas solamente para Maestras

Capacidades Valor Actual


Tiempo de Espera para la Respuesta Completa de la Capa de Aplicación (ms): Tiempo de espera en la Maestra si todos los fragmentos de un mensaje de respuesta no son recibidos en el tiempo especificado.

Ninguno

Fijo en ______ ms


Configurable, seleccionable de ___,___,___ms



Reintentos máximos de la Capa de Aplicación para los mensajes solicitados: El número de veces que la Maestra debe retransmitir un mensaje solicitado por la capa de aplicación si una respuesta no es recibida. Este parámetro nunca debe causar que la Maestra retransmita mensajes de control o sincronización de tiempo. Las Remotas nunca deben transmitir reintentos.

Ninguna (se requiere)

Fijo en _________


Configurable, seleccionable de ___,___,___



Continua…


CFE G0100-14

133 de 154

120713 Rev 161021

…Continuación

Tiempo de espera incremental para el primer o siguiente fragmento de una respuesta de la Capa de Aplicación.

Ninguno

Fijo en ______ ms







134 de 154

120713 Rev 160720 161021

A.2 TABLA DE IMPLEMENTACIÓN

La siguientes tablas de implementación identifican cuales grupos de objetos y variantes, códigos de función y

calificadores que el dispositivo soporta tanto en solicitudes como respuestas. La columna de solicitud identifica todas

las solicitudes que puedan ser enviadas por la Maestra o todas las solicitudes que deben ser analizadas por una

Remota.

La columna de respuesta identifica todas las respuestas que deben ser analizadas por la Maestra o todas las

respuestas que pueden ser enviadas por una Remota.

NOTA: La tabla de implementación debe incluir toda la funcionalidad requerida por el dispositivo sea maestra o estación remota tal como se define el Procedimientos Pruebas de Conformidad DNP3 IED. Cualquier funcionalidad más allá del más alto nivel de subgrupo soportado es indicado en los renglones remarcados. Cualquier grupo de objetos no previsto por una estación remota o no procesado por una maestra se indica con una tachadura (tenga en cuenta que estos grupos de objetos todavía debe ser analizado).

Continua…

GRUPO DE OBJETO Y VARIACION DEL DNP

SOLICITUD La Maestra puede emitir

instrucción La UTR debe analizar

RESPUESTA La Maestra debe analizar

La UTR puede emitir instrucción

Num. Grupo

Num. Varia

Descripción

Códigos de

Función (dec)

Códigos de Calificador

(hex)

Códigos de

Función (dec)


(hex)

0 211 Atributos de dispositivo –Identificador de soporte de usuario-Atributos específicos

1(lectura) 00 (inicio-paro) 129

(respuesta)

00 (inicio-paro) 17 (índice)

0 212 Atributos de dispositivo –Número de maestra-Prototipo de ajustes de datos definidos


(respuesta)


0 213 Atributos de dispositivo –Número de Remota-Prototipo de ajustes de datos definidos


(respuesta)


0 214 Atributos de dispositivos –Número de maestra-Ajustes de datos definidos


(respuesta)


0 215 Atributos de Dispositivos –Número de remota-Ajustes de datos definidos


(respuesta)


0 216 Atributos de dispositivos –Número máximo de salidas binarias por solicitud


(respuesta)


0 217 Atributos de dispositivo –Tiempo de precisión local 1(lectura) 00 (inicio-paro) 129

(respuesta)


0 218 Atributos de dispositivo -Duración del tiempo de precisión


(respuesta)


0 219 Atributos de dispositivo -Suporte para eventos de salida analógica


(respuesta)


0 220 Atributos de dispositivo –Máximo índice de salidas analógicas


(respuesta)


0 221 Atributos de dispositivo –Número de salidas analógicas 1(lectura) 00 (inicio-paro) 129

(respuesta)


0 222 Atributos de dispositivo –Soporte para eventos de salidas binarias


(respuesta)


0 223 Atributos de dispositivo –Máximo índice de salida binaria


(respuesta)


0 224 Atributos de dispositivo –Número de salidas binarias 1(lectura) 00 (inicio-paro) 129

(respuesta)


0 225 Atributos de dispositivo –Soporte para eventos de contadores congelados


(respuesta)


0 226 Atributos de dispositivo –Soporte para contadores congelados


(respuesta)


0 227 Atributos de dispositivo –Soporte para eventos de contador


(respuesta)


0 228 Atributos de dispositivo –Máximo índice de contador 1(lectura) 00 (inicio-paro) 129

(respuesta)




135 de 154

120713 Rev 160720 161021

…Continuación

Continua…

0 229 Atributos de dispositivo –Número de contador de puntos


(respuesta)


0 230 Atributos de dispositivo -Support for frozen analog inputs


(respuesta)


0 231 Atributos de dispositivo –Soporte para eventos de entradas analógicas


(respuesta)


0 232 Atributos de dispositivo –Máximo índice de entradas analógicas


(respuesta)


0 233 Atributos de dispositivo –Número de puntos de entradas analógicas


(respuesta)



SOLICITUD La Maestra puede emitir

instrucción La UTR debe analizar

RESPUESTA La Maestra debe analizar


Num. Grupo

Num. Variac

Descripción

Códigos de

Función (dec)


(hex)

Códigos de Función

(dec)


(hex)

0 234 Atributos de dispositivo –Soporte para eventos de entrada de doble bit binario


(respuesta)

00 (inicio-paro)

17 (índice)

0 235 Atributos de dispositivo –Máximo índice de entrada de doble bit binario


(respuesta)

00 (inicio-paro)

17 (índice)

0 236 Atributos de dispositivo –Número de puntos de entrada de doble bit binario


(respuesta)

00 (inicio-paro)

17 (índice)

0 237 Atributos de dispositivo –Soporte para eventos de entradas binarias


(respuesta)

00 (inicio-paro)

17 (índice)

0 238 Atributos de dispositivo –Máximo índice de entradas binaria


(respuesta)

00 (inicio-paro)

17 (índice)

0 239 Atributos de dispositivo –Número de puntos de entradas binarias


(respuesta)

00 (inicio-paro)

17 (índice)

0 240

Atributos de dispositivo –Máximo tamaño de fragmentos transmitidos


(respuesta)

00 (inicio-paro)

17 (índice)


(respuesta)

00 (inicio-paro)

17 (índice)

0 241 Atributos de dispositivo –Máximo tamaño de fragmentos recibidos


(respuesta)

00 (inicio-paro)

17 (índice)

0 242 Atributos de dispositivo – Versión del “software” del dispositivo fabricado


(respuesta)

00 (inicio-paro)

17 (índice)

0 243 Atributos de dispositivo – Versión del “hardware” del dispositivo fabricado


(respuesta)

00 (inicio-paro)

17 (índice)

0 245

Atributos de dispositivo -Usuario-Nombre de ubicación asignado


(respuesta)

00 (inicio-paro)

17 (índice)


(respuesta)

00 (inicio-paro)

17 (índice)

0 246

Atributos de dispositivo – Código id asignado al usuario/Número


(respuesta)

00 (inicio-paro)

17 (índice)


(respuesta)

00 (inicio-paro)

17 (índice)



136 de 154

120713 Rev 160720 161021

…Continuación

0 247

Atributos de dispositivo -Usuario-Nombre de dispositivo asignado


(respuesta)

00 (inicio-paro)

17 (índice)


(respuesta)

00 (inicio-paro)

17 (índice)

0 248 Atributos de dispositivo – Número serial del dispositivo 1(lectura) 00 (inicio-paro) 129

(respuesta)

00 (inicio-paro)

17 (índice)

0 249 Atributos de dispositivo – DNP subset and conformance 1(lectura) 00 (inicio-paro) 129

(respuesta)

00 (inicio-paro)

17 (índice)

0 250 Atributos de dispositivo – Device manufacturer’s product name and model


(respuesta)

00 (inicio-paro)

17 (índice)

0 252 Atributos de dispositivo – Device manufacturer’s name 1(lectura) 00 (inicio-paro) 129

(respuesta)

00 (inicio-paro)

17 (índice)

0 254 Atributos de dispositivo – Non-specific all attributes

request 1(lectura)

00 (inicio-paro)

06 (no range, or

all)

-- --

0 255

Atributos de dispositivo - List of attribute variations 1(lectura)

00 (inicio-paro)

06 (no range, or

all)

129 (respuesta)

00 (inicio-paro)

5B (format libre)



137 de 154

120713 Rev 160720 161021

Numero

de Grupo

Numero

de

Variaciòn

DescripciónCodigos de Función

(dec)

Codigos de Clasificación

(hex)

RESPUESTA

La Maestra debe

analizar

La UTR puede emitir

Codigos de Clasificación

(hex)

1 0 Entrada Binaria - Cualquier Variaciòn 1 (leer)

22 (asignaciòn de clase)

00, 01 (iniciar - detener)

06 (sin alcance o todo)

1 1 Entrada Binaria - Formato Comprimido 1 (leer)00, 01 (iniciar - detener)

06 (sin alcance o todo) 129 (respuesta) 00, 01 (iniciar - detener)

1 2 Entrada Binaria - Con banderas 1 (leer)00, 01 (iniciar - detener)


2 0 Evento de Entrada Binaria - Cualquier Variaciòn 1 (leer)06 (sin alcance o todo)

07, 08 (calidad limitada)

2 1 Evento de Entrada Binaria - Sin Tiempo 1 (leer)06 (sin alcance o todo)


129 (respuesta)

130 (respuesta sin resolver)17, 28 (indice)

2 2 Evento de Entrada Binaria - Con tiempo absoluto 1 (leer)06 (sin alcance o todo)


129 (respuesta)


2 3 Evento de Entrada Binaria - Con tiempo relativo 1 (leer)06 (sin alcance o todo)


129 (respuesta)


10 0 Salida Binaria - Cualquier Variaciòn 1 (leer)00, 01 (iniciar - detener)


10 2 Salida Binaria - Estado de Salida con banderas 1 (leer)00, 01 (iniciar - detener)


12 1 Comando Binario - Bloque de salida del relevador de control

3 (seleccionar)

4 ( operar)

5 (operaciòn directa)

6 (operaciòn directa sin

reconocimiento)

17, 28 (indice) 129 (respuesta) repeticiòn de solicitud

20 0 Contador - Cualquier Variaciòn

1 (leer)

7 ( bloqueado)

8 (bloqueado

sin reconocimiento)

9 (quitar bloqueado)

10 ( quitar bloqueado sin

reconocimiento)



20 1 Contador - 32 bits con bandera 1 (leer)00, 01 (iniciar - detener)


20 2 Contador - 16 bits con bandera 1 (leer)00, 01 (iniciar - detener)


20 5 Contador - 32 bits sin bandera 1 (leer)00, 01 (iniciar - detener)


20 6 Contador - 16 bits sin bandera 1 (leer)00, 01 (iniciar - detener)


21 0 Contador bloqueado - Cualquier Variaciòn1 (leer)




21 1 Contador bloqueado - 32 bits con bandera 1 (leer)00, 01 (iniciar - detener)


21 2 Contador bloqueado - 16 bits con bandera 1 (leer)00, 01 (iniciar - detener)


21 9 Contador bloqueado - 32 bits sin bandera 1 (leer)00, 01 (iniciar - detener)


21 10 Contador bloqueado - 16 bits sin bandera 1 (leer)00, 01 (iniciar - detener)


22 0 Evento del contador - Cualquier Variaciòn 1 (leer)06 (sin alcance o todo)



SOLICITUD

La Maestra puede emitir instrucción

La UTR debe analizar

RESPUESTA

La Maestra debe analizar




138 de 154

120713 Rev 160720 161021

Numero

de

Grupo

Numero

de

Variaciò

DescripciònCódigos de Función

(dec)

Códigos de Clasificación

(hex)

Códigos de Función

(dec)

Codigos de Clasificaciòn

(hex)

0 211Dispositivo atributo - Identificador de soporte para usuarios de

atributos específicos1 (leer)



129 (respuesta)


0 212Dispositivo atributo - Identificador de soporte para usuarios de

atributos específicos 1 (leer)06 (sin alcance o todo)


129 (respuesta)


0 213 Evento del Contador Bloqueado - Cualquier Variaciòn1 (leer)



0 214 Evento del Contador Bloqueado - 32 bits con bandera1 (leer)



129 (respuesta)


0 215 Evento del Contador Bloqueado - 16 bits con bandera 1 (leer)06 (sin alcance o todo)


129 (respuesta)


30 0 Entrada Analogica - Cualquier Variaciòn1 (leer)




30 1 Entrada Analogica - 32 bits con bandera1 (leer)



30 2 Entrada Analogica - 16 bits con bandera1 (leer)



30 3 Entrada Analogica - 32 bits sin bandera1 (leer)



30 4 Entrada Analogica - 16 bits sin bandera 1 (leer)00, 01 (iniciar - detener)


32 0 Evento de Entrada Analogica - Cualquier Variaciòn 1 (leer)06 (sin alcance o todo)


32 1 Evento de Entrada Analogica -32 bits sin tiempo 1 (leer)06 (sin alcance o todo)


129 (respuesta)


32 2 Evento de Entrada Analogica - 16 bits sin tiempo 1 (leer)06 (sin alcance o todo)


129 (respuesta)


40 0 Estado de Salida Analogica - Cualquier Variaciòn 1 (leer)00, 01 (iniciar - detener)


40 1 Estado de Salida Analogica - 32 bits con bandera 1 (leer)00, 01 (iniciar - detener)


40 2 Estado de Salida Analogica - 16 bits con bandera 1 (leer)00, 01 (iniciar - detener)


41 1 Salida Analogica - 32 bits

3 (seleccionar)

4 ( operar)



reconocimiento)


41 2 Salida Analogica - 16 bits

3 (seleccionar)

4 ( operar)



reconocimiento)


1 (leer) 07 (calidad limitada = 1) 129 (respuesta)07 (calidad limitada)

(calidad = 1)

2 (escribir) 07 (calidad limitada = 1)

51 1 Hora y Fecha CTO - Tiempo absoluto, sincronizado129 (respuesta)

130 (respuesta sin resolver)

07 (calidad limitada)

(calidad = 1)

51 2 Hora y Fecha CTO - Tiempo absoluto no sincronizados129 (respuesta)

130 (respuesta sin resolver)

07 (calidad limitada)

(calidad = 1)


SOLICITUD

La Maestra puede emitir instrucciòn


RESPUESTA


La UTR puede emitir instrucciòn

50 1 Hora y Fecha - Tiempo absoluto



139 de 154

120713 Rev 160720 161021

Numero

de

Grupo

Numero

de

Variaciòn

DescripciònCodigos de Funciòn

(dec)


(hex)

Codigos de Funciòn

(dec)


(hex)

52 1 Retardo de Tiempo- Grueso 129 (respuesta)07 (calidad limitada)

(calidad = 1)

52 2 Retardo de Tiempo - Fino 129 (respuesta)07 (calidad limitada)

(calidad = 1)

60 1 Objetos de Clase - Datos de Clase 0 1 (leer) 06 ( sin alcence o todo )

1 (leer)06 (sin alcance o todo)


20 (habilitar sin resolver)

21 (deshabilitar sin resolver)

22 ( asignaciòn de clase)

06 ( sin alcence o todo )













1 (leer) 00, 01 (iniciar - detener) 129 (respuesta) 00, 01 (iniciar - detener)

2 (escribir)00 (iniciar - detener )

indice = 7

13 (reiniciar en frio)

23 (mediciòn del retardo)

3 Objetos de Clase - Datos de Clase 2

60 4 Objetos de Clase - Datos de Clase 3


SOLICITUD

La Maestra puede emitir instrucciòn


RESPUESTA


La UTR puede emitir instrucciòn

Sin Objeto ( Unicamente codigo de funciòn )

Sin Objeto ( Unicamente codigo de funciòn )

Objetos de Clase - Datos de Clase 160 2

80 1 Indicaciones Internas - Formato Comprimido

60

Comando Binario - Patròn de Bloque de Control (g12v2)

Comando Binario - Patròn de Mascara (g12v3)

NOTA

Nota: Los siguientes objetos fueron previamente requeridos de conformidad para el subconjunto DNP3 Nivel 3 y ya no son necesarios a partir de 2007:



140 de 154

120713 Rev 160720 161021

APÉNDICE B

(Informativo)

ADMINISTRACIÓN Y PRUEBAS ADICIONALES DEL PROYECTO

Proveedor debe usar “microsoft project” para manejo de proyectos computarizado durante este contrato. Este sistema

es capaz de presentar la dirección e integración del proyecto desde su inicio hasta su terminación, de tal forma que

los objetivos trazados sean alcanzados dentro de las restricciones de desempeño, duración, costos y mano de obra

predefinidas.

Las actividades de monitoreo y control del proyecto incluyen todas las acciones necesarias para definir el estado

actual del proyecto, predecir los objetivos de tiempo más probables para la terminación de las actividades, identificar

las áreas con problemas, iniciar las acciones correctivas necesarias y predecir las fechas de terminación revisadas.

El monitoreo del programa debe estar basado en una comparación de las tareas terminadas versus tareas

programadas y estimación de los esfuerzos requeridos, en días-hombre, para completar las tareas faltantes. No se

debe utilizar el cálculo de avance del proyecto en porcentaje basado en el tiempo aplicado versus el tiempo

programado.

Proveedor debe mantener e incluir en todos sus reportes, lo siguiente:

a) El programa detallado de Implementación original y aprobado como una referencia.

b) El programa detallado de Implementación actual y revisado.

El ciclo de control de manejo del proyecto debe ser un proceso mensual, con los siguientes pasos:

a) Recolección del estado exacto, oportuno y datos de predicción sobre cada uno de los parámetros del programa de implementación, a nivel de actividad o tarea.

b) Análisis de los datos para determinar las desviaciones existentes entre el estado actual y el programa aprobado.

c) Evaluación del impacto total de las desviaciones existentes y pronosticadas, y el aislamiento de

ellas que, si no son corregidas, pueden causar cambios en la fecha de terminación del proyecto, convenios de ciclos de revisión u otra consecuencia inaceptable.

d) Investigación de las causas de las desviaciones claves.

e) Desarrollo de soluciones alternativas para los problemas conocidos y anticipados.

f) Evaluación de las posibles soluciones.

g) Toma de acciones correctivas aprobadas por la CFE para resolver los problemas reales y

potenciales.

h) Revisión del programa detallado de implementación para incorporar todas las revisiones aprobadas.



141 de 154

120713 Rev 160720 161021

Debe ser el objetivo del proyecto resolver los problemas identificados dentro de un período de diez (10) días. Se debe definir, como máximo, un curso de acciones remédiales por escrito dentro de los cinco (5) días después de la identificación del problema. B.1 INFORMES DE AVANCE El proveedor debe presentar por escrito un Informe de avance bimestral que cubra todos los aspectos del proyecto en un formato aprobado por CFE, el primer reporte se después de dos meses del inicio del proyecto. La sección inicial del Informe de avance bimestral debe ser una evaluación general de todo el proyecto. El reporte debe incluir el avance relacionado con el programa detallado de implementación. Se debe suministrar una copia en disco compacto o DVD de los archivos de datos programados con cada informe. El informe debe ser suministrado en copia impresa y en un formato electrónico se debe presentar los programas original y revisado, el estado actual, el tiempo faltante y las fechas de terminación pronosticadas. El informe debe reflejar el estado del proyecto hasta el último día del mes anterior. El Informe de avance bimestral debe incluir todas las actividades de CFE, así como las actividades de Proveedor y de cualquier otra parte que esté participando en el proyecto. El Informe debe incluir el estado de los puntos importantes del período y una indicación de la meta que se deberá cumplir en el reporte del siguiente período. El Informe de avance bimestral debe incluir todas las actividades programadas. Además, el informe de avance bimestral debe incluir una explicación apropiada de las desviaciones del programa, existentes y pronosticadas, el impacto sobre el proyecto, la causa u origen de la desviación, las alternativas consideradas, las soluciones adoptadas o recomendadas y las conclusiones alcanzadas o anticipadas. En particular, el Informe debe hacer notar la falta de cualquier información a ser enviada a o por CFE que se necesite para mantener el proyecto a tiempo. El informe de avance bimestral debe identificar las decisiones oportunas o pendientes. Este incluirá una descripción de los aspectos y la fecha oportuna actual, las consecuencias del retraso y cualquier recomendación relacionada con el proceso de decisión. El informe de avance bimestral debe incluir dos (2) listas de los aspectos pendientes. Una lista debe ser de aspectos pendientes que están actualmente incompletos. La otra lista debe ser de aspectos pendientes que fueron completados durante el período de Informe. Cada una de las listas tendrá la siguiente información para cada uno de los aspectos pendientes:

a) Número de serie único de la acción.

b) Fecha de iniciación.

c) Número de referencia del documento que lo origina.

d) Fecha oportuna.

e) Organización responsable.

f) Descripción.

g) Fecha de terminación.

h) Número de referencia de terminación. El informe de avance bimestral debe incluir dos (2) registros de correspondencia de los comunicados (oficios, email, entre otros.) del proveedor a la CFE y en otra de la CFE al proveedor.



142 de 154

120713 Rev 160720 161021

B.2 PRUEBAS, INSTALACIÓN Y PUESTA EN OPERACIÓN DEL SISTEMA Ningún componente del sistema configurado debe ser embarcado hasta que CFE reconozca que el sistema ha pasado exitosamente la Prueba de Aceptación en Fábrica (FAT) o sea autorizado por CFE. Se debe ejecutar las Pruebas Preliminares de Aceptación en Fábrica (Pre-FAT) y las Pruebas de Aceptación en Fábrica. CFE se reserva el derecho de inspeccionar el avance del Pre-FAT en cualquier momento después de que Proveedor haya anunciado su comienzo, o para observar completamente el Pre-FAT. CFE debe estar en libertad de observar las pruebas del Pre-FAT, sin embargo la dirección y administración del Pre-FAT debe ser a discreción de Proveedor. El propósito del Pre-FAT y FAT debe ser verificar que el “hardware” y “software” que está siendo probado cumpla íntegramente y como esté especificado en el contrato y a entera satisfacción de CFE. Las pruebas debe verificar el desempeño y la integridad funcionales de los subsistemas individuales, y se debe demostrar la operación de los subsistemas sobre la base de un sistema integrado. Todas las funciones se debe presentar completamente implementadas. Se debe probar la modificación de reportes, desplegados, bases de datos y funciones relacionadas. Se debe demostrar la eficiencia y respuesta del sistema a través de la prueba de respuesta de la interfaz de usuario, respuesta de los programas de sistema, respuesta de los programas de aplicaciones, utilización del procesador, capacidad de respaldo, capacidad de seguridad, utilización de entradas/salidas, manejo y procesamiento de alarmas. Las fallas detectadas (eventos) durante las pruebas FAT, SAT, instalación y producción del sistema deben ser clasificadas por CFE por prioridades para su atención. La no atención de un evento clasificado como falla crítica, media y baja se definen a continuación:

a) Crítica:

- Si el evento se origina durante las pruebas FAT y este no se corrige, el sistema no se debe enviar a sitio.

- Si el evento se origina durante la instalación en sitio, no se puede llevar a cabo la puesta en servicio hasta que esté resuelto.

b) Media:

- Si el evento se origina durante las pruebas FAT, se debe de corregir antes de la puesta en servicio.

- Si el evento se origina durante la instalación en sitio, no se puede llevar a cabo la puesta en servicio hasta que esté resuelto.

c) Baja:

Si el evento se origina durante las FAT, SAT, instalación en sito o cuando el sistema esté en producción, debe ser corregido en un tiempo convenido entre ambas partes.

B.3 PRUEBAS PRELIMINARES DE ACEPTACIÓN EN FÁBRICA (PRE-FAT) Las FAT deben comenzar solamente después de la terminación exitosa del Pre-FAT, con el fin de asegurar que aquel sea completado también exitosamente y oportunamente. Luego de que el plan y procedimientos de pruebas en fábrica hayan sido aprobados por la CFE, cada prueba en el Pre-FAT deben completar una corrida de su equivalente en el FAT. La intención de Proveedor debe ser detectar y corregir todos los problemas de diseño, integración, bases de datos, desplegados, parámetros de tiempo y desempeño, así como la elaboración y entrega de protocolos de prueba para llevar a cabo las FAT del sistema antes de que el personal de la CFE conduzca/atienda el FAT en la fábrica Proveedor bajo la supervisión del mismo. El Pre-FAT debe ser supervisado por la persona designada para servir como el director del FAT, y cada prueba debe ser formalmente firmada por esta persona. Los resultados de prueba firmados



143 de 154

120713 Rev 160720 161021

debe ser revisados por CFE y Proveedor, antes de que el personal de la CFE conduzca/atienda el FAT en las instalaciones de Proveedor. Proveedor debe notificar a la CFE antes del inicio del Pre-FAT y este debe tener la opción de testigo. B.3.1 Prueba de Aceptación en Fábrica (Fat) Estas pruebas de aceptación deben permitir probar la funcionalidad de los sistemas del sistema, que incluye el SCADA, la seguridad del sistema, tanto en el “software” como en la LAN, los programas de aplicaciones de potencia, como lo es el ambiente de desarrollo de “software”, en el cual se debe compilar el “software” Proveedor o propio de CFE y transferirlo a otro sistema, como lo es la funcionalidad de transferir y contener la base de datos de cada sitio. El proveedor debe notificar oficialmente con anticipación, un mes cuando menos, a la CFE, la fecha real de inicio del FAT. El proveedor debe enviar los procedimientos firmados del Pre-FAT inmediatamente después de finalizadas estas, para que la CFE certifique que el sistema está listo para el FAT. Es requisito indispensable entregar los procedimientos firmados de Pre FAT a la CFE para dar inicio las pruebas FAT. El FAT debe ser ejecutado y supervisado por la persona designada para servir como director del FAT de Proveedor. La CFE debe participar activamente en la ejecución de cada FAT y debe evaluar los resultados de la prueba con los protocolo de prueba anteriormente acordados entre ambas partes. Cada prueba debe ser formalmente probada por la CFE y Proveedor. Se tendrá disponible en el piso de pruebas, toda la documentación importante del sistema a ser probado, incluyendo documentos funcionales, de diseño y mantenimiento, manuales de usuario, procedimientos de prueba y plan de pruebas durante el FAT. Durante la etapa de FAT's Proveedor debe entregar los documentos actuales del sistema. Los documentos finales debe ser entregados en sitio en conjunto con el sistema en tres copias en papel y una en disco. Además el Proveedor debe proporcionar los equipos externos necesarios con el fin de probar la funcionalidad completa de la cadena de adquisición de datos, que permitan ejercitar el perfil completo de cada protocolo con el fin de probar toda la cadena de adquisición de datos. La CFE debe considerar proveer equipos adicionales para la pruebas en Fabrica, los cuales, deben ser enviados en tiempo forma para que estos estén disponibles para las pruebas Pre-FAT. B.3.2 Pruebas de Equipos en Fábrica Las pruebas de equipos incluyen lo siguiente:

a) Pruebas visuales.

b) Pruebas de diagnóstico de hardware.

c) Verificación de la compatibilidad de la instalación. Pruebas Visuales: Estas pruebas deben verificar que el sistema bajo prueba incluya todo el equipo requerido y esté apropiadamente configurado. La inspección visual debe ser ejecutada para comprobar su integración apropiada y la identificación adecuada de todo el equipo, incluyendo cables y conectores. Pruebas de Diagnóstico de hardware: Estas pruebas deben consistir de pruebas individuales de todas las componentes de “hardware” del sistema en prueba. Estas pruebas deben consistir de la ejecución de programas estándares de diagnóstico en línea y fuera de línea del hardware y programas especiales de diagnóstico usados por Proveedor.



144 de 154

120713 Rev 160720 161021

Se debe verificar la Compatibilidad de la Instalación: Estos procedimientos deben verificar los requisitos de la instalación del sistema en prueba, con respecto a espacio, potencia, aire acondicionado, entre otros., cumpliendo con lo establecido en el documento Preparación en Sitio e Instrucciones para la Instalación del sistema proporcionado por Proveedor antes de las pruebas de FAT. Esto debe ser verificado mediante cálculos basados en datos técnicos para la configuración final del sistema. B.3.3 Prueba no Estructurada Proveedor debe asignar el 30 % del tiempo asignado a las pruebas FAT a la CFE, para conducir pruebas no estructuradas que no fueron incluidas en el documento FAT. El personal Proveedor debe estar disponible para consulta durante estas pruebas si la CFE lo requiere. Las Pruebas No Estructuradas no deben violar las restricciones de operación definidas en la documentación aprobada.

Características Particulares para: Unidades Centrales Maestras

para Centros de Control de Distribución y Transmisión

Correspondientes a la especificación CFE G0100-14 145 de 154

120713 Rev 160720 161021

CP

E -

474

CARACTERÍSTICAS PARTICULARES

1 FUNCIONES PRINCIPALES DE LA UNIDAD CENTRAL MAESTRA QUE DEBEN SER

MANDATORIAS

FUNCIONES PRINCIPALES CENTRO DE CONTROL

CCA CCS CCD

Control Automático de Generación N/A N/A

IPS M M

Procesador de topología N/A N/A

Flujos de potencia en línea para desbalanceo de 3 fases N/A N/A

Análisis de contingencia N/A N/A

Análisis en modo estudio N/A N/A

Análisis de corto circuito N/A N/A

Administración de la Tensión/Potencia Reactiva N/A N/A

Análisis de pérdidas N/A N/A

Monitoreo visual de equipos e instalaciones. N/A N/A

Detección de fallas, ubicación, aislamiento y

restablecimiento del servicio N/A N/A

O = Opcional

M = Mandatorio

N/A = (No aplica)




120713 Rev 160720 161021

CP

E -

474

2 SE REQUIERE LA ENTREGA DEL CÓDIGO FUENTE DEL SOFTWARE DE APLICACIÓN DE LA UCM

Si ( ) No( ) 3 DIMENSIONAMIENTO MÍNIMAS DEL SISTEMA:

Si ( ) No( ) Cantidad de Entradas Binarias ( ) puntos Cantidad de Entradas Analógicas ( ) puntos Cantidad de Salidas Binarias ( ) puntos Cantidad de Salidas Analógicas ( ) puntos Cantidad de Contadores ( ) puntos Dimensionamiento para Funciones Básicas de la UCM Volumen de datos diario que debe manejar la UCM que deben ser grabados en disco duro: registro de _____ cambios de cada señal analógica, ___% del total de las entradas binarias que deben generar un evento por día. Administración de Puntos Etiquetados: ___ al ___ % del total de puntos Espacio requerido para el almacenamiento de 2 años de información en línea de al menos ( _____ ) GB Archivado de Datos históricos debe ser de (___) años. En caso de no indicar un valor se debe tomar lo que se indica en la especificación que son 5 años. Información de alarmas y bloqueo de comandos

Archivo Capacidad de Registros

Alarmas ___% del total, filtrables por categoría y por

severidad

Anormales _________ puntos del sistema

Inhibidos _________ puntos del sistema

Requerimientos mínimos esperados por el área usuaria Versión requerida del TASE.2 ___________________ Bloques requeridos del TASE.2: Bloque 1 Si ( ) No ( ) Bloque 2 Si ( ) No ( ) Bloque 3 Si ( ) No ( )




120713 Rev 160720 161021

CP

E -

474

Bloque 4 Si ( ) No ( ) Bloque 5 Si ( ) No ( ) Bloque 6 Si ( ) No ( ) Bloque 7 Si ( ) No ( ) Bloque 8 Si ( ) No ( )

Parámetro de dimensionamiento Cantidad

Unidades Terminales Remotas (UTR’s)

Enlace con: TASE.2 Número de enlaces (mayor a 15): Número de entradas analógicas por enlace: Número de salidas analógicas por enlace: Número de entradas binarias por enlace: Número de salidas binarias por enlace: TCP/IP: LAN’s EXTERNAS:

ENTRADAS ANALÓGICAS: Telemedidos: Calculados:

ENTRADAS BINARIAS: Telemedidos: Calculados:

ACUMULADORES: Telemedidos: Calculados:

SALIDAS BINARIAS (CONTROLES) Salidas de Control a UTR’s




120713 Rev 160720 161021

CP

E -

474

Bloque de Operaciones (Cada bloque puede operar un máximo de 20 dispositivos, tiro y restauración de carga)

Puntos a ser verificados por Violaciones de Límites

Puntos a ser verificados por tasa de cambio (cambios en binarios, analógicos y acumuladores)

PARÁMETROS DE INTERFAZ DE USUARIO: Áreas de Responsabilidad (AOR) Tamaño de las ventanas en que se navegará por Monitor (Viewports) Desplegados (Tabulares, unifilares, entre otros)

PARÁMETROS DE ALARMAS: Tamaño del Archivo (número de alarmas y eventos) por día. Niveles de Severidad

ALMACENAMIENTO DE ALARMAS Y EVENTOS (LOGGERS) Número de Alarmas/Eventos a almacenar (1 año)

MANEJO DE SECUENCIAS DE CONTROL: Número de Secuencias Número de Instrucciones por Secuencia

HISTÓRICO Número de etiquetas (tags) del Histórico Número de usuarios concurrentes

4 PROTOCOLOS DE COMUNICACIÓN ADICIONALES A LOS INDICADOS EN LA ESPECIFICACIÓN Y SUS CARACTERÍSTICAS:

PROTOCOLO MAESTRO ESCLAVO

( ) ( )

( ) ( )

( ) ( )




120713 Rev 160720 161021

CP

E -

474

5 EL EQUIPAMIENTO MÍNIMO DE LA UCM ES CONFORME A LO QUE SE INDICA EN LA TABLA 2, SI

EL ÁREA USUARIA REQUIERE EQUIPAMIENTO ADICIONAL MARCAR LA OPCIÓN CORRESPONDIENTE

Si ( ) No ( )

Nota: En caso de requerir el área usuaria equipamiento distinto, debe indicarlo a continuación:

6 SE REQUIERE SERVIDORES DE COMUNICACIÓN INDEPENDIENTES DE LOS SERVIDORES SCADA Si ( ) No ( ) 7 CANTIDAD Y TIPO DE PUERTOS REQUERIDOS EN LOS SERVIDORES DE COMUNICACIONES 8 SUMINISTRO DE CONSOLAS DE OPERACIÓN: Cantidad de Consolas de Operador ( ) piezas Cantidad de Monitores por Consola de Operador ( ) piezas

Número de licencias para Consolas de Operador ( ) piezas 9 PROCEDIMIENTO PARA ACTUALIZACIÓN DE ANTIVIRUS _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________

DESCRIPCIÓN CANTIDAD

Servidor SCADA, históricos y de Aplicaciones

Servidor “web” Nota: Se requieren ___ conexiones concurrentes de usuarios

Consolas de Operación

Monitores por consola de Operación

Consolas de Mantenimiento (con 1 monitor)

Switch y “firewall”

Impresora Láser a Color

Sistema Estándar de Tiempo y Frecuencia sincronizado con GPS (2 relojes GPS y 2 Antenas)

CENTRO DE CONTROL/CAMPO TOTAL DE PUERTOS PROTOCOLO UTILIZADO




120713 Rev 160720 161021

CP

E -

474

10 SE REQUIERE ACCESO DE INFORMACIÓN, HACIA Y DE LA INTRANET Si ( ) No ( ) _________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ 11 NIVELES DE SEGURIDAD ADICIONALES A LOS INCLUIDOS EN LA ESPECIFICACIÓN: Biométrico ( ) Lector de tarjetas ( ) Otro (especificar) 12 SE REQUIERE LA ENTREGA DE HERRAMIENTAS CON EL QUE SE DESARROLLARON LAS

APLICACIONES ESPECÍFICAS QUE CFE SOLICITA Y EL PROVEEDOR DEBE CONTAR CON UNA HERRAMIENTA QUE CONTROLE LOS CAMBIOS DE VERSIONES DE LOS PROGRAMAS EN LA UCM

Si ( ) No ( ) 13 SIMULADOR DE PROTOCOLOS Cantidad de simuladores ( ) Protocolos y requerimientos del equipo para simulador: __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 14 SE REQUIERE LA FUNCIONALIDAD DE DESACTIVACIÓN AUTOMÁTICA PARA ENTRADAS BINARIAS POR NÚMERO DE CAMBIOS EN UN PERÍODO DETERMINADO Si ( ) No ( ) 15 SE REQUIERE LA FUNCIONALIDAD DE 4 CONJUNTOS DE NIVELES PARA LOS 6 NIVELES DE SIGNIFICANCIA QUE DEBEN SER AGRUPADOS POR PARES DE LAS SEÑALES ANALÓGICAS Si ( ) No ( ) 16 SE REQUIERE LA FUNCIONALIDAD DE VIGILANCIA DE LA RAZÓN DE CAMBIO PARA SEÑALES ANALÓGICAS, CON GENERACIÓN DE ALARMA Si ( ) No ( )




120713 Rev 160720 161021

CP

E -

474

17 SE REQUIERE PROTOCOLO DNP ESCLAVO Si ( ) No ( ) NOTA: En caso de requerirse se debe anexar el Perfil en el anexo B de la presente especificación

18 SE REQUIERE EL MÓDULO PARA EL TIRO Y RESTAURACIÓN DE CARGA Si ( ) No ( ) 19 SE SOLICITAN LOS REQUERIMIENTOS FUNCIONALES PARA UN ENLACE DE RED PARA SISTEMAS EXTERNOS Si ( ) No ( ) NOTA : En caso de que sea solicitada esta opción, debe anexarse la necesidad del área usuaria relacionada con este punto Indicada en el punto 4 de estas Características Particulares en la Sección del “software” Adicional.

20 NECESIDADES ESPECÍFICAS PARA LOS SERVICIOS DE COMUNICACIÓN Y CONVERSIÓN DE PROTOCOLOS (PUNTO 6.8.7): __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 21 AREAS DE RESPONSABILIDAD Numero de áreas de responsabilidad requeridas para el sistema _____________________________ 22 SE REQUIERE INCLUIR COMENTARIOS EN EL RELATORIO DEL OPERADOR (APLICACIÓN

DESARROLLADA POR CFE) Si ( ) No ( ) 23 CONTROL DE ALARMAS Nivel de serveridad requeridos para el sistema. ______________________(por defecto 8) 24 SE REQUIEREN LAS FUNCIONES RELACIONADAS CON EL CONTROL SUPERVISORIO Control de Libranzas y Licencias ( ) Bloqueos de Comando de Cierre ( ) Desplegados en “web” ( ) 25 ALMACENAMIENTO DE DATOS históricos: __________________ años (por defecto 5 años)




120713 Rev 160720 161021

CP

E -

474

26 NÚMERO DE USUARIOS CONCURRENTES AL SISTEMA DE BASE DE DATOS HISTÓRICO

_________ USUARIOS 27 ARCHIVADO Y GRABADO DE DATOS HISTÓRICO ___________ AÑOS (2 AÑOS POR DEFECTO) 28 INTERCOMUNICACIÓN CON OTROS sistemaS SCADA Nivel de Implementación Alcance de suministro de los enlaces requeridos con otros sistemas _____________ Número de puntos requeridos por cada enlace ______________ 29 REQUERIMIENTOS ESPERADOS POR EL USUARIO PARA DESEMPEÑO DE CADA SERVIDOR Servidores de SCADA, de comunicaciones, histórico, “web”, base de datos o de aplicaciones

CARACTERÍSTICAS OFERTADAS

Servidor:_____________________________________________

CPU

Sistema operativo

Velocidad de reloj

Memoria RAM

Montaje en rack de 48.26 cm (19 pulgadas)

Discos duros

DVD/CD +/- RW

Arreglo RAID

Red “ethernet”

Puerto de administración

Otro (s) dispositivo (s)

30 SE REQUIERE EL SUMINISTRO DEL EQUIPAMIENTO PARA LA VISUALIZACIÓN MAGNIFICADA

DEL SISTEMA ELÉCTRICO Si ( ) No ( ) Elementos de Visualización Tableros mímicos ( ) Pantallas de Video ( ) Video Proyectores ( ) Cantidad de Elementos de visualización: _________________ piezas, en arreglos de _______ X ______ Observaciones adicionales: ______________________________________________________________________________________________ ____________________________________________________________________________________________________________________________________________________________________________________________




120713 Rev 160720 161021

CP

E -

474

Se requiere Estructura para Montaje Si ( ) No ( ) Observaciones adicionales: __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Características para el Almacenamiento de los discos duros (6.15.1, inciso c)) Las señales de video deben ser desplegadas en ventanas libremente escalables y posicionales a lo largo del sistema de visualización que se haya solicitado en “Características Particulares” 31 REQUERIMIENTOS DE LOS EQUIPOS DE IMPRESIÓN: _____________________________________________________________________________________________ _____________________________________________________________________________________________ _____________________________________________________________________________________________ 32 TIEMPO DE RESPALDO DE LAS UPS´S PARA PROPORCIONAR AUTONOMÍA DE SUMINISTRO DE

ENERGÍA ELÉCTRICA A LA UCM, MEDIANTE BANCOS DE BATERÍAS ( ) h 33 SE REQUIERE EL SUMINISTRO DEL MOBILIARIO PARA LAS UCM´S Si ( ) No ( ) Dimensiones del mobiliario: Longitud de mesas de control _____________________ Número de mesas de control ______________________ Número de usuarios por mesas de control _______________ Número total de sillas ____________________ Características especiales del diseño de las mesas de control: ______________________________________________________________________________________________ ______________________________________________________________________________________________ ______________________________________________________________________________________________ NOTA: El área usuaria debe repetir el concepto que corresponda para mesas adicionales de analistas, supervisores y

administradores del sistema.

Puesta a punto 34 EL ÁREA USUARIA, REQUIERE LOS SERVICIOS DEL PROVEEDOR, REALIZAR TODAS LAS

ACTIVIDADES PARA EL REEMPLAZO Y MIGRACIÓN DEL SISTEMA EXISTENTE AL NUEVO SISTEMA, INCLUYENDO LOS AJUSTES Y ADECUACIONES DE LOS MEDIOS DE COMUNICACIÓN EXISTENTES.

Si ( ) No ( )




120713 Rev 160720 161021

CP

E -

474

35 SE REQUIERE LA INTERCONEXIÓN CON UN GIS Si ( ) No ( ) 36 EN EL ALCANCE DEL SUMINISTRO, SE REQUIERE QUE EL PROVEEDOR REALICE EL(LOS)

ENLACE(S) CON OTRO CENTRO(S) DE CONTROL MEDIANTE PROTOCOLO ICCP (LA CFE PROPORCIONA EL MEDIO DE COMUNICACIÓN). EN CASO DE REQUERIRSE, CFE ANEXA LA DOCUMENTACIÓN PARTICULAR QUE INDICA , EL (LOS) CENTRO(S) DE CONTROL, LA BASE DE DATOS CON LA NOMENCLATURA DEL MAPA DE PUNTOS Y LOS REQUERIMIENTOS TÉCNICOS DEL MEDIO DE COMUNICACIÓN PARA REALIZAR EL ENLACE.

Si ( ) No ( ) __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 37 SE REQUIERE PÓLIZA DE MANTENIMIENTO

Si ( ) No ( ) 38 “SOFTWARE” DE APLICACIÓN ADICIONAL REQUERIDO, INCLUYE LA INSTALACIÓN Y PUESTA

EN SERVICIO DE LA INTERCONEXIÓN CON OTRAS APLICACIONES CORPORATIVAS QUE INCLUYEN EL DESARROLLO DE LAS INTERFACES. EN CASO AFIRMATIVO SE ANEXAN ESTOS DESARROLLOS Y LOS REQUERIMIENTOS TÉCNICOS PARA QUE EL PROVEEDOR PUEDA DESARROLLARLOS

Si ( ) No ( ) ____________________________________________________________________________________________________________________________________________________________________________________________ 39 REQUERIMIENTOS DE INTERFACES DE COMUNICACIÓN: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 40 CAPACITACIÓN PARA LA INSTALACIÓN, ADMINISTRACIÓN Y OPERACIÓN DEL SISTEMA Número de Cursos para Puesta en Operación ( ) Persona que deben recibir el curso de puesta en operación ( ) Número de Cursos para la Administración del sistema ( ) Personas que deben recibir el curso de Administración del sistema ( ) Número de Cursos para la Operación del sistema ( ) Personas que deben recibir el curso de Operación del sistema ( )

Documents

UNIDADES CENTRALES MAESTRAS PARA …lapem.cfe.gob.mx/normas/pdfs/f/G0100-14.pdf · remotos, ubicados en las instalaciones eléctricas y con ello formando la integración de un sistema