SLRP-A Y B€¦ · DOC.N° SEIS EO Unificación Parte A y B para el CDEC 28/12/16 J.P.T. E.D. M.P. M.C. A.D. REVISION DESCRIPCIÓN FECHA REALIZÓ REALIZÓ REALIZÓ REVISÓ APROBÓ

EO Unificación Parte A y B para el CDEC 28/12/16 J.P.T. E.D. M.P. M.C. A.D. REVISION DESCRIPCIÓN FECHA REALIZÓ REALIZÓ REALIZÓ REVISÓ APROBÓ

LISTA DE REVISIONES

sistemas eléctricos ingeniería y servicios

ESTUDIO DE DISEÑO, ESPECIFICACIÓN Y PROGRAMA PARA LA IMPLEMENTACIÓN DEL SISTEMA DE LECTURA REMOTA DE

PROTECCIONES DEL SIC y EL SING

NOMBRE Y FIRMA FECHA ESTUDIO SLRP

DOCUMENTO UNIFICADO DE:

ETAPA A – ESTADO DEL ARTE DE LOS SLRP

ETAPA B – DISEÑO DE ARQUITECTURA Y ESPECIFICACIÓN DEL SISTEMA

REALIZÓ E. DIAZ

REALIZÓ J. TETTAMANTI

REALIZÓ M.G.R. PIERRO

REVISÓ M. CANNIZZO

APROBÓ A. DI CÉSARE

ARCHIVO: SLRP - Estudio Unificado - (A) Estado del Arte y (B) Diseño del Sistema

CODIFICACIÓN N°CLIENTE REV:

ANTECEDENTES:

HOJA 1 de 230

FORMATO A4

DOC.N° SEIS REV: EO

ESTUDIO DE DISEÑO, ESPECIFICACIÓN Y PROGRAMA LA IMPLEMENTACIÓN DEL SISTEMA DE LECTURA REMOTA DE PROTECCIONES DEL SIC y EL SING

(A) ESTADO DEL ARTE - (B) DISEÑO DE Y ESPECIFICACIÓN DEL SISTEMA

NºSEIS: PÁGINA: 2 DE 230 REV:EO


ÍNDICE PARTE A: ESTADO DEL ARTE DE LOS SLRP ............................................................................................. 12

Capítulo 1. INTRODUCCIÓN .............................................................................................................................. 13

Capítulo 2. AUTOMATIZACIÓN ACTUAL DE LAS INSTALACIONES ELÉCTRICAS .............................. 15 2.1 Introducción ............................................................................................................................................... 15 2.2 Niveles de Automatización ........................................................................................................................ 16 2.3 Necesidad de Integración de Dispositivos ................................................................................................. 20 2.4 Necesidad de Comunicación entre Instalaciones ....................................................................................... 21 2.5 Referencias................................................................................................................................................. 22

Capítulo 3. PROTOCOLOS DE COMUNICACIÓN ........................................................................................... 23 3.1 Introducción ............................................................................................................................................... 23 3.2 Modelo OSI ................................................................................................................................................ 24 3.3 Modelo TCP/IP .......................................................................................................................................... 26 3.4 Modbus ...................................................................................................................................................... 28

3.4.1 Introducción ........................................................................................................................................ 28 3.4.2 Formato de Tramas .............................................................................................................................. 29 3.4.3 Funciones Soportadas .......................................................................................................................... 30 3.4.4 Casos de Uso ....................................................................................................................................... 32 3.4.5 Conclusiones ....................................................................................................................................... 34

3.5 DNP 3.0...................................................................................................................................................... 35 3.5.1 Introducción ........................................................................................................................................ 35 3.5.2 Formato de Mensajes .......................................................................................................................... 36 3.5.3 Funciones Soportadas .......................................................................................................................... 37 3.5.4 Niveles de implementación ................................................................................................................. 40 3.5.5 Casos de Uso ....................................................................................................................................... 40 3.5.6 Conclusiones ....................................................................................................................................... 42

3.6 IEC 61850 .................................................................................................................................................. 43 3.6.1 Introducción ........................................................................................................................................ 43 3.6.2 Tipos de Mensajes ................................................................................................................................ 44 3.6.3 Funciones Soportadas .......................................................................................................................... 54 3.6.4 Casos de Uso ....................................................................................................................................... 55 3.6.5 Conclusiones ....................................................................................................................................... 56

3.7 ICCP ........................................................................................................................................................... 58 3.7.1 Introducción ........................................................................................................................................ 58 3.7.2 Bloques de Datos ................................................................................................................................. 58 3.7.3 Funciones Soportadas .......................................................................................................................... 60 3.7.4 Casos de Uso ....................................................................................................................................... 61





3.7.5 Conclusiones ....................................................................................................................................... 62 3.8 Referencias................................................................................................................................................. 63

Capítulo 4. DISPOSITIVOS DE COMUNICACIÓN ........................................................................................... 64 4.1 Introducción ............................................................................................................................................... 64 4.2 Dispositivos Electrónicos Inteligentes ........................................................................................................ 64

4.2.1 Introducción ........................................................................................................................................ 64 4.2.2 Funciones de Protección ..................................................................................................................... 65 4.2.3 Módulos Disponibles y sus Características ......................................................................................... 65 4.2.4 Casos de Uso ....................................................................................................................................... 66 4.2.5 Conclusiones ....................................................................................................................................... 68

4.3 Unidades de Terminal Remota .................................................................................................................. 68 4.3.1 Introducción ........................................................................................................................................ 68 4.3.2 Módulos Disponibles y sus Características ......................................................................................... 68 4.3.3 Casos de Uso ....................................................................................................................................... 71 4.3.4 Conclusiones ....................................................................................................................................... 72

4.4 Merging Unit .............................................................................................................................................. 72 4.4.1 Tipos de Merging Unit ........................................................................................................................ 73 4.4.2 Transmisión de Datos .......................................................................................................................... 73 4.4.3 Sincronización de Base de Tiempo ..................................................................................................... 74

4.5 Gateway de Subestación ............................................................................................................................ 74 4.5.1 Introducción ........................................................................................................................................ 74 4.5.2 Funciones Avanzadas .......................................................................................................................... 76 4.5.3 Casos de Uso ....................................................................................................................................... 77 4.5.4 Concluciones ....................................................................................................................................... 80

4.6 Referencias................................................................................................................................................. 81

Capítulo 5: SEGURIDAD DE LA INFORMACIÓN ........................................................................................... 82 5.1 Introducción ............................................................................................................................................... 82 5.2 Identificación de Riesgos ........................................................................................................................... 83 5.3 Medidas de Seguridad ................................................................................................................................ 83 5.4 Referencias................................................................................................................................................. 85

Capítulo 6: NUEVAS TENDENCIAS EN AUTOMA-TIZACIÓN DE INSTALACIONES ELÉCTRICAS .... 86 6.1 Introducción ............................................................................................................................................... 86 6.2 Soluciones ABB ......................................................................................................................................... 86 6.3 Soluciones Kalkitech ................................................................................................................................. 90 6.4 Soluciones Siemens ................................................................................................................................... 96 6.5 Soluciones Moxa........................................................................................................................................ 98 6.6 Estudio Estadístico del SIC y el SING .................................................................................................... 102 6.7 Topología Propuesta ................................................................................................................................ 104 6.8 Referencias............................................................................................................................................... 107





PARTE B: DISEÑO DE ARQUITECTURA Y ESPECIFICACIÓN DEL SLRP .............................................. 108

Capítulo 1. JUSTIFICACIÓN DEL DESARROLLO. CRITERIOS DE DISEÑO ............................................. 109 1.1 Antecedentes ............................................................................................................................................ 109 1.2 Objetivos .................................................................................................................................................. 109 1.3 Alcance del Estudio ................................................................................................................................. 111 1.4 Metodología y Premisas de Diseño ......................................................................................................... 112 1.5 Referencias............................................................................................................................................... 114

Capítulo 2. EL SLRP COMO FUENTE DE INFORMACIÓN .......................................................................... 115 2.1 Introducción ............................................................................................................................................. 115 2.2 Información Asociada a Protecciones Eléctricas ..................................................................................... 117 2.3 Disponibilidad de la Inf.de Protecciones en los Sistemas Corporativos de Análisis de Datos ............... 119 2.4 Referencias............................................................................................................................................... 121

Capítulo3. ARQUITECTURA BÁSICA PROPUESTA PARA EL SLRP ......................................................... 122 3.1 Parque de Protecciones del SLRP ............................................................................................................ 122

3.1.1 Capacidad de acceso remoto de los puntos de monitoreo ................................................................. 122 3.1.2 Distribución geográfica de los puntos de monitoreo......................................................................... 124 3.1.3 Distribución de los puntos de monitoreo respecto de sus propietarios ............................................. 124

3.2 Filosofía de Diseño del SLRP .................................................................................................................. 127 3.2.1 Filosofía de diseño del módulo de acceso remoto de protecciones .................................................. 127 3.2.2 Filosofía de diseño del Módulo Concentrador de Registro de Eventos (CRE) ................................ 133

3.3 Arquitectura Global del Sistema .............................................................................................................. 136 3.3.1 Diagrama funcional del SLRP ........................................................................................................... 136 3.3.2 Arquitectura básica del SLRP ........................................................................................................... 137 3.3.3 Flujo de la Información en el SLRP .................................................................................................. 149 3.3.4 Propuesta de arquitectura para el SLRP ............................................................................................ 155 3.3.5 Definición del alcance respecto los equipos y elementos por parte del CDEC y Coordinados ........ 159

3.4 Referencias............................................................................................................................................... 159

Capítulo4. MODELO DE DATOS PROPUESTO PARA EL SLRP.................................................................. 161 4.1 Introducción ............................................................................................................................................. 161 4.2 Modelo de Datos para el Módulo Concentrador de Registro de Eventos (CRE) .................................... 161

4.2.1 Antecedentes. Normativa vigente ..................................................................................................... 161 4.2.2 Formato de nombre completo............................................................................................................ 161 4.2.3 Configuración de registros oscilográficos ......................................................................................... 162 4.2.4 Nomenclatura de Señales dentro de los registros oscilográficos ..................................................... 165

4.3 Modelo de Datos para el Módulo de Acceso Remoto de Protecciones (ARP) ....................................... 171 4.4 Referencias .............................................................................................................................................. 172





Capítulo 5. ARQUITECTURA DE DETALLE. ................................................................................................. 173 5.1 Descripción de la Arquitectura Seleccionada .......................................................................................... 173 5.2 Fuentes de Datos ...................................................................................................................................... 173 5.3 Concentradores de Datos Locales ............................................................................................................ 174

5.3.1 Funcionalidades de los Concentradores de Datos ............................................................................. 175 5.3.2 Protocolos y formatos soportados ..................................................................................................... 175 5.3.3 Otras características .......................................................................................................................... 176 5.3.4 Comparativa de Productos comerciales ............................................................................................ 176

5.4 Aplicaciones............................................................................................................................................. 177 5.5 Requerimientos de los Enlaces de Comunicación ................................................................................... 180 5.6 Requerimientos para la infraestructura de TI .......................................................................................... 182

5.6.1 Lineamientos del datacenter .............................................................................................................. 182 5.6.2 Lineamientos de servidores ............................................................................................................... 182 5.6.3 Lineamientos de almacenamiento ..................................................................................................... 183 5.6.4 Lineamientos de aed .......................................................................................................................... 186 5.6.5 Lineamientos de virtualización ......................................................................................................... 189

5.7 Requerimientos para la Seguridad Informática ....................................................................................... 195 5.8 Referencias............................................................................................................................................... 197

Capítulo 6. ESPECIFICACIONES MÍNIMAS REQUERIDAS PARA LOS EQUIPOS DEL SLRP PERTENECIENTES AL COORDINADO. ........................................................................................................ 198

Capítulo 7. IMPLEMENTACIÓN DEL SLRP ................................................................................................... 202 7.1 Introducción ............................................................................................................................................. 202 7.2 Descripción de las tareas ......................................................................................................................... 202

7.2.1 Establecimiento del plan de implementación del SLRP ................................................................... 203 7.2.2 Delineamiento de los Proyectos de Coordinados .............................................................................. 204 7.2.3 Lanzamiento de Licitación para Implementación del SLRP ............................................................. 205 7.2.4 Desarrollo de Ingeniería Básica ........................................................................................................ 206 7.2.5 Desarrollo de Ingeniería de Detalle ................................................................................................... 206 7.2.6 Ensayos FAT ..................................................................................................................................... 206 7.2.7 Montaje e Integración ....................................................................................................................... 207 7.2.8 Integración de los Sistemas ............................................................................................................... 207 7.2.9 Ensayos de Sitio Integrales ............................................................................................................... 207 7.2.10 Habilitación de los Sistemas ........................................................................................................... 207 7.2.11 Marcha Blanca ................................................................................................................................ 208

7.3 Plazos ....................................................................................................................................................... 208





ANEXO I: DESCRIPCIÓN DE ARCHIVOS COMTRADE.............................................................................. 209

ANEXO II: SEGURIDAD EN LAS REDES ...................................................................................................... 216

ANEXO III: TIPOS DE DATACENTER ........................................................................................................... 224

ANEXO IV: PROGRAMA DE IMPLEMENTACIÓN DEL SLRP ................................................................... 228





ACRÓNIMOS, SIGLAS Y DEFINICIONES. Ajuste de Protecciones Corresponde a la configuración de los dispositivos de protección de

manera que operen únicamente ante la ocurrencia de fallas que se supone deben despejar, promoviendo la salida de servicio del elemento que falla u opera en forma anormal.

Automatización Transferir tareas de producción, realizadas habitualmente por operadores humanos a un conjunto de elementos tecnológicos.

Black-Out Corresponde a una pérdida total del suministro eléctrico.

Calidad de Suministro Es el conjunto de parámetros físicos y técnicos que, conforme al Reglamento y las normas técnicas pertinentes, deberá cumplir el producto electricidad. Dichos parámetros son, entre otros, tensión, frecuencia y disponibilidad.

CDEC Centro de Despacho Económico de Carga

Centro de Despacho y Control (CDC)

Ente encargado de coordinar la operación en tiempo real del conjunto de centrales generadoras y líneas de transporte de un sistema eléctrico en el que exista un CDEC.

Centro de Operación El Centro de Operación de cada empresa es el ente encargado de supervisar y operar sus propias instalaciones, en coordinación con el CDC del respectivo CDEC.

CIM Common Information Model. Estándar para la transmisión y distribución de potencia eléctrica, adoptado por la IEC y desarrollado en lenguaje UML, que permite el intercambio de información acerca las redes eléctricas entre aplicaciones de software.

CIP Protección de Infraestructura Crítica

Circuito Red eléctrica que contiene al menos una trayectoria cerrada, en las Subestaciones Eléctricas también son consideradas como los tableros eléctricos en los que se conectan e instalan los IED o RTU.

COMFEDE Common Format for Event Data Exchange, formato requerido de archivos de eventos para el intercambio de información.

COMTRADE Common Format for Transient Data Exchange, formato requerido de archivos de valores instantáneos para el intercambio de información.





Coordinados Se refiere a quien explote a cualquier título instalaciones que se encuentren interconectadas, sean estas: Centrales generadoras, Líneas de transmisión a nivel troncal, subtransmisión o adicionales, Enlaces HVDC, Líneas de interconexión entre sistemas interconectados, Equipos de compensación de energía reactiva, Equipos de compensación de energía activa, Subestaciones, incluidas las Subestaciones Primarias de Distribución, Barras de Consumo de Clientes Libres alimentados directamente desde el ST o a través de alimentadores de uso exclusivo desde barras de media tensión de SE Primarias de Distribución, o Instalaciones de Empresas de Distribución.

CRC Cyclic Redundancy Check; Tipo de chequeo de errores en paquetes de datos.

CSV Comma Separated Value, formato de archivos de texto

Data Agregation Proceso ejecutado por un PDC de construir un único set de datos a partir de múltiples fuentes.

DFR Digital Fault Recorder, Registrador Digital de Fallas

Dispositivo de Protección Dispositivo destinado a dar orden de apertura a un interruptor.

DNP 3.0 Distributed Network Protocol (Protocolo de red distribuido).

DO Dirección de Operación del CDEC

DOE Department of Energy (USA)

EDAC Esquema de desprendimiento automático de carga

EDAG Esquema de desprendimiento automático de generación

EMS Energy Management Systems

Enclavamiento Protección lógica, utilizada en las subestaciones eléctricas para la apertura o cierre de interruptores o seccionadores.

EPRI Electric Power Research Institute

Equipos de Medición Instrumentos y accesorios destinados a la medición o registro de potencia y energía eléctrica activa y reactiva, de demandas máximas de potencia o de otros parámetros involucrados en el control, supervisión y suministro de electricidad. Se consideran incluidos en estos equipos, los transformadores de corriente y de potencial, desfasadores y relojes interruptores horarios.





ERAG Esquema de reducción automática de generación

Estado de Alerta Estado del SI en el cual pese a cumplirse los rangos preestablecidos de tensión y frecuencia, por alguna causa o simple contingencia no se están cumpliendo los criterios de seguridad establecidos lo que podría afectar la continuidad de servicio frente a una segunda contingencia.

Estado de Alerta Nivel 1 Se prevé un desbalance próximo entre los recursos disponibles y la demanda, por lo que es necesario acordar en forma oportuna y programada las acciones de resguardo.

Estado de Alerta Nivel 2 Se produce intempestivamente la pérdida de un componente del Sistema, que no afecta directamente el suministro pero que requiere acciones inmediatas o muy rápidas para evitar que frente a la ocurrencia de otra contingencia, el SI entre en un estado de Emergencia.

Estado de Emergencia En este estado, el SI presenta sobrecargas en algunos equipamientos, tensiones y/o frecuencias fuera de rango, desconexión de algunos equipamientos y pérdida de algunos suministros, pero sin perder su integridad. Deben tomarse medidas urgentes e inmediatas para llevar el SI a un estado aceptable de operación y evitar que este estado se transforme en emergencia mayor. En este estado no se cumplen criterios de Seguridad.

Estado de Emergencia Mayor

En este estado, el SI presenta en forma generalizada inestabilidad, sobrecargas inaceptables en los equipamientos, tensiones y/o frecuencias nulas o fuera de rango, pérdidas de grandes consumidores, formación de islas, apertura de interconexiones, etc., perdiendo su integridad.

Estado Normal de Operación del Sistema

Cuando los consumidores están siendo servidos mediante flujos de energía dentro de la capacidad permanente de las instalaciones, tanto de generación como de transmisión y los niveles de tensión y de frecuencia están dentro de sus rangos aceptables de operación.

Flag Bandera o indicador. Usado en este documento para referirse a un elemento que genera una indicación, una alarma, un evento o acción similar.

GPS Sistema de Posicionamiento Global. Se basa en un sistema satelital que provee una señal de posición y tiempo con una precisión que puede ser menor a 1 μs.

HMI Human Machine Interface (interfaz humano-máquina).

ICCP Inter Control Center Protocol (Protocolo para la comunicación entre Centros de Control).





IEC 61850 Protocolo de comunicaciones, estandarizado por el International Electrotechnical Commission (Comisión Electrotécnica Internacional).

IED Intelligent Electronic Device (Dispositivo electrónico inteligente).

IEEE 1588 V2 Perfil Sistemas de Potencia

Estándar para el Protocolo de Precisión de Reloj de Sincronismo aplicado en Redes de Comunicaciones de Sistemas de Control y Medición.

IEEE C37.239-2010 Common Format for Event Data Exchange (COMFEDE) for Power Systems

IEEE C37.111 Estándar que especifica el Formato Común para el Intercambio de Datos Transitorios (COMTRADE) en sistemas de potencia.

IEEE C37.278 PTP ("Perfil Sistemas de Potencia")

Perfil para la utilización del estándar IEEE 1588 Protocolo de Precisión de Tiempo en aplicaciones de Sistemas de Potencia.

IEEE C37.238-2011 Perfil para la utilización del estándar IEEE 1588 Protocolo de Precisión de Tiempo en aplicaciones de Sistemas de Potencia.

IEEE C37.240-2014 Estándar de Requisitos de seguridad cibernética para Automatización, Protección y Control de Sistemas de Potencia

Instalación Eléctrica Conjunto de elementos de una red eléctrica que se encarga de un rol específico dentro de la misma (a saber, generación, transmisión y distribución)

Integración Recopilar los datos de los diferentes IED’s y RTU’s en el sistema SCADA local.

Interoperabilidad Que dos o más IED’s puedan intercambiar valores y funciones operativas entre ellos.

Lenguaje SCL Lenguaje de programación de IED que usan el protocolo IEC 61850.

MODBUS Protocolo de comunicaciones basado en la arquitectura maestro/esclavo.

NT SyCS Norma Técnica de Seguridad y Calidad de Servicio de la Comisión Nacional de Energía. Ministerio de Energía. Gobierno de Chile.

Periodicidad Intervalo de tiempo en el cual serán intercambiados los puntos.

Protocolo Método establecido para el intercambio de datos entre equipos electrónicos.





Relé IED que cumple diversas funciones dentro de la S/E.

RTU Remote Terminal Unit (Unidad terminal remota). Corresponde a un dispositivo que permite en tiempo real, tanto la recolección de información de campo como la emisión de comandos, hacia y desde el centro de control supervisor.

SCADA (Sistema de Control y Adquisición de Datos)

Supervisory Control And Data Acquisition (supervisión, control y adquisición de datos). Es un conjunto de equipos (hardware) y programas (software) que permiten la supervisión y control del sistema eléctrico.

Sistema Eléctrico Conjunto de instalaciones de centrales eléctricas generadoras, líneas de transporte, subestaciones eléctricas, líneas de distribución, interconectadas entre sí, que permite generar, transportar y distribuir energía eléctrica

SI Sistema Interconectado.

SIC Sistema Interconectado Central.

SING Sistema Interconectado del Norte Grande.

SLRP Sistema de Lectura Remota de Protecciones que corresponde al Módulo de Registro de Protecciones Eléctricas que establece el Anexo Técnico Sistema de Monitoreo

SM Sistema de Monitoreo.

Subestación Eléctrica (S/E)

Conjunto de instalaciones eléctricas (transformadores, aisladores, interruptores, etc) y de infraestructura (terreno, edificio, etc), que sirven para transferir energía, transformar voltajes, recibir y entregar energía y suministrar electricidad a consumos.

Tasa de muestreo Número de muestras por segundo que se obtienen en el proceso de conversión de las señales análogas en señales digitales.

UTC Tiempo Universal Coordinado. Corresponde al tiempo de la zona horario de referencia respecto a la cual se calculan todas las otras zonas (longitud 0º).





PARTE A

ESTADO DEL ARTE DE LOS SLRP





Capítulo 1. INTRODUCCIÓN

Según la normativa vigente NT SyCS, “Es necesario disponer de un Sistema de Medición permanente en los puntos del Sistema Interconectado que la Dirección de Operaciones del CDEC determine, que permita verificar el desempeño de las instalaciones en estados de operación como también en estados de contingencia. Además, el SM está conformado por los módulos Registro de Señales, Registro de Protecciones Eléctricas y Medición Fasorial”.

Las diversas tecnologías aplicadas en los procesos de generación, transmisión y distribución de la energía eléctrica se encuentran en constante desarrollo. Este desarrollo no solo afecta a las tecnologías propias de los sistemas eléctricos de potencia sino también a todos los sistemas auxiliares que son necesarios para brindar un confiable y seguro suministro de energía a los usuarios. Entre estos sistemas, son de nuestro interés y motivo del presente estudio los sistemas de monitoreo de estaciones.

El desarrollo de los sistemas de monitoreo de estaciones nos ha permitido contar con la posibilidad de realizar un número mayor de tareas y obtener mayor información de los sistemas eléctricos a medida que las tecnologías han evolucionado. Estas mejoras han implicado, por otra parte, un desafío (tanto económico como tecnológico) en cuanto a los esfuerzos de modernización e integración en equipos, enlaces, instalaciones auxiliares, etc., necesarios para que esto sea posible. El sorteo de estos desafíos conduce indudablemente a un mejor conocimiento, un mayor control, una mayor predictividad y un mejor tratamiento del sistema eléctrico y de los problemas que este pudiese presentar.

Según la normativa vigente en el SIC y el SING, NT SyCS, Ës necesario disponer de un Sistema de Medición permanente en los puntos del Sistema Interconectado que la Dirección de Operaciones del CDEC determine, que permita verificar el desempeño de las instalaciones en estados de operación como también en estados de contingencia¨. Atendiendo a esta normativa los organismos CDEC SIC y CDEC SING han propuesto la implementación de un Sistema de Lectura Remota de Protecciones (SLRP), cuyo alcance está descripto en el documento ¨Términos de Referencia – Estudio de Diseño, Especificación y Programa para la Implementación del Sistema de Lectura Remota de Protecciones del SIC¨.

El propósito principal del presente estudio es modelar conceptualmente y elaborar las especificaciones técnicas y programa de implementación del Módulo de Registro de Protecciones





Eléctricas a emplear en el Sistema Interconectado de Chile, dotando al CDEC de toda la documentación necesaria para su implementación.

En el presente informe, correspondiente a la etapa A Ëstado del Arte de los Sistema de Lectura Remota de Protecciones¨. En esta etapa se presenta un panorama general sobre los estándares y mejores prácticas utilizados en la actualidad en la industria de monitoreo de estaciones eléctricas. En el mismo se estudiarán arquitecturas y procedimientos clásicos para la toma de datos y eventos en los equipos que controlan, protegen y monitorean los sistemas eléctricos, teniendo en cuenta no solo la integración al sistema de los equipos actuales, sino también obtener un sistema flexible para expansión a futuro.

La Segunda Sección considera los problemas que existen en la integración de equipos de medición, control y monitoreo de un sistema eléctrico complejo. Se introduce también, a los modelos de redes de datos comúnmente utilizados, como a los problemas de flexibilidad, auditoría y escalamiento que se enfrentan hoy en día en este tipo de instalaciones.

La Tercera Sección se encarga del análisis detenido de los distintos protocolos de comunicación disponibles actualmente, sus propiedades más relevantes, grado de adopción y nivel de expansión a futuro.

La Cuarta Sección realiza un análisis detallado de los dispositivos involucrados en la captación (protecciones), centrando la atención en las variables medidas, eventos registrados, características eléctricas, interfaces mecánicas, soporte técnico, etc.

La Quinta Sección presenta un análisis profundo sobre los diversos estándares de seguridad existentes, las mejores prácticas empleadas por los distintos segmentos de la industria y su aplicación en el campo de aplicación de las Instalaciones Eléctricas.

En la Sexta Sección se revisan las nuevas tendencias en automatización de redes eléctricas, las topologías propuestas por los distintos fabricantes y concluye con la propuesta de una opción superadora.

Finalmente se presentan los puntos de sugerencia y conclusiones del estudio de investigación desarrollado.





Capítulo 2. AUTOMATIZACIÓN ACTUAL DE LAS INSTALACIONES ELÉCTRICAS

2.1 Introducción

En el pasado, la automatización de instalaciones eléctricas (control, supervisión, adquisición de datos, etc.) se ha llevado a cabo integrando equipos de un único fabricante por medio de protocolos propietarios. Este enfoque ha sido aplicado sin grandes inconvenientes, ya que las instalaciones no eran de gran tamaño y las manejaba un único agente, el cual normalmente no percibía perjuicio alguno.

Esta tendencia ha perdido fuerza en los últimos años con el surgimiento de desafíos complejos, como la generación distribuida y las energías renovables. En esta clase de proyectos es común que se instalen equipos provenientes de distintos fabricantes en todos los niveles. Es imprescindible lograr integrar estos equipos en sistemas robustos y confiables resguardando una correcta operación de todo el sistema. A tales fines, es primordial la adopción de protocolos abiertos que garanticen la interoperabilidad entre los fabricantes de todos los subsistemas involucrados.

Un desafío de particular relevancia, dada la creciente ola de automatización de las redes eléctricas y la integración de los dispositivos inteligentes a las redes de computadora, es el de garantizar la seguridad del sistema de información. Se destaca esto, debido a que cualquier vulnerabilidad puede resultar en el acceso a información confidencial, daños en los equipos de campo e incluso en la disrupción del servicio.

Es necesario resaltar las influencias de la interrupción del servicio como consecuencia de una política de seguridad negligente, dado que una gran cantidad de industrias, individuos y sistemas económicos completos dependen del correcto funcionamiento del suministro eléctrico. En la siguiente figura se detallan las dependencias entre servicios.

Otro factor a tener en cuenta al momento de diseñar soluciones de esta índole, es el análisis de la diversidad de protocolos involucrados, tratando de lograr la mayor integración con un menor número de ellos. Por último, se hace necesario incluir solo aquellos protocolos expandibles y con soporte a largo plazo, para sectores donde se planea extender el sistema, y en su defecto, integrar otros protocolos tradicionales por cuestiones de compatibilidad.





Figura 1. Dependencia entre servicios.

2.2 Niveles de Automatización

Un modelo de gran utilidad a la hora de analizar las redes de datos utilizadas en entornos industriales, es el modelo S95 o modelo de Purdue. Este modelo fue desarrollado por el Comité ISA99 (Manufactura y Seguridad de Sistemas de Control) de la Sociedad de Automatización y nos provee de una jerarquía y nomenclatura ampliamente utilizadas en redes de automatización de procesos.

Nivel de Dispositivos de Campo (Nivel 0)

El nivel 0 incluye los sensores, actuadores y demás elementos que se encuentran en contacto inmediato con el proceso productivo. Generalmente es un nivel que contiene dispositivos con requerimientos eléctricos/mecánicos elevados y con un acceso por parte de personal bastante restringido.

En seguridad de redes está dentro de lo que se conoce como zona de confianza, por lo que los mecanismos de seguridad aplicados a este nivel suelen ser bastante modestos.

En este nivel se encuentran dispositivos como: Interruptores, Seccionadores, Transformadores de Medición, entre otros. Estos dispositivos son controlados por los elementos que se encuentran en el nivel 1.





Nivel de Control de Procesos (Nivel 1)

El nivel 1 incluye los equipos de control de procesos, los cuales reciben datos de los sensores y envían acciones de control a los actuadores correspondientes. Es común también, que varios equipos de este nivel cooperen para tomar decisiones y acciones en conjunto. Los equipos en este nivel suelen estar interesados en la seguridad funcional de los elementos de campo y su correcta operación continua.

En cuanto la seguridad de redes, en este nivel se produce un incremento de la misma, generalmente mediante el uso de gateways/rtus que aíslan la red de sensores/actuadores de la red de supervisión, agregando algún mecanismo de autenticación y cifrado.

En este nivel es donde se encuentran generalmente las Unidades de Terminal Remota (RTUs), los Controladores Lógicos Programables (PLCs) y otra multitud de Dispositivos Electrónicos Inteligentes (IEDs). Estos dispositivos son configurados y controlados por los elementos que se encuentran en el nivel 2.

Figura 2. Modelo de Purdue.





Nivel de Supervisión de Área (Nivel 2)

El nivel 2 incluye los equipos de control de un sector de producción.

En este nivel es donde se encuentran los Sistemas de Control y Adquisición de Datos (SCADAs), las Interfaces Humano Máquina (HMIs) y las estaciones de trabajo de la sala de control (OWSs).

Aquí los mecanismos de seguridad son más estrictos dado que presentan accesos de personal más frecuentes. Estos equipos pueden comunicar datos a los sistemas ubicados en el Nivel 3 generalmente a través de una conexión segura.

Nivel de Operaciones y Control (Nivel 3)

El nivel 3 incluye los sistemas involucrados en la obtención y control de calidad del producto deseado.

En este nivel se encuentran los centros de control remotos o centros de recolección de datos a mayor escala, que suelen estar alejados físicamente del sistema de supervisión principal.

En este nivel los mecanismos de seguridad son similares a los del nivel anterior requiriendo de una conexión segura entre ambos.

Nivel de Planeamiento y Logística (Nivel 4)

En este nivel se encuentra la infraestructura de sistemas informáticos involucrada en tareas de reporte, manejo de inventario, correo electrónico, telefonía y servicios de impresión.

Los sistemas de este nivel se encuentran normalmente bajo la supervisión del sector de servicios informáticos (IT), que implementaran mecanismos de seguridad que involucran firewalls, que delimitan la zona no segura o desmilitarizada (DMZ), separando la red interna de la red externa.

Nivel Corporativo (Nivel 5)

En este nivel se encuentran la totalidad de las aplicaciones y sistemas de infraestructura, los sistemas de acceso remoto y el servicio de internet, entre otros.

En general se intenta minimizar la interacción de este nivel con todos los niveles inferiores dado el riesgo que representa un incidente de seguridad informática.





Equivalencias entre el modelo de Purdue y el modelo aplicado a Subestaciones

En el siguiente gráfico se puede observar un modelo que se aplica típicamente al análisis de los niveles de automatización en subestaciones. El mismo se puede ver como un subconjunto de los niveles que se encontraban en el modelo de Purdue.

Figura 3. Modelo típico de Automatización de una estación.

Las equivalencias entre el modelo de seis niveles de Purdue y el modelo de cuatro niveles utilizado en el análisis de subestaciones son:

El nivel de dispositivos de campo (nivel 0) se conoce como nivel de proceso (Process level).

El nivel de control de procesos (nivel 1) suele denominarse nivel de bahía (Bay level).

El nivel de supervisión de área (nivel 2) se designa como nivel de estación o nivel de subestación (Station level).

El nivel de operaciones y control (nivel 3) se menciona comúnmente como el nivel de centro de control (Control center level).





Adicionalmente, es común referirse a los dispositivos por medio de la red de mayor jerarquía a la cual se encuentran conectados, por lo tanto, también es importante notar las siguientes definiciones:

El bus de procesos (Process bus) se refiere a la red que conecta los dispositivos de nivel de procesos con los correspondientes dispositivos de nivel de bahía.

El bus de subestación o bus de estación (Station bus) se refiere a la red que conecta los dispositivos de nivel de bahía con los de nivel de estación.

A lo largo del siguiente texto, se hará referencia a los niveles y buses de este último modelo, a menos que se indique lo contrario.

2.3 Necesidad de Integración de Dispositivos

Los requerimientos impuestos por las tendencias actuales en materia de generación, distribución y transmisión de energía eléctrica exigen que nos planteemos como se deben integrar los equipos en una instalación eléctrica y que características son realmente relevantes a la hora de realizar dicha integración. A continuación se mencionan los aspectos que deben ser tenidos en cuenta.

Un aspecto importante es la capacidad de configurar los equipos. Hoy día, la mayoría de los equipos requieren de software específico de cada fabricante para su configuración, esto implica que se deba abrir un programa diferente por cada equipo que se integra a la red y atenta contra nuestra capacidad de visualizar la configuración de la instalación como un conjunto. Afortunadamente, se está trabajando para revertir esta tendencia y permitir que la totalidad de los dispositivos se puedan configurar con un único software, indistintamente del fabricante.

Si bien la capacidad de configurar la totalidad de los equipos de una instalación eléctrica desde una misma aplicación puede parecer una cuestión trivial, en la práctica se cometen muchos errores debido a discrepancias en las configuraciones, producto de no contar con una política unificada en el manejo de los dispositivos. Adicionalmente, contar con mecanismos estándar para la configuración de todo el equipamiento involucrado, posibilita que tanto el operador como un tercero puedan corroborar que los equipos estén configurados acordes a lo estipulado, permitiendo que los sistemas puedan ser debidamente auditados.

Por último, otro aspecto que es necesario destacar, es la interoperabilidad entre equipos. Una práctica muy común cuando se realizan grandes proyectos es obtener todos los equipos a través de un único





fabricante. Esto parece razonable en primera instancia, pero no contempla la posibilidad de imprevistos tales como cambios de requerimientos, modernización de equipos o quiebra del fabricante. Afortunadamente, los estándares más modernos garantizan la interoperabilidad, permitiéndonos cambiar de fabricante si la situación así lo requiere.

2.4 Necesidad de Comunicación entre Instalaciones

La comunicación entre instalaciones es beneficiosa a la hora de optimizar el funcionamiento de la red eléctrica a gran escala o en área amplia, ya que nos permite conocer con exactitud el estado operativo de cada uno de los sistemas involucrados y responder de la mejor manera posible en caso de contingencia.

Recientemente, varios países han notado las ventajas que implica contar con esta información, no solamente para el análisis de fallas puntuales y la operación minuto a minuto, sino también para el planeamiento de proyectos de expansión y diseño de medidas de regulación/facturación.

Adicionalmente, cada uno de los agentes encargados de la operación y mantenimiento de las instalaciones eléctricas se beneficia al contar con esta información adicional a la hora de analizar las causas de una falla, incluso con la posibilidad de cooperar entre sí.

Otro aspecto importante del acceso inmediato y permanente a los datos de operación de todos los agentes involucrados, es que permite a los entes reguladores la implementación de programas que sean capaces de calcular de manera automática métricas (disponibilidad, eficiencia, etc.), computar las penalidades asociadas y generar reportes según corresponda.

Además de la integración horizontal que se ha planteado hasta ahora, es muy útil integrar los centros de control y demás instalaciones en sistemas multinivel (integración vertical). Esta forma de integración permite a los centros de control de mayor nivel explorar datos y configuraciones provenientes de otros equipos ubicados debajo de él, simplificando notablemente las tareas administrativas y facilitando la auditabilidad de configuraciones.

Para lograr integración de instalaciones es de vital importancia tener en cuenta los estándares que existen actualmente para tal propósito, considerando cuidadosamente los sistemas que pudieran encontrarse ya implementados en otras partes del mundo.





2.5 Referencias

Ethernet Design Considerations for Control System Networks - Rockwell Automation.

Ethernet-to-the-Factory 1.2 Design and Implementation Guide - Cisco.

Secure Architecture for Industrial Control Systems - Sans Institute.

Application of Ethernet Fieldbus to Substation RTU and Automation Networks - David Dolezilek, Francisco Chumbiauca, and Michael Rourke.

Automatización de una Subestación Eléctrica utilizando el Protocolo IEC 61850 y el ICCP para el envio de Datos - Marco Antonio Toscano Palacios.

Propuesta de Automatización de una Subestación Eléctrica de Distribución - Chávez Mosqueda Gerardo.

Substation Automation Process Bus - ABB.

IEC 61850 Multivendor Substation Applications: What's Working in Europe? . Fernando Matos and Rogério Paulo.

Integración perfecta - Antonio Carvalho, Johan Hansson.





Capítulo 3. PROTOCOLOS DE COMUNICACIÓN

3.1 Introducción

Hoy en día, los dispositivos que pertenecen a una instalación eléctrica necesitan una manera estandarizada de dialogar para poder intercambiar información que les permita llevar a cabo sus funciones. Al conjunto de convenciones que posibilita esta comunicación se lo conoce con el nombre de protocolo. Entre las convenciones se definen ciertas reglas que pueden ser físicas (niveles de tensión, formas de onda, medio de propagación, etc.), o lógicas (formato de tramas, control de errores, reintentos, temporización, modelo de datos, etc.).

Para emitir un juicio de valor de un protocolo sobre otro, es necesario conocer un conjunto de métricas y criterios que permiten evaluarlos. Es por esto, que se comenzará por una introducción al modelo de interconexión de sistemas abiertos (ISO/OSI), el cual divide las funcionalidades de los protocolos en capas, permitiendo su análisis y comparación.

Luego, se verán en detalle algunos de los protocolos más usados en la industria eléctrica, ya sea porque son considerados tradicionales y es muy probable encontrarlos en equipos ya instalados, o porque son nuevos estándares que demuestran solidez y permanencia a largo plazo.

Vale destacar que en la industria encontramos dos clases de protocolos:

Protocolos propietarios: Diseñados por un fabricante, que no publica las convenciones de la comunicación, y sólo prevé el funcionamiento de manera exclusiva con sus equipos (SIEMENS, ABB, GE, etc).

Protocolos abiertos: Diseñados por un conjunto de fabricantes o individuos, que publican las convenciones de la comunicación y prevén interoperabilidad entre marcas.

La principal desventaja que se observa en el uso de los protocolos denominados propietarios es que los mismos mantienen cautivo al usuario, ya que en principio son incompatibles con los productos de los demás fabricantes que se encuentran en el mercado. Por cuestiones de competitividad, y para mejor, los fabricantes han tenido que ceder e implementar, además de sus propios protocolos, protocolos abiertos que permitan integrar sus productos a sistemas ya vigentes.





En la presente sección se analizarán los protocolos abiertos más relevantes para el sector eléctrico (Modbus, ICCP, IEC 61850, entre otros), sus características principales y sus funciones más destacadas. Adicionalmente, se analizan a modo de ejemplo, distintos equipos del mercado, con el fin de comprender las posibilidades y limitantes de cada protocolo en un caso práctico.

Para finalizar, se buscará establecer conclusiones sobre cada protocolo y determinar dentro de qué parte del problema del “monitoreo de protecciones” aplicarían.

3.2 Modelo OSI

El modelo de interconexión de sistemas abiertos (ISO/IEC 7498-1), más conocido como modelo OSI, es un modelo de referencia para los protocolos de red, creado en el año 1980 por la Organización Internacional de Normalización (ISO).

El modelo OSI define en 7 capas el proceso de transmisión de la información, donde cada capa se encarga de realizar una parte del proceso total. Proceso que, aún siendo completamente teórico, puede utilizarse para describir y estudiar un sin número de protocolos reales utilizados en la interconexión de sistemas.

Figura 4. Modelo OSI.





Las capas del modelo se ordenan según niveles de abstracción, donde las capas de abajo ofrecen servicios a las capas de arriba y abstraen a las mismas de ciertos detalles de la información.

La comunicación entre capas se realiza solo través de interfaces bien definidas que deben ser respetadas para que la comunicación tenga éxito. Sin embargo, los detalles de implementación de cada capa pueden variar de un sistema a otro.

Este último punto, es lo que hace a este modelo tan interesante, permitiendo la interconexión de sistemas que presentan grandes diferencias en procesamiento, memoria, sistema operativo, codificación interna de datos, etc.

La primera capa (nivel físico) se encarga de la transmisión y recepción de una secuencia no estructurada de bits sin procesar, provenientes de la capa de enlace de datos, a través de algún medio físico (cobre, fibra óptica, etc.). En esta capa se definen las características eléctricas y mecánicas del protocolo. Es decir que se especifican convenciones tales como niveles de tensión, forma de las señales, velocidad de datos físicos, distancias de transmisión, conectores a utilizar y otros atributos similares.

La segunda capa (nivel de enlace de datos) ofrece una transferencia sin errores de tramas de datos desde un nodo a otro a través de la capa física, permitiendo a las capas superiores asumir virtualmente que la transmisión se da sin errores. Esta capa se ocupa del direccionamiento físico de cada nodo, del acceso al medio en caso de múltiples nodos, de la detección de errores, de la distribución ordenada de tramas y del control del flujo.

La tercera capa (nivel de red) se encarga traducir las direcciones lógicas (direcciones IP, etc.) en direcciones físicas (dirección de hardware de tarjeta de red MAC, etc.). También se encarga de determinar la ruta por la cual deben viajar los datos hasta la dirección de destino. Otro problema que suele solucionar esta capa es la interconexión de redes heterogéneas, solucionando problemas de incompatibilidad de protocolos y traducción de direcciones en diferentes dominios.

La cuarta capa (nivel de transporte) acepta los datos de la capa superior y los divide en unidades más pequeñas acorde a la arquitectura de red, asegurando que todos los segmentos lleguen de forma ordenada a la dirección de destino. En esta capa se encuentran las funcionalidades que intentan dar confiabilidad y calidad de servicio a la transmisión.

La quinta capa (nivel de sesión) se encarga de establecer, gestionar y finalizar el diálogo entre nodos participantes de la comunicación. Una vez establecida la comunicación entre nodos, esta capa se





encarga de ubicar puntos de control en la secuencia de datos, que permitirán luego, retomar la operación en caso de una falla que termine finalizando la sesión actual.

La sexta capa (capa de presentación) está destinada a dar formato a los datos de aplicación convirtiéndolos a un sistema genérico, cuya representación sea legible por todos los nodos de la red. También es la encargada de funciones más avanzadas, como la encriptación y compresión de datos extremo a extremo.

La séptima capa (nivel de aplicación) proporciona la interfaz y servicios de red a las distintas aplicaciones del usuario. Define un conjunto de funciones primitivas que le sirven al implementador para construir una aplicación dada que haga uso total o parcial del protocolo. Vale aclarar, que el usuario nunca interactúa directamente con la capa de aplicación, sino que lo hace con los programas que hacen uso de la misma.

3.3 Modelo TCP/IP

El modelo TCP/IP es una descripción de protocolos de red desarrollado por Vinton Cerf y Robert E. Kahn en la década de 1970. TCP/IP provee conectividad de extremo a extremo, especificando como los datos deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario.

Si lo comparamos con el modelo OSI, este modelo combina las capas de sesión y presentación en conjunto con la capa de aplicación (Application layer). Además, combina también la capa física con la capa de enlace de datos y las denomina capa de acceso a red (Network access layer). Por último, la capa de red cambia su nombre a capa de internet (Internet layer), resultando en un modelo de 4 capas, mostrado en la figura 5.

La capa de enlace de red define todos los procedimientos para conectar dos o mas nodos de red cercanos, sin la intervención de routers de por medio. Esta capa dependerá del medio físico sobre el cual se soporte la red (Ethernet, Wireless, Fibra óptica) y deberá definir los mecanismos de acceso al mismo en caso de que muchos nodos lo compartan. Son protocolos de nivel de enlace: ARP, MAC, PPP, entre otros.

La capa de internet define el direccionamiento y enrutamiento de los datos a través de toda la red, abstrayendo a las capas superiores de la estructura física real que ésta presenta. Uno o más nodos





enrutadores serán los encargados de hacer llegar los datos desde la dirección lógica de origen hacia la dirección lógica de destino. Son protocolos de nivel de internet: ICMP, IPv4, IPv6, entre otros.

Figura 5. Modelo de cuatro capas TCP/IP

La capa de transporte provee un canal de comunicación entre aplicaciones a través de la red, garantizando cierto grado de confiabilidad o calidad de servicio en los mensajes. Son protocolos de nivel de enlace: TCP, UDP, entre otros.

La capa de aplicación provee los métodos para crear datos de usuario, formatearlos y transmitirlos a otra aplicación conectada a la red, utilizando las funcionalidades de las capas inferiores. Son protocolos de nivel de aplicación: SSH, SNMP, NTP, FTP, HTTP, SHTTP, entre otros.

El modelo TCP/IP es muy útil para describir un subconjunto de protocolos muy usados en los dispositivos electrónicos que necesitan conectarse a internet. Más precisamente, muchos de los equipos utilizados en redes de datos de subestación, disponen de protocolos que pueden ser modelados de esta manera, por lo cual es necesario tener en claro este modelo para comprender los siguientes temas a abordar.





3.4 Modbus

3.4.1 Introducción

El protocolo de aplicación industrial Modbus, fue creado por la empresa Modicon en 1979 para su utilización en PLCs. Debido a su simpleza en la implementación, resulta muy atractivo para los dispositivos que disponen de hardware limitado en recursos.

Su especificación define varias modalidades. La modalidad RTU es de arquitectura maestro-esclavo y está generalmente implementada sobre una capa física RS232 o en su defecto RS485. Luego, con la necesidad de una mayor velocidad de datos surgió la modalidad TCP, cuya arquitectura es cliente-servidor y está soportada sobre la capa física Ethernet. Por último, existe una tercer variante denominada ASCII que a diferencia de RTU, utiliza una representación de caracteres para los datos.

En todas las modalidades los dispositivos se comunican uno a uno, mediante una solicitud de datos y esperan su respuesta a la misma. Esto significa que si la red está formada por varios dispositivos, existirá un maestro de la comunicación que solicitará datos de aplicación a cada uno mientras el resto deberá esperar. Esta sería una de las claras desventajas del protocolo, sobre todo para aplicaciones que necesiten acusar eventos con rapidez (por ejemplo: Aplicación de detección de fallas con su asociada acción correctiva).

Desde el punto de vista del modelo de datos, la especificación sólo define el enmarcado de los mismos. Es decir que existe una parte del paquete (tanto en la solicitud como en la respuesta) que lleva la dirección del dispositivo de destino junto con un código de función a ejecutar en él (por ejemplo: lectura de un conjunto de registros). Pero en ningún caso se rigidiza la representación de esos datos en la carga útil y eso correrá por cuenta de la implementación. Si bien esto último puede sonar bastante flexible y permite la utilización del protocolo en una gran cantidad de aplicaciones, realmente complica bastante el modelado de sistemas más complejos como son los sistemas eléctricos.

Un detalle importante a tener en cuenta es que el enmarcado de datos no contempla la asociación de una estampa de tiempo en origen al dato en cuestión, y esto dificulta la correlación temporal de datos generados en diferentes puntos de la red. Si bien Modbus es un protocolo extensible y existen maneras de implementar esta funcionalidad en la capa de aplicación (Por ejemplo: definiendo una estructura de datos que incluya la estampa junto con los registros en la respuesta), complica considerablemente el diseño y no resuelve los problemas de interoperabilidad entre fabricantes.





3.4.2 Formato de Tramas

Dependiendo de la modalidad del protocolo y sus variantes (o incluso extensiones), las tramas de solicitud y respuesta pueden llegar a diferir bastante. Esto se debe a que según las capas inferiores del protocolo en las que quede soportada la modalidad (RTU o TCP), podría permitir o no una transferencia de las responsabilidades de sincronización, direccionamiento o incluso control de errores hacia las mismas.

Figura 6: Comparación entre las Tramas de las Modalidades RTU y TCP.

Como puede observarse en las tramas de la figura 6, ambas comparten el campo del código de función (FCode) y el campo de datos (Data) cuyas características como longitud y tipo dependen de la función solicitada.

Por otro lado, puede inferirse que la modalidad RTU (como también sucede en la modalidad ASCII) requiere de un control de integridad adicional propio de la aplicación soportada en un bus serial (CRC), a diferencia de la modalidad TCP donde este control recae en las funcionalidades de las capas inferiores. Esto se debe a que el protocolo TCP/IP prevé mecanismos para asegurar la integridad del mensaje y no es necesario implementarlos en las capas superiores.

También se observa que el direccionamiento de los mensajes se produce de manera diferente en ambos casos. En la modalidad RTU, todos los dispositivos están a la escucha del bus serie y solo interpretará la función aquel que tenga la dirección de esclavo coincidente con la solicitud (SlavID). En la modalidad TCP, primero se producirá la transferencia del mensaje a través de los elementos enrutadores de la red IP con ayuda de la cabecera de enrutamiento TCP, hasta llegar a equipos que





pueden llegar a soportar uno o más dispositivos Modbus identificados mediante el identificador de unidad (UnitID).

3.4.3 Funciones Soportadas

El protocolo Modbus no define un modelo de datos particular y se basa en un modelo de registros. Los dispositivos electrónicos esclavos/servidores que hagan uso del protocolo, podrán o no soportar todas las funciones definidas en la especificación, pero en su mayoría se encargaran de mapear un conjunto de variables, comandos, parámetros, etc. a una tabla de registros dentro de su memoria interna. Luego habrá una entidad intérprete (pieza de software) que recibirá las tramas desde el dispositivo maestro/cliente y decodificará la función a ejecutar para construir la respuesta obteniendo los datos de esa tabla.

Las funciones definidas se pueden clasificar en tres grandes grupos ordenados por su código de función:

Figura 7: Clasificación de Funciones en Modbus.

Funciones públicas: Las cuales garantizan la interoperabilidad entre dispositivos dado que el código de las mismas es único y está bien documentado. Entre ellas podemos citar:

Funciones de acceso a datos:

Lectura individual de bit o entrada.





Escritura individual de bit o salida.

Lectura múltiple de bits.

Escritura múltiple de bits.

Lectura individual de registros.

Escritura individual de registros.

Lectura de archivos.

Escritura de archivos.

Lectura de cola circular (FIFO).

Funciones de diagnóstico:

Lectura de estados.

Lectura de eventos.

Lectura de identificación de dispositivos.

Otras funciones:

Interface para encapsulamiento de datos.

Funciones de usuario: Las cuales permiten extender el protocolo agregando códigos de función propios del fabricante y ampliar las funcionalidades del dispositivo.

Funciones reservadas: Las cuales no debieran ser utilizadas por el usuario y generalmente definen funcionalidades de transporte para otros protocolos (por ejemplo: CANopen).

La siguiente tabla de referencia muestra los códigos de función para las funciones públicas como también la sección dentro de la especificación donde esta se detalla:





Figura 8: Códigos de función para las funciones públicas.

3.4.4 Casos de Uso

El relé modular gestor de transformador (Transformer Management Relay) GE T60 es muy usado entre los equipos de protección relevados por el CDEC y tiene implementado Modbus esclavo en sus modalidades RTU y TCP (dependiendo del modelo). Este equipo representa un 17% del total de los equipos relevados, por lo cual es atractivo para su análisis.

En el manual de usuario del relé se destaca el soporte de las siguientes funciones públicas, las cuales son útiles para configurar, leer variables y obtener el estado del equipo:

Lectura de valores actuales mediante el uso de las funciones 0x03 (Read Holding Registers) y 0x04 (Read Input Registers).

Lectura de parámetros mediante el uso de las funciones 0x03 (Read Holding Registers) y 0x04 (Read Input Registers).

Ejecución de operaciones mediante la función 0x05 (Write Single Coil).





Cambiar un parámetro mediante la función 0x06 (Write Single Register).

Cambiar un bloque de parámetros mediante la función 0x10 (Write Multiple Registers).

Figura 9: Foto de Relé GE T60

Con este pequeño juego de funciones primitivas se puede obtener información de utilidad sobre cada módulo del relé, como ser:

Corrientes de cada fase (en magnitud y ángulo), corriente de tierra, corrientes de falla a tierra, corrientes de secuencia cero, positiva o negativa (en magnitud y ángulo).

Voltajes de cada fase (en magnitud y ángulo), voltajes de secuencia cero, positiva o negativa (en magnitud y ángulo).

Potencia activa (por fase y trifásica), potencia reactiva (por fase y trifásica), potencia aparente (por fase y trifásica), factor de potencia (por fase y trifásico).

Contadores de energía.

Frecuencia.

Demanda de corrientes.

Componentes armónicas y distorsión.

Estado de entradas digitales y entradas analógicas (por ejemplo: RTDs).

Reportes de fallas y eventos.





Adicionalmente, el mismo juego de funciones primitivas permite modificar configuraciones en el relé, como ser:

Parámetros de comunicaciones en todos los protocolos soportados (direcciones, velocidad de datos, factores de escala, etc.).

Ajustes de reloj (fecha y hora), y señales de sincronización (IRIG-B, SNTP).

Frecuencias de muestreo.

Parámetros de histogramas y oscilografías.

Parámetros de los TP y TC (relación de transformación y escalamiento).

Parámetros de transformador.

Por último y no menos interesante, el relé permite la obtención de archivos oscilográficos e histogramas en formato COMTRADE solo mediante el uso de las funciones de lectura/escritura múltiple.

3.4.5 Conclusiones

Modbus es un protocolo bastante simple por lo que es muy probable encontrarlo en gran variedad de dispositivos hoy en día. Incluso en aquellos dispositivos más nuevos que implementan protocolos avanzados pero aún lo preservan por una cuestión de compatibilidad. Es por ello que si se desea planear una topología de sistema flexible en cuanto a marcas y modelos de equipos que la conforman, se deberá tener en cuenta un punto de unión a este protocolo, ya sea en forma directa o mediante la utilización de conversores de protocolos (gateways).

No obstante, hay que tener en cuenta que la utilización de Modbus en la rama eléctrica es cada vez menor por las siguientes razones:

Velocidad de datos muy baja con respecto a otros protocolos.

No incluye soporte directo para estampas de tiempo.

No incluye un modelo de datos de aplicación y su implementación por fuera del protocolo lo torna poco práctico.





La naturaleza de la comunicación en caso de múltiples esclavos (polling) lo hace inviable para el acuse de eventos rápidos.

En el caso de la modalidad TCP, las latencias introducidas por los enrutadores, como la naturaleza de la red IP, lo hacen inviable para aplicaciones de tiempo real.

No ofrece seguridad alguna y la implementación de encriptación y niveles de usuario por fuera del protocolo lo torna poco práctico.

Por lo anteriormente expuesto, se concluye que para que un sistema de comunicación heterogéneo sea flexible debe incluir el soporte para dispositivos Modbus, pero sin atarse al mero uso del mismo. Menos aún en el caso de las redes eléctricas donde la seguridad informática, los tiempos de respuesta, los modelos de datos complejos y la correlación temporal de variables, entre otros conceptos, son claves y no se deben obviar.

3.5 DNP 3.0

3.5.1 Introducción

El protocolo DNP3 (Distributed Network Protocol) fue desarrollado por la empresa Westronic en el año 1993 como necesidad de adelantarse a la salida del standard IEC 60870-5. Es un protocolo diseñado para optimizar las comunicaciones entre subestaciones y centros de control/supervisión para los sistemas eléctricos.

Aunque la especificación no define una capa física en especial, e históricamente se lo puede encontrar implementado sobre RS-232 y RS-485, la tendencia de hoy en día será utilizar enlaces de tipo Ethernet/Fibra debido no solo a la velocidad de datos alcanzable, sino también por las longitudes máximas admisibles.

Al igual que Modbus, los dispositivos que conforman la red se comunican uno a uno con arquitectura de maestro-esclavo, por lo que en principio, el resto deberían esperar a ser consultados. No obstante, a diferencia de Modbus, DNP3 ofrece una serie de servicios propios del protocolo que permiten resolver situaciones en las que se necesite acusar eventos con mayor rapidez (por ejemplo: prioridad de mensajes, respuestas no solicitadas, etc.). A pesar de esto, el protocolo quedará soportado (en la mayoría de los casos) sobre las capas subyacentes de TCP/IP, por lo que nunca existirá determinismo





en los tiempos del mensaje y de este modo no se adaptará a situaciones de emergencia (por ejemplo: Aplicación de detección de fallas con su asociada acción correctiva).

En lo que al modelo de datos refiere, no solo se define el enmarcado de los datos a nivel de enlace, sino que permite un modelo de objetos extensible por el usuario. Es decir, la especificación impone condiciones en cuanto a los datos que transporta el protocolo, tornándose en un protocolo más complejo, menos flexible y de dificultosa implementación en equipos de hardware limitado. Es un protocolo de aplicación específica, a diferencia de Modbus donde se suele montar la capa aplicación por encima del protocolo.

Cabe destacar que los objetos definidos en el modelo de datos están categorizados en clases, una de las cuales permite anexar a los datos una estampa de tiempo en origen, facilitando la correlación temporal entre datos generados en distintos puntos de la red. Entre los servicios disponibles también se encuentra un modo de sincronización de reloj entre maestro y esclavo como también un sistema de mensajes no solicitados. Todos estos puntos presentan una clara ventaja frente a Modbus cuando se los compara para su uso en sistemas eléctricos.

3.5.2 Formato de Mensajes

Al protocolo DNP3 se lo puede explicar mediante un modelo de tres capas bien diferenciadas, como se muestra en la figura 10. En ella se aprecian:

Nivel de enlace: Donde los datos son representados por pequeñas “tramas” con un tamaño no mayor a 292 bytes. La trama comienza con una cabecera que contiene información de sincronización, direccionamiento (origen y destino) y control de integridad para garantizar una correcta transferencia de datos entre maestros y esclavos del protocolo. Luego de la cabecera se intercalan 16 bytes de datos provenientes del nivel de pseudo-transporte y luego 2 bytes para control de errores de los mismos (CRC), repitiendo el esquema hasta completar el tamaño máximo de la trama.

Nivel de transporte: Donde los datos son representados por “segmentos”. En este nivel, se dividen los fragmentos provenientes del nivel de aplicación y se le agrega como cabecera un número de secuencia de paquetes que permitirá reagrupar los datos en el otro extremo.

Nivel de aplicación: Donde los datos son representados por “fragmentos”. Cuando los mensajes de aplicación (datos, comandos, eventos, etc.) superen el tamaño de fragmento configurado, serán





divididos. El tamaño del fragmento dependerá del tamaño del buffer que es capaz de manejar el receptor, y se negociará en una etapa de preámbulo de la comunicación.

Figura 10: Modelo de Tres Capas del Protocolo DNP3.


El modelo de objetos DNP3 está orientado a servicios de aplicación. Es decir, que los tipos de datos que el protocolo es capaz de manejar se agrupan en objetos bajo un criterio de funcionalidad (por ejemplo: señales analógicas, señales digitales, reportes, etc.). Dentro de cada grupo existirán variaciones del objeto pensadas para resolver situaciones típicas (por ejemplo: señal analógica con estampa de tiempo, evento por cambio en señal digital, evento por umbral superado en señal analógica, etc.). También, los objetos pueden ser clasificados para establecer prioridades. De este modo el maestro puede solicitar los datos de la clase prioritaria con más frecuencia que otros que él considere menos críticos.

A continuación se muestra una lista con algunas de las funcionalidades disponibles:

A. Autenticación segura: A diferencia de Modbus cuya aplicación suele estar delimitada a un bus de campo sin la necesidad de salida al exterior, DNP3 debe comunicar centros de control muy distantes entre sí y por lo tanto requiere de un mecanismo de seguridad intrínseco. Este mecanismo está basado en el Standard IEC 62351 (versión 2) identificando las entidades que





forman parte de la comunicación (mediante contraseña y firma digital) y evitando así la ejecución de comandos por parte de intrusos en la red. Además, como se utilizan los servicios de las capas subyacentes TCP/IP, se puede encriptar la comunicación sin un mayor esfuerzo, de ser necesario.

B. Estampa de tiempo: Los objetos pueden incluir, si se deseara, información temporal del instante en el que han sido generados. Esta información es de suma utilidad para casos donde se necesita correlacionar datos de diferentes fuentes en una etapa posterior de análisis o cuando durante la adquisición se producen pérdidas de comunicación prolongada. DNP3 prevé el uso de variaciones en los objetos para dar una solución a estos casos. Es decir, un objeto del tipo entrada analógica, podrá o no incluir timestamp, según la variación utilizada.

Figura 11: Librería de Objetos DNP3.

C. Sincronización: Los esclavos del protocolo pueden ser configurados para enviar una petición de sincronización temporal al maestro. Esta funcionalidad usada junto con la estampa de tiempo, permite no solo el muestreo de datos y el acuse de eventos con una gran precisión





temporal, sino también el disparo de acciones locales sincronizadas (por ejemplo: mensajes no solicitados, conmutar salidas, etc.).

D. Diagnóstico: Los objetos pueden incluir, si se deseara, información de la sanidad del dato que transportan. Esta información es de suma importancia para evitar el almacenamiento y análisis de datos que pueden estar corruptos o inválidos. Son indicaciones comúnmente utilizadas: valor fuera de rango, punto de medición fuera de línea, actuador localmente forzado, etc.

E. Reportes por excepción: Gracias a la funcionalidad de mensajes no solicitados, es posible configurar los esclavos para que envíen datos sin necesidad que el maestro los consulte de forma periódica. El destino de los reportes puede ser múltiple si así se lo requiere.

F. Librería de objetos: Como ya se adelantó, existe un conjunto de datos que el protocolo es capaz de intercambiar que llamamos objetos. La tabla mostrada en la figura 11 muestra alguno de los objetos soportados con sus variaciones.

Es necesario aclarar que:

Los objetos de entradas binarias (grupos 1 y 2) pueden corresponderse con entradas físicas o flags de software.

Los objetos usados para detectar cambios (grupo 2) contienen la misma información que los objetos estáticos (grupo 1), solo difieren en el grupo (por ejemplo: “Binary input” y “Binary input change”).

Los objetos de salidas binarias (grupos 10 y 12) pueden corresponderse con salidas físicas o flags de software.

El control de salida binarias (grupo 10) se realiza a través del objeto “Binary output” y su lectura de estado a través del objeto “Binary output status”.

Los objetos de relé (grupo 12) permiten un control de la salida a través de pulsos o estado enganchado (tipo latch).

Los objetos de relé “Pattern control block” y “Pattern mask” permiten realizar la misma operación que el objeto “Control relay output block” pero aplicada a varios puntos de control en forma simultánea.

Los objetos contadores (grupo 20 y 21) son capaces de reportar condiciones de desborde.





G. Manejo de archivos: La especificación define objetos especiales para transferencia y manipulación de archivos. Estos objetos son muy útiles a la hora de transferir archivos de configuración/reporte, hacia o desde los dispositivos remotos.

3.5.4 Niveles de implementación

Al igual que Modbus, DNP3 puede estar implementado de forma parcial debido a que algunos dispositivos podrían estar limitados en recursos y obligarlos a implementar el protocolo completamente los haría ineficientes. Entonces, para asegurar compatibilidad entre fabricantes es necesario poder determinar si soportan los mismos grupos de objetos y servicios. Para resolver esto, la especificación de DNP3 define tres niveles de implementación, a saber:

Nivel 1: Es simple de implementar y está destinado a la comunicación entre concentradores y dispositivos pequeños como puede ser un relé o un sensor.

Nivel 2: Es de complejidad media en la implementación y está destinado a comunicar subestaciones, concentradores, terminales remotas o dispositivos más complejos.

Nivel 3: Es de gran complejidad en la implementación dado que soporta todas las funcionalidades de DNP3. Está destinado la comunicación entre centros de control o terminales remotas avanzadas.

3.5.5 Casos de Uso

La protección diferencial de transformador (Transformer differential protection) SIEMENS 7UT6 es muy usado entre los equipos de protección relevados por el CDEC e implementa DNP3 esclavo, en los niveles 1 y 2, sobre un enlace físico RS-485 o fibra óptica (dependiendo de la placa de comunicaciones utilizada). Este equipo representa un 4% del total de los equipos relevados, por lo cual es atractivo para su análisis.

En el manual de comunicación DNP3 de la protección se destaca el soporte de los siguientes objetos, los cuales son útiles para configurar, leer variables y obtener el estado del equipo:

Lectura de estado mediante el uso del grupo de objetos Binary inputs (grupos 1 y 2).

Ejecución de comandos mediante el uso del grupo de objetos Binary outputs (grupos 10 y 12).





Lectura de mediciones mediante el uso del grupo de objetos Analog inputs (30 y 32).

Con este pequeño juego de objetos se puede obtener información de suma utilidad, como ser:

Eventos y alarmas generales del dispositivo.

Eventos de fallas de fase (a ambos lados del transformador).

Eventos de falla de tierra (a ambos lados del transformador).

Eventos de sobre corriente (a ambos lados del transformador).

Eventos de sobrecarga térmica.

Eventos de desbalance de carga.

Eventos de falla en el interruptor.

Eventos de disparo remoto.

Mediciones guardadas en los instantes de falla (por ejemplo: corrientes de fase, frecuencia, corrientes de secuencia cero, positiva y negativa, a ambos lados del transformador).

Lectura de sensores de temperatura tipo RTDs

Lectura de entradas analógicas de usuario.

Figura 12: Imagen de Relés de línea SIEMENS 7UT6.





Adicionalmente, el mismo juego de funciones objetos permite ejecutar comandos en el equipo, como ser:

Disparo remoto de la protección.

Cambio entre cuatro grupos de parámetros definibles por el usuario.

Por último, cabe destacar que la protección no implementa servicios de configuración remota, ni los objetos correspondientes a la transferencia de archivos. Esto implica que el equipo debe ser configurado en forma local mediante el software de configuración DIGSI de Siemens.

3.5.6 Conclusiones

Dada la concepción para su aplicación en sistemas eléctricos, el protocolo DNP3 parece ser una buena opción para establecer una comunicación eficiente entre un centro de control y varias subestaciones. Si bien es complejo y requiere de una mayor cantidad de recursos a la hora de su implementación, resuelve muchos de los problemas que presentan los protocolos industriales como Modbus (seguridad de datos, sincronización entre dispositivos, eventos con prioridad, estampa de tiempo en origen, modelo de datos aplicable a la industria eléctrica, etc.).

Por otro lado, es un protocolo bastante antiguo que presenta las siguientes desventajas:

1. Pese a que el modelo de datos es extensible, el mismo ha quedado obsoleto para la integración de equipos complejos como son los sensores distribuidos y las protecciones inteligentes. Estos nuevos dispositivos pueden compartir datos entre sí y cooperar en sus funciones. Un esquema de este tipo no puede ser resuelto fácilmente mediante este protocolo.

2. Más allá de la clara ventaja de los mensajes no solicitados, la comunicación entre maestros y esclavos no deja de ser punto a punto, requiriendo aún de técnicas como polling para obtener los datos, por lo que complica la implementación de topologías multinivel (por ejemplo: centros de control en cascada).

3. Al igual que Modbus, las capas subyacentes por lo general serán TCP e IP (sobre todo si el maestro y esclavo están muy alejados el uno del otro), siendo inviable para aplicaciones de tiempo real (por ejemplo: disparar una protección con un retardo en el orden de los milisegundos).





Por lo anteriormente expuesto, DNP3 resulta una alternativa interesante para unir centros de control con subestaciones e incluso centros de control entre sí, pero no tanto para la comunicación entre dispositivos inteligentes dentro de la subestación. Por este motivo un sistema heterogéneo y flexible debería, de ser posible, soportar DNP3 por cuestiones de compatibilidad, pero no supeditar el sistema al mero uso del mismo.

3.6 IEC 61850

3.6.1 Introducción

La norma IEC 61850 es un estándar internacional desarrollado por la Comisión Electrotécnica Internacional, en conjunto con diversos fabricantes del sector eléctrico. Emitido en 2005, surge de la necesidad de integración de sistemas de protección, control, monitoreo y diagnóstico. El objetivo principal de esta norma es simplificar y estandarizar el intercambio de información entre los distintos sistemas, a fin de posibilitar mejoras operativas y mayores niveles de integración.

Dentro de su especificación se definen requerimientos de comunicación, convenciones de nomenclatura para datos, características funcionales y estructuras de datos en dispositivos. A diferencia de otros estándares, no define cómo se debe realizar el intercambio de datos, sino que se enfoca en la integración de estos. Esto, le confiere una flexibilidad y adaptabilidad difícilmente igualables por estándares anteriores.

Entre las ideas que la norma introduce, es de vital importancia su modelo de datos. El mismo permite dividir la subestación mediante el concepto de nodo lógico, separando cada elemento en funciones y unidades de información simples. Adicionalmente, cada dispositivo conectado a la red es capaz de publicar sus capacidades por medio de este método.

Otra característica interesante de esta norma es la introducción de un lenguaje de configuración estándar para todos los dispositivos. Este lenguaje está basado en el conocido lenguaje de marcas extensibles XML (Extensible markup language), lo cual permite hacer uso de la extensa cantidad de herramientas existentes para dicho lenguaje.

En la actualidad, el nombre del estándar ha sido modificado, renombrandolo como Automatización de Sistemas de Potencia, reflejando su importancia para la industria eléctrica.





3.6.2 Tipos de Mensajes

Dado que la información disponible en una instalación eléctrica contiene múltiples formatos y pertenece a campos de aplicación con requerimientos temporales muy diversos, la norma define los siguientes tipos de mensajes:

Tipo 1: Mensajes rápidos con fines de protección.

Tipo 1A: Disparos utilizados con fines de protección.

Tipo 2: Mensajes de velocidad media con propósito de control.

Tipo 3: Mensajes lentos para la supervisión y configuración.

Tipo 4: Envío de valores instantáneos de señales analógicas.

Tipo 5: Transferencia de archivos.

Tipo 6: Sincronización de tiempo.

Figura 13: Tipos de Mensajes en IEC 61850.





Como se observa en el modelo de capas expuesto, existen servicios del estándar que no están soportados sobre capas las transporte TCP o UDP, sino que directamente están montados sobre la delgada capa de enlace denominada Ethertype.

Este hecho, radica en la necesidad de evitar las latencias provocadas por los mecanismos de enrutamiento, a la hora de enviar valores instantáneos o mensajes de alta velocidad, permitiendo funcionalidades de cooperación y protección entre dispositivos que se encuentran en la red.

Esta característica, es una diferencia fundamental con respecto al resto de los protocolos, y es lo que distingue a un verdadero protocolo con funcionalidades de tiempo real.

Por último cabe destacar que para que estos servicios rápidos funcionen correctamente, los elementos enrutadores de la red deben cooperar y evitar poner en cola de mensajes los paquetes correspondientes. Es decir, que si se requiere de estos servicios, se deberá tener mucho cuidado en la selección de los routers a instalar.

El núcleo de las comunicaciones está conformado por los mensajes MMS (Manufacturing Message Specification), los cuales se utilizan para el intercambio de información no crítica usando un enfoque cliente-servidor, por ejemplo para obtener el estado o configuración de alguna protección o equipo de la red.

Figura 14: Flujo de información que toman los servicios para una aplicación general de medición y control.





Para la transmisión de datos analógicos en tiempo real, como implica la lectura de fasores de tensión y corriente desde una Merging Unit, el estándar definen los mensajes tipo SV (Sampled Values).

Para aplicaciones de envío de eventos más exigentes, como es el comando de apertura de un interruptor o mensajería entre elementos de protección, se acostumbra utilizar los mensajes GOOSE (Generic Object Oriented Substation Event).

Por último, para la sincronización temporal de todos los dispositivos de la red, será de gran importancia el servicio SNTP (Simple Network Time Protocol).

Manufacturing Message Specification (MMS)

El estándar internacional MMS (Manufacturing Message Specification) es un protocolo de capa de aplicación diseñado originalmente para el control y monitoreo de equipos tales como RTUs y PLCs. En la actualidad, es la base del proyecto de Arquitectura de Comunicación para redes de Servicios (UCA) y el estándar IEC 61850 entre otros.

¿Que define?

El estándar MMS define los siguientes aspectos de una comunicación entre dispositivos:

Un conjunto de objetos estándar que deben existir en cada dispositivo, sobre los cuales operar (ej: lectura y escritura de variables, señalización de eventos, etc).

A. Un conjunto de mensajes estándar para intercambios entre cliente y servidor con el propósito de controlar los objetos.

B. Un conjunto de reglas de codificación de mensajes (mapeo de valores a bits y bytes).

C. Un conjunto de protocolos (reglas para el intercambio de mensajes).

Modelo cliente/servidor

El estándar MMS describe el comportamiento entre dos dispositivos con un modelo cliente/servidor. El cliente puede ser un sistema de monitoreo, un centro de control o cualquier otro dispositivo inteligente. El servidor puede representar uno o varios dispositivos, o bien todo el sistema.





Este estándar adopta un modelo orientado a objetos; el mismo define clases (Variable con Nombre, Dominio, Lista de Variables con Nombres, Diario, etc), instancias de clases y métodos (servicios de lectura, escritura, reporte, descarga, etc).

Figura 15: Modelo Cliente/Servidor.

Si bien el estándar es extenso, esto no implica que la implementación deba ser complicada. Si se utiliza un subconjunto del estándar, la implementación puede ser más simple. Esto posibilita que los mensajes MMS puedan ser implementados tanto en computadoras como en sistemas limitados en hardware (sistemas embebidos).

El estándar no especifica detalles sobre la implementación del servidor, y solo define cómo deben comportarse los objetos y sus representaciones desde el punto de vista externo y cómo es que un cliente debe accederlos.

El servidor MMS provee una representación de los objetos disponibles para acceso público. De estos objetos, el VMD (Virtual Manufacturing Device) es el contenedor más externo, en el cual los demás objetos deben ser incluidos.





Dado que un servidor MMS se ocupa de modelar datos reales (temperatura, corriente, etc)., el estándar provee clases bastante comunes para tal fin. Por ejemplo, la clase Variable con Nombre permite ordenar la información provista para su acceso, si bien no se define la semántica del contenido que debe intercambiarse.

Las “llamadas” que el cliente envía al servidor se describen en la sección ISO 9506-1. Usando estas “llamadas”, el cliente puede definir, borrar, cambiar o acceder objetos por medio de operaciones de lectura/escritura.

Los dispositivos físicos tienen permitido desempeñar ambos roles (cliente y servidor) simultáneamente. Por ejemplo, un servidor a nivel de bahía puede ser un cliente a nivel de subestación, como generalmente sucede en topologías extensas.

Figura 16: Árbol de Semántica de Puntos de un Sistema Eléctrico Arbitrario.

Por último, como muestra la figura 16, en el estándar se estructura y define una semántica de varios puntos de sistemas eléctricos, en forma de árbol. Por ejemplo, un elemento denominado "Ancoa/XCBR3.Pos.stVal" se corresponde con la posición del tercer interruptor de la subestación Ancoa. Los nombres “XCBR”, “Pos” y “stVal” forman parte del estándar y corresponden al nodo lógico, objeto y atributo, respectivamente.

Características de conexión





El estándar MMS define un protocolo orientado a la conexión, esto significa que hace falta establecer una conexión entre ambos dispositivos antes de poder realizar cualquier operación. Una vez establecida la conexión, es poco probable que se vea interrumpida. Aún así, en caso de que esto ocurra (ya sea por una conexión defectuosa o por otro motivo) esta condición es rápidamente detectada y remediada con ayuda de las capas inferiores (capa de sesión).

Dado que se trata de un protocolo de capa de aplicación, algunas de las características más destacadas de una conexión MMS son:

Reserva de los recursos que una conexión necesita (procesador y memoria). Esto asegura que no falten recursos en ambos extremos.

Control de flujo, a fin de evitar bloqueos y transmisiones fallidas.

Supervisión de la conexión por parte de las capas más bajas.

Confirmación de la transmisión de datos.

Segmentación de mensajes.

Enrutamiento de mensajes.

Autenticación, protección de acceso (password) y codificación de mensajes.

El dispositivo de manufactura virtual (VMD)

El dispositivo de manufactura virtual representa el comportamiento visible de un dispositivo real. A tal fin, contiene objetos (variables, listas, etc.) que suelen estar almacenados en el dispositivo en cuestión y representan una auto-descripción del mismo. Esto asegura la validez de los datos y que los mismos representen de manera consistente la configuración del dispositivo.

Si bien los dispositivos virtuales son descripciones de datos y dispositivos reales, existen distintas alternativas en cuanto a dónde puede estar ubicado:

Si se encuentran en el dispositivo final, entonces se tiene acceso a los datos reales del dispositivo. El modelado se realiza de manera que distintos campos de aplicación cuentan con representaciones diferentes, todas ellas independientes de las demás.





Si se implementan en un equipo separado (gateway), entonces los objetos que describen el acceso a los datos se encuentran en una única ubicación. Cuando son accedidos, los datos pueden encontrarse en la memoria del dispositivo, o bien, se solicitan en el momento.

Si se implementan en un archivo (base de datos, ftp, etc), entonces se puede acceder directamente a todos los datos. Esto es de utilidad a la hora de incluir la representación de un nuevo dispositivo que aún no hemos recibido.

Un dispositivo virtual cuenta con los siguientes servicios:

o Dos servicios para obtener el estado del servidor (Unsolicited Status y Status).

o Un servicio que retorna datos, que permiten verificar que el dispositivo sea el que corresponde (Identify, lee los atributos Vendor Name, Model Name and Revision).

o Un servicio para leer el nombre de los objetos disponibles (Get Name List). Luego, es posible hacer uso de servicios específicos para averiguar la clase y atributos de cada objeto.

o Un servicio para cambiar el nombre de un objeto (Rename).

Dominios

Los dominios se pueden ver como contenedores que representan áreas de memoria donde el nombre nos abstrae de la información contenida dentro del mismo. El contenido presente en estos dominios se puede intercambiar entre los distintos dispositivos y sus datos se pueden codificar de manera transparente o bien de manera arbitraria. Incluso es posible codificar los datos de manera que posibilite la carga y guardado de la totalidad de información contenida en estos dispositivos.

El estándar define la carga de datos en dos direcciones:

Transmisiones del cliente al servidor (descarga).

Transmisiones del servidor al cliente (carga).

A su vez, el proceso de carga puede estar en una de tres fases diferentes:

Apertura de transmisión.





Transmisión segmentada.

Cierre de transmisión.

El proceso de transmisión es iniciado siempre por el cliente. Si el servidor necesita iniciar una transferencia, debe indicarle al cliente dicha necesidad. Incluso es posible que un tercero inicie la operación, informando al servidor para que esté a su vez le informe al cliente.

Figura 17: Modelo de Procesos de Carga, Descarga y Apertura y Cierre de Transmisión.

Generic Object Oriented Substation Events (GOOSE)

Los mensajes GOOSE (Generic Object Oriented Substation Events) son mensajes de velocidad media con propósito de control.

Dados los requerimientos que este tipo de mensajes deben enfrentar, son mensajes cortos, de alta prioridad, que se envían directamente a nivel Ethernet. Por lo tanto requieren del uso de elementos de red que posibiliten saltarse los paquetes de menor prioridad que se encuentren encolados a fin de que la comunicación de estos paquetes sea casi instantánea, dándoles carácter de tiempo real.





Figura 18: Esquema de Mensajes GOOSE.

Los mensajes GOOSE se transmiten a los dispositivos de protección de la red que se encuentren suscritos con anterioridad en una etapa de preámbulo o modelado de la subestación. Dado que la transmisión se realiza a varios dispositivos simultáneamente, no existe un mecanismo de confirmación adecuado. Por lo tanto, se debe repetir el mensaje para asegurar su correcta transmisión. En ausencia de eventos, los mensajes se envían cada un tiempo máximo predeterminado, sin embargo, cuando ocurre un evento, se acorta este intervalo y luego se aumenta progresivamente hasta volver al tiempo predeterminado.

Figura 19: Proceso de Transmisión de Mensaje GOOSE por arranque de la función 51.





La gran velocidad que logra este servicio, con tiempos de respuesta del orden de unos pocos milisegundos, lo tornan muy útil para los sistemas que realizan maniobras de protección coordinada entre dos o más dispositivos inteligentes.

Sampled Values (SV)

El propósito de los mensajes SV (Sampled Values) o valores muestreados, es el envío de valores instantáneos de señales analógicas (generalmente tensiones y corrientes). Este tipo de valores es utilizado por los distintos dispositivos de control y protección, resultando de vital importancia que sea de naturaleza determinística.

El estándar define una trama muy simple que contiene exactamente un APDU (Application Protocol Data Unit).

Figura 20: Definición de Trama para Sampled Values

Cada uno de los campos que componen un APDU están conformados por una terna que indica el tipo, la longitud y el valor del campo respectivamente. Dentro de cada APDU se encuentran campos que contienen el número de paquete y la cantidad de ASDU (Application Service Data Unit). A su vez, cada ADSU contiene información sobre amplitud y fase para cada una de las cuatro corrientes/tensiones y la frecuencia.

Como ya se adelantó, este servicio dispone de un mecanismo de transporte de red similar al de GOOSE, garantizando la disposición de los datos casi de forma instantánea por parte de todos los dispositivos inteligentes que se suscriban al mismo en la etapa de preámbulo o configuración de subestación.





Figura 21: Modelo del APDU.


A continuación se presenta un resumen de las funcionalidades soportadas por el estándar, que facilitan su comparación con el resto de los protocolos:

Auto-descripción de dispositivos: El uso de un modelo de datos estándar permite que cada dispositivo sea capaz de averiguar las capacidades de los demás elementos presentes en la red.

Envío de informes de señalización y alarmas, tanto periódicos como generados por eventos predefinidos.

Registro de un conjunto de datos, tanto periódicos como generados por eventos predefinidos.

Intercambio rápido y confiable de eventos: La funcionalidad de mensajes GOOSE permite que todos los dispositivos de la red (suscriptos) se enteren de manera casi instantánea de los eventos de falla de los elementos vecinos.

Transmisión de valores muestreados: La funcionalidad de mensajes SV permite que todos los dispositivos de la red (suscriptos) obtengan valores instantáneos de cada sensor presente en el sistema.

Estampa de tiempo: Los datos y eventos generados en el sistema viajan con una estampa de tiempo adjunta. Esta información es útil cuando se desea ver una correcta representación





temporal de datos muestreados por múltiples equipos, como por ejemplo, analizar la secuencia de eventos ante un caso de falla.

Sustitución del valor de los parámetros: El uso de un modelo de datos estándar y la implementación de mensajes MMS permiten que se puedan alterar a voluntad los parámetros de los distintos dispositivos.

Control de mediante comandos de los dispositivos inteligentes.

Transferencia de ficheros: La especificación define objetos para transferencia y manipulación de archivos. Estos objetos son muy útiles a la hora de transferir archivos de configuración/reportes hacia/desde los dispositivos remotos.

Configuración: La definición de un lenguaje de configuración utilizado por los distintos dispositivos, llamado Substation Configuration Language (SCL) permiten que se pueda intercambiar datos de configuración y utilizar diversas herramientas diseñadas para automatizar estos procedimientos (independientemente del fabricante). Esta funcionalidad es quizás una de las más interesantes que presenta este estándar, y por eso será vista en profundidad dentro de la segunda parte de este estudio, dado que sirve para entender la configuración de algunos equipos que formarán parte de la topología elegida.

3.6.4 Casos de Uso

El dispositivo electrónico inteligente de protección de transformador ABB RET670 es muy usado entre los equipos de protección relevados por el CDEC e implementa el protocolo IEC 61850. Este equipo representa un 17% del total de equipos relevados, lo cual lo hace muy atractivo para su análisis.

En el manual de usuario se menciona el soporte del protocolo IEC 61850 y enumera varias de las características soportadas, a saber:

Implementación de módulos de comunicación IEC 61850-8-1 en todas las interfaces ethernet.

Seteo de parámetros mediante IEC 61850.

Implementación de las funciones de monitoreo: Generic communication I/O functions (SPGGIO), Generic communication I/O functions 16 inputs (SP16GGIO) y Generic communication function for Measured Value (MVGGIO).

Comunicación horizontal para funciones de bloque por medio de GOOSE.

Recepción binaria por medio de GOOSE (GOOSEBINRCV).





Figura 22: Imagen Relés de línea ABB RET670.

Con este conjunto de características, es posible obtener modificar cada una de las configuraciones disponibles, tales como:

Parámetros de transformador.

Parámetros de comunicaciones en todos los protocolos soportados (direcciones, velocidad de datos, factores de escala, etc.).

Ajustes de reloj (fecha y hora), y señales de sincronización (IRIG-B, SNTP).

Tiempos de grabación pre y post falla.

Parámetros de histogramas y oscilografías.

Parámetros de los TP y TC (relación de transformación y escalamiento).

Por último, este relé permite la obtención de archivos oscilográficos e histogramas en formato COMTRADE.

3.6.5 Conclusiones

IEC 61850 fue concebido como un sistema para la automatización de subestaciones. Si bien es complejo y a nivel de instalación requiere equipos capaces de respetar determinadas características del protocolo, como el caso de los routers, es un estándar que ha sentado las bases para los desarrollos presentes y futuros en sistemas eléctricos, generación distribuida y energías renovables, entre otros.





Por otro lado, la extensión del protocolo para la comunicación entre centros de control se encuentra actualmente bajo desarrollo, por lo que a futuro se podrán unificar los buses de proceso, bahía y subestación, sin la necesidad de equipos dedicados a la conversión de protocolos.

Las características más destacadas de este estándar son:

Interoperabilidad entre fabricantes.

Proporciona flexibilidad respecto de la arquitectura del sistema.

Se basa en estándares ampliamente aceptados para el transporte de datos (Ethernet, TCP/IP, MMS).

Soporta todas las funciones de medición, supervisión, control y protección requeridas por una instalación eléctrica.

Permite la extensión de funcionalidades, por lo que es adaptable a futuro.

Tiene un alto grado de aceptación a nivel mundial.

Define una infraestructura de comunicación única.

Define una interfaz denominada ACSI (Abstract Communication Services Interface) para separar la definición del estándar de las tecnologías de comunicaciones utilizadas.

Define un lenguaje denominado SCL (Substation Configuration Language) para la configuración de los dispositivos electrónicos inteligentes.

Desde el punto de vista del estudio, este estándar parece el más adecuado para la integración de dispositivos actuales y venideros. Cada vez son más los equipos que lo implementan, inclusive a nivel de bus de proceso, como es el caso de los nuevos transformadores no convencionales.

Este estándar realmente soluciona de raíz todos los problemas que presentan los protocolos anteriormente mencionados en cuanto a: sincronización temporal, acuse de eventos rápidos y modelo de datos definido. Ofreciendo además, funciones adicionales como el nuevo lenguaje de descripción de configuración, que disminuye el gasto administrativo y facilita la auditabilidad.

Todas estas características lo tornan interesante para formar parte de la arquitectura del “sistema de monitoreo”, con la salvedad y desventaja de que no aplica aún al tramo de comunicación entre centros de control, y por lo tanto, deberá estudiarse alternativas para la solución de esta indeterminación.





3.7 ICCP

3.7.1 Introducción

El protocolo ICCP (Inter Control Center Protocol), también conocido como IEC 60870-6/TASE.2 es un estándar internacional desarrollado por el Comité Técnico número 57 de la Comisión Electrotécnica Internacional. El mismo surge de la necesidad de intercambiar información de tiempo real entre los distintos agentes del sector eléctrico.

Dentro de su especificación se definen objetos y servicios básicos para la transmisión de información. A diferencia de otros estándares analizados, el protocolo ICCP se caracteriza por enfocarse exclusivamente en la comunicación entre instalaciones eléctricas.

Entre las decisiones de diseño destacables de este protocolo, se encuentra el uso de la Especificación de Mensajes de Fabricación, el cual es una norma con un extenso historial en el intercambio de datos de tiempo real a nivel industrial y aporta una solución en todas las capas del modelo OSI. El estándar MMS cuenta con un diseño orientado a objetos, lo cual permite la representación simple de los modelo de datos mas utilizados en las instalaciones eléctricas.

Otra característica interesante de esta norma es el uso de una tabla bilateral para el intercambio de información. Si bien el mantenimiento de una tabla en ambos extremos de una comunicación puede verse como un proceso engorroso, el uso de esta tabla fuerza a ambos participantes a convenir la información que desean intercambiar, permitiendo aplicar políticas de control de acceso dato por dato. Adicionalmente, si alguno de los participantes decidiera revocar este contrato, el otro participante tendría un acuse inmediato de la violación de dicho acuerdo.

Por último, se desea destacar el hecho de que el protocolo ICCP forma parte de la Arquitectura de Comunicaciones de Servicios (UCA), el cual es un estándar de la IEEE al cual le concierne la reducción de costos y la integración a gran escala de los servicios de electricidad, gas y agua.

3.7.2 Bloques de Datos

Como se mencionó anteriormente, el protocolo ICCP basa parte de su implementación en el uso de los mensajes MMS, por lo tanto, el stack de comunicaciones queda representado como se observa en la figura 23.





Figura 23: Stack del protocolo ICCP

Los bloques de datos definidos para el intercambio entre nodos ICCP son:

Datos Periodicos: este tipo de datos lo conforman los valores analogicos, eventos de protecciones, estampas de tiempo e indicadores de calidad.

Datos de Monitoreo: en este grupo se incluyen la transferencia de datos que involucran cambios de estados y verificaciones de integridad del sistema.

Bloque de Datos: sirve para transmitir de manera eficiente datos de eventos específicos.

Mensajes de Información: mecanismo regular para la transferencia de mensajes en forma de texto o binaria.

Control de dispositivos: su función es la de solicitar la operación de un dispositivo ubicado en la instalación.

Ejecución de aplicación: se usa para la ejecución de un programa en la instalación.

Reporte de eventos: incluye los eventos de registros y eventos de condición.

Objetos adicionales de usuario: se usa para la carga de datos adicionales, como oscilografías y documentos de análisis de fallas.

Series de tiempo: empleado para el envío de datos históricos.






El modelo de objetos ICCP está orientado a la comunicación entre entidades. Por lo tanto, el mismo cuenta con categorías optimizadas para una amplia gama de operaciones (lectura datos históricos, envío de comandos, transmisión de archivos, etc). Dentro de cada categoría se puede transmitir una gran diversidad de datos, pero los mismos responden a un modelo de datos convenido entre las partes.

Algunas de las funciones implementadas por este protocolo se mencionan a continuación:

Intercambio de datos en tiempo real: Si bien los demás protocolos analizados intercambian datos en tiempo real, algunos de ellos (Modbus, IEC 61850) solo están orientados al intercambio de datos entre dispositivos dentro de una instalación eléctrica. Entre las clases de datos que es posible transmitir en tiempo real se encuentran valores analógicos (datos periódicos), eventos (datos de monitoreo) y estados específicos de protecciones (bloque de datos).

Carga de archivos: Existe la posibilidad de cargar archivos para su transmisión entre el cliente y el servidor. Es una tarea frecuente el envío de cronogramas y reportes de fallas por parte de los operadores de instalaciones eléctricas a los entes reguladores.

Ejecución remota de programas: Esta capacidad resulta muy atractiva para la ejecución de tareas que no dependen directamente del personal encargado de la normal operación de las instalaciones. Una tarea de esta índole puede ser la generación de reportes cuya necesidad y frecuencia es determinada y manejada por un ente regulador.

Solicitud de actuación remota de protecciones: Esta función resulta de gran utilidad cuando es necesario coordinar la operación de varias instalaciones, como puede ser el caso de maniobras complejas entre subestaciones.

Control de acceso a datos: Si bien protocolos como DNP3 permiten la autenticación segura de sus conexiones, ICCP da un paso adicional permitiendo controlar granularmente qué datos se intercambian al obligar a que la representación de los datos en ambos extremos sea coincidente.

Encriptación de datos: Si bien el protocolo ICCP no especifica formas de autenticación y encriptación, las capas más bajas si proveen dichos servicios. Por lo tanto, no debemos preocuparnos por la implementación de dicha característica.





3.7.4 Casos de Uso

Una aplicación interesante es el software AX-S4 ICCP de la empresa SISCO. El mismo se utiliza en conjunto con un sistema SCADA (como puede ser el MicroSCADA Pro SYS600 de ABB) que se encuentre corriendo en un servidor, el cual puede ser el mismo que se utiliza con fines de control local o bien un sistema separado con propósito de recolección de datos.

En este esquema, mostrado en la figura 24, el software AX-S4 ICCP se ocupa de proveer una interfaz entre el SCADA y el sitio remoto, comunicándose con el SCADA por medio de OPC y con el sitio remoto usando ICCP.

Figura 24: Modelo del software AX-S4 ICCP de interfaz entre el SCADA y el sitio remoto.

Por otra parte, es el software MicroSCADA Pro quien provee la comunicación con los distintos dispositivos por medio del soporte de los siguientes protocolos:

DNP3

IEC 61850





Modbus RTU or Modbus TCP.

IEC 60870-5-101/103/104.

3.7.5 Conclusiones

El protocolo ICCP es una interesante alternativa a la hora de interconectar entre sí instalaciones de la red eléctrica. A pesar de ser un protocolo de mayor complejidad, cuenta con características que resultan de utilidad en la operación a gran escala de sistemas de potencia (actuación remota de protecciones, transmisión de datos en tiempo real, etc.).

Como ya se mencionó anteriormente, algunas de las características más interesantes del estándar son:

La utilización de MMS, el cual es un estándar robusto y de desempeño comprobado, utilizado originalmente en la transmisión de información en procesos de manufactura.

Utiliza tablas en ambos extremos de la transferencia, lo cual requiere lograr un acuerdo en cuanto a los datos que se van a transmitir.

Tiene un diseño modular, el cual está basado en el uso de bloques para representar sus funciones.

Forma parte de la Arquitectura de Comunicaciones de Servicios, donde se lo define como un excelente estándar para el intercambio de datos y acceso a bases de datos en tiempo real.

Este protocolo ha sido aceptado gratamente por la industria y como consecuencia cuenta con soporte en una variedad de aplicaciones. Lamentablemente, el estándar no exige la implementación de la totalidad de los bloques como medida de cumplimiento de las normas. Por lo tanto, es necesario verificar con cada fabricante las características de su implementación.

Todas estas características lo tornan interesante para formar parte de la arquitectura del “sistema de monitoreo”, dado que permite salvar la indeterminación anteriormente mencionada, que presenta el estándar IEC61850.





3.8 Referencias

Modelo de Referencia OSI - UTN FRM.

El modelo OSI - UNICEN.

El modelo OSI y los protocolos de red.

Communication Protocols and Networks for Power Systems, Current Status and Future Trends - ABB.

Power Industry Communication Protocol Features and Benefits - ProSoft.

Teoría en Protocolo Modbus - Axon Group.

Teoría en Protocolo DNP3 - Axon Group.

Teoría en Protocolo IEC 61850 - Axon Group.

A DNP3 Protocol Primer - DNP.

IEC61850 & ICCP-TASE.2 Technical Overview - SISCO.

IEC 61850 Communication Networks and Systems In Substations: An Overview for Users.

Implementación Práctica del Protocolo IEC 61850 en Subestaciones Eléctricas. Problemas y Soluciones - Mario Benitez Lobato.

Automatización de una Subestación Eléctrica utilizando el Protocolo IEC 61850 y el ICCP para el envío de Datos - Marco Antonio Toscano Palacios.






Capítulo 4. DISPOSITIVOS

4.1 Introducción En la actualidad, las instalaciones eléctricas están conformadas por un vasto ecosistema de dispositivos con propósitos muy diversos que van desde medir una señal analógica hasta interconectar los miles de dispositivos presentes.

En primer lugar es preciso categorizar los elementos involucrados, basándose en el rol que cumplen dentro del sistema. Dicha clasificación resultará posteriormente de vital importancia para el análisis de las interacciones entre las distintas partes y cómo estas afectan al sistema en su conjunto.

Para el estudio de cada uno de los dispositivos, es necesario analizar sus características generales, bloques que lo componen, funciones que realiza, ventajas y desventajas de su uso. Adicionalmente, se presentará casos de uso práctico donde se buscará esclarecer los criterios de selección a utilizar cuando se evalúa uno de estos dispositivos.

Finalmente, se buscará concluir las áreas en las que cada elemento aporta una mejora significativa.

4.2 Dispositivos Electrónicos Inteligentes

4.2.1 Introducción

Los dispositivos electrónicos inteligentes, también conocidos como IEDs (Intelligent Electronic Devices), son sistemas basados en microprocesadores que se emplean en funciones de protección, monitoreo, automatización, medición y control.

Este tipo de dispositivos suelen contar con capacidades de comunicación entre elementos de un mismo nivel jerárquico, permitiéndoles cooperar para proteger los elementos de campo.

Los avances recientes en cuanto a capacidad de procesamiento han posibilitado que un único IED realice múltiples tareas de protección y control.





Adicionalmente, algunos de estos dispositivos han agregado funcionalidades similares a las de un PLC, permitiendo el desarrollo de lógica de control personalizada.

4.2.2 Funciones de Protección

Los dispositivos IED cuentan con una gran variedad de funciones de protección, lo cual no hace más que complicar la tarea de comparación de los mismos. Afortunadamente, existen estándares que ayudan a simplificar dicha tarea.

Uno de dichos estándares es el estándar de números, acrónimos y designación de contactos para dispositivos eléctricos de potencia (ANSI/IEEE C73.2), el cual identifica características de un dispositivo mediante números y letras.

Otro estándar que se acostumbra usar para identificar las funciones de protección de un IED es el IEC 61850, donde las funciones están divididas en grupos y categorías.

4.2.3 Módulos Disponibles y sus Características

Módulo de Procesamiento de Información

Los módulos de procesamiento de un IED se ocupan de controlar las funciones que ejecuta el dispositivo. Es en éste módulo donde se ejecutan las funciones de protección, control, etc. provistas.

Módulos de entrada/salida

Los IED cuentan con módulos de entrada/salida de características muy diversas. Dependiendo del fabricante, estos módulos se pueden encontrar divididos por tipo de dato (analógico/digital), dirección del dato (entrada/salida), ambos o ninguno (teniendo un módulo mixto de entrada/salida analógico/digital).

Módulo de alimentación





El módulo de alimentación se ocupa de proveer los niveles de tensión requeridos por todos los demás módulos y subsistemas a partir de una tensión de alimentación de entrada determinada (típicamente 12, 24 o 48 VDC o bien 110 o 220 VAC).

Módulo de comunicaciones

Los IED cuentan con multitud de medios de comunicación, pero lo más común es que cuenten con una o varias de las siguientes interfaces:

RS 232/RS 442/RS 485

10/100BASE-T

10/100Base-F

Módulo de sincronización de base de tiempo

La sincronización de estampas de tiempo es crítica en los dispositivos electrónicos inteligentes; es por eso que la mayoría cuentan con un módulo capaz de sincronizar la base de tiempo, ya sea por medio de un reloj maestro IEC 61588 PTP, mediante la señal de sincronización PPS o bien haciendo uso de una conexión por antena.

4.2.4 Casos de Uso

Los dispositivos electrónicos inteligentes de protección SEL 351 y 351A son particularmente relevantes dado el amplio número de interfaces con las que cuentan y la variedad de protocolos de comunicación soportados.

Figura 25: Equipos SEL 351 y 351A





Estos dispositivos soportan los protocolos IEC 61850, Modbus TCP, Modbus RTU, DNP3 IP y DNP3 Serial.

En lo que respecta a sus interfaces, cuentan con hasta 2 puertos ethernet (redundantes), 3 puertos seriales (EIA-232), 1 puerto serial (EIA-485/SEL-2812 fiber), 1 puerto IRIG-B BNC y un puerto USB-B. Uno de los puertos seriales puede ser usado como interface hacia un receptor GPS. Adicionalmente, estos dispositivos permiten comunicaciones desde cualquier terminal ASCII sin requerir ninguna clase de software especial.

Figura 26: Recursos Físicos de Conectividad de los Equipos SEL.

Además:

Guarda reportes de eventos en formato COMTRADE.

Posee funciones de controlador lógico programable mediante el uso del lenguaje IEC 61131.

Tiene embebido un servidor Web que permite el acceso a los parámetros de configuración, los reportes de medición y de fallas y la actualización de firmware.

Cuenta con verificación de firmware firmado con el algoritmo SHA-1.





4.2.5 Conclusiones

Los dispositivos electrónicos inteligentes, gracias a los avances tecnológicos, han pasado a integrar un número cada vez mayor de funciones de protección en un mismo equipo. Es por este motivo que se han vuelto herramientas imprescindibles a la hora de automatizar instalaciones eléctricas.

La capacidad de estos equipos de trabajar de manera conjunta ha permitido reducir la cantidad de cableado requerido así como optimizar el espacio utilizado en las distintas bahías de una instalación.

Por último y no menos importante, los IED con capacidad de autodescripción y configuración remota resultan de particular interés ya que permiten obtener información actualizada sobre las capacidades del equipo a la vez que mantener su configuración actualizada en todo momento.

4.3 Unidades de Terminal Remota

4.3.1 Introducción

Las unidades de terminal remota, también denominadas RTUs (Remote Terminal Units) son sistemas basados en microprocesadores que tienen la capacidad de monitorear sensores, transmisores y otros equipos de proceso con propósitos de telemetría y control.

La RTU realiza una exploración periódica de las variables del proceso y permite el intercambio de dicha información con una estación maestra.

4.3.2 Módulos Disponibles y sus Características

Módulo de Procesamiento de Información

El módulo de procesamiento de información de una RTU es el encargado de controlar todas las funciones que ejecuta la unidad remota. Es en éste módulo donde se ejecutan los procesos y algoritmos necesarios para transformar señales crudas en datos útiles.

Este módulo suele estar conformado por un procesador (CPU) y memorias volátil y no volátil de capacidades reducidas.





Módulo de Entradas Analógicas

La función de un módulo de entradas analógicas es la convertir valores de señales provenientes de sensores o variables físicas en valores de CPU.

Los componentes principales que constituyen un módulo de entradas analógicas son:

El multiplexor de entrada.

El amplificador de entrada.

El circuito de muestreo y retención.

El conversor analógico digital.

Si bien suele haber gran variedad en cuanto a las características entre los distintos fabricantes, algunos valores típicos son:

Señales de tensión en los rangos 0/5V, ±5V, ±10V, ±15V.

Señales de corriente en el rango 4-20mA.

Resoluciones de entre 8 y 12 bits.

Módulos de 8, 16 y 32 entradas.

Módulo de Salidas Analógicas

La función de un módulo de salidas analógicas es la de convertir valores de CPU en señales físicas, capaces de interactuar con diversos actuadores.

Algunos valores típicos para este tipo de módulos son:

Señales de tensión en los rangos 0/5V, ±5V, ±10V, ±15V.

Señales de corriente en el rango 4-20mA.

Resoluciones de entre 8 y 12 bits.

Módulos de 8, 16 y 32 salidas.





Figura 27: Esquema de Comunicación Estándar con RTU.

Módulo de Entradas Digitales

Los módulos de entradas digitales se utilizan para adquirir señales que indican estados binarios o condiciones de alarma.

Módulo de Salidas Digitales

Los módulos de salidas digitales se utilizan para habilitar actuadores binarios, tales como los relés.

Módulo de Alimentación

El módulo de alimentación se ocupa de proveer los niveles de tensión requeridos por todos los demás módulos y subsistemas a partir de una tensión de alimentación de entrada determinada (típicamente 12, 24 o 48 VDC o bien 110 o 220 VAC).

Módulo de Comunicaciones





Las RTU modernas son lo suficientemente flexibles para manejar multitud de medios de comunicación.

Algunos casos soportados típicamente son:

RS 232/RS 442/RS 485.

Ethernet.

Celular.

Radio satelital en 900MHz.

4.3.3 Casos de Uso

Este equipo del fabricante ABB es una buena alternativa a la hora de integrar dispositivos a los sistemas de control y monitoreo, independientemente de que se trate de dispositivos con protocolos actuales, dispositivos con protocolos Legacy o bien, dispositivos que utilizan señales analógicas y/o digitales, dado que el mismo cuenta con una amplia variedad de módulos entre los cuales seleccionar.

Figura 28: Imagen RTU ABB.

Entre los módulos de comunicaciones disponibles, encontramos unidades con interfaces de tipo serie (RS-232/RS-485), interfaces de red (100BASE-T, 100BASE-F) y módems. Adicionalmente, estos





módulos son capaces de soportar gran variedad de protocolos (Modbus TCP, Modbus RTU, DNP3 y V.23 entre otros).

Entre los módulos de entrada/salida, podemos encontrar unidades para medición de señales analógicas (12 bits, 2mA, 10mA, 20VDC, etc.), salidas digitales (16 salidas, 24 a 60 VDC) y entradas digitales con LEDs (16 entradas, 125 VDC), entre una lista de posibles selecciones.

Adicionalmente, este módulo cuenta con un módulo que proporciona una Interfaz Humano Máquina (HMI).

4.3.4 Conclusiones

Las RTU actuales son dispositivos bastante versátiles, que han dejado de ser meros adquisidores de señales con una conexión serial, para pasar a integrar módulos y funciones adicionales que le permiten cumplir una amplia variedad de roles. Es por esto que las unidades de terminal remota encuentran aplicación en segmentos que van desde el control de pequeñas estaciones transformadoras, pasando por la actuación de dispositivos de campo, la integración de dispositivos a nivel de bahía y en ocasiones el control de instalaciones de mediana envergadura.

4.4 Merging Unit La merging unit es un dispositivo encargado de aportar una interfaz a los transformadores de tensión y corriente. La misma crea un conjunto de muestras coherentes en el tiempo con tres fases de tensión, tres fases de corriente y neutros de tensión y corriente. Desde el punto de vista del modelo de datos de la norma IEC 61850, esto es equivalente a los nodos lógicos TCTR (transformador de corriente) y TVTR (transformador de tensión).

Esta clase de dispositivos suelen ser de utilidad a la hora de extender la vida útil de equipamiento que, de otra manera, sería considerado obsoleto para los estándares actuales.





Figura 29: Esquema de Comunicación Mering Unit.

4.4.1 Tipos de Merging Unit

En principio, existen dos tipos de merging unit, las analógicas y las digitales.

Las merging unit de tipo analógica (AMU), obtienen sus tensiones y corrientes de transformadores convencionales. Luego convierten dichas señales analógicas en valores digitales y los transmite utilizando el estándar IEC 61850.

Las merging unit de tipo digital, obtienen sus datos de transformadores no convencionales, como pueden ser los que cumplen con la interfaz digital establecida en la norma IEC 60044-8, donde el uso de este tipo de dispositivos resulta obligatorio.

4.4.2 Transmisión de Datos

Generalmente, los datos obtenidos por las merging unit se publican como valores muestreados (SV) para ser utilizados posteriormente por los controles de nivel de bahía y/o relés de protección.

Adicionalmente, existen merging units como la MU320 de Alstom que cuentan con mensajes tipo GOOSE para el manejo de instrumentos de campo.





4.4.3 Sincronización de Base de Tiempo

Dependiendo del caso, las merging unit suelen sincronizar su estampa de tiempo por medio de un reloj maestro IEC 61588 PTP o mediante la señal de sincronización PPS, cumpliendo cualquiera de estos enfoques con los requerimientos necesarios para utilizar valores muestreados en el protocolo IEC 61850.

4.5 Gateway de Subestación

4.5.1 Introducción

En el marco de las redes de comunicación, un gateway (puerta de enlace, pasarela o conversor de protocolo), es una entidad de red capaz de hacer de interfaz entre equipos que utilizan diferentes protocolos. Esta entidad puede realizar la conversión de protocolos en cualquiera de las capas del modelo de interconexión de redes o incluso en todas ellas (desde la adaptación al medio físico hasta la capa de aplicación).

Algunas de las funciones que estos dispositivos realizan en sus puertos son:

Adaptar niveles eléctricos de las señales (capa física).

Adaptar impedancias de los medios por los cuales se transportan las señales (capa física).

Adaptar la modulación de la señal acorde al canal y al ruido en él (capa física).

Adaptar el entramado y el control de integridad acorde al ruido de canal (capa de enlace).

Adaptar las reglas de direccionamiento y transporte en la red para acceder a todos los dispositivos conectados por mas que pertenezcan a un espacio diferente de direcciones (capas de red y transporte).

Adaptar el modo en el que establecen enlace y dialogan las aplicaciones (capa de sesión).

Adaptar el formato en que se transmiten los objetos o datos más allá de las diferentes representaciones internas (capa de presentación).

Adaptar el modo en el que el usuario accede a la información para su uso (capa de aplicación).





En el contexto de las aplicaciones eléctricas, un gateway de subestación, difiere un poco del gateway comúnmente utilizado en infraestructuras de redes. Se trata de un equipo (hardware + software) dedicado a convertir protocolos eléctricos para integrar equipos de diferentes fabricantes y tecnologías a un mismo sistema eléctrico, agregando funciones de aplicación que permiten reunir los datos de los dispositivos inteligentes, re-mapearlos en una estructura de datos alternativa y accederlos en forma tanto local como remota. Se los puede encontrar en formatos monolíticos o modulares, permitiendo los últimos, la expansión del sistema en etapas.

Figura 30: Ejemplo de una Aplicación de Comunicación en Subestación con Gateway Netcon.





En la figura 30 se muestra un ejemplo, el gateway es capaz de integrar una gran variedad de dispositivos inteligentes que utilizan diferentes protocolos como pueden ser: Modbus, DNP3, IEC61850, IEC60870-5- 103, JBUS y SPA.

4.5.2 Funciones Avanzadas

El gateway de subestación es quizás uno de los equipos de red con mayor complejidad que puede llegar a encontrarse en los sistemas eléctricos, dado que, por cuestiones comerciales y de competitividad, los fabricantes integran gran cantidad de funcionalidades que anteriormente eran resueltas por otro tipo de equipos y excedían al concepto de Gateway.

Entre las funcionalidades que se pueden encontrar, tenemos:

Funciones de redundancia: Dependiendo de los requerimientos de disponibilidad y robustez del sistema, podemos llegar a necesitar gateways que presenten redundancia de componentes. Los sistemas redundantes suelen estar asociados a fuente de alimentación, unidad de procesamiento, placas de comunicación y elementos de almacenamiento. Muchos gateways están preparados directamente para operar agrupados en configuraciones del tipo hot-standby o hot-hot.

Funciones de seguridad: Dado que muchos de los protocolos soportados no disponen de seguridad propia, estos dispositivos suelen implementar mecanismos propios de seguridad, que posibilitan el acceso seguro a los datos en forma local y remota. Los sistemas de seguridad comúnmente implementados son niveles de usuario con perfiles de acceso, encriptación de la comunicación, redes virtuales, firewalls y túneles.

Funciones de almacenamiento: Para subsanar casos en que la disponibilidad de la red de comunicación se vea afectada, se provee de funciones para el concentrado de datos. Es común también, que algunos dispositivos permitan acceder en forma local y obtener información de eventos y datos desde una memoria extraíble. Las dos funcionalidades anteriormente mencionadas se acompañan algunas veces por un motor de base de datos que posibilita la búsqueda de eventos e información.

Funciones de red: Para facilitar la integración del gateway a diferentes topologías de red (por ejemplo: gestión de enlaces redundantes) se incluye un switch/router interno conectado a dos o más puertos.





Funciones de sincronización: Como muchos protocolos soportados disponen de métodos para sincronización temporal, los gateways permiten no solo la sincronización de su propio reloj, sino también cooperan para sincronizar a los dispositivos conectados a sus puertos. Para ello, pueden disponer de un puerto dedicado a la conexión de un GPS o señal IRIG y servir protocolos del estilo de NTP o SNTP.

Funciones de gestión y visualización: Para facilitar la configuración, mantenimiento y visualización de datos de forma local y remota, integran funcionalidades de HMI. Generalmente lo hacen a través de un servidor web o permitiendo la conexión de pantalla y teclado para acceder a una consola de usuario. También es común que permitan la gestión a través de la red mediante protocolos como SNMP o SSH.

Funciones de automatización: Existen gateways que pueden interactuar directamente con los dispositivos inteligentes ejecutando funciones de monitoreo y control, permitiendo al usuario la programación de la lógica y algoritmos mediante lenguajes estandarizados como IEC 61131.

Funciones de conectividad: Otro opcional puede ser el soporte para redes inalámbricas (Wifi, GPRS, 3G y 4G) generalmente con placas de expansión.

Funciones de extensión: Dada la marcada evolución de los dispositivos inteligentes y la posible aparición de nuevos protocolos, tanto propietarios como abiertos, algunos gateways ofrecen una interfaz de software para integrar el soporte de los mismos mediante librerías.

4.5.3 Casos de Uso

Estudiados ya los criterios de selección para los gateways de subestación, se presentan a continuación algunos modelos comerciales que aplican a soluciones de pequeña, mediana y gran escala.

Netcon GW502-IM

Es un equipo del fabricante Netcontrol, con formato monolítico, muy atractivo para la integración de dispositivos inteligentes en pequeña y mediana escala. Corre Linux embebido como sistema operativo, lo que le brinda seguridad, flexibilidad y confiabilidad. Aísla la ejecución de tareas de tiempo real y de tiempo compartido, garantizando la prioridad en las comunicaciones y almacenamiento sobre los procesos de visualización y administración.





Figura 31: Imagen de Equipo Netcon GW502-IM.

Provee soporte orientado a librerías para cerca de 50 protocolos utilizados en servicios de energía entre los cuales encontramos: IEC 61850, IEC 60870-5-10x, Modbus TCP, Modbus RTU, DNP3, ADLP, ANSI X3.28, RMT, RP570 y SPA. Según sea el caso, algunos protocolos pueden configurarse en modalidad de maestros o esclavos y re-mapear un protocolo a otro.

Puede manejar un máximo de 5000 puntos de conexión integrando hasta 100 dispositivos inteligentes dependiendo de la configuración.

Permite la redundancia total del hardware mediante el apareamiento de dos unidades iguales. Además provee de 2 puertos ethernet dedicados a configuraciones que necesiten redundancia en la conectividad de red.

Tiene 4 puertos ethernet y 1 puerto de fibra óptica a través de un switch, sumados a 4 puertos seriales (RS232/RS485) que permiten la conexión de los dispositivos inteligentes. Uno de los puertos seriales provee una consola de depuración con gran cantidad de herramientas para análisis de los diferentes protocolos. Otro de los puertos seriales puede ser usado como interface hacia un receptor GPS.

Posee 2 fuentes de alimentación independiente con tensión de entrada extendida hasta 60 volts.





Su diseño separa la memoria de configuración de la memoria de almacenamiento en 2 tarjetas flash, facilitando las funciones administrativas en topologías del tipo cluster, donde todos los equipos contienen la misma configuración.

En cuanto a las funciones de seguridad permite perfiles de usuario, redes privadas virtuales (VPNs), firewalls y encriptación AES-256.

Posee funciones de controlador lógico programable mediante el uso del lenguaje IEC 61131.

Tiene embebido un SCADA reducido basado en el producto Netcon 3000 del mismo fabricante.

Multidin D400

Es un equipo del fabricante General Electric con formato modular cuya configuración de hardware dependerá de que placas se utilicen conectadas a los slots de expansión.

Figura 32: Imagen de Equipo Multidin D400.

Este equipo dispone de gran capacidad de procesamiento y almacenamiento, por lo que es una buena opción para integrar dispositivos inteligentes a mediana y gran escala.

Entre los protocolos que es capaz de manejar se encuentran: DNP3 (serial y tcp), IEC 61850, Modbus RTU, Modbus TCP, Hydran, Generic ASCII, SEL, IEC 60870-5- 10x.





Permite instalar 2 fuentes de alimentación extraíbles en caliente, lo que permite garantizar una alta disponibilidad incluso durante la falla de una de ellas. Se dispone de una gran gama de fuentes para elegir tanto en tensión alterna como continua.

Su diseño modular permite hasta 16 puertos serie (RS232/RS485) para conexión de dispositivos y hasta 64 puertos series virtuales. También dispone de placas de expansión ethernet y de fibra óptica, que incluyen switches con varios puertos según las distintas necesidades.

Ofrece varios sistemas de sincronización temporal entre los que se encuentran: IRIG, SNTP, NTP. Existe también una placa de expansión que permite distribuir la señal de IRIG hacia otros dispositivos.

Entre las funciones de seguridad permite autenticación basada en RADIUS y TACACS+, control de acceso basado en roles, registros de acceso auditables, acceso seguro a través de protocolos como SSH, SCP o HTTPS, encriptación de 128 bits, firewall, redes privadas virtuales, entre otras.

Posee funciones avanzadas de automatización mediante el uso del lenguaje IEC 61131 que le permiten realizar funciones de cálculo, seguridad, control y medición.

También encontramos un sin número de funciones de almacenamiento y visualización como: registro de eventos, registros de datos, soporte para descarga de oscilografías, búsqueda avanzada mediante motor de base de datos e interface HMI a través de un servidor web (accesible de forma local y remota).

4.5.4 Concluciones

Los gateway de subestación son dispositivos muy poderosos, que gracias a los avances tecnológicos han dejado de ser meros conversores de protocolo, para pasar a integrar gran cantidad de funciones realmente interesantes. Es por ello, que en el contexto de una subestación, línea de transmisión o incluso en los centros de generación (donde suele haber gran mixtura de equipos de diferentes fabricantes) resultan útiles para establecer un punto de convergencia que permita reunir la información, empaquetarla y enviarla a un punto de supervisión y control aguas arriba de la red como puede ser un sistema SCADA o similar.

El control de acceso y los niveles de seguridad que estos gateway agregan ayuda a integrar protecciones, puntos de medición y demás equipos críticos, disminuyendo el riesgo de una





manipulación malintencionada por parte de intrusos en la red. Otra de las ventajas clave, es que permiten el acceso remoto seguro para tareas de mantenimiento, incluso a los dispositivos inteligentes conectados aguas abajo, lo que ahorra un gran gasto administrativo y evita ciertos problemas de auditabilidad.

El conjunto de funciones disponibles en cuanto a almacenamiento, visualización, gestión y depuración, permiten una eficiente puesta en marcha de los equipos tanto de manera local como (cuando se necesita de soporte) remota.

Por último y no menos importante, los gateways modulares resultan de particular interés en aplicaciones donde se prevé cierto crecimiento en la cantidad de dispositivos inteligentes a conectar, por lo cual habrá que tenerlos en cuenta al planear una topología de interconexión genérica. Esta topología podría planearse en forma de clusters idénticos a modo de acotar el gasto administrativo y las tareas de configuración y mantenimiento.

4.6 Referencias Automatización de una Subestación Eléctrica utilizando el Protocolo IEC 61850 y el ICCP

para el envio de Datos - Marco Antonio Toscano Palacios.


Manuales SEL 351.

Manuales SEL 351A.

Manuales RTU500 Series.

Manuales Remote Terminal Unit RTU560.

Manuales MU 320.

Manuales Netcon GW502-IM Substation Gateway.

Manuales Multilin D400 Advanced Substation Gateway.





Capítulo 5: SEGURIDAD DE LA INFORMACIÓN

5.1 Introducción Hoy en día las redes eléctricas se encuentran compuestas por un elevado número de dispositivos electrónicos inteligentes, estos elementos han sido interconectados como nunca por medio de redes de comunicaciones, incluso las distintas instalaciones que forman parte del sistema han sido integradas entre sí.

Este grado de conectividad favorece el intercambio de información y la operación en tiempo real del sistema, pero a la vez lo hace vulnerable a los más recientes tipos de amenazas informáticas. Esta clase de ataques tienen la capacidad de interrumpir el servicio, provocando un inmenso daño económico.

Por lo tanto, es preciso establecer la mejor manera de proteger los sistemas de información y los servicios de comunicación involucrados en el sistema eléctrico. A tal fin, se identificaran lineamientos y medidas concretas aplicables a las redes eléctricas.

En función de lo establecido por los distintos estándares en materia de seguridad informática (ISO 27000, NIST 800-53, NERC CIP, IEC 62443 y IEC 62351), las medidas analizadas se clasifican a grandes rasgos de la siguiente manera:

Gestión de riesgos.

Gestión de procesos.

Seguridad de los sistemas de información.

Seguridad de la infraestructura de red.

Seguridad de datos.

Auditoría de datos.

Respuesta a incidentes.

Continuidad de operaciones.





5.2 Identificación de Riesgos Uno de los primeros pasos en el establecimiento de un plan de seguridad informática consiste en la identificación de las potenciales amenazas y riesgos dentro de los sistemas de la información involucrados. A tal fin, se realizará una breve enumeración de algunas de las principales vulnerabilidades presentes en la normal operación de un sistema eléctrico.

Dentro de una instalación: Como ya se mencionó en reiteradas ocasiones, algunos dispositivos utilizados en la normal operación de un sitio son de particular interés para un atacante informático; algunos objetivos estratégicos son los IEDs, las RTUs y el SCADA.

Entre instalaciones: Actualmente, las comunicaciones entre instalaciones utilizan una amplia variedad de tecnologías (satélite, fibra óptica, etc.), con el propósito de integrar un número cada vez mayor de funciones y dispositivos entre dos o más puntos remotos. Por lo tanto, la interrupción de estas conexiones tienen la capacidad de generar fallas en cascada de los sistemas de la red eléctrica.

Entre el centro de control y las instalaciones: Los centros de control se comunican con las distintas instalaciones para la operación normal del sistema interconectado. En la actualidad, dado que los centros de control no tienen la capacidad de lidiar con la creciente cantidad de información generada, debe hacer uso de equipamiento ubicado en las instalaciones con dicho propósito; dicho canal de comunicaciones puede proveer de un canal adecuado para un ataque malicioso. Otro punto de particular interés es el canal de comunicaciones entre instalaciones y el ente regulador.

Entre centro de control principal y secundario: Hoy día, se suele hacer uso de centros de control secundarios como medida de seguridad adicional. Si bien esto es favorable para la seguridad operativa del sistema, estos sitios comparten accesos a bases de datos y otras fuentes de información crítica. Adicionalmente, este tipo de operaciones se suelen llevar a cabo a través de la red corporativa. Por lo tanto, si un atacante consiguiera vulnerar uno de estos sitios, conseguiría replicar fácilmente sus pasos para acceder al otro.

5.3 Medidas de Seguridad Una vez que se han establecido las amenazas más relevantes, es posible identificar un conjunto de medidas concretas para asegurar los sistemas involucrados. A continuación se mencionan algunas de las medidas más relevantes a tener en consideración.





Separación física de redes: dentro de una instalación, es normal que convivan equipos de uso corriente con acceso a internet, servidores con las aplicaciones SCADA y dispositivos inteligentes entre otros. En este ambiente, colocar en distintas redes los equipos con diferentes funciones provee una medida de seguridad adicional, ya que no se puede acceder lo que no está conectado.

Bloqueo físico de conexiones: el bloqueo físico de los puertos de conexión libres y el aseguramiento de las conexiones existentes dificultan la capacidad de infiltración de terceras partes “de confianza”. Adicionalmente, es posible deshabilitar por software los conectores en desuso de los distintos switches, routers y demás equipos de la infraestructura de comunicaciones.

Uso de redes virtuales (VLAN): el uso de redes virtuales para la separación en grupos funcionales de los distintos dispositivos utilizados en una instalación eléctrica es una eficiente medida a la hora de reducir la vulnerabilidad a amenazas informáticas. El uso de VLAN permite imponer un control estricto sobre la comunicación entre dispositivos, complicando así el uso de gran cantidad de ataques que intentan explotar vulnerabilidades inundando la red con falsa información.

Gestión de usuarios: es importante configurar usuarios y contraseñas únicos para cada dispositivo electrónico inteligente y terminal remota que se encuentre dentro de una instalación eléctrica ya que esto minimiza el grado de exposición. Luego, es posible brindar un control de acceso a los usuarios que lo requieran por medio de gateways encargados de establecer una conexión con propósitos administrativos entre usuarios autenticados y los distintos dispositivos.

Encriptación de comunicaciones: si bien la encriptación de las comunicaciones dentro de una instalación suponen una carga excesiva y pueden afectar las características de tiempo real de las mismas, esto no es cierto para todas las comunicaciones que se mantienen hacia afuera. Por lo tanto, es de vital importancia el uso de conexiones encriptadas en las conexiones con instalaciones, centros de control, entes reguladores y cualquier otra comunicación de características similares.

Eliminar puertas traseras: una práctica bastante común es el mantenimiento de conexiones secundarias, normalmente inseguras, para la tarea de soporte y actualización de equipos por parte del fabricante. Es sumamente prioritario eliminar este tipo de conexiones y reemplazarlas por el uso de permisos de acceso temporales garantizados exclusivamente en el momento que sean necesarios y revocados una vez que terminen las tareas a realizar.





5.4 Referencias Análisis de las normas de seguridad para los controles, las comunicaciones y otros equipos

críticos de la red de energía

Security Evaluation of Substation Network Architectures.

Making the most out of substation IEDs in a secure, NERC compliant manner.

Data Communication in Substation Automation System.

Inter-Control Center Communications Protocol (ICCP, TASE.2): Threats to Data Security and Potential Solutions.

Secure Architecture for Industrial Control Systems - Sans Institute.

How to protect the substations from physical or cyber intrusion - IEEE.

White Paper on Security Standards in IEC TC57.





Capítulo 6: NUEVAS TENDENCIAS EN AUTOMA-TIZACIÓN DE INSTALACIONES ELÉCTRICAS

6.1 Introducción Hoy en día las redes eléctricas operan de forma ininterrumpida en todo el mundo, esto hace que sea imprescindible contar con una topología de red que sea adecue a dichos requerimientos.

Cuando un componente dentro de un sistema de protección falla, existen normalmente dos posibles resultados: (a) que la falla saque de servicio la totalidad del sistema, (b) que el sistema pierda la función de protección y quede expuesto. En consecuencia, las comunicaciones de una instalación eléctrica se diseñan con el propósito de que la falla de uno de sus elementos no derive en la afectación del normal funcionamiento del sistema.

Otro tema no menor a considerar en el diseño de la topología es el tema de seguridad de la red, ya que las redes eléctricas son un servicio crítico y, por lo tanto, un objetivo muy atractivo para agentes maliciosos y fuerzas hostiles. Por lo tanto, es de vital importancia separar correctamente las redes de operación, de las redes de acceso remoto, en forma física o lógica, según corresponda.

También es importante tener en cuenta en la heterogeneidad de dispositivos existentes. Si bien siempre existen esfuerzos tendientes a estandarizar y modernizar los equipos y protocolos utilizados, no sería realista esperar que todos los agentes involucrados cuenten con las últimas tecnologías al momento de llevar a cabo un proyecto de gran alcance. En consecuencia, debe considerarse el uso de equipos cuyo propósito sea adecuar los distintos sistemas, siempre y cuando esto sea posible.

Por último deberá considerarse, no sólo la capacidad de expansión hacia una mayor cantidad de equipos y protocolos actualmente disponibles, sino el nivel de adaptación que la topología puede ofrecer respecto a los futuros protocolos y dispositivos que pueda llegar a ofrecer el mercado a corto-mediano plazo.

6.2 Soluciones ABB





Integración de Subestaciones

La firma ABB, conocida empresa en las áreas de generación de energía y automatización industrial, cuenta con un portfolio de soluciones bastante atractivo para la operación de instalaciones eléctricas.

Una de sus principales propuestas consiste en utilizar unidades de terminal remota de la familia RTU560 en cada una de las bahías que componen una subestación. Dichas unidades proveen de conectividad a los dispositivos que se encuentran dentro del rack gracias a un diseño modular, el cual cuenta con módulos de procesamiento independientes para cada protocolo y tipo de enlace necesario. A su vez, es posible conectar un IED a más de un módulo para proveer un enlace redundante.

Una vez resuelta la conectividad a nivel de bahía, cada una de las RTU se conecta a otras dos para lograr una conexión en anillo, la cual tiene por finalidad mejorar la tolerancia a fallos de la arquitectura propuesta.

Figura 33: Arquitectura de Comunicación con RTU 560 para una Estación.





En lo relativo a seguridad a nivel de dispositivos, las unidades de terminal remota permiten la configuración de redes virtuales, un sistema de manejo de usuarios, acceso basado en roles y la capacidad de deshabilitar puertos que se encuentren en desuso. Esto nos permitirá proteger los distintos dispositivos que se encuentren conectados a nivel de subestación mediante la restricción de accesos no autorizados.

Las unidades de terminal remota RTU560 también pueden equiparse con el software SDM600. Este software agrega funciones para el seguimiento de versiones de firmware de los dispositivos, control de versiones de las configuraciones, recolección automática de archivos de los distintos IED y visualización de los mismos, todo por medio de una interfaz web.

Figura 34: Esquema de Comunicación para una Estación con Software SDM600.

En el centro de control, el sistema SDM600 puede ejecutarse como una aplicación en servidores que cuenten con el sistema operativo Windows Server 2008/2012. Desde allí, es capaz de comunicarse con las instancias que se encuentran a nivel de subestación, preferentemente a través de una conexión segura.

También es posible ejecutar la aplicación en estaciones de trabajo que utilicen Windows 7/8. Esto nos permite ejecutar este sistema de manera conjunta con el SCADA de subestación (como puede ser el MicroSCADA Pro de ABB).

En conclusión, es posible diseñar una arquitectura alrededor de los productos ABB que cuente con la posibilidad de integrar dispositivos de distintos fabricantes y generaciones, ya sea a nivel de bahía, subestación o centro de control. Sin embargo, es necesario considerar que esto nos fuerza a depender de ABB como proveedor exclusivo en lo que respecta a infraestructura.





Figura 35: Esquema de Sistema Conjunto SCADA/SDM600.

Recolección Automática de Archivos de Perturbaciones

Un problema relevante resuelto por ABB es un proyecto de recolección automática de archivos realizado en una ciudad Europea (con 1.4 millones de habitantes). Dicha ciudad contaba con 40 subestaciones transformadoras (de 110kV a 10kV), las cuales debían ser visitadas en auto para recolectar manualmente los archivos de perturbaciones cada vez que ocurría un incidente.

Dado que el costo asociado al uso de ingenieros para tareas de recolección manual de archivos era desproporcionado, el cliente decidió instalar la aplicación SDM600 en terminales remotas RTU560 que se encontraban en su poder. Si bien esto puede sonar complicado, el proceso se reduce a la inserción de un único módulo (560HMR01) en un slot estándar de dicha unidad.

Una vez realizada la conexión entre RTU y centro de control, el proceso de recopilación de información envía un correo electrónico a los responsables de manera automática, permitiendo tomar la decisión correcta en una fracción del tiempo requerido por el sistema anterior, reduciendo los costos de operación enormemente.

Adicionalmente, el software SDM600 posee funciones de seguridad que permiten controlar el acceso de los usuarios para tareas de mantenimiento y la detección de intrusión en el sistema.





Figura 36: Esquema de Sistema de Recolección de Datos.

6.3 Soluciones Kalkitech

Expansión de Subestaciones

Kalkitech es una reconocida empresa que se dedicada a brindar soluciones en el área de servicios energéticos orientados a Smart-grid y a la eficiencia energética. Uno de sus giros comerciales está enfocado en el monitoreo, automatización y optimización de los sistemas de potencia. Por eso resulta interesante para el estudio analizar en detalle los casos de implementación que la firma ha realizado en diferentes partes del mundo.

Entre sus notas de aplicación, encontramos el caso de una subestación a la que entran dos líneas en 220kV y que alimenta dos salidas en 110kV, con necesidades de expansión. El caso es interesante debido a que implica realizar la expansión del bus de subestación utilizando la norma IEC 61850, sin reemplazar los dispositivos inteligentes ya Existentes.

En la figuras 38 se muestran las arquitecturas del sistema, donde se recolectan datos provenientes de equipos de medición, protección y control que utilizan protocolos propietarios o antiguos y se los integra a un bus IEC 61850 mediante el uso de un gateway SYNC 2000 y una terminal remota SYNC





2111. Los nuevos equipos a instalar ya soportan IEC 61850 de forma nativa, por lo que se integran a la red de forma directa.

Figura 37: Estación del estudio de Soluciones de Kalkitech

Adicionalmente a la visualización y control local, los datos adquiridos se proveen al centro de despacho de carga (LDC) mediante un enlace del tipo IEC 60870-5-104 sobre fibra óptica con opción de redundancia. Esta última conversión de protocolo se realiza mediante el concentrador de datos SYNC 3000. De este modo toda la comunicación troncal responde a estándares IEC que facilitarán la futura expansión.

Esta arquitectura descentralizada tiene las ventajas de optimizar tanto el cableado como las comunicaciones permitiendo un mejor manejo de los datos. Por ejemplo, los equipos de protección que se conectan al gateway mediante protocolos como SEL, SPA, IEC 60870-5-103 y Areva Courier son mapeados a nodos lógicos, al igual que los medidores de energía que se conectan por MODBUS a la terminal remota. La terminal remota mapea también al bus, entradas provenientes de diferentes servicios auxiliares. De este modo, a nivel subestación todos los datos se integran al mismo modelo y quedan disponibles para uso local en el SCADA o remoto en el LDC.





Figura 38: Arquitecturas de comunicación del Caso de Estudio.

Automatización Personalizada a Gran Escala

Otro caso interesante para el análisis, es el proyecto realizado para la distribuidora eléctrica de Endesa con operación en Colombia llamada Codensa. El mismo consistía en modernizar 70 subestaciones de alta tensión para incorporar tecnología de comunicaciones actualizada, manteniendo compatibilidad con el equipamiento existente.

Una particularidad de este proyecto es que el cliente necesitaba integrar no sólo estándares abiertos para compatibilidad a futuro, sino también preservar un protocolo personalizado basado en el IEC 60870-5-101 al que llamaban IEC101-ENDESA.

Si bien los detalles del sistema dependían de las condiciones particulares de cada subestación, el núcleo de la solución fue el concentrador de datos SYNC 3000 mencionado anteriormente.





Figura 39: Arquitectura de Caso de Estudio Revamping Condesa.

El concentrador de datos SYNC 3000 es muy robusto y dispone de una gran cantidad de funcionalidades entre las que podemos encontrar:

Soporte para una extensa cantidad de protocolos propietarios y abiertos.

Motor de conversión de protocolo extensible permitiendo personalizar los protocolos existentes o implementar alguno nuevo.

Capacidad de comunicación con múltiples maestros.

Sincronización temporal (servidor y esclavo) mediante gran cantidad de protocolos como IRIG, SNTP, NTP, etc.

Seguridad de redes como redes privadas, túneles y encriptación.

Almacenamiento local de data y eventos.

Interface web para monitoreo y control.

Redundancia en la conectividad soportando PRP.





Redundancia opcional de la fuente de alimentación.

Diseño modular permitiendo agregar puertos seriales, ethernet, de fibra óptica o incluso conectividad celular.

Este conjunto de características lo definieron como el candidato ideal para conectar el bus de procesos y el bus de subestación con los centros de control situados aguas arriba del esquema, resolviendo los problemas de redundancia y personalización de protocolos.

Plantas de Generación

El siguiente proyecto fue realizado para una compañía de generación eléctrica ubicada en la India con una potencia instalada de 2000MW. Consistió en implementar un sistema automático de lectura de medidores (AMR) en 3 plantas de generación térmica para su monitoreo desde un centro de control (GCC). Este sistema debía permitir la captura de datos en tiempo real desde todas las unidades de generación de cada planta y reportarlos hacia un único centro de control que decidiera cómo optimizar el despacho de energía.

El problema fue resuelto en base a gateways SYNC 2000 (ya mencionados anteriormente) junto con servidores basados en el sistema de adquisición de datos (MDAS) SYNC 5000, como se observa en la arquitectura mostrada en la figura 40.

A nivel de planta, dada su compatibilidad con el protocolo Modbus RTU, los medidores de energía se conectaron en un esquema multidrop RS485 distribuidos en los puestos serie de los gateways SYNC 2000. Estos últimos se unieron a la red de área local mediante el uso de enlaces ethernet y fibra óptica en los casos donde la distancia superaba los 100 metros. Este último caso, requirió conversores de medios ubicados en ambos extremos del enlace.

Todas las plantas están conectadas al centro de control mediante un enlace redundante administrado por routers. Estos routers manejan la comunicación conmutando a un canal satelital en caso de pérdida en el canal principal.

Tanto en las redes locales de planta como en la red local del centro de control, encontramos servidores SYNC 5000 corriendo la aplicación ELTRIX. Este software modular se utiliza para optimizar procesos de generación, transporte y distribución. En este caso se implementó un sistema de tarifas basado en la disponibilidad, mediante el uso del módulo de despacho de carga DOPS (Dispatch operations of power systems).





Por último, la comunicación y sincronización de los datos entre servidores SYNC 5000 distribuidos en el sistema sucede automáticamente a nivel de aplicación. También estos servidores son los encargados de sincronizar temporalmente los equipos medidores. Los usuarios que desean obtener datos y realizar operaciones de control podrán conectarse a los mismos mediante estaciones de trabajo distribuidas en las redes de área local.

Figura 40: Arquitectura del Caso de Estudio de Monitoreo en Tiempo Real de Generadores en India.





6.4 Soluciones Siemens

Administración Remota de IEDs

Un problema adicional que se presenta comúnmente, además de la lectura sincronizada de datos y eventos desde los centros de control, es la configuración y auditoría remota de dispositivos inteligentes ubicados a lo largo del sistema eléctrico. La marca Siemens dispone de una gama de equipos denominada Ruggedcom que permiten atacar este problema.

Combinando el uso de routers Ruggedcom RX1500 con un software denominado Ruggedcom Crossbow se puede establecer una comunicación segura entre uno o varios centros de control con una o varias subestaciones. A continuación se muestra un diagrama simplificado de referencia con la arquitectura propuesta.

Mucho más que un router, el Ruggedcom RX1500, es todo un gateway modular multiprotocolo con funciones adicionales de capa 2 y 3 del modelo OSI. Por esta razón, además de las funciones de ruteo, permite integrar dispositivos inteligentes mediante el uso de placas de expansión (seriales, ethernet, fibra óptica). Algunos de los protocolos soportados son: Modbus RTU, Modbus TCP, DNP3, IEC 61850, entre otros.

Como se ve en la figura 41, el router obtiene datos y eventos desde varios IEDs u otros equipos (terminales remotas, gateways, etc.) conectados a la red de subestación (comúnmente mediante el protocolo IEC 61850). Adicionalmente, mediante el uso de las funciones de capa 2 y 3 puede establecer un enlace seguro (red privada virtual sobre IPSEC) hacia otro router RX1500 o algún servidor similar del centro de control.

En el centro de control, ya sea en un servidor físico o un servidor virtual (con sistema operativo Windows Server) se ejecuta el software Ruggedcom Crossbow SAM (Secure Access Manager). Este software administra las conexiones desde múltiples clientes y las redirige hacia los IEDs. También es el encargado de manejar criterios de seguridad, como qué usuarios pueden acceder a qué IEDs o qué rol pueden tener en ese acceso (configuración, lectura de datos, lectura de eventos, etc). Además provee una serie de funciones automatizables dentro del mismo servidor, como: descarga de registros de datos y eventos, generación de alarmas, envío de mails, entre otras. Si se lo combina con el software Ruggedcom Crossbow SAC (Station Access Controller), instalado en un servidor adicional o un router RX1500 (con sistema operativo Siemens Rox), se puede hacer uso de todas las





funcionalidades en forma local (dentro de la misma subestación), aún en caso de pérdida de conexión con el servidor.

Figura 41: Solución con Tecnología Ruggedcom.

La arquitectura cliente-servidor de Crossbow es escalable y multinivel, integrando múltiples sitios dentro de un centro de control o inclusive múltiples centros de control en cascada. Todos los usuarios deben conectarse mediante un software cliente al servidor SAM, el cual es el único cliente confiable de los IEDs. Luego de validado el usuario y rol (mediante el sistema RBAC), se podrá explorar los IEDs en una estructura de directorios (según algún criterio), y solicitar al servidor SAM una conexión con alguno de ellos a través de la red privada virtual. Esta conexión puede tener que atravesar varios elementos de la red como ser los routers RX1500, pero desde el punto de vista del usuario la verá como una conexión directa y transparente hacia el IED. Una vez conectado con el IED, el usuario puede elegir entre un conjunto de aplicaciones que saquen provecho del mismo, ya sea para configurarlo u obtener datos.





El sistema propuesto es compatible con aplicaciones y equipos de las marcas ABB, SEL, GE, Novatech, Cooper, entre otras. También tiene aspectos interesantes desde el punto de vista de la tecnología de información como ser: el cumplimiento del estándar de seguridad NERC, integración directa con los servidores Active Directory/RSA o base de datos SQL ya existentes en una infraestructura, generación de reportes para auditoria, control de acceso a usuarios basado en roles, redundancia para alta disponibilidad (HA) y más. Por último, se dispone de un conjunto de módulo (plugins) que dan valor agregado al proceso administrativo de los IEDs, permitiendo: descarga de registros oscilográficos o reportes de falla a demanda o de forma planificada, detectar inconsistencia entre versiones de firmware de un grupo de IEDs, detectar inconsistencia entre archivos de configuración de un grupo de IEDs, etc.

Como se puede anticipar, esta arquitectura resulta interesante para cuando existe toda una infraestructura de tecnología de información ya montada dentro de los centros de control y de las subestaciones. En ese caso el software Crossbow SAM puede instalarse sin mayores cambios en algún servidor o máquina virtual ubicadas en los centro de control y cooperar con los servidores ya existentes de autenticación y almacenamiento de datos conectados a la misma red. Dentro de la subestaciones se deberán instalar routers RX1500 a modo de conectar los IEDs que se desee, y si fuese necesario garantizar el acceso local, configurar Crossbow SAC en alguno de ellos.

Para terminar, si bien la propuesta es multimarca y de simple implementación, presenta una gran desventaja, dado que Crossbow es una plataforma cerrada y por lo tanto utiliza protocolos no estándar para la conexión a los routers RX1500 o equipos de la serie Ruggedcom. Esto obliga a una dependencia del fabricante cuando se pretenda escalar en tamaño o expandir las funcionalidades del sistema.

6.5 Soluciones Moxa

Sincronización de Valores Muestreados

Moxa es un importante fabricante en materia de redes industriales y soluciones de automatización. La empresa cuenta con una línea de productos para redes eléctricas con soporte para los protocolos IEC 61850 (Automatización de Sistemas de Potencia) y IEEE 1588 (Protocolo de Tiempo Preciso).





En el proyecto bajo análisis, la principal subestación de transformación de 500kV a 220kV de la ciudad de Suzhou (Jiangsu, China) contaba con transformadores (CT/VT) conectados por medio de merging units por medio de valores muestreados (IEC 61850-9-2). Para garantizar la precisión temporal de los datos de valores muestreados, el personal de la subestación diseñó una arquitectura basada en el estándar de sincronización de tiempo IEEE 1588.

A tal fin, Moxa diseñó una solución en base a dos de sus renombrados switches. Para el bus de procesos, el cual tenía requerimientos de precisión temporal, se utilizaron switches serie PT-7728-PTP, con soporte para el protocolo IEEE 1558 v2 y para IEC 61850. Para el bus de subestación, se utilizaron switches serie PT-7728, con soporte para el protocolo IEC 61850. Adicionalmente, en cada bus se implementó una doble topología estrella con el fin de proporcionar redundancia.

Figura 42: Solución con Tecnología Moxa para Estación Suzhou.

Integración de Subestaciones a Gran Escala





Este proyecto fue realizado para una compañía de distribución de energía en Alemania. Siendo uno de los proveedores más grandes de Alemania (con alrededor de 530 mil usuarios), el cliente se encontraba en la necesidad de interconectar un gran número de subestaciones al centro de control de una manera eficiente.

Figura 43: Solución Moxa de Integración de Control y Monitoreo de Estaciones Alemanas.

Para cumplir con los requerimientos del cliente se instalaron 48 switches Moxa de la línea PowerTrans conectando subestación y switches mediante fibra óptica en una topología en estrella. Esto representa una solución flexible, donde la falla de cualquiera de las subestaciones no afecta la comunicación de las demás con el centro de control. Otra ventaja de la configuración en estrella es que se puede mejorar a la conexión en cadena de Moxa (Moxa Turbo Chain) cuando se desee, mejorando la confiabilidad de la red.

Adicionalmente, fue posible satisfacer las siguientes necesidades del cliente con un único modelo (Moxa PT-7728):

Instalar un conjunto de switches gestionables con 24 puertos.





Instalar un conjunto de switches gestionables con 48 puertos.

Instalar tres switches principales en la sala de control.

Esto permitió simplificar el mantenimiento y reducir los costos asociados.

Integración Masiva de IEDs

En este proyecto, Moxa tuvo que implementar una solución de bajo costo para la integración de 100 IEDs mediante una topología orientada a la confiabilidad en la transmisión de los mensajes GOOSE. El proyecto fue realizado en una subestación propiedad de la Compañía KOSPO (Korea Southern Power Company), ubicada en la región de YoungWol con una tensión de 154kV.

Figura 44: Solución de integración de Estaciones en YoungWol

La implementación se resolvió mediante una red en anillo redundante, donde cada uno de los switch a los que se conectan los IED se encuentra conectado a dos switches (principal y backup) siguiendo dicha topología.

Cada uno de los switches utilizados (PT-7728) soporta hasta 18 puertos con enlace de fibra óptica. Esto permitió conectar la cantidad de dispositivos requeridos con un moderado número de switches.





Adicionalmente, la topología en anillo utilizada por Moxa permite conectar hasta 250 switches con tiempos de recuperación inferiores a 20 ms, lo cual permite garantizar que no se perderán paquetes aún en redes de gran tamaño.

6.6 Estudio Estadístico del SIC y el SING Con el fin de proporcionar información adicional que soporte las decisiones de diseño de la solución propuesta, se llevó a cabo un análisis estadístico de protecciones relevadas con el propósito del presente estudio.

La metodología empleada es simple, se seleccionaron las 13 protecciones de uso más frecuente, las cuales representan más del 75% de las protecciones relevadas. Luego se estudiaron en detalle las hojas de datos de los equipos seleccionados, concentrándose en las funcionalidades y protocolos que estos ofrecían.

En la figura 45 se incluye una tabla y gráficas, las cuales muestra las protecciones seleccionadas, indicando su modelo y marca, el porcentaje que representan sobre el total de protecciones utilizadas y el nivel de soporte para los protocolos abiertos más relevantes que fueron analizados (indicando variante utilizada, donde corresponda).

De la gráfica se observa que el 80% sobre el total de los equipos relevados traen un soporte para el estándar IEC 61850, el 65% sobre el total de los equipos relevados disponen de DNP3, el 55% sobre el total de equipos relevados disponen de Modbus (RTU o TCP) y un 5% no disponen de protocolos para interconexión.

Estos porcentajes nos dan idea de que nuestro esfuerzo por integrar equipos al sistema de monitoreo de protecciones, debe hacerse en mayor medida hacia el estándar de largo plazo IEC 61850. En instalaciones relativamente nuevas que lo contemple, podrá hacerse conectando directamente estos equipos a los switchs del bus de bahía o del bus de proceso. En instalaciones más antiguas que no lo contemple, se deberá recurrir a una conversión de protocolo (gateway) hacía el protocolo troncal utilizado en la estación.





Figura 45: Resultados de Relevamiento de Protocolos en el SIC y el SING.

Para el resto de equipos que no dispongan del estándar IEC 61850, generalmente existirá en el mercado (como ya vimos), algún equipo capaz de mapear sus datos provenientes de protocolos como Modbus (RTU o TCP) y DNP3 hacia este nuevo estándar, donde una vez hecho esto, será indistinguible a los ojos del usuario.

Como conclusión, puede asegurarse entonces, que mediante el uso de una topología que tenga como troncal el bus IEC 61850 (al menos en los niveles de bahía y subestación), y disponga de gateways/rtu que acompañen a la integración de buena cantidad de protocolos tradicionales (existen gateways que soportan hasta 50 protocolos!), se facilitará en gran medida la integración de protecciones tanto actuales como futuras.





6.7 Topología Propuesta Después de haber analizado las soluciones propuestas por distintos fabricantes, es posible concluir que la topología presentada como parte del anteproyecto sigue manteniendo su validez. A modo de recordatorio, la estructura propuesta consiste en dos partes bien diferenciadas; una es el módulo recolector y la otra el módulo concentrador. Por lo tanto, se procederá a mostrar las equivalencias existentes entre las distintas soluciones y la propuesta original.

El módulo recolector cuenta con funciones para: (a) adaptar el medio físico y los protocolos específicos de cada protección, (b) agregar los datos y eventos obtenidos para su despacho y (c) despachar los datos hacia los módulos concentradores en un formato estándar.

Figura 46: Modelo del Módulo Recolector.

Teniendo en cuenta las soluciones estudiadas, el nodo concentrador, el cual lleva a cabo la adaptación de las señales de medición, presenta funciones muy similares a las de un gateway o una RTU. Estos dispositivos cuentan con módulos (o a veces solamente funcionalidades) para la conversión de los protocolos y medios utilizados por cada IED a un formato estandarizado (IEC 61850). Las conversiones de señales analógicas y digitales a un formato estándar se pueden efectuar por medio de otros módulos (en los dispositivos que así lo permitan), RTU más pequeñas, IEDs y merging units.





Algunos de los dispositivos destacados para la implementación de nodos recolectores son la RTU560 de ABB, el Ruggedcom RX1500 de SIEMENS y los SYNC 2000/2111 de Kalkitech.

Por su parte, el módulo concentrador es capaz de: (a) recepción de los datos y eventos provenientes de los distintos recolectores, (b) el almacenamiento de datos y eventos, (c) la implementación de un mecanismo de generación de eventos globalizado, (d) la adaptación de los datos para su visualización y (e) la generación de reportes.

Figura 47: Modelo del Módulo Concentrador.

El nodo recolector, como su nombre lo indica, tiene la función primordial de obtener todos los datos con formato estandarizado provenientes de los distintos nodos concentradores. Para esta función, existen gateways y RTUs capaces de obtener datos, archivos de eventos, configuraciones de dispositivos, etc., haciendo uso de protocolos estandarizados. Estos dispositivos suelen contar, adicionalmente, con funciones de tipo HMI/SCADA. También es posible implementar nodos recolectores por medio de servidores, generalmente a través del uso de aplicaciones de tipo SCADA o similares.

Algunas selecciones importantes para la implementación del nodo recolector están compuestas por el software SDM600 de ABB corriendo en sus RTU560 o en un servidor, el software Crossbow SAC de SIEMENS ejecutándose en switch Ruggedcom RX1500 o en un servidor y el dispositivo SYNC 3000 de Kalkitech.





Adicionalmente, es necesario considerar como parte del sistema a implementar, el conjunto de equipos y/o aplicaciones que se requiere implementar en los distintos Centros. Dichos equipos tienen por función el monitoreo y recolección de los datos generados por los distintos nodos recolectores.

Algunos candidatos para los sistemas que se ejecutarán en el CDEC son el software SDM600 de ABB corriendo en servidores del CDEC, el software Crossbow SAM de SIEMENS ejecutandose en servidores del CDEC y uno o varios equipos SYNC 4000 de Kalkitech.

En conclusión, no existe una única implementación posible, sino un conjunto de soluciones de características similares que se pueden aplicar y combinar a fin de implementar un sistema de monitoreo de protecciones.

Figura 48: Modelo Completo





6.8 Referencias Substation Automation Solutions SAS 600 Series - ABB.

RTU560 product line - ABB.

System Data Manager SDM600 - ABB.

MicroSCADA Pro DMS600 - ABB.

MicroSCADA Pro - ABB.

SDM600 functionality joins RTU560 flexibility - ABB.

Transmission Substation Automation Using SYNC 3000 And SYNC 2100 - Kalkitech.

AMR for enabling Online Availability Based Tariff System in a Power Generation Company - Kalkitech.

Enabling Large-Scale Substation Automation Using Kalkitech’s DCU, SYNC 3000 - Kalkitech.

Substation Automation Case Studies - Moxa.





PARTE B

DISEÑO DE ARQUITECTURA Y

ESPECIFICACIÓN DEL SLRP





Capítulo 1. JUSTIFICACIÓN DEL DESARROLLO. CRITERIOS DE DISEÑO

1.1 Antecedentes Según la normativa vigente NT SyCS, “Es necesario disponer de un Sistema de Medición permanente en los puntos del Sistema Interconectado que la Dirección de Operaciones del CDEC determine, que permita verificar el desempeño de las instalaciones en estados de operación como también en estados de contingencia. Además, el SM está conformado por los módulos Registro de Señales, Registro de Protecciones Eléctricas y Medición Fasorial”.

Por otro lado, conforme a lo señalado en el Anexo Técnico Sistema de Monitoreo de la NT SyCS, el Módulo de Registro de Protecciones Eléctricas tiene como objetivo disponer de los parámetros de ajuste, registros oscilográficos y de eventos de los Sistemas de Protecciones Eléctricas de todas aquellas instalaciones del SI que califiquen según el criterio establecido en dicho Anexo.

Además, de acuerdo con dicha normativa, éste sistema deberá estar conformado por dos módulos: el Módulo de Acceso Remoto de Protecciones y el Módulo Concentrador de Registros de Eventos, los que deberán cumplir las siguientes funciones mínimas:

Acceso Remoto de Protecciones desde el CDC: deberá permitir la lectura de información, de datos de ajustes y eventos registrados en los equipos de protección, de acuerdo con lo indicado en la NT SyCS.

Disponibilidad de Registro de Eventos del CDEC: deberá poder disponer en forma automática de todos los registros oscilográficos y de eventos por operación de protecciones que se produzcan en las instalaciones del SI.

1.2 Objetivos A partir de los antecedentes señalados, este Consultor ha desarrollado un Estudio de Diseño, Especificaciones y Programa para la Implementación del Módulo de Registro de Protecciones Eléctricas del SI cuyo resultado final contribuirá a:





1. Dotar al Sistema de Monitoreo del CDEC de un mecanismo automático de recolección de datos de las protecciones principales del SI en cuanto a estado, configuraciones y registros de eventos por operación.

2. Definir y especificar las herramientas necesarias para la transmisión, almacenamiento y disponibilidad de estos datos, para su acceso en forma remota en el CDC, y eventualmente en los distintos Centros de Operación de los Coordinados.

3. Definir y especificar las herramientas necesarias para la disponibilización, gestión y el uso de la información. Es decir, las herramientas, aplicaciones y software que permitan:

a) Verificar el correcto funcionamiento de las protecciones del SI en cuanto a los valores de ajuste, tiempos de intervención requeridos y su adecuada coordinación.

b) Realizar análisis post contingencia luego de fallas ocurridas en el SI.

Los Sistemas de Información, en general se pueden clasificar de tres formas según sus propósitos generales. En este sentido Peralta (2008) clasifica los sistemas de información en tres tipos fundamentales:

Sistemas Transaccionales: Son sistemas de información que logran la automatización de procesos operativos.

Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos: Son sistemas de información que brindan análisis, pre-análisis automáticos o recomendaciones que sirven como guía en el proceso de toma de decisiones por parte de un ejecutor.

Sistemas Estratégicos: Son sistemas de información desarrollados en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.

En base a lo descripto en párrafos anteriores un SLRP constituye claramente un sistema de información de apoyo a las decisiones. Decisiones, en general, destinadas a la mejora continua en cuanto a operación confiable y segura del sistema eléctrico, que tienen como objetivo final el aseguramiento de la calidad y continuidad de servicio a los usuarios consumidores de energía.

Los objetivos del SLRP como sistema de información de apoyo a las decisiones son:





Mejorar la disponibilidad y la confiabilidad del Sistema Interconectado Chileno.

Proporcionar apoyo a decisiones que ayuden a la resolución de problemas en el SI relacionados con la actuación de dispositivos de protección de manera rápida y económica.

Brindar valor agregado a las inversiones en elementos de protección, adquisición, transmisión y procesamiento de datos de los mismos.

Lograr la verificación de la coordinación de protecciones y el análisis de fallas del sistema eléctrico de manera rápida y confiable.

Responder a los requerimientos regulatorios con exactitud y prestancia en cuanto al reporte de perturbaciones en el sistema eléctrico y de sus causas.

1.3 Alcance del Estudio El SLRP es un sistema de recolección, almacenamiento, transmisión hacia los Centros de Decisión y de procesamiento de datos relativos a las protecciones eléctricas del SI, que incluye información de estado en tiempo real de las protecciones; reportes de fallas y eventos, incluyendo oscilografías de los comportamientos característicos antes y después de dichas fallas o eventos; e información de configuración y funcionamiento de las mismas. A los fines de dimensionar el Sistema de Lectura Remota de Protecciones se han considerado las siguientes instalaciones según los requerimientos de los Términos de Referencia del Proyecto:

Unidades generadoras cuya potencia nominal sea superior a 10 MVA.

Unidades generadoras cuyo punto de conexión al SI es en un nivel de tensión superior a 200 kV.

Instalaciones del sistema de transmisión con tensión nominal sobre 200 kV.

Instalaciones de tensión nominal igual o menor a 200 kV, consideradas como necesarias dentro del SLRP por el CDEC.

Instalaciones de clientes que cuentan con Esquemas de Desconexión Automática de Carga (EDAC) por sub-frecuencia, sub-tensión o señal específica, o algún otro automatismo similar.





Instalaciones que participen en el Plan de Defensa contra Contingencias Extremas a través de EDAC, EDAG, ERAG, operación de interruptores por señal específica, etc.

No está en el alcance del presente estudio determinar caso por caso qué equipos de protección poseen los recursos tecnológicos para integrarse dentro del SLRP. No obstante, este consultor ha desarrollado una clasificación de los equipos que se encuentran en el Parque de Protecciones del CDEC SIC y CDEC SING en diferentes categorías, cada una de las cuales tiene una solución propuesta para su incorporación al SLRP. Dicha clasificación tiene que ver con las características de las protecciones en cuanto a:

1. Capacidad de auditabilidad de parámetros y ajustes de las protecciones.

2. Capacidad de acceso a los eventos registros oscilográficos de la protección y formato de los datos almacenados.

1.4 Metodología y Premisas de Diseño Como se menciona en el Informe del Estado del Arte de los SLRP actuales, primera parte del presente estudio, la tendencia actual en la industria de la energía es hacia la integración de sistemas diversos, la descentralización de los sistemas de control hacia mecanismos distribuidos de control basados en protecciones y plataformas inteligentes, y hacia el monitoreo activo de componentes en toda la cadena de Generación, Transmisión y Distribución de la Energía. En particular, esto es posible debido a los acuerdos a nivel internacional que homologan sintáctica y semánticamente la interoperabilidad y la intercomunicación entre equipos de funcionalidad, filosofía de diseño y proveedores o fabricantes diversos.

Del análisis de las mejores prácticas internacionales en la materia, en particular, de los trabajos de IEEE PSRC Working Group, de algunas implementaciones en otros países de Sistemas de Monitoreo Remoto de Protecciones de nivel regional y de la revisión y el estudio del Parque de Protecciones del CDEC, se proponen las siguientes premisas de diseño que constituyen la guía bajo la cual se desarrolla el resto del estudio.

Las consiguientes premisas de diseño son:

a. Criterio de Modularidad: La arquitectura del SLRP del presente estudio se divide en elementos modulares que pueden ser estudiados de manera separada y que cuentan con





soluciones tecnológicas diversas. Además, estos módulos pueden ser vistos, estudiados o entendidos como la unión de varias partes que interactúan entre sí y que trabajan solidariamente para alcanzar un objetivo común, realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo.

b. Criterio de Flexibilidad: La arquitectura del SLRP del presente estudio permite la incorporación de equipos de protección al Sistema de Información de un parque de protecciones de diversos fabricantes, que manejan protocolos de comunicaciones diferentes e incompatibles entre sí e incluso de protecciones que no cuentan con mecanismos de comunicación remotas.

c. Criterio de Adaptabilidad: La arquitectura del SLRP del presente estudio considera mecanismos de interoperabilidad y de intercomunicación basados en estándares abiertos de amplia aplicación y amplia disponibilidad de posibilidades de implementación a nivel internacional, pero también con proyección en cuanto a la adaptación futura a posibles cambios tecnológicos que se podrían dar en los próximos años.

d. Criterio de Escalabilidad: La arquitectura del SLRP del presente estudio considera mecanismos de implementación escalables en cuanto a cantidad de equipos de protección que se incorporarán paulatina y sostenidamente a la estructura, y que finalmente alcanzará dimensiones de área amplia en los dos Sistemas Interconectados más grandes del país (SIC y SING).

Otras características deseables del diseño de carácter auxiliar son:

i. Interoperabilidad entre datos provenientes de sistemas, dispositivos, aplicaciones componentes diferentes y con objetivos y requerimientos de seguridad de redes diferentes.

ii. Verificación de estándares y de mejores prácticas internacionales.

iii. Integración semántica de datos recolectados a partir de diferentes protecciones y posiblemente de distintos fabricantes no necesariamente compatibles entre sí.

iv. Seguridad en redes: Chile actualmente no cuenta con normativas estándar de seguridad en redes aplicables a los Servicios Públicos. Por este motivo estándares y normativas en esta materia, aplicadas y vigentes en Europa y Estados Unidos son materia de consulta permanente a lo largo del presente desarrollo.





1.5 Referencias NT SySC.

Anexo Técnico Sistema de Monitoreo NT SySC.

Druzdzel, M. J. and R. R. Flynn (1999). Decision Support Systems. Encyclopedia of Library and Information Science. A. Kent, Marcel Dekker, Inc.

Términos de Referencia. Estudio de Diseño, Especificaciones y Programa para la Implementación del Sistema de Lectura Remota de Protecciones del SIC. Dirección de Operaciones del CDEC SIC.

Catastro de protecciones a incluir en el SLRP del SIC.

Catastro de protecciones a incluir en el SLRP del SING.





Capítulo 2. EL SLRP COMO FUENTE DE INFORMACIÓN

2.1 Introducción Las redes eléctricas son, como todo dispositivo tecnológico, susceptibles de sufrir anomalías de diferentes orígenes: fallas, situaciones de inestabilidad, desequilibrios, etc. Si estas perturbaciones no son contenidas a tiempo conducen, irremediablemente, a daños que pudieran ser de gran envergadura. Con la consiguiente repercusión en los costos de operación y en la calidad de servicio hacia el usuario final.

Los Sistemas Eléctricos de Potencia son sistemas muy expuestos, en gran parte por su naturaleza y extensión, a agresiones de todo tipo: climáticas, ambientales, y otras derivadas de la actividad humana como accidentes, vandalismo, etc. Sin embargo, comparado con otros sistemas que existen en otras industrias, tienen un grado muy alto de fiabilidad y solidez. Los pilares sobre los que se soporta la solidez del sistema eléctrico son varios y de diferente tipo:

Diseños que contrarrestan las posibilidades de fallas con altos grados de redundancias.

Mantenimientos adecuados con especial dedicación a los aspectos preventivos que minimizan las posibilidades de fallas.

Sistemas de supervisión en tiempo real que complementados con las diversas tecnologías de comunicaciones y de procesamiento de la información disponibles, posibilitan el conocimiento del estado del sistema y la actuación inmediata de los operadores y/o automatismos para corregir o compensar las anomalías que se vayan produciendo.

Sistemas de protección encargados de detectar las fallas instantáneamente y tomar las acciones necesarias para su aislamiento, minimizando los daños producidos y los sectores de red afectados.

Los sistemas de protección de los equipos y elementos de las redes, además de cumplir con la función de preservarlos ante la aparición de fallas, también poseen un sofisticado sistema de captura y almacenamiento de información sobre la evolución de la red inmediatamente antes, durante e inmediatamente después de la aparición de un evento de falla.





Esta información es de vital importancia ya que describe la reacción del sistema eléctrico real en condiciones de falla real. Además de ello describe la reacción del propio sistema de protección que actúa para preservarlo. Esto último es sumamente útil, ya que posibilita conocer la red en detalle y al mismo tiempo detectar posibles defectos en su diseño, en su fiabilidad, en los sistemas de operación, o en los sistemas de protección en general, su coordinación, interacción, etc. Posibilita además la determinación de acciones de mantenimiento preventivo, el diseño de automatismos de protección, y las acciones correctoras de operación ante situaciones críticas. Todas estas decisiones y acciones mencionadas ayudan a mejorar la solidez del sistema y a que no se produzcan desastres en su operación de cara hacia el futuro.

Un caso específico ejemplificador de las ventajas del manejo de esta información es el que se da en situaciones de inestabilidad del sistema eléctrico, producto de un repentino cambio de topología de las redes, generalmente por contingencias en el mismo o maniobras en puntos de relevancia. En estas situaciones de inestabilidad un segundo evento que se presente en la red (no necesariamente tan severo), por ejemplo por la pérdida de un importante vínculo, un bloque de cargas, o la salida intempestiva de grandes bloques de generación, puede llevar al sistema al colapso; pérdida de sincronismo, colapso de tensión, etc. Estos eventos, poco comunes y probables, producen graves perjuicios, incluso si se resguardan los sistemas eléctricos por la actuación de las protecciones, debido a la energía no suministrada durante el tiempo que demanda restablecer el suministro eléctrico, tarea que puede llevar muchas horas.

Para estos casos es muy importante contar con un sistema que obtenga y administre información que clarifique el origen y las causas de las situaciones adversas que se presentan, y lo logre en forma rápida y sistemática. La información permite tener mejores y más rápidas respuestas para restablecer el sistema a condiciones de operación seguras, evitando que se produzcan estos fenómenos.

Naturalmente, todo lo dicho hasta aquí es cierto si y sólo si la información es recolectada, organizada, analizada y utilizada en la forma correcta. En el presente Estudio se presenta, precisamente, un sistema para la recopilación automática, la normalización y la ordenación de dicha información de manera que resulte útil a todos los departamentos del CDEC y a los de las compañías de los Coordinados que pueden tomar decisiones operativas, para mejorar su fiabilidad y su eficiencia, y en forma integral, para mejorar el conocimiento que se posee sobre el Sistema Eléctrico en general.





2.2 Información Asociada a Protecciones Eléctricas Para que la información sea útil para tomar decisiones a corto plazo, y además se convierta en conocimiento del propio Sistema, deben cumplirse algunos requisitos que enmarcan los problemas con los que el CDEC y los Coordinados se enfrentan en el manejo de los datos capturados:

Recuperación rápida, lo que se traduce en rápida disponibilidad para el análisis.

Necesidad de conectarse y operar con datos procedentes de muy diversos equipos y de diferentes fabricantes.

Normalización y unificación de formatos de la información capturada, ya que diferentes dispositivos y fabricantes utilizan distintas soluciones a los problemas de captura, almacenamiento y protocolos de comunicaciones.

El Sistema de Lectura Remota de Protecciones (SLRP) que se presenta en este Estudio cumple con estos requisitos y ofrece una solución simple y escalable en costos.

Figura 2.1. Sistema Integrado de S/E.





La experiencia acumulada a nivel internacional en los últimos años en cuanto a diseño, implementación y explotación de sistemas de monitoreo de redes ha llevado al desarrollo y a la tendencia de conformar sistemas de monitoreo integrados de S/E, como los que se mostraron en el informe “Estado del Arte”. Tanto es así, que se puede afirmar que tanto para instalaciones de nuevo diseño como para ampliaciones y mejoras de instalaciones ya existentes, es la solución universalmente aplicada.

La demostración de las ventajas y la confianza adquirida por la utilización de estos sistemas abre un nuevo conjunto de expectativas orientadas a conseguir aún mayores prestaciones, a facilitar su aplicación y a extender su campo de utilización a las instalaciones más complejas.

En realidad, lo que hace posible la integración de protecciones al SLRP es el desarrollo y madurez de tecnologías digitales en general, la mejora en cuanto a diseño de protecciones eléctricas en particular, los mecanismos avanzados de modelado de datos, el avance en cuanto a la seguridad en redes, los estándares internacionales de seguridad cibernética aplicables a servicios públicos, la estandarización de formatos de transmisión de reportes de fallas como es el caso del formato COMTRADE y el protocolo IEC 61850. Hoy existe una muy amplia aplicación de estas tecnologías a lo largo de todo el planeta y una vasta experiencia en cuanto a implementación con resultados de aplicación muy positivos. Existen por otro lado, prometedoras perspectivas de que a futuro se siga creciendo en el mismo sentido; tanto en aplicación como en funcionalidad.

Por el contrario, en cuanto a la gestión y el control de un sistema de protecciones de tipo tradicional extendido por los Sistemas Interconectados, se puede decir que se presentan serios problemas de logística. La recolección de eventos y oscilografías, así como la eventual realización de cambios de ajustes en los equipos de protección implican sobrecostos debido a los gastos de desplazamiento y, sobre todo, implican tiempos de respuesta muy lentos ante cualquier intervención.

Sin embargo, la solución propuesta en el presente estudio intenta no dejar afuera del SLRP a este tipo de protecciones. Permitiendo, con algunos recaudos, su incorporación al sistema. La adaptación de las comunicaciones para estos casos puntuales se alimenta del uso de concentradores y/o convertidores de protocolos. Se ampliará conceptualmente esta solución en secciones subsiguientes.





2.3 Disponibilidad de la Información de Protecciones en los Sistemas Corporativos de Análisis de Datos Una vez que la Información es recolectada mediante los medios mencionados en apartados anteriores, la misma deberá ser clasificada y analizada de manera que se convierta en información útil a la hora de resolver problemas.

Dado que diversos IED pueden ser usados para recolectar las mediciones en subestaciones actuales: registradores digitales de falla (DFR), relés de protecciones digitales (DPR), PQ meters, monitores de interruptores de circuitos (CBM), unidades terminales remotas (RTU), registradores de secuencias de eventos (SER), y controladores lógicos programables (PLC), entre otros, se hace necesario definir claramente nuevos requerimientos de procesamiento y de análisis. Esto ocurre en todos los niveles de decisión a lo largo de la cadena de Generación, Transmisión y Distribución Eléctrica.

Algunas de las funciones requeridas por estos nuevos sistemas son:

1) Para el análisis automático de la información proporcionada por los DFR, las DFRA (Digital

Fault Register Application).

2) Para el análisis automático de la información proporcionada por los DPR, las DPRA (Digital

Protection Register Application).

3) Para el análisis automático de la información proporcionada por los el circuit breaker monitor, las CBMA (Circuit Braker Monitor Application).

4) Para el análisis automático de la información proporcionada por los sistemas regionales, los sistemas de análisis y de coordinación de protecciones con funciones de localización de fallas (FAFL).

Los datos que procesan las aplicaciones mencionadas incluyen siempre información de mantenimiento, información de configuración e información de ajuste de las protecciones. También se procesan datos de salida de los propios IED como oscilografías, reportes de fallas y de eventos. El concepto de agregar nuevas funciones de análisis a los Sistemas de IED en subestaciones existentes se ilustra en la figura 2.2.





Figura 2.2. Nuevas funcionalidades requeridas en Centros de Control de Operaciones.

Para hacer esto posible, la información de los IED deberá ser automáticamente recolectada e integrada a bases de datos comerciales, con formatos estandarizados e independientes del fabricante para cada uno de los equipos.

El resultado de la integración de datos es una base de datos más un repositorio de archivos. Este repositorio debería incluir:

1. Datos IED (COMTRADE con un mecanismo de asignación de nombres de archivos adecuado).

2. Descripciones de las configuraciones (descriptos en Lenguaje de Configuración de Subestaciones SCL).

3. Reportes de los análisis en formatos amigables con el usuario.

El desarrollo de la solución para lograr una integración de datos como la descripta, la especificación de la arquitectura necesaria para el soporte de la implementación de funciones y aplicaciones de análisis para apoyo a decisiones de ingeniería y las consideraciones de diseño e implementación de cada uno de sus componentes son materia de los capítulos venideros.





Figura 2.3. Repositorio de archivos de un Sistema Integrado de Datos de S/E.

2.4 Referencias Substation Data Integration for Automated Data Analysis Systems. M. Kezunovic, T. Popovic.

Texas A&M University, Test Laboratories International Inc.

ZIV. IRV - Terminal integrado de protección, control y medida. Manual de instrucciones. 2011.

Rubén García Ariño. Análisis y mejora de procedimientos aplicados en el área de protecciones y ajustes de una compañía distribuidora. Proyecto Fin de Carrera. Departamento Ingeniería Eléctrica. Universidad de Zaragoza. Marzo 2010.

Endesa-Circe. Criterios ajustes para la protección de sistemas de Alta Tensión. 2007.





Capítulo3. ARQUITECTURA BÁSICA PROPUESTA PARA EL SLRP

3.1 Parque de Protecciones del SLRP

3.1.1 Capacidad de acceso remoto de los puntos de monitoreo

En relación a los equipos de protección que formarán parte del SLRP se ha realizado un análisis estadístico, en base a los catastros de protecciones entregados por el CDEC SIC y el CDEC SING, y la información adicional enviada por los mismos, para evaluar las posibilidades de acceso remoto que estas presentan. De acuerdo a este análisis, se deduce lo siguiente:

1. Existe una muy amplia diversidad de equipos instalados en la población analizada.

2. Los mismos se encuentran en diferentes estados de adecuación al requerimiento de los CDC-CDEC en cuanto a necesidades de acceso remoto y posibilidades de estandarización de reportes.

3. La mayoría de los equipos de protecciones instalados pueden integrarse al sistema de monitoreo sin esfuerzo mediante el estándar de largo plazo IEC 61850.

4. Reportes de eventos, fallas y oscilografías pueden recuperarse de los equipos de protección mediante protocolos IEC 61850 y opcionalmente mediante FTP de la mayoría de los equipos.

5. Equipos que sean Modbus (RTU o TCP) y DNP3 pueden mapearse a IEC 61850 mediante gateways comerciales de forma transparente.

La información recabada se resume en la figura y tabla 3.1.

Por otro lado las funciones de protección a ser monitoreadas se asocian a dispositivos de generación de potencias nominales mayores a 10 MVA, transformadores y líneas de transmisión que operen con tensiones mayores a 200kV y a clientes que participan del sistema EDAC. En la tabla 3.2 se resumen las funciones de protección a ser monitoreadas.





Tabla 3.1. Contabilización del Parque de Protecciones del SI respecto de sus capacidades de comunicación remota.

Figura 3.1. Clasificación del Parque de Protecciones del SI de acuerdo a su protocolo nativo.

87/87G Relé diferencial 87/87L/87T Diferencial 81 subfrecuencia59N/64GN Sobretensión residual 21/21N/21T Distancia de fases y residual 27 subtensión40/40G Sobrexcitación del generador 67/67N/67L Sobre corriente direccional de fases y residual ? señal específica32/32R Potencia inversa 50/50BF Falla de interruptor40/40G Pérdida de excitación 50/51/50N/51N Sobre corriente de fases y residual46/47/60 Desbalance 59/27 Sobre tensión y baja tensión49/49G Protección térmica del estator 68 Bloqueo antioscilaciones de potencia21/21N Sobrecorriente falla a tierra o distancia residual 68 SOFT21/21G Sobrecorriente de estator o distancia de fase5959G Sobretensión25/25S Pérdida de sincronismo81/81G Baja o sobre frecuencia? Relé maestro unidad en giro desexcitada? Relé maestro unidad F/S Detención Falla Mecánica? Relé maestro unidad F/S Detención Falla Eléctrica

Generacion +10MVA Transmision +200kV clientes (EDAC)

Tabla 3.2. Contabilización de funciones de protección a ser monitoreadas por el SLRP.





3.1.2 Distribución geográfica de los puntos de monitoreo

Con respecto a la distribución geográfica de los puntos a ser monitoreados, se observa un parque de protecciones muy distribuido en el actual SING respecto del actual SIC. Esto se debe, en parte, a la arquitectura global de la red eléctrica actual que comprende gran cantidad de usinas de generación en la zona del Norte Grande con líneas de transmisión generalmente en 220kV. Por el contrario el SIC posee gran cantidad de líneas de 110kV actuando como transmisoras, cuyas protecciones no participan del SLRP.

En virtud de la estructura del SI actual del parque de protecciones, de la infraestructura de telecomunicaciones del SCADA/EMS, y de la tasa de crecimiento del sistema que se prevé a futuro en cuanto a incorporación al SLRP de nuevos equipos, se propone la división geográfica del SI en tres zonas. Esta división responde al objetivo de administrar y gestionar la implementación, la operación y el mantenimiento de los sistemas, pero también, a los fines de modularizar la incorporación de recursos informáticos, tanto de software como de hardware y de recursos de comunicaciones.

En principio se propone la creación de las siguientes zonas, sin perjuicio de que a futuro se agreguen otras o se redistribuyan las existentes:

A. Zona Norte Grande: Incluye todo el sistema eléctrico desde la S/E Parinacota hasta la S/E Laguna Seca

B. Zona Centro-Norte: Incluye todo el sistema eléctrico desde la S/E Diego de Almagro hasta la S/E A. Jahuel e incorpora además, todo el sistema de transmisión de 500 kV en construcción

C. Zona Centro-Sur: Incluye todo el todo el sistema eléctrico desde la S/E Itahue hasta la S/E Quellón.

3.1.3 Distribución de los puntos de monitoreo respecto de sus propietarios

En la tabla 3.3 se resume el conteo y la clasificación de equipos de protección por Coordinado, en función a los catastros entregados y a información encontrada en los sitios web del CDEC. La información de la tabla es meramente referencial. La misma se ha confeccionado con el propósito de obtener una estimación del conjunto universo de protecciones del sistema interconectado y los coordinados que las operan.





Cuando se compara la cantidad de Coordinados respecto de la cantidad aproximada de puntos de monitoreo presentados en los apartados anteriores, puede establecerse las siguientes conclusiones:

SIC Coordinado n° Reles % SIC Coordinado n° Reles %SING

Transelec 381 43,7 Arauco Bioenergía S.A. 2 0,2

Endesa 100 11,5 ASERRADEROS Arauco 2 0,2

Colbun 78 8,9 Central Cardones S.A. 2 0,2

AES GENER 34 3,9 CMPC Papeles Cordillera 2 0,2

Chilectra 25 2,9 Comasa 2 0,2

Chilquinta 23 2,6 E.E. Capullo 2 0,2

Bioenergías Forestales S.A. 20 2,3 E.E. Licán 2 0,2

Transnet 19 2,2 Empresa Eléctrica Aguas del Melado 2 0,2

Duke Energy S.A. 16 1,8 Empresa Eléctrica Rucatayo S.A. 2 0,2

Enlasa Generación Chile SA 16 1,8 Energía Pacífico 2 0,2

Celulosa Arauco y Constitución S.A. 8 0,9 Equipos Generación 2 0,2

El Arrayan 8 0,9 GasSur 2 0,2

Empresa Eléctrica Guacolda S.A. 8 0,9 Hidroeléctrica la Confluencia 2 0,2

Generadora del Pacífico S.A. 8 0,9 Hidroeléctrica la Higuera 2 0,2

STS 7 0,8 Hidromaule 2 0,2

Compañía Barrick Chile Generación 6 0,7 Los Guindos Generación SpA 2 0,2

E.E. Panguipulli 6 0,7 Masisa Ecoenergía 2 0,2

HYDROCHILE 6 0,7 Pacific Hydro Chile 2 0,2

Arauco 4 0,5 Paneles Arauco 2 0,2

CMPC Celulosa 4 0,5 Parque Eólico El Arrayán SpA 2 0,2

Colihues Energía 4 0,5 Parque Eólico Los Cururos Ltda 2 0,2

Consorcio Santa Marta S.A. 4 0,5 Parque Eólico Taltal S.A. 2 0,2

Emelda 4 0,5 Petropower 2 0,2

Empresa Eléctrica Panguipulli S.A. 4 0,5 Punta Palmeras S.A. 2 0,2

Eólica Monte Redondo S.A. 4 0,5 SAGESA 2 0,2

Hidroangol 4 0,5 SWC 2 0,2

Hidroeléctrica San Andrés 4 0,5 Termoeléctrica Colmito 2 0,2

Pacific Hydro Chacayes 4 0,5 Termoeléctrica Los Espinos S.A. 2 0,2

PUNTILLA 4 0,5 EPM Chile 2 0,2

Amanecer Solar SpA 2 0,2

TOTAL RELÉS SIC 873

TOTAL DE COORDINADOS 59

Tabla 3.3 Conteo de puntos de monitoreo del SLRP (Parte A, SIC).





SING Coordinado n° Reles % SIC Coordinado n° Reles %SING

ENGIE 142 22,9 TAMAKAYA ENERGÍA 6 1,0

MINERA ESCONDIDA 104 16,8 CELTA 4 0,6

TRANSELEC NORTE 44 7,1 MINERA ANTUCOYA 4 0,6

AES GENER 42 6,8 TRANSMISORA BAQUEDANO 4 0,6

GASATACAMA 28 4,5 AES GENER-NORGENER 4 0,6

MINERA COLLAHUASI 26 4,2 TRANSELEC S.A 4 0,6

MINERA ESPERANZA 24 3,9 ANDINA 4 0,6

CODELCO CHILE 22 3,5 GENERACIÓN SOLAR SpA. 4 0,6

ANGAMOS 18 2,9 HORNITOS 4 0,6

MINERA LOMAS BAYAS 14 2,3 COCHRANE 4 0,6

NORGENER 14 2,3 PLANTA SOLAR SAN PEDRO III 4 0,6

MINERA ZALDIVAR 12 1,9 GRACE 2 0,3

MINERA SPENCE 10 1,6 MINERA ATACAMA MINERALS 2 0,3

SIERRA GORDA SCM 10 1,6 MINERA CERRO COLORADO 2 0,3

MINERA EL TESORO 8 1,3 MINERA MANTOS BLANCOS 2 0,3

MOLY-COP 8 1,3 MINERA MERIDIAN 2 0,3

MINERA EL ABRA 6 1,0 NORACID 2 0,3

SQM 6 1,0 POZO ALMONTE SOLAR 3 2 0,3

TRANSEMEL 6 1,0 SPS LA HUAYCA 2 0,3

MINERA QUEBRADA BLANCA 6 1,0 VALLE DE LOS VIENTOS 2 0,3

EGP SUR 6 1,0

TOTAL RELÉS SING 620

TOTAL DE COORDINADOS 41

Tabla 3.3 Conteo de puntos de monitoreo del SLRP (Parte B, SING).

En el SIC se observa que un 20% de los Coordinados, son propietarios del 80% de los relés a

ser monitoreados.

En el SING se observa que un 30% de los Coordinados, son propietarios del 80% de los relés a ser monitoreados.

Es decir, se encuentra una gran concentración de Coordinados para ambos SI, siendo relativamente mayor en el primero respecto del segundo.





Se sugiere que esta distribución sea aprovechada durante las etapas de implementación, operación y mantenimiento del sistema, dado que estratégicamente sugiere los puntos y actores en donde deberá reservarse mayor energía a los fines de garantizar el éxito del proyecto y de optimizar el aprovechamiento de los recursos en tiempos y costos requeridos.

3.2 Filosofía de Diseño del SLRP

Como indica el Anexo ¨Sistema de Monitoreo de la NT SyCS¨ el SLRP está dividido en dos módulos principales, el Módulo de Acceso Remoto de Protecciones (ARP) y el Módulo Concentrador de Registro de Eventos (CRE).

3.2.1 Filosofía de diseño del módulo de acceso remoto de protecciones

El propósito de este módulo, es contar con una base de datos de las configuraciones, ajustes, registros y de estado de cada una de las protecciones que forman parte del SLRP.

Para lograr esto se propone la aplicación de protocolos de comunicación estandarizados, ampliamente utilizados en la industria de la energía, que permiten la adaptación de los formatos, de medios físicos y de niveles adecuados de protección de señales, y que posibilitan su recolección para ser transmitidos en un formato común e independiente del fabricante, para luego ser incorporados en el resto del sistema.

3.2.1.1 Protocolos de comunicación

Para la propuesta de integración de las protecciones al SLRP que se desarrolla en este estudio se utiliza y propone el protocolo IEC 61850.

Siguiendo estos lineamientos, los datos que incorporase el Sistema de Lectura Remota de Protecciones tendrían un formato común y abierto, dados por los estándares IEC 61850 y por los estándares y recomendaciones de la IEEE, en particular del subcomité de protecciones PSRC. De esta manera el acceso a estos datos se puede lograr de forma independiente del fabricante y de la tecnología de las protecciones utilizada en el conjunto de las instalaciones.





Figura 3.2. Diagrama del SLRP según la normativa vigente.

Por otro lado, se propone y desarrolla más adelante un modelo de datos que garantiza la representación homogénea de los dispositivos de protección eléctrica y que provee a los datos de una semántica común a fin de poder contar con información normalizada y precisa para su uso en el SLRP.

3.2.1.2 Estampa de tiempo

En los equipos en donde los datos son generados se incorpora una estampa de tiempo común (protocolo IRIG-B o SNTP) que permite un ordenamiento temporal de los mismos de manera confiable y consistente, abarcando todo el SLRP. Los datos son mezclados en los concentradores con los de otros dispositivos con el fin de complementar la información concerniente a parámetros, ajustes, registros oscilográficos y de eventos por falla o por perturbaciones en la red. Dicha fuente de tiempo es consistente a lo largo de todo el sistema, desde que el dato es generado hasta que el mismo es procesado por las aplicaciones de análisis por parte del usuario final, garantizando de extremo a extremo la coherencia de la información.





3.2.1.3 Recolector y concentrador local

Un almacenamiento local permite el agregado de los datos de protección provenientes de uno o más IED, con las siguientes funciones básicas:

1) Alinear temporalmente los datos.

2) Reducir la cantidad de conexiones hacia los sistemas superiores mejorando los aspectos de seguridad respecto de los accesos remotos.

3) Adaptar los datos para lograr un formato común independientemente de los niveles de implementación del IEC61850 que realicen los diferentes fabricantes.

4) Evitar pérdidas de datos ante interrupciones de comunicación prolongadas entre la S/E y los centros de control.

Una vez que los datos son recolectados, se encuentran alineados y son agregados junto con los de otras protecciones, entonces se mezclan con registros y eventos que pudieran provenir de otras fuentes de información. A continuación, los datos son localmente almacenados y eventualmente pasan por una conversión de formato para posibilitar su transmisión hacia los centros de información superiores en un formato común, independiente del fabricante y que garantiza la interoperabilidad del uso de la información.

3.2.1.4 Acceso a la información del SLRP

Se permiten dos esquemas básicos de acceso a la información, que se explican a continuación:

Esquema Automático disparado por eventos.

Esquema Manual a demanda por necesidad particular del CDEC.

Esquema de Acceso Automático disparado por eventos

Existen dos métodos básicos de actualización de datos para un sistema de monitoreo, denominados autopoll y autocall. El método que se conoce como autopoll es el que generalmente utiliza un SCADA/EMS tradicional. Éste consiste en programar peticiones de datos periódicas en estrategias





cliente-servidor. En cambio en el método autocall o de reporte espontáneo, el cual se propone para el SRLP, las actualizaciones son disparadas por eventos específicos. A continuación se resume la secuencia de un proceso autocall:

1) El IED es configurado para suscribir a una serie de eventos desencadenantes cuya ocurrencia ocasiona la generación automática de un reporte que va a ser almacenado en el propio IED.

2) El IED tiene recursos de memoria y almacenamiento escasos. Por este motivo y por las causas adicionales ya argumentadas en el apartado anterior, a partir del momento de disparo del evento, los reportes son sincronizados con un concentrador Local alojado en instalaciones del Coordinado propietario del equipo.

3) Ante posibles pérdidas de comunicación con el centro regional de control a continuación los reportes del concentrador local son sincronizados con un concentrador regional alojado en las oficinas del CDEC.

4) Finalmente, los reportes son integrados a la base de datos a fin de que esta información quede disponible fuera de línea para su procesamiento por parte de las aplicaciones de gestión de protecciones, gestión de configuraciones, análisis automático de fallas y otras del SLRP.

Los posibles eventos que desencadenan estas llamadas de sincronización de datos son los siguientes:

a) Cambio de configuración por función de protección.

b) Evento de activación o desactivación de funciones de protecciones.

c) Falla o actuación de protecciones en cuyo caso se dispara un reporte de oscilografía.

d) Evento de orden general de desenganche y apertura de interruptores por función de protección.

e) Telecomandos.

f) Órdenes directas.

Esquema de Acceso Manual a demanda, de acuerdo a necesidad particular del CDEC

Independientemente de que los eventos pre-configurados presentados en el apartado anterior sean disparados, un esquema de acceso a demanda (manual) deberá estar disponible para ser utilizado en el





momento en que un operador del CDEC/CDC lo requiera, y con el fin de recolectar reportes de configuraciones, ajustes, eventos, fallas y oscilografías.

Este modo de acceso también podría permitir, a futuro, el acceso a datos de la protección no previstos en los reportes predefinidos ya descriptos en párrafos anteriores, utilizando las capacidades autodescriptivas del IEC61850.

3.2.1.5 Transmisión hacia los Centros de Control

La información del módulo de acceso remoto de protecciones del SLRP es almacenada en formato de archivo conteniendo reportes predefinidos, tal como se indica en el apartado anterior. En el modo automático, dicha información es transmitida mediante protocolos de transferencia de archivo hacia los centros superiores de datos.

La información a intercambiar comprende lo siguiente:

Archivos de reportes temporizados de eventos y alarmas SOE (Sequence of Events).

Archivos de reportes de diagnóstico COMTRADE con información de estado de la protección antes, durante y después de ocurrida la falla/evento.

Archivos de reportes y datos en línea de configuración y ajustes de la protección SSD, ICD, SCD y CID de IED XML basado en SCL (Substation Configuration Language).

El SLRP en su concepción deberá soportar los siguientes protocolos para la transmisión de archivos de reporte predefinidos hacia los Centros de Control de los Coordinados y/o Centros de Despacho de Carga:

IEC 61850 MMS para tipos de mensaje en formato de archivo.

FTP (File Transfer Protocol).

IEC 61850 MMS.

El primero, de preferencia, es recomendado como el método principal para la transferencia de información. El segundo se deja como alternativa para la incorporación de datos prevenientes de equipos de protección que no soporten IEC61850 o bien de datos provenientes de equipos de





protocolo IEC61850 con implementación incompleta. El tercero se dejará para otros tipos de mensaje no predeterminados (a futuro).

3.2.1.6 Clúster de datos

Los datos del conjunto de protecciones de una S/E, ya en formato estándar, deberán ser agregados con los de otras subestaciones (u otros Coordidados) y alineados en tiempo en unidades de clúster zonales de 10 protecciones cada uno, dentro de los Concentradores Locales. Esto es necesario a los fines de proveer un sistema que permitirá determinar las capacidades de cómputo, de almacenamiento y de ancho de banda requeridos a medida que se vayan incorporando dispositivos al SLRP.

En el centro de cómputos del CDEC se deberán concentrar los CLDP (Clúster Local de Datos de Protección) de los Coordinados, agregando los datos de los mismos en Clústeres Regionales de Datos de Protección (CRDP) de 100 protecciones cada uno y alineando los datos temporalmente en caso de corresponder. Por otra parte, los CRDP deberán ser administrados por zonas de acuerdo al criterio geográfico propuesto en apartados anteriores.

Al finalizar este proceso los datos de todas las protecciones del Sistema Interconectado que pertenecen al SLRP se deberán concentrar en los servidores de datos de las instalaciones del CDEC.

3.2.1.7 Aplicaciones del SLRP

En este mismo Datacenter se concentrarán otros servidores como los de autenticación de usuarios, los de aplicaciones SCADA, los de aplicaciones específicas de monitoreo y gestión de protecciones remotas, y de otras aplicaciones de análisis automático que se especifican en detalle en secciones subsiguientes.

3.2.1.8 Arquitectura del centro de cómputos

Se deberá prever la duplicidad del centro de cómputos en las oficinas del centro secundario de datos que dispone el CDEC, de manera de que el sistema tenga una recuperación rápida luego de alguna contingencia.

Además, se propone una arquitectura de recursos informáticos que incluya redundancia y confiabilidad similar a la de los SCADAS preexistentes (99,95%). Esto se logra fácilmente mediante





la virtualización de los servidores que componen el SLRP y tiene las siguientes ventajas respecto de otras arquitecturas de centros de cómputos:

Mayor aprovechamiento de recursos informáticos: Normalmente un mal extendido entre los centros de cómputo es el gran número de servidores infrautilizados.

Aislamiento de fallas de software / Integridad de la seguridad informática: Las máquinas virtuales son totalmente independientes entre sí y con el hypervisor, por tanto, una falla en una aplicación o en una máquina virtual involucra únicamente a esa sola máquina virtual. El resto de máquinas virtuales y el hypervisor siguen funcionando normalmente sin verse afectados. Del mismo modo, un ataque de seguridad en una máquina virtual sólo afectará a esa máquina.

Mayor agilidad de implementación y capacidad de escalamiento: La creación de una máquina virtual es un proceso muy rápido, básicamente la ejecución de un comando. Por tanto, la disponibilidad de un nuevo servidor es casi instantánea, sin pasar por el proceso de compra, configuración y demás problemas administrativos.

Portabilidad: Toda la configuración de una máquina virtual reside en uno o varios ficheros. Esto hace que sea muy fácil clonar o transportar la máquina virtual a otro servidor físico, simplemente copiando y moviendo dichos ficheros que encapsulan la máquina virtual.

Recuperación rápida en caso de fallo: Si se dispone de una copia de los archivos de configuración de la máquina virtual para casos de desastre, la recuperación será muy rápida. Simplemente se deberá arrancar la máquina virtual con los ficheros de configuración guardados. No es necesario reinstalar, recuperar backups y otros procedimientos largos que se aplican en las máquinas físicas.

3.2.2 Filosofía de diseño del Módulo Concentrador de Registro de Eventos (CRE)

El propósito de este módulo es brindar al Coordinado un canal alternativo mediante el cual sea posible ingresar los reportes de falla provenientes de DFR (Registradores de Datos) y DPR (Relés de Protecciones Digitales). El mismo se basa en el formato COMTRADE (IEEE P37.111 1991, 1999, 2013), el cual es un formato muy común que han adoptado casi todos los fabricantes de equipos de protección. No podemos decir lo mismo del IEC61850, protocolo que actualmente no se encuentra





disponible en el 100% de la Planta de Protecciones del sistema eléctrico que aplican al SLRP. A los fines de poder incorporar al SLRP dispositivos no compatibles con IEC61850, deben utilizarse mecanismos de conversión de formato que puedan salvar este inconveniente.

La solución en cuanto a arquitectura y especificación de componentes, que atiende a este requerimiento, es idéntica a la presentada en forma general en el apartado anterior. Por este motivo, no volverá a mencionarse en este punto.

Al momento de la confección del presente informe, el CDEC cuenta con un mecanismo de gestión de oscilografías y reportes de eventos por actuación de protecciones. Actualmente la plataforma Sistema de Registro de Protecciones SIREP (www.sirep.cdec.cl) actúa como concentrador de registros oscilográficos. Se trata de una página web accesible vía internet, en la cual cada Coordinado deberá subir manualmente los registros oscilográficos en un plazo máximo de 12 horas de ocurrida una operación por actuación de protecciones.

El sistema actual tiene el inconveniente de no ser un sistema automático, por lo que el Coordinado puede subir la información fuera de término, o en peores casos entregar información errónea o no entregarla. No obstante el SIREP tiene las ventajas de facilitar la disponibilidad de reportes provenientes de protecciones que por algún motivo demoren su incorporación al SLRP, o que su incorporación resulte del todo imposible, o en ocasiones de contingencia o pérdidas de comunicación con el CDEC.

Por estos motivos se deberá prever un mecanismo desatendido de incorporación de los reportes ingresados por el SIREP a los repositorios del SLRP, sin perjuicio de que además el SLRP permita el ingreso manual de archivos asociados a alguna protección específica. De acuerdo a esto último, la especificación de aplicaciones para el manejo de archivos oscilográficos incluye como requerimiento la funcionalidad de incluir de forma manual los reportes adquiridos por medio de canales alternativos como por ejemplo correo electrónico.

Finalmente, en cuanto al modelo de datos del módulo CRE, y debido a las propias limitaciones del formato, deberá incorporarse algún sistema adicional que garantice compatibilidad entre reportes provenientes de DFR o DPR diferentes. Este mecanismo se menciona en el siguiente apartado.

3.2.2.1 Filosofía del Modelo de Datos del Módulo Concentrador de Registros de Eventos (CRE)





Los aspectos a tener en cuenta en cuanto a modelo de datos para este módulo del SLRP son los siguientes:

1) Deberá definirse un mecanismo de renombrado de archivos de reporte y/o oscilografías, dado que de lo contrario el sistema receptor no puede distinguir entre los diferentes orígenes de datos. El sistema de nombre completo que se elija deberá considerar las siguientes características mínimas: Deberá ser un nombre único a nivel global, permitir como mínimo determinar el momento en que se disparó la oscilografía y especificar el lugar de origen del dispositivo DPR o DFR. Afortunadamente, ya existe un estándar que atiende a esta situación. Por este motivo se incorpora el std. IEEE C37.232.2007 a la solución de diseño propuesta en el presente informe con algunas consideraciones adicionales que se amplían en las secciones de Especificación y de Diseño Detallado.

2) La configuración de las oscilografías deberá definirse de forma estándar, con el fin de que los reportes de salida sean compatibles respecto de los registrados en las diferentes protecciones y respecto de las configuraciones registradas en el módulo de acceso remoto de protecciones. En cuanto al último punto, se ha tomado como estándar de configuración lo que indica la NT SyCS en su Anexo Técnico ¨Sistemas de Monitoreo¨, que se desarrolla más adelante en el apartado ¨Modelo de Datos¨.

3) En el caso en que el SLRP y el SICRE deban convivir, los puntos 1) y 2) antes citados deben respetarse, por norma, en ambos sistemas. Lo mismo cabe para los archivos incorporados manualmente al SLRP.

3.2.2.2 Consideraciones acerca de la implementación del Módulo Concentrador de Registros de Eventos (CRE)

La mayor complejidad en cuanto a la implementación del SLRP se encuentra en la conversión de protocolos y adaptación de formatos al modelo de datos común para los DPR (Relés de Protección Digitales).

Por el contrario, es tarea muy sencilla la adaptación de reportes de eventos y oscilografías que disponen los distintos equipos de protección en forma nativa al formato y a las consideraciones que se acaban de mencionar en los párrafos precedentes.





Es por ello que, si bien el modelo de datos que postula este estudio encuadra perfectamente a ambos módulos anteriormente citados bajo un mismo concepto, la implementación del SLRP con la división planteada en 2 módulos A (CRE) y B (ARP), se podría encarar por separado y en simultáneo bajo esta subdivisión. Por ello, a lo largo de todo el informe se irán detallando y especificando los distintos aspectos y especificaciones por separado. Este Consultor, intenta de esta manera facilitar la tarea vinculada a la implementación de los dos módulos del SLRP, teniendo en cuenta la disimilitud entre las complejidades aparejadas que se acaba de mencionar. Además, dado que los módulos CRE y ARP tienen objetivos claramente diferentes, conviene mantenerlos separados en la especificación a los fines de que la asignación de prioridades durante la etapa de ejecución del proyecto sea la adecuada.

3.3 Arquitectura Global del Sistema

3.3.1 Diagrama funcional del SLRP

El diagrama funcional que resuelve el SLRP, ya fue adelantado en el informe Ëstado del Arte¨. El mismo representa la solución funcional del SLRP dividiéndolo en dos Etapas:

1) Etapa de adaptación de medio, recolección y adaptación de datos provenientes de los DFR y de los DPR de campo

2) Etapa de concentración y adaptación de la información al modelo de datos, incluido el que se ha venido tratando en el informe.

En la figura 3.3 se repite el esquema funcional mencionado con el fin de utilizarlo como punto de partida para el diseño de la arquitectura de detalle:





Figura 3.3. Diagramas funcionales del SLRP.

3.3.2 Arquitectura básica del SLRP

3.3.2.1 Descripción general de la arquitectura básica

La arquitectura del SLRP se basa en la generación espontánea de reportes desde las protecciones hacia los concentradores Locales de los Coordinados (CLDR) instalados en la S/E donde se originan





los datos, en los centros de datos de los Coordinados, o bien donde ellos dispongan. La información es conducida desde estos últimos hacia concentradores Regionales (zonales) de Datos de Relés de Protección (CRDR), instalados en las instalaciones del CDEC bajo la responsabilidad del CDEC, privilegiando la flexibilidad y expansibilidad de la red SLRP y otorgando niveles básicos de confiabilidad y de disponibilidad de la información.

Dado que la capacidad de almacenamiento de los IED pudiera ser limitada, las unidades concentradoras de información a nivel Local, en las instalaciones de los Coordinados, incrementan la capacidad de respaldo de información en caso de pérdida del o los enlaces de comunicación desde el concentrador local hacia el concentrador regional.

Asimismo, los Concentradores Locales (CLDR), son la puerta de entrada a los Coordinados que deseen hacer uso de la información disponible en dichas unidades de almacenamiento. Siempre y cuando lo realicen en forma independiente, y sin interferir las funciones de monitoreo ejecutadas desde el concentrador regional instalado en el CDEC, cada uno de los Coordinados podría, en carácter opcional y en caso de necesitarlo, diseñar, instalar y construir sus propias aplicaciones para monitoreo, análisis y gestión de protecciones que requiera para sus propios fines. Dichas aplicaciones pueden residir en la propia S/E donde se generan los datos, en el centro de control del Coordinado o en ambos, de acuerdo a la propia conveniencia del propietario de los dispositivos de protección.

De igual manera, los Coordinados pueden estructurar sus recolectores de datos de forma jerárquica incorporando niveles de agregación adicionales de manera opcional, si sus propios requerimientos de seguridad informática y de acceso remoto así lo determinaran. El único requisito necesario, es que exista un CLDR por Coordinado para hacer de interface (y de servidor de archivos) hacia el CRDR del CDEC.

Por el otro lado, el CLDR del Coordinado deberá cumplir con los formatos de datos, los protocolos de comunicación establecidos, los criterios de seguridad informática, la estampa de tiempo en origen y la política en cuanto a respaldo en la información asociada a los relés de protección que manda la NT SyCS.

Además, la arquitectura básica es definida en forma modular y jerárquica, tal cual se la presentó en el apartado ¨Filosofía de Diseño del SLRP¨, permitiendo entonces, que se vayan acoplando protecciones uniforme y paulatinamente, y sin que ello incida en el funcionamiento normal de la parte del SLRP que se encuentre ya en operación.





En cuanto a modelo de datos, los elementos de configuración de las protecciones y la estructura de los reportes de oscilografías o de eventos siguen criterios mínimos, de manera de lograr la compatibilidad de la información respecto de la recabada en el mismo o en niveles superiores dentro de la estructura del SLRP.

Por último, la Arquitectura Global para el SLRP define una serie de conceptos básicos, cada uno de los cuales es necesario definir con precisión. Ellos son:

a. Fuentes de datos: En forma genérica siempre refieren a un IED en el sentido de la IEC61850. Si el relé de protección físico no es compatible con dicho protocolo, deberá convertirse mediante algún nodo recolector o gateway de protocolo al formato estándar IEC61850.

b. Nodo recolector: Es el gateway de protocolo o RTU que realiza funciones de conversión, adaptación y agregación de datos en caso de que sean necesarios.

c. Concentradores de datos: Son los elementos encargados de alinear los datos temporalmente mediante alguna señal de clock IRIG-B o SNTP, de agregar los datos de estado, oscilografías y de eventos provenientes de otras fuentes de corresponder, y de concentrar o agregar otras estructuras de datos a alguna unidad contenedora de datos de orden superior o clúster de datos.

d. Software de aplicación: Es la entidad que procesa los datos previamente agrupados en la etapa concentradora.

e. Comunicaciones: La red de comunicaciones es el conjunto de medios físicos y de protocolos de comunicación que posibilitan el envío de la información hacia sitios remotos.

f. Almacenamiento de datos: Es el mecanismo de respaldo que impide la pérdida de datos ocasionada por falta de energía o cortes en los enlaces de comunicación. Por otro lado, es el elemento que permite el procesamiento fuera de línea por parte de las aplicaciones especializadas de Análisis o de Apoyo a las Decisiones del SLRP. Así mismo, este componente posibilita que los Coordinados pudieran realizar sus propios análisis si así lo requirieran.





Concentrador Local de

Protecciones

Aplicaciones CDEC

BD Relacional

Concentrador Local de

Protecc.(**)

Concentrador Regional De Protecciones

DPR2

Aplicaciones Coordinado (*)

Repositorio de Archivos / Base de Datos

Recolector Local de

Protecc. (*)

Aplicaciones Locales S/E (*)

DPR1

SCADA/EMS del CDEC

DPR3

CDEC

Centro de Control -

Coordinado

S/E - Coordinado

Recolector Local de

Protecciones (*)

DPR4

(*) De carácter opcional

(**) De carácter obligatorio en alguna Dependencia del Coordinado

Figura 3.4. Arquitectura básica del Módulo de Acceso Remoto de Protecciones Eléctricas (CRE) y del Módulo de Acceso Remoto de Protecciones (ARP).





A continuación, se discuten los requerimientos básicos para cada uno de los ítems mencionados.

3.3.2.2 Fuentes de datos del SLRP

DFR y DPR

Los IED son automatismos avanzados para equipos de S/E. Su importancia radica en que incorporan uno o más microprocesadores con capacidad, tanto de transmisión como de recepción de datos. Mediante capacidades de autodescripción de funcionalidades, facilitan la comunicación entre los diferentes dispositivos y hacia los centros de control. El cableado necesario para la comunicación de señales entre automatismos se ve notablemente reducido mediante el uso de esta tecnología. Además, las capacidades de comunicación y de información de los IED pueden ser verificados de forma remota, dando pie solo a pequeñas visitas a la S/E en caso de algún evento.

Los IED trabajan como relés de protección y controladores de equipos de campo, cumpliendo además las siguientes funciones:

a) Supervisar el estado de equipo: El módulo ARP del SLRP, requiere acceso a información a demanda utilizando las capacidades autodescriptivas disponibles.

b) Registrar datos: En el SLRP, de acuerdo a la función de protección utilizada, son registrados valores analógicos de interés antes, durante y después del disparo de eventos pre-configurados. Las variables a registrar se especifican con mayor detalle en el capítulo Modelo de Datos.

c) Notificar eventos: Para el SLRP son de interés como mínimo las siguientes notificaciones de eventos:

Cambio de parámetros / ajustes.

Activación / desactivación de la función de protección.

Cambio de estado del interruptor asociado.

Falla / actuación de la función de protección.

Telecomandos.

d) Reportar datos: Para el SLRP se configuran reportes de oscilografías, de secuencias de eventos (SOE), de fallas, de configuraciones, de ajustes de sistema.





Respecto del Módulo Concentrador de Registros de Oscilogramas y Eventos (CRE) es de interés hacer mención en dos tipos particulares de IED: el DPR (Digital Protection Register) y el DFR (Digital Fault Register). Si bien ambos tienen como objetivo el registro de datos de oscilografía a partir de un evento de disparo generalmente asociado a una señal digital relacionada con el disparo de la protección, tienen una diferencia fundamental:

Para los primeros la lectura analógica utilizada para el registro proviene de una función de medición integrada que utiliza intrínsecamente los mismos datos primarios que hacen que actúe la protección.

Por el contrario los DFR utilizan una función de medición que hace uso de un sensado externo a la protección en sí. Cuando el dispositivo se trata de un DFR la forma correcta de tomar la medición es como indica la figura 3.5.

Figura 3.5. Puntos de medida de registradores eventos con osciloperturbógrafos no integrados a la función de protección.

Concentradores de datos (CD)

El Diseño de SLRP que se detalla en el presente estudio incluye la definición de dos niveles de agregación de datos:

a) Concentrador de datos local.

b) Concentrador de datos regional

Las funciones principales de un CD son:





1. Recibir y administrar la información proveniente de múltiples IED.

2. Detectar y rechazar los datos mal recibidos.

3. Alinear los datos recibidos desde múltiples fuentes mediante una estampa de tiempo común.

4. Compatibilizar los datos de ajuste y configuración de protecciones utilizando software propietario dependiente del fabricante de ser necesario.

5. Crear un registro coherente de oscilografías de eventos por falla y por actuación de las protecciones.

Un CD puede verse entonces como un contenedor de datos agregados alineados temporalmente entre sí.

Asimismo se definen dos unidades de contenedor de datos, en adelante clúster, vinculadas a cada uno de los niveles de agregación de los CD mencionados en el párrafo anterior:

1. Clúster Local (CLDP): Define la medida de agregación de los datos a nivel de Coordinado, la cual está dimensionada en principio en la cantidad de 10 protecciones.

2. Clúster Regional (CRDP): Define la medida de agregación de datos a nivel global, la cual está dimensionada en principio en la cantidad de 100 protecciones.

La decisión de organizar los datos de la manera descripta en el párrafo anterior tiene dos grandes ventajas:

a. Permite escalar el ancho de banda requerido para la comunicación de datos hacia los centros superiores de coordinación, dado que al tener el clúster un número máximo de datos de protecciones agregadas define un límite superior a la cantidad de ancho de banda requerida por cada clúster que se agrega al SLRP.

b. Permite escalar el tamaño del almacenamiento de datos requerido para la comunicación de datos hacia los centros superiores de coordinación, dado que al tener el clúster un número máximo de datos de protecciones agregadas define un límite superior a la cantidad de almacenamiento requerida por cada clúster que se agrega al SLRP en cada uno de los niveles.





Por último un Concentrador de orden superior, tal como el concentrador regional del CDEC, puede concentrar los datos recibidos desde múltiples concentradores de datos, almacenando los datos de ajustes, configuraciones, registros oscilográficos de fallas y eventos del sistema eléctrico en su totalidad.

Cluster Local de Datos de Protecciones

Nivel de S/E - Coordinado

Nivel de Centro de Control Regional

CLDP

10 Protecciones

100 Protecciones

CCDP

Cluster Corporativo de Datos de Protecciones

Figura 3.6. Agregación de los datos en clústeres.

Aplicaciones de Software

A continuación se enlistan las aplicaciones de análisis de fallas que existen para subestaciones modernas integradas:

Aplicaciones tipo DPRA (Digital Proteccion Register Application).

1. Chequeo de consistencia de datos entre diferentes archivos de la protección. Dichos chequeos de consistencia se realizan entre configuraciones / ajustes de la protección, oscilografías, reportes de eventos y reportes de falla.





2. Chequeo de validez de los datos de archivos de la protección entre configuraciones / ajustes de la protección, oscilografías, reportes de eventos y reportes de falla.

3. Sistema de adquisición de datos para aplicaciones de análisis automático de fallas y de localización de fallas o para datos de entrada de un analista.

Aplicaciones tipo DFRA (Digital Fault Register Application)

1. Detección y clasificación de fallas y perturbaciones.

2. Verificación de los sistemas de protección.

3. Verificación de operaciones de circuit braker.

4. Sistema de adquisición de datos para aplicaciones de análisis de fallas y de localización de fallas o para datos de entrada de un analista.

Aplicaciones tipo CBMA (Circuit Braker Monitor Application)

1. Performance de los circuit brakers para mantenimiento preventivo.

2. Performance de los circuit brakers para mantenimiento correctivo.

Aplicaciones tipo FAFL (Fault Análisis and Fault Localization)

1. Sistema experto de análisis de cascada de fallas

2. Sistema experto de análisis de localización de fallas

3. Seleccionar de manera automática caso de pruebas con el propósito de realizar verificaciones en el software de simulación de redes eléctricas.

En primera medida se propone en la sección de especificación de detalle un paquete de aplicaciones que utilizan los datos de Salida del SLRP correspondiéndose con las funcionalidades de aplicaciones tipo DPRA, DFRA y FAFL que se acaban de describir.





Por último se propone la investigación a futuro de la implementación de aplicaciones tipo CBMA, dado que el SLRP una vez instalado y en operación podría proveer de infraestructura adecuada que permita su desarrollo.

Sistema de comunicaciones

El Sistema de Monitoreo del CDEC estará compuesto por tres módulos:

a) Módulo de registro de señales (SCADA/EMS)

b) Módulo de medición fasorial (Red WAM/Sincrofasores)

c) Módulo de Registro de Protecciones Eléctricas (SLRP)

Los sistemas de comunicación de la red subyacente para los dos primeros son similares en términos de tecnología, arquitectura y medios de comunicación: ambos sistemas de monitoreo son un flujo continuo y empaquetado de datos.

Por el contrario, la información del SLRP: ajustes, configuraciones, reportes oscilográficos por evento, reportes SOE suministrados por los DFR, los DPR y los otros elementos que componen el SLRP, tienen una naturaleza diferente a la de los datos suministrados por las RTU para un SCADA tradicional. Los datos de un SLRP son requeridos usualmente para su procesamiento por parte de aplicaciones de configuración de sistemas, de gestión de configuraciones, de análisis y sistemas expertos fuera de línea, en donde los tiempos de refresco de la información no son críticos. El intercambio de información básico entre los Coordinados y el CDEC consta de reportes predefinidos de datos (COMTRADE, SOE, SCL-XML) a través de protocolos de transferencia de archivos (MMS – FTP).

No obstante, no son deseables tiempos de transferencia de la información extremadamente largos, dado que una de las aplicaciones de las cuales se ampliará en la sección de aplicaciones de software, concretamente la vinculada a la conformación de secuencias de actuación de las protecciones (SOE), es frecuentemente utilizada por operadores del sistema para restablecer el sistema luego de alguna contingencia compleja.

Es por ello que a los efectos prácticos del cálculo de ancho de banda requerido por protección y de la especificación de los sistemas de almacenamiento que se discute en las especificaciones detalladas de diseño en los próximos capítulos, este estudio considera como válido y aceptable un tiempo límite de transferencia de los datos estimada por protección de 15 minutos. El estudio del requerimiento de





ancho de banda requerido por protección deberá considerarse tomando en cuenta una estimación de la probabilidad de ocurrencia de los eventos disparadores de la transferencia espontánea de reportes y del tamaño típico de los archivos a transferir cuando ocurre dicho evento disparador.

Todas las necesidades del SLRP referentes a los sistemas de comunicación se traducen en los requisitos cualitativos para la red de comunicaciones del SLRP de la tabla 3.4.

Latencia No hay límite de tiempo Jitter No hay límite de tiempo

Naturaleza del Tráfico En ráfagas / avalancha de datos / volumen alto.

Calidad de Servicio No hay requerimientos

Perdida de Paquetes No hay requerimientos (protocolos orientados a la conexión)

Enlace Compartido

Tabla 3.4. Requisitos cualitativos para la red de comunicaciones del SLRP.

Finalmente, mientras la tasa de refresco es menor en un SLRP que en un sistema de monitoreo tradicional, la cantidad de información transmitida será mucho mayor, ya que los modelos de datos subyacentes, consideran grandes cantidades de datos de interés. A este hecho se suma la realidad de que ante una contingencia que provenga de una cascada de actuación de protecciones, posiblemente las ráfagas de datos de reportes transmitidos podrían crecer exponencialmente.

Estos últimos aspectos se han tenido en cuenta a la hora de definir la especificación de los enlaces y de los sistemas de almacenamientos locales (Coordinados) y regionales (CDEC) con el fin de mitigar el problema.

Sistemas de almacenamiento de datos.

Motores de base de datos para el procesamiento de la información de protecciones.

Los motores de base de datos orientados a objetos y a grandes cantidades de datos han avanzado mucho durante los últimos años. Sin embargo, el uso más difundido para el sistema de almacenamiento de los concentradores de datos sigue siendo el de base de datos tradicional. La





especificación del SLRP lo incorpora como medio primario de almacenamiento y lo tiene en cuenta en cuanto a la lista de aplicaciones y licencias que el CDEC deberá adquirir para la implementación completa del sistema.

La ventaja principal, es que de esta manera se logra interface completa entre las aplicaciones y el SCADA/EMS existente, por lo cual esta tecnología sigue siendo poderosa y otorga cierto grado de flexibilidad, robustez y performance en cuanto a la capacidad de computo que implique grandes cantidades de operaciones de lectura/escritura sobre los dispositivos periféricos de almacenamiento de los servidores.

No obstante, se prevé que en un futuro, sistemas de base de datos más avanzados y acordes con las tecnologías orientadas a objetos subyacentes a los protocolos eléctricos IEC que se vienen estudiando prevalezcan.

La tecnología de virtualización seleccionada para el centro de cómputos del SLRP del CDEC, otorga la flexibilidad suficiente para encarar dicha migración en un futuro cercano sin perjuicio de los sistemas que eventualmente pudieran estar en servicio.

Sincronización horaria

Actualmente, la única fuente de tiempo ampliamente disponible, confiable y precisa para sistemas de monitoreo que utilicen estampas de tiempo es el GPS.

Los códigos de tiempo de los satélites son estables y sincronizados a la base universal UTC, de modo que estas señales son usadas no solo para determinar su posición sino que también para obtener una base de tiempo muy precisa.

Un DPR o DFR o concentrador de datos o convertidor de protocolo, puede tener un GPS instalado internamente o puede tener una interface para recibir una señal de sincronía desde un GPS externo. La señal de un GPS básico es de 1.575 MHz de modo que solo puede ser transmitida sobre distancias limitadas a no más de cien metros desde la posición de la antena. Esto deberá tenerse en consideración llegado el caso en que se tenga que utilizar un dispositivo con reloj interno. Existen las interfaces necesarias como IRIG-B o SNTP para suministrar sincronía a varios equipos receptores utilizando amplificadores y repetidores. La interface más común es IRIG-B y tiene mayor precisión que otras interfaces para la sincronía de tiempo. Si el GPS es interno, el tiempo y estado





pueden ser derivados directamente. Por el contrario, se hace necesario instalar alguna fuente de tiempo externa.

Es por ello que, para la red del SLRP del CDEC se recomienda la utilización de unidades de sincronía externa con salidas estandarizadas IRIG-B que puedan ser utilizadas por uno o más equipos DFR, DPR, RTU u otros que lo requieran.

Seguridad en redes

En el Anexo II de este documento se describe la problemática, amenazas y propuestas de soluciones respecto a este importante punto.

3.3.3 Flujo de la Información en el SLRP

Como se explica en el apartado 3.2.1.4 el SLRP provee dos estrategias básicas para el intercambio de información desde que ésta es generada por los IED hasta que es procesada por las aplicaciones del SLRP: Modo Automático disparado por eventos (por autocall) y Modo Manual (por pooling) iniciado a demanda.

3.3.3.1 Flujo de la información en el Modulo Concentrador de Registros de Eventos (CRE)

El flujo de la información para datos de eventos y oscilografías desde el IED hasta las bases de datos de históricos requiere desde un punto de vista abstracto alguna integración de diferentes tecnologías que actúan a diferentes niveles en cada componente del SLRP. La siguiente figura muestra un bosquejo de los componentes del módulo CRE del SLRP. El estado digital de un evento, comúnmente llamado SOE (Sequence of Events), se puede obtener mediante IEC61850. Posee estampa de tiempo en origen con tiempo de disparo del evento y la duración del mismo.

De la figura se observa que todos los elementos a lo largo del SLRP deben ser sincronizados en tiempo, de manera que eventos generados en diferentes puntos del sistema de potencia puedan ser comparados y ordenados cronológicamente bajo un criterio común.





Figura 3.7. Flujo de la información para el Módulo CRE del Sistema SLRP.

Con propósito de simplificar la explicación el CRE, puede ser dividido en dos subsistemas: a) La recolección de datos oscilográficos y b) la organización de los datos y el almacenamiento las bases de datos de históricas. Por un lado, el subsistema de generación y gestión de archivos de eventos es el responsable de recolectar los datos generados en el IED y de almacenarlo en un repositorio de archivos en formato COMTRADE estandarizado. Por el otro lado, el subsistema “historizador” es el encargado del almacenamiento de los datos de eventos en un formato común de base de datos que permita completar los análisis.

Subsistema de generación y gestión de archivos COMTRADE

El sistema de generación y gestión de archivos consta de tres componentes principales: Los IED, el software de gestión de la información para el sistema de potencia y el servidor de archivos. El software de gestión de la información para el sistema de potencia por un lado y el servidor de archivos por el otro pueden residir en la misma máquina virtual o bien en servidores separados. A los fines de la discusión se presentan separados.

De acuerdo a la figura este subsistema se divide en los siguientes componentes:

El IED: Este componente deberá ser configurado como fuente de datos para generar reportes SOE y de oscilografías basados en criterios predeterminados. Los criterios son los eventos mencionados en la sección 3.3.2.2.





Figura 3.8. Generación y Gestión de archivos COMTRAD.

El software de gestión de la información para el sistema de potencia: Es una aplicación de software que se ejecuta como servicio continuo del sistema operativo que contiene información tanto de la conectividad hacia cada uno de los IED como del método de recuperación de los archivos de oscilación asociados a cada uno de ellos. Algunas herramientas de software de gestión de la información disponibles en el mercado poseen la característica adicional de ser capaces de convertir archivos de reportes de eventos y oscilografías de formatos dependientes de los distintos fabricantes a formato COMTRADE estandarizado, o de almacenar flujo continuo de mediciones fasoriales alineadas en tiempo.

Además cuando este módulo reconoce un nuevo evento en un IED monitoreado, éste remite la información a un servidor de archivos para su almacenamiento local. Si los datos provienen de varios IED realiza una función de mezclado y de alineación de datos. Archivos COMTRADE son renombrados de acuerdo al estándar de nombres en este punto.

Se puede decir entonces, que este módulo es una funcionalidad típica de software para S/E. Ejemplos comerciales son: Crossbow SAC de Siemens o Subnet Power System Server.

Asimismo la aplicación deberá tener alta disponibilidad, deberá estar sincronizada en tiempo con los IED y ser capaz de reconocer mensajes MMS (o bien manejar protocolo FTP).

File Server: Los archivos de reportes son movidos a un repositorio (concentrador local) para su despacho al concentrador zonal del CDEC mediante FTP, MMS File Transfer o cualquier otro mecanismo de transferencia de archivos no críticos en cuanto a latencias y a QoS. Periódicamente (3





meses exige la norma y 9 meses para el caso de fallas / operación de protecciones), archivos dentro del concentrador, deben ser removidos mediante los procesos de almacenamiento fuera de línea (backup) para asegurar el espacio libre para nuevos archivos. Una posibilidad interesante, sería monitorear una variable en el registro de históricos que indique que el servidor de archivos podría estar lleno.

Dado que el dato oscilográfico puede estar basado en ciclos eléctricos previos o posteriores a un evento, el IED deberá almacenar continuamente en un buffer, las señales a monitorear. De esta manera, cuando el evento ocurre, el IED toma los datos almacenados temporariamente en el buffer, y finalmente genera los archivos CFG, HDR y DAT que constituyen el formato COMTRADE.

El formato de nombre completo de los archivos COMTRADE incluye identificación del relé de protección, el cual le permite al sistema de procesamiento de archivos oscilográficos interpretar y almacenar los datos en la base de datos de históricos.

Subsistema de procesamiento de archivos oscilográficos

La figura 3.9 muestra el procesamiento de históricos de la colección de archivos COMTRADE.

La aplicación SOE (Sequence of Events) procesa los datos a demanda. Esto significa que cuando arriba un nuevo archivo COMTRADE, el mismo es decodificado, procesado e insertado al registro de históricos. Al finalizar, la aplicación espera que nuevos archivos arriben al repositorio para ser procesados. Cuando el archivo es procesado, la aplicación SOE genera un registro individual con estampas de tiempo del evento procesado. Para el caso de archivos COMTRADE la estampa de tiempo proviene de los registros de tiempo del disparo y de la duración del evento almacenados en el propio reporte. Por esto último independientemente de los tiempos de espera entre que el dato se genera hasta que llega al registro de históricos, la información de estampa de tiempo no se pierde, dado que es generada y agregada por el propio IED fuente de los datos.

Por todo esto se puede decir que el uso de datos por parte de aplicaciones de análisis de fallas, de gestión de eventos y de otras aplicaciones pertenecientes al SLRP siempre se disponibiliza un tiempo después de generada la falla: Típicamente algunos minutos.





Figura 3.9. Procesamiento de archivos oscilográficos.

Sin embargo, estos tiempos de demora entre la recuperación y el tratamiento de los archivos hasta que estos están disponibles finalmente en el registro de históricos no afectan la funcionalidad del SLRP, ni provocan perdidas de los datos.

Deberá hacerse hincapié en que dado que la interface S/E – Datacenter se realiza mediante protocolos de transferencia de archivos desde un repositorio local en la S/E hacia un repositorio zonal en el Datacenter, aplicaciones desatendidas pueden perfectamente transferir archivos COMTRADE desde el Sistema Web existente de reporte de fallas de los Coordinados hacia el SLRP sin problemas. Ambos sistemas podrían convivir, brindando un marco para la incorporación de archivos COMTRADE provenientes de IED que no aplican a las características mínimas impuestas para participar del SLRP al Sistema de Registro de Protecciones de la presente especificación, como se ha sugerido anteriormente.

Por último, una vez que los datos de eventos y oscilografías ya se encuentran en el registro de históricos, trendings, análisis y cálculos específicos pueden ser ejecutados por parte de las aplicaciones del SLRP para propósitos de reportes.

3.3.3.2 Flujo de la Información en el Modulo de Acceso Remoto de Protecciones (ARP)

Los IED de toda la S/E deben parametrizarse de acuerdo a las configuraciones específicas de los dispositivos físicos correspondientes. Para simplificar este proceso, IEC 61850 parte 6 ha propuesto un lenguaje de marcas extensible (XML) basado en el lenguaje de configuración de subestaciones





(SCL). Esto facilita la descripción de relaciones entre el sistema de automatización de subestaciones y el cuadro de maniobras físico real. SCL especifica un formato de archivos para describir las configuraciones de los IED relacionadas con las comunicaciones, los parámetros de los IED, las configuraciones del sistema de comunicaciones, las estructuras de las funciones de protección y las relaciones entre todos ellos. Los diferentes archivos SCL incluyen una descripción de la especificación del sistema (SSD), la descripción de la configuración de fábrica (ICD) la descripción de la configuración de S/E (SCD), y los archivos de descripción de los IED configurados (CID).

La figura 3.9 utiliza el intercambio de datos SCL en el proceso de ingeniería de configuración de protecciones

Figura 3.10. Flujo de la información para el Módulo ARP del Sistema SLRP.

Los componentes ubicados por encima de la línea punteada (correspondientes a oficinas de tomas de decisión estratégica o de ingeniería de protecciones), indican dónde los archivos de SCL son utilizados. El Configurador de IED es una herramienta dependiente del fabricante que permite la posibilidad de importar o exportar los archivos definidos en el párrafo anterior. Ésta permite la





generación de parámetros y ajustes específicos de los IED así como los archivos necesarios para dicha configuración, o bien permite la descarga de estas configuraciones hacia los IED.

Por otro lado el configurador del sistema es una herramienta independiente del sistema que posibilita la importación o exportación de archivos de configuración SCL 61850 tal como se necesitan para los sistemas de simulación a nivel ingeniería, y usados por los ingenieros de protecciones para agregar información de sistema eléctrico compartidos por diferentes IED. De este modo, el configurador del sistema puede generar un archivo de configuraciones que puede ser correlacionado con el que utiliza el configurador de IED para las configuraciones especificas dependientes del fabricante.

De esta manera SCL puede utilizarse para reestructurar por completo el proceso de diseño del sistema de potencia, eliminando las configuraciones manuales y por lo tanto prescindiendo de los errores de ingreso de datos por parte del personal técnico y disminuyendo las inconsistencias entre las funcionalidades de los equipos y sus requerimientos por parte de los ingenieros de protección.

Para finalizar, si a este esquema se le agregara la posibilidad de ingresar los ajustes y parámetros a una base de datos, tal cual se recomienda en el apartado anterior para el caso del módulo CRE, se abriría la posibilidad de realizar control, registro, seguimiento y trazabilidad sobre todos los parámetros y ajustes del sistema de protección. Se recomienda explorar esta posibilidad a la hora de implementar un sistema de control de calidad sobre los procedimientos de ingeniería de las configuraciones de relés de protección.

3.3.4 Propuesta de arquitectura para el SLRP

En base a todo lo detallado hasta este punto, y teniendo en mente las premisas de diseño que se postulan al comienzo del informe, es preciso definir una arquitectura que resuelva el SLRP en cuanto a equipamiento de redes, de almacenamiento y de cómputo a lo largo de los diferentes niveles de la estructura.

En la siguiente figura, se muestra a modo de ejemplo, y en forma resumida una posible implementación del SLRP por parte del Coordinado. La especificación de detalle de los equipos del SLRP que son propiedad de los Coordinados se detallan más adelante en este mismo estudio. Sin embargo puede adelantarse los siguientes comentarios:





El Concentrador Local en sus dos funcionalidades (sistema de gestión de la información del sistema y el servidor de archivos) podría alojarse en forma virtual en los mismo equipos físicos de concentración de datos para sistema SCADA/EMS o en los servidores de la red WAM en caso que los puntos de monitoreo coincidan. La recomendación de implementación es utilizar hardware dedicado para los concentradores del SLRP. Por último, la opción de instalar herramientas marca Ruggedcom, línea Crossbow en los switches /routers Ruggedcom RX1500 también lo resolvería. El Concentrador Local pudiera alojarse en un centro de control del Coordinado en lugar de utilizar la propia S/E siempre y cuando se cumpla con todas las características y funcionalidades que se piden para el concentrador local del SLRP.

Se requiere redundancia de comunicaciones entre los IED y el concentrador local.

Se requiere servidor de tiempo basado en señal de GPS y protocolo Irig-B.

Se requiere alimentación segura y redundante a nivel S/E tanto para los IED como para el servidor de tiempo Irig-B y el Concentrador Local.

Los switches a nivel S/E deben soportar las variantes GOOSE y SV del IEC61850, por lo cual deben soportar funcionalidades de QoS, multicast 61850, segmentación en VLAN, redundancia de redes IEC 62439-3-Parallel Redundancy Protocol (PRP).

Además del concentrador local exigido por el SLRP, el Coordinado podría instalar otros servidores de ingeniería con aplicaciones de análisis propias que aprovechen la infraestructura que brinda el SLRP para la concentración de datos de las protecciones. Estas instalaciones adicionales no deben interferir con el resto de las aplicaciones y funcionalidades del SLRP.

Equipos de protección no compatibles con el SLRP pueden incorporarse al sistema mediante GW de protocolo o RTU que interprete DNP3 Nivel 2 o Modbus RTU/TCP y genere hacia el concentrador Local los reportes en los formatos requeridos y los nodos lógicos correspondientes en el sentido 61850.





VPN

GPS

GW/RTU

GW/RTU

GW/RTU

Al Coordinado

VLAN1 104VLAN2 61850

IED1 IED2 IED4

DPR1 DPR2 DFR1

PMU1

VLAN 3ICCP

SCADA

GBGB

GB

GW/ Concentrador

de Datos

Ruggedcom RX1500

TI

TV

ANIL

LO 1

618

50 G

OO

SE/S

V/M

MS

ANIL

LO 2

/MM

S/M

BTCP

Ruggedcom RX1500

MB RTU

DNP3

IED3

VLAN4 Mantenim

Figura 3.9 Ejemplo de Arquitectura de Detalle para el SLRP en la S/E.





Zona Centro NorteIp Zonal: 10.20.0.0/15

Zona Centro SurIp Zonal: 10.30.0.0/15

Zona Norte GrandeIp ZONAL: 10.10.0.0/15

Datacenter Principal CDECRed 10.0.0.0/15

Centro de control y despachoRed 10.4.0.0/15

Datacenter Secundario – Disaster RecoveryRed 10.2.0.0/15

BD

CCDP (100)

CLDP-2-1 SLRPRango asignado:

10.20.0.0/25

Coord


10.20.4.0/25

Coord

CLDP-2-128 SLRPRango asignado:10.21.252.0/25

Coord


10.30.0.0/25

Coord


10.30.4.0/25

Coord


Coord


10.10.0.0/25

Coord


10.10.4.0/25

Coord


Coord

SLRP

APLICAC SLRPSCADA/EMS

BD

CCDP (100)SLRP

Figura 3.10 Arquitectura de detalle propuesta para el SLRP en las oficinas del CDEC

La arquitectura propuesta para los equipos del SLRP que son responsabilidad del CDEC se resume en el diagrama lógico de la figura 3.10. La especificación de detalle de estos equipos se detalla más adelante en este mismo estudio. Sin embargo, puede adelantarse los siguientes comentarios:

El centro de cómputos es redundante contemplando la estructura que posee el sistema de monitoreo actual en las instalaciones de los CDC.

Utiliza virtualización del hardware con todas las ventajas que ello supone.





Cuenta con una previsión de direccionamiento IP acorde con las planificaciones de crecimiento de la red SLRP hacia el futuro, promoviendo desde su diseño su alcance global hacia todo el país o incluso los países vecinos.

Contempla los aspectos de la seguridad de las redes requeridos.

Brinda posibilidades de crecimiento del sistema en forma escalonada.

Brinda disponibilidad y confiabilidad de los datos a nivel Global garantizados con una demora aceptable a partir de que los datos fueron generados.

3.3.5 Definición del alcance respecto los equipos y elementos por parte del CDEC y/o de los Coordinados

La arquitectura presentada define el alcance y la delimitación de responsabilidades por cada uno de los equipos/funcionalidades. El límite está indicado mediante línea punteada y se explicita a continuación:

El CDEC es responsable por los elementos/equipos/software que se encuentran instalados dentro del perímetro de los centros de datos que alojan a los servidores, concentradores de datos y hardware asociado.

Los Coordinados son responsables por los elementos/equipos/software que se encuentran instalados dentro del perímetro de sus Instalaciones. Ya sea por los elementos instalados en los centros de datos o bien por los instalados en las subestaciones que operan.

3.4 Referencias

Substation Data Integration for Automated Data Analysis Systems. M.Kezunovic, T.Popovic. Texas A&M University, Test Laboratories International Inc.

A Collation & Analysis Methodology for Substation Event Data via a Web Interface (supporting COMTRADE, GOOSE & MMS Data Sources from Multiple Vendors) Author: Bruce Mackay





Automated Fault Analysis System in Thailand Power System N.AKEKURANANT S. CHAMNAN VANICHKUL. Electricity Generating Authority of Thailand THAILAND.

Common Format for IED Configuration Data IEEE PSRC WG H5.

IEEE Std C37.111-2013, IEEE Standard Common Formatfor Transient Data Exchange-COMTRADE – for Power Systems.

std IEEE C37.232.2007. IEEE Recommended Practice for Naming Time Sequence Data Files

An Introduction to Applying Network Intrusion Detection for Industrial Control Systems Tom Bartman and Jason Kraft Schweitzer Engineering Laboratories, Inc.

Substation Data Integration for Automated Data Analysis Systems. M. Kezunovic, T. Popovic. Texas A&M University, Test Laboratories International Inc.

An Introduction to Applying Network Intrusion Detection for Industrial Control Systems. Tom Bartman and Jason Kraft. Schweitzer Engineering Laboratories, Inc.

Documentos Técnicos de los Sistemas de Comunicación de S/E y Sistemas de Monitoreo vigentes de los Coordinados del SIC y el SING entregados por los CDEC.





Capítulo4. MODELO DE DATOS PROPUESTO PARA EL SLRP

4.1 Introducción

Hasta ahora se han expuesto los criterios básicos en cuanto a la definición y especificación de los equipos y funcionalidades necesarios para la correcta incorporación de protecciones al SLRP. No obstante, existe un aspecto igualmente importante a definir que es la adecuación de los datos a un formato y significado común, que permita generar datos homogéneos y compatibles entre sí. Este Modelo de Datos, que supone dicha homogeneización, es materia de estudio del presente capítulo.

4.2 Modelo de Datos para el Módulo Concentrador de Registro de Eventos (CRE)

4.2.1 Antecedentes. Normativa vigente

NTCyCS, Anexo Técnico. CNE. ME Chile.

IEEE Std C37.111-2013, IEEE Standard Common Format for Transient Data Exchange –COMTRADE – for Power Systems.

IEEE Std C37.232-2011, IEEE Recommended Practice for Naming Time Sequence Data Files.

Configuración y Definición de Parámetros para Registros Oscilográficos de fallas en formato COMTRADE”.CDEC-SING.

Identificación de funciones de protección o ANSI/IEEEC37.2 - IEEE Standard C37.2-2008.

4.2.2 Formato de nombre completo

Como ya se adelantó en el apartado ¨Filosofía de Diseño del Modelo de Datos¨ la presente especificación adopta el formato de nombre completo IEEE Std C37.232-2011.





Este formato de nombre completo figura en la norma PSRC citada en el párrafo anterior, y se usa para nombrar archivos de datos con secuenciación temporal. En las columnas de la tabla 4.1 se despliega el contenido del nombre completo. El nombre del archivo comprende seis campos, cada uno delimitado por medio de comas. Los demás campos son facultativos. La tabla presenta también al final 4 columnas opcionales para campos definidos por el usuario.

Las aplicaciones de gestión de archivos COMTRADE que se seleccionen deben soportar este estándar de nombre completo, y además permitir al usuario llenar los campos opcionales con información.

A continuación se muestra un ejemplo de un nombre completo de archivo de registro oscilográfico:

000112,123433234,-5S,SouthArkey,DLP1,SunPower,000003000,T,4287N,6587W.OCS

Dependiendo de las aplicaciones propietarias que utilice el Coordinado, se recomienda salvar los archivos originales ya que algunas aplicaciones no pueden abrir los archivos después de que se hayan renombrado.

Todos los archivos asociados con los archivos COMTRADE seleccionados serán renombrados (archivos ".CFG", ".INF", ".HDR", ".DAT" y "*.D##").

Existe gran variedad de aplicaciones en el mercado que soportan o ayudan en la gestión de archivos en formato COMTRADE, que permite realizar esta tarea de renombrado de forma automática o semiautomática. Por ejemplo WaveWin ™ de Schneider.

4.2.3 Configuración de registros oscilográficos

Tal como se discutió anteriormente en la filosofía del Modelo de Datos del Módulo CRE, es preciso definir un modelo estándar para la configuración de reportes COMTRADE, de manera que reportes generados en diferentes puntos de las instalaciones del sistema eléctrico, y posiblemente de distintos Coordinados, sean comparables entre sí.

Al no haberse encontrado a la fecha un estándar en cuanto a la configuración de los archivos de reporte COMTRADE, se adoptará la recomendación del SING publicada en su página WEB. Esta configuración se describe en la tabla 4.2.





Campo Ejemplo Presentación Definición

Fecha 000112 01/12/2000

El campo Fecha define la fecha por defecto en el archivo. Los campos de la fecha se definen de la siguiente manera: los 2 primeros caracteres representan el año, los dos siguientes el mes y los dos últimos el día. (obligatorio)

Hora 123433234 12:34:33.234

El campo Hora define la hora por defecto en el archivo. Los campos de la hora se definen de la siguiente manera: los 2 primeros caracteres representan la hora, los dos siguientes son los minutos, los dos siguientes los segundos y los dos o tres últimos los milisegundos. (obligatorio)

Código horario

-5S -5S

El campo Código horario define la diferencia entre la hora del sistema que se usa como hora de inicio y la Hora Universal. Así -5s sería específico a la hora Este de los EE.UU. Si se utiliza la hora universal (UT) como hora de inicio entonces el código de este campo es 0z, Nota: UT es la abreviación internacional para la Hora Universal, también llamada Greenwich Mean Time o GMT. (obligatorio)

S/E South Arkey South Arkey El nombre o código de la S/E que corresponde al lugar en dónde se encuentra el equipo. (obligatorio)

Dispositivo DLP1 DLP1 El nombre o código del dispositivo que genera el archivo. (obligatorio)

Compañía Sun Power Sun Power El nombre de la compañía de la S/E. (obligatorio)

Duración 000003000 000003000 La duración del archivo. (opcional)

Tipo T T El tipo de falla o el contenido de la falla del archivo. (opcional)

Latitud 4287N 4287N La latitud representa la posición geográfica de la S/E. La letra N sitúa la latitud en el Hemisferio Norte. (opcional)

Longitud 6587W 6587W La longitud representa la posición geográfica de la S/E. La letra W sitúa la latitud en el Hemisferio Oeste. (opcional)

Tabla 4.1 Sistema de nombre completo para archivos COMTRADE





Item Descripción

Tasa de Muestreo Deberá ser a lo menos de 16 muestras por ciclo. Arranque (trigger) Deberá ocurrir al detectarse un evento de falla (pickup activo).

Estampa de tiempo Sincronizada mediante GPS conectado al terminal RTU local u otro dispositivo de sincronización GPS

Tiempo total de registro Al menos 80 ciclos. Tiempo de pre falla Al menos 20 ciclos. Señales analógicas Corrientes y tensiones por cada fase, y residual donde corresponda.

Señales binarias

Deberán estar identificadas, individualmente y por separado las siguientes señales: Orden general para desenganche y apertura de interruptor. Orden individual de desenganche por cada una de las funciones de

protección existentes. Orden general para desenganche y apertura de interruptor. Orden individual de desenganche por cada una de las funciones de

protección existentes. Arranque de la función de protección activada. Envío y recepción de señales de teleprotección, si corresponde. Envío y recepción de señales de transferencia de desenganche directo, si

corresponde. Magnitudes monitoreadas: Deberán ser registradas en la oscilografía en

valores primarios.

Tabla 4.2 Configuración de Registros Oscilográficos

Para aquellos equipos que presenten restricciones técnicas de almacenamiento de registros tal que no sea recomendable el arranque del registro por detección de falla, sino que por orden de desenganche, se deberá privilegiar la configuración de arranque por desenganche.

No obstante, el propietario del equipo registrador deberá evaluar alternativas técnicas con tal de disponer de los registros con arranque por detección de fallas y no exclusivamente por operación de las protecciones.





4.2.4 Nomenclatura de Señales dentro de los registros oscilográficos

Con el propósito de estandarizar la nomenclatura utilizada para designar señales análogas y binarias en los registros oscilográficos, y de esa forma agilizar los procesos de análisis respectivos, se recomienda aplicar las indicaciones siguientes:

Nomenclatura para señales analógicas

La nomenclatura y formato propuesto se muestran en las tablas 4.3 y 4.4. La estructura es la siguiente:

magnitud_índice_(unidad)_opcional

Nomenclatura para Señales Analógicas en Notación de Componentes Simétricas

Para efectos de habilitar señales en cantidades de secuencia (componentes simétricas), se propone la siguiente estructura. El detalle se presenta en la tabla 4.5 y 4.6.

magnitudX_índice_(unidad)_opcional

Campo Ejemplo Definición

Magnitud V Se identificarán corrientes y tensiones por cada fase, residual (cuando corresponda) y frecuencia. (obligatorio)

Índice A

Se hará referencia a las fases: A, B o C, según corresponda. El neutro se identificará con el índice N. Estudios que no encuadran con ninguno de los índices anteriores identifican magnitudes monofásicas, y se identificarán con la letra M (obligatorio). En este último caso el campo opcional se utilizará para diferenciar los distintos casos.

(unidad) kA Se identificará a la unidad de medida de las magnitudes de corriente, tensión y frecuencia. Se utilizarán: kA para las corrientes, kV para tensiones y Hz para frecuencia. (obligatorio).

Opcional XXX Asignación opcional para que el propietario de la instalación incorpore alguna definición de interés respecto de la señal identificada.

Tabla 4.3. Definición de los campos para definición de señales analógicas.





Señal Magnitud Índice Unidad Opcional

Corriente I A, B, C, N o M kA XXXX

Tensión V A, B, C, N o M kV XXXX

Frecuencia F - Hz XXXX

Impedancia F - Ω XXXX

Potencia Activa P A,B,C o 3 MW XXXX

Potencia Reactiva Q A,B,C o 3 MVAR XXXX

Tabla 4.4. Cuadro Resumen para definición de señales analógicas.


Magnitud V Señal de corriente o voltaje, expresada como I o V. (obligatorio).

X 0 Secuencia positiva, negativa y cero, expresada en número como 1, 2 y 0, respectivamente (obligatorio).

Índice mag

Especificará si se visualiza magnitud o fase de la señal, se utilizará el término: (obligatorio)

mag: para indicar magnitud. ang: para indicar el ángulo.

(unidad) kA

Expresa la unidad de medida. Se recomienda indicar la unidad de medida haciendo uso de paréntesis. (obligatorio)

kA: para magnitudes de corriente. deg: para indicar la unidad angular

Opcional XXXX Asignación opcional para que el propietario de la instalación incorpore alguna definición de interés respecto de la señal identificada (opcional).

Tabla 4.5. Definición de los campos para definición de señales analógicas en notación de componentes simétricas.





Señal Magnitud_ X Índice Unidad Opcional

Corriente y Tensión I, V 1, 2, 0 mag ang kA deg XXXX

Tabla 4.6. Cuadro Resumen para definición de señales analógicas en notación de componentes simétricas.

Nomenclatura para Señales Binarias

La nomenclatura utilizada para señales binarias se representa en la siguiente estructura y en las tablas 4.7 y 4.8rá de la forma siguiente:

num_fx_índice_opcional


num 1 Función de protección o señal de teleprotección según corresponda, identificado según norma vigente ANSI/IEEE C37.2

fx Trip

Se utilizará para hacer referencia a una acción o estado, por ejemplo: Trip: Disparo. Pkup: Arranque.

SEND/RCV: Envío/recepción de señales de teleprotección. ED: Esquema de desprendimiento (EDAG/EDAC)

Índice mag

Se utilizará cuando sea necesario destacar una particularidad, por ejemplo: Designar Fases o neutro: A, B, C, 3F o N. Dirección de operación: FW (indica hacia adelante)/RV (indica hacia

atrás). Tipo de señal de señal teleprotección:

A: Aceleración. C: Comparación. D: Desenganche directo.

Indicar escalón de frecuencia: 1, 2 3 para designar el primero, segundo y sucesivos.

Opcional XXXX Asignación opcional para que el propietario de la instalación incorpore alguna definición de interés respecto de la señal identificada (opcional).

Tabla 4.7. Definición de los campos para señales binarias.





Señal Número fx Índice Opcional

Función de Protección (aplicable a funciones

residuales)

87, 21, 67, 50BF, 81U/81O, 50/51, etc.

Trip Pkup ED A, B ó C, 3F

FW/RV 1, 2, 3, etc.

XXXX

Señal de Teleprotección 85 SEND/RCV A, C y D XXXX

Tabla 4.8. Cuadro Resumen para definición de señales binarias.

En caso de que el Coordinado haya definido parámetros adicionales a los indicados en este documento, junto con el registro oscilográfico se solicita la entrega del listado de señales adicionales utilizadas, junto a su nomenclatura y definición.

Códigos IEEE C37.2-2008 de las Funciones de Protección Eléctricas

Especifica las funciones de protección existentes mediante un número. Según la (IEEE Standard C37.2-2008), también se le puede agregar una letra para especificar la aplicación.

Cod Aplicación B Bus F Field G Grounds or Generator N Neutral T Transformer

Tabla 4.9. Codificación de Aplicaciones de Protecciones Eléctricas (IEEE Standard C37.2-2008).





Cod Función de Protección (En negrita las más comunes) 1 Master Element 2 Time Delay Starting or Closing Relay 3 Checking or Interlocking Relay 4 Master Contactor 5 Stopping Device 6 Starting Circuit Breaker 7 Rate of Change Relay 8 Control Power Disconnecting Device 9 Reversing Device

10 Unit Sequence Switch 11 – Multifunction Device 12 Overspeed Device 13 Synchronous-speed Device 14 Underspeed Device 15 Speed or Frequency-Matching Device 16 Data Communications Device 20 Elect. operated valve (solenoid valve) 21 Distance Relay 23 Temperature Control Device 24 Volts per Hertz Relay 25 Synchronizing or Synchronism-Check Device 26 Apparatus Thermal Device 27 Undervoltage Relay 30 Annunciator Relay 32 Directional Power Relay 36 Polarity or Polarizing Voltage Devices 37 Undercurrent or Underpower Relay 38 Bearing Protective Device 39 Mechanical Conduction Monitor 40 Field (over/under excitation) Relay 41 Field Circuit Breaker 42 Running Circuit Breaker 43 Manual Transfer or Selector Device 46 Rev. phase or Phase-Bal. Current Relay 47 Phase-Seq. or Phase-Bal. Voltage Relay 48 Incomplete-Sequence Relay 49 Machine or Transformer Thermal Relay 50 Instantaneous Overcurrent 51 AC Time Overcurrent Relay





52 AC Circuit Breaker 53 Field Excitation Relay 55 Power Factor Relay 56 Field Application Relay 59 Overvoltage Relay 60 Voltage or Current Balance Relay 62 Time-Delay Stopping or Opening Relay 63 Pressure Switch 64 Ground Detector Relay 65 Governor 66 Notching or jogging device 67 AC Directional Overcurrent Relay 68 Blocking or “out of step” Relay 69 Permissive Control Device 74 Alarm Relay 75 Position Changing Mechanism 76 DC Overcurrent Relay 78 Phase-Angle Measuring Relay 79 AC-Reclosing Relay 81 Frequency Relay 83 Automatic Selective Control or Transfer Relay 84 Operating Mechanism 85 Pliot Communications, Carrier or Pilot- Wire Relay 86 Lockout Relay 87 Differential Protective Relay 89 Line Switch 90 Regulating Device 91 Voltage Directional Relay 92 Voltage and Power Directional Relay 94 Tripping or Trip-Free Relay

Tabla 4.10. Codificacion de funciones de protecciones eléctricas (IEEE Standard C37.2-2008).





4.3 Modelo de Datos para el Módulo de Acceso Remoto de Protecciones (ARP)

Los datos de oscilografías asociados a las protecciones y sus parámetros se rigen por el modelo de datos anteriormente citado.

A la hora de definir una modelo de intercambio estándar en cuanto a formato de datos de configuración de los IED hay que distinguir dos aspectos:

a) La Sintaxis que permite definir sin ambigüedades los datos a intercambiar está resuelta en IEC61850 mediante el uso de SCL como lenguaje descriptivo.

b) La Semántica en cambio, refiere al significado de los datos intercambiados sin ambigüedades en cuanto nombre de variables, descripción y tipo de datos.

Si bien hay avances en cuanto al punto b el problema aún no está resuelto por completo. Al momento de redactar el presente informe no se existe un estándar abierto para el intercambio de parámetros que aplique a los IED a lo largo de toda la cadena en la industria de la energía.

Por el contrario es práctica común el uso de drivers dependientes de los distintos fabricantes para salvar este inconveniente. De esta manera se logra homogeneizar el intercambio de la información sin ambigüedades. Ya se mostró este concepto en la especificación básica del módulo ARP: El problema se resuelve mediante herramientas de software adecuadas que hermanan los modelos del sistema utilizados por aplicaciones de simulación y diseño de sistemas con los modelos utilizados por los distintos fabricantes de IED. El resultado, es un conjunto de archivos SCL que se intercambian entre los repositorios de los concentradores locales (propiedad del Coordinado) y los concentradores regionales (propiedad del CDEC).

Asimismo, a la hora de definir el modelo de datos para el módulo SGP también son de interés los trabajos realizados por el grupo IEEE PSRC WG H5, que buscan estandarizar un modelo de intercambio de información que aplique a todo el proceso de Generación, Transmisión y Distribución Eléctrica. Un estándar para lograr esto aún se encuentra en desarrollo. Sin embargo se completará en un futuro próximo. Las aplicaciones deberán actualizarse cuando esto suceda. El resto de la arquitectura del SLRP, junto con las recomendaciones de virtualización de hardware recomendadas en este estudio, tanto en las instalaciones de los Coordinados como en las del CDEC, facilitan esta tarea de adaptación, minimizando los costos de actualización.





Sin embargo la propuesta del presente estudio atiende la limitación de los estándares citada en los párrafos precedentes. Por un lado se han seleccionado las herramientas adecuadas que salvan este problema, por otro lado se ha resuelto las conexiones seguras bajo el estándar NERC-CIP, de manera que conexiones a los diferentes equipos por parte de diferente software propietario se han autenticadas debidamente.

4.4. Referencias

NTCyCS, Anexo Técnico. CNE. ME Chile.

IEEE Std C37.111-2013, IEEE Standard Common Format for Transient Data Exchange - COMTRADE - for Power Systems.

IEEE Std C37.232-2011, IEEE Recommended Practice for Naming Time Sequence Data Files

Configuración y Definición de Parámetros para Registros Oscilográficos de fallas en formato COMTRADE”.CDEC-SING.

Identificación de funciones de protección o ANSI/IEEE C37.2 - IEEE Standard C37.2-2008.

ZIV Sistema de Gestión de Protecciones v2.0Manual de Instrucciones.

Red de monitoreo y supervisión de las variables eléctricas en sub-estaciones. Luis Andreula.





Capítulo 5. ARQUITECTURA DE DETALLE.

5.1 Descripción de la Arquitectura Seleccionada

La arquitectura del SLRP propuesta en el capítulo 3 se basa en una supervisión global mediante Concentradores de nivel Regional o Corporativo CDEC (CCDP en la figura), instalados en los dominios del CDEC, privilegiando la flexibilidad y escalabilidad de la red SLRP, y otorgando niveles básicos de confiabilidad y de disponibilidad de la información. A su vez, la arquitectura considera la implementación de unidades concentradoras de información a nivel Local (CLDP) en las instalaciones de los Coordinados a nivel local. Dicho almacenamiento permitirá otorgar la capacidad de respaldo de información en caso de pérdida del o los enlaces de comunicación desde el concentrador local hacia el concentrador.

Los concentradores locales serán la puerta de entrada a los Coordinados que deseen hacer uso de la información existente en dichas unidades de almacenamiento en forma independiente y sin perturbar el monitoreo ejecutado desde el concentrador regional instalado en el CDEC. Cada uno de los Coordinados podrá, en caso de necesitarlo, diseñar, instalar y construir sus propias aplicaciones para analizar, monitorear y calcular lo que requiera para sus propios fines.

Por otro lado la arquitectura general es definida en forma modular y jerárquica, permitiendo entonces que se vayan acoplando protecciones uniforme y paulatinamente y sin que ello incida en el funcionamiento normal del SLRP ya en funcionamiento. El concentrador local dispondrá de toda la información de cada una de los IED conectados a él.

5.2 Fuentes de Datos

Los relés deberán registrar como mínimo los eventos en el sistema descriptos en el capítulo 3 que se repiten a continuación. Con cada evento se registrarán el mes, día, hora, minutos, y segundos en que suceden:

a) Cambio de parámetros / ajustes. b) Activación / Desactivación de la protección. c) Cambio de estado del interruptor asociado.





d) Falla / Actuación de la protección. e) Telecomandos.

Además deberán cumplir con los siguientes requerimientos:

a) Puerto frontal: Para acceso local los relés deben tener un puerto USB o Ethernet RJ45 frontal para realizar ajustes y adquirir información localmente. Este puerto deberá quedar disponible para cualquier operación por fuera del SLRP relacionada con el relé de manera de no afectar el normal funcionamiento del sistema.

b) Puertos traseros: Para acceso remoto los relés deben tener dos puertos Ethernet configurables en forma independiente. La velocidad de transferencia de información deberá ser de 100 /1000 Mbps. Los puertos Ethernet deben soportar el protocolo de redundancia IEC 62439-3-Parallel Redundancy Protocol (PRP) o bien el protocolo RSTP IEEE 802.1w

c) Protocolos de comunicación: El protocolo de comunicación de los puertos traseros deberá ser IEC 61850. Se deberá permitir el acceso a los relés para la descarga de todos los ajustes (protecciones y comunicación), y opcionalmente oscilografías, eventos y fallas a través de protocolo FTP o variantes que permitan realizar lo mismo.

d) Sincronización Horaria: Los relés deben incluir un puerto para sincronización horaria a través de protocolo IRIG-B (preferentemente con bornera mediante tornillo) o mediante IEEE 1588 versión 2.

e) Seguridad informática: Los relés deben proporcionar niveles de seguridad tales como contraseña, autentificación y autorización, de tal forma que permita el acceso sólo al personal autorizado.

f) Alimentación: Los relés deben soportar energía de alimentación universal CA (100-300) y CC (100-300) y doble fuente de alimentación.

5.3 Concentradores de Datos Locales

A continuación se listan los requerimientos que deben presentar los concentradores locales propiedad de los Coordinados para poder incorporarse al SLRP:





5.3.1 Funcionalidades de los Concentradores de Datos

a) Gestión de reportes de eventos: Los concentradores deben poder gestionar conexiones a los diferentes IED, manejar administraciones de usuario, utilizar capacidades de acceso basada en roles, interpretar archivos COMTRADE y soportar sistemas de nombres completo para reportes COMTRADE.

b) Gestión de la información de protecciones: Los concentradores deberán gestionar conexiones a los diferentes IED, manejar administraciones de usuario, utilizar capacidades de acceso basada en roles, interpretar archivos SCL dependientes del fabricante

c) Agregación y mezclado de reportes: Los concentradores deberán ejecutar agregación y mezclado de datos de reportes provenientes de múltiples IED.

d) Sincronía: Los concentradores deberán realizar sincronización horaria mediante GPS a través del reloj externo con salida IRIG-B no modulada propuesto para los IED instalados en el mismo sitio que el propio concentrador.

e) Validación de datos: Los concentradores deberán soportar validación de datos. En este caso el proveedor deberá indicar alcance y condiciones bajo las cuales se soporta la validación ofrecida.

f) Servidor de archivos: Los concentradores deberán actuar como servidor de archivos de reportes, ajustes y otra información relativa a los relés de protección de importancia hacia el concentrador corporativo correspondiente. Deberán incluir también funciones de almacenamiento fuera de línea (backup) a los fines de cumplir la reglamentación vigente en cuanto a vigencia de disponibilidad de los reportes.

5.3.2 Protocolos y formatos soportados

a) FTP

b) IEC 61850 MMS

c) Lenguaje de Configuración del Sistema

d) COMTRADE





5.3.3 Otras características

Los concentradores deberán soportar fuente de alimentación universal: AC (100-300) y CC (100-300)

Los concentradores deberán proveer doble puerto de red Ethernet a los fines de poder conectarse a la red LAN en topología de anillo redundante.

Los concentradores deberán contar con almacenamiento Hot Swap 2 x 3 Tbytes como mínimo.

Los concentradores deberán utilizar preferentemente hardware virtualizado con procesador de 2 núcleos y 4 GB de RAM como mínimo.

5.3.4 Comparativa de Productos comerciales

La comparación entre las opciones disponibles en el mercado para la funcionalidad de concentrador local responsabilidad del Coordinado, se resume en la tabla 5.1.

Solución Siemens Solución Kalkitech Solución SEL Solución SubNET ZIVCrossbow SAC/SAM/ELAN SYNC2000/4000/5000 Synchro WAVe / acSELerator Power System Server SGR

G es tión de la informac ión de protec c iones . Cumple Cumple Cumple Cumple CumpleG es tión de reportes de ev entos . Cumple Cumple Cumple Cumple CumpleG es tion c onexiones IE D Cumple Cumple Cumple Cumple CumpleG es tion de ac c es o bas ada en roles Cumple Cumple Cumple Cumple CumpleG es tion de arc hiv os C O MT R ADE Cumple Cumple Cumple Cumple Cumple

S oporte protoc olos y formatos S L R P Cumple Cumple Cumple Cumple CumpleF T P Cumple Cumple Cumple Cumple CumpleIE C 61850 MMS Cumple Cumple Cumple Cumple CumpleL eng uaje de C onfig urac ión del S is tema Cumple Cumple Cumple Cumple CumpleC O MT R ADE Cumple Cumple Cumple Cumple Cumple

Ag reg ac ión y mez c lado de reportes . Cumple CumpleS inc ronía. CumpleValidac ión de datos . Cumple Cumple CumpleVirtualiz able Cumple No Cumple Cumple Cumple

Tabla 5.1. Concentradores locales para el SLRP disponibles en el mercado.





5.4 Aplicaciones

Existe en el mercado una gran variedad de aplicaciones encargadas del procesamiento de la información proveniente de los módulos de acceso remoto de protecciones (ARP) y del concentrador de reportes oscilográficos de perturbaciones y fallas eléctricas (módulo CRE). Se han clasificado las funcionalidades en:

DFRA: Aplicaciones de adquisición, chequeo y clasificación de perturbaciones o de fallas.

DPRA: Aplicaciones de adquisición y chequeo de consistencia entre ajustes de protecciones.

CBA: Aplicaciones de verificación del correcto funcionamiento de interruptores.

FAFL: Aplicaciones de análisis automático de fallas, localización y sistemas expertos.

SGP: Software de gestión de activos.

La tabla 5.2 resume las funcionalidades de las aplicaciones disponibles en el mercado, destacando en negrita aquellas aplicaciones que exige la NT SyCS.

La tabla 5.3 presenta a modo de ejemplo una lista de aplicaciones de la marca Survalent que cumpliría los requisitos del SLRP de acuerdo al presente informe.

La tabla 5.4 presenta un estudio comparativo entre las aplicaciones para el SLRP que se encuentran disponibles en el mercado. Se busca con esto proporcionar información que permita al SLRP cumplir con las siguientes pautas:

Ser compatible con la NTSySC en cuanto a los requerimientos mínimos de funcionalidad.

Ser escalable en cuanto a requisitos de almacenamiento, enlace y procesamiento.

Utilizar base de datos unificada de manera que se puedan vincular a otros sistemas de monitoreo, como los del SCADA/EMS. O bien que se pueda vincular a sistemas de gestión de activos o a sistemas de Ingeniería o software de simulación.

Ser virtualizable de manera que se puedan utilizar los esquemas propuestos con el fin de aprovechar las ventajas de los sistemas de virtualización.





Tipo

Descripción

DPRA

1 Chequeo de consistencia de datos entre diferentes protecciones (configuración y ajustes, oscilografías, reportes de evento y de falla)

2 Chequeo de validez de los datos de archivos de la protección (configuración, ajustes, oscilografías, reporte de evento y reporte de falla)

3 Sistema de adquisición de datos para aplicaciones de análisis automático de fallas y de localización de fallas, o para datos de entrada de un analista.

DFRA

1 Detección y clasificación de fallas y perturbaciones

2 Verificación de los sistemas de protección

3 Verificación de operaciones de circuit braker.

4 Sistema de adquisición de datos para aplicaciones de análisis automático de fallas y de localización de fallas, o para datos de entradas de un analista.

CBMA 1 Performance de los CB para mantenimiento preventivo

2 Performance de los CB para mantenimiento correctivo

FAFL

1 Sistema experto de análisis automático de fallas en cascada.

2 Sistema experto de análisis de automático de localización de fallas

3 Seleccionar de manera automática caso de pruebas con el propósito de realizar test en Software de Simulación de Redes Eléctricas.

SGP 1 Software de Gestión de Activos

Tabla 5.2 Clasificación de aplicaciones mandatorias y opcionales para el procesamiento de datos.

Mandatorias

Survalent ONE SCADA Manejo de alarmas, eventos, oscilografías, datos CB, datos DFR, datos DP , datos DPR, Reportes

Control Panel Adquisición de protecciones DataBase Transcripcion Herramienta para intercambio de datos con el SCADA/EMS del CDEC

Opcionales Protection Setting Manager Gestión de la configuración de protecciones (Aplicación Recomendada solo para

Coordinados) FLISR Análisis automático de fallas, incluye algoritmo de localización

Utilidades Oracle Server Motor de Base de Datos Sistema Operativo Windows Server, Linux

Tabla 5.3. Ejemplo de selección de aplicaciones recomendadas para el SLRP.





Siemens Survalent ABB SEL SubNet ZIV

CrossBow SAM/Digsi

Manager

One / ADMS PCM 600 Ascele-

rator

Power Sistem Center

SGR/SGP

Cumplimiento de requisitos

mandatorios

Disponibilizar reportes de fallas y perturbaciones al CDEC Si Si Parcial Si Si Si

Interface con SCADA/EMS del CDEC Si Si Si Si Si Si

Comparar ajustes de protecciones con valores de variables que den origen a la actuación de protecciones

Si Si Parcial Si Si Si

Determinar secuencias de operación de protecciones Si Si Parcial Si Si Si

Cumplimiento de requisitos opcionales

Mostrar ajustes de protrcciones no pertenecientes al SRLP (vía modem) Si No Parcial No Si Si

Permite configurar remotamente ajustes de protecciones del SLRP (opcional para coordinado).

Si Parcial Parcial Parcial No Parcial

Permite configurar remotamente ajustes de protecciones del SLRP (vía modem) (opcional para coordinado).

Si No Parcial No Si Si

Funcionalidades /Características de

la aplicación

Virtualizable Si Si Si Si Si Si

Base de datos unificada Si Si No Si Si Si

Capacidad de generación de informes (tablas de ajustes, eventos, informe diario, estadísticas de incidencias)

No Si Si Si Si Si

Posee alarmero en tiempo real No Si No Si Si Si

Gestión de usuarios (perfiles, password, niveles de acceso) Si Si Si Si Si Si

Cumplimiento de los estándares NERC-CIP Si Si Si Si Si Si

Permite asociae información externa a la base de datos de protecciones (planos, manuales, registros de puesta en marcha)

Si Si No Si No Si

Clasificación

DPRA Si Si Si Si Si Si

DFRA Si Si Si Si Si Si

CBA No No No No No Si

FAFL Si Si No Si No No

SGP No Si No Si No No

Tabla 5.4 Tabla comparativa de aplicaciones disponibles en el mercado para el SLRP


(A)ESTADO DEL ARTE – (B) DISEÑO DE ARQUITECTURA Y ESPECIFICACIÓN DEL SISTEMA

NºSEIS: PÁGINA: 180 DE 230 REV: EO


5.5 Requerimientos de los Enlaces de Comunicación

Según las características de cada uno de los tipos de enlaces que existen se muestra en la tabla 5.5 un análisis de cumplimiento de requerimientos según los aspectos tratados al respecto para el SLRP en el presente informe: a) latencia (suma de retardos temporales de una red. b) jitter (variabilidad de la latencia). c) disponibilidad del enlace.

Respecto al Ancho de Banda Requerido de los mismos, se realiza a continuación un cálculo estimado, tomando como punto de partida una tasa aproximada de capturas de oscilografías de los equipos por año, que se desarrolla en el capítulo siguiente para el cálculo de los servidores de almacenamiento.

Según estudios estadísticos realizados por este consultor los generadores presentan el mayor índice de registros oscilográficos en un valor de 3,43 capturas al año. Por lo tanto, se estima, suponiendo un muy alto congestionamiento en la red que provoque mil retransmisiones de los eventos 3,43*1000 =3.430 archivos oscilográficos por año por protección. Para el valor de 3.430 archivos se requieren aproximadamente 60 kb para la transmisión completa de la información de protecciones.

Entonces utilizando la conocida fórmula bps = 1,2 (nn xL x F), donde nn es el número de bytes a transmitir vía protocolo Ethernet, L es el largo del byte de mensaje (1 bit de start, 8 bits de datos, 2 bits de stop, 1 bit de paridad; por lo cual L = 12 bits), y F es la frecuencia de los mensajes, se tiene que:

1,2*(60[kbytes]*1024[bytes/kbytes]*12[bits/byte]*(1/60)[1/seg])=14.745,6bits/seg=14.754.6kbps=14,4kbyte/s

14,4bbyte/s por protección, considerando una tasa de refresco de 1 minuto. Con un factor de seguridad de 2x que es lo usual en estos cálculos debido a sobrecarga administrativa de los protocolos de red, se deberá reservar 30 kbps de Ancho de Banda en la red para la transmisión de datos relativos a las protecciones eléctricas.





De lo anterior, se puede decir con seguridad que no hay requerimientos importantes de ancho de banda ni especificaciones rigurosas de los enlaces para las comunicaciones del SLRP tal y como está planteado el esquema de transmisión de los datos.

Enlace Cumple Disponibilidad

Cumple Latencia

Cumple Jitter Observaciones

Fibra Óptica oscura Sí Sí Sí

Enlace de transmisión vía SDH Sí Sí Sí

Fibra Óptica coloreada Sí Sí Sí

VPN Sí Sí Sí Este tipo de enlaces suelen tener disponibilidades bajas.

Enlace de Microondas Sí Sí Sí

La latencia y la disponibilidad son dependientes de las condiciones de interferencia del enlace. Deberá utilizarse una banda de frecuencia regulada y registrarse los enlaces en ente regulador.

VHF/UHF Sí Sí Sí La latencia y la disponibilidad son dependientes de las condiciones geográficas del enlace.

Enlace en la banda de 5.8 Ghz Sí Sí Sí

La latencia y la disponibilidad son dependientes de las condiciones geográficas del enlace y las condiciones de interferencia del enlace. Deben registrarse los enlaces ante ente regulador de frecuencias.

Enlace satelital VSAT Sí Sí Sí Este tipo de enlaces suelen tener disponibilidades bajas.

3G Sí Sí Sí Este tipo de enlaces presenta un jitter (variabilidad de la latencia) variable y baja disponibilidad del enlace.

LTE Sí Sí Sí Este tipo de enlaces presenta un jitter (variabilidad de la latencia) variable y baja disponibilidad del enlace.

Tabla 5.5. Cumplimiento de los los requerimientos del SLRP para diferentes tipos de enlace.





5.6 Requerimientos para la infraestructura de TI

Dado que el centro de recepción de datos es de fundamental importancia para el CDEC se torna crítico asegurar un correcto y permanente funcionamiento del mismo.

Para ello se plantea la utilización de los criterios de mejores prácticas para el diseño de centro de cómputos, la implementación de redundancia de equipamiento y la utilización de una arquitectura de software virtualizada.

Finalmente para asegurar el funcionamiento del servicio de adquisición y procesamiento de datos ante un evento catastrófico en el sitio principal se propone la réplica completa del equipamiento involucrado en un centro de cómputos off-site denominado Disaster Recovery.

El principal objetivo de los siguientes lineamientos es establecer los parámetros necesarios para lograr una disponibilidad superior al 99,7% de todos los servicios que se brindan desde el centro de cómputos.

5.6.1 Lineamientos del datacenter

Se utilizan los criterios definidos en la norma ANSI/TIA-942 del Uptime Institute. La misma define 4 niveles de Centros de Cómputo categorizados según el uptime. En el Anexo N°III de este documento se describen los tipos de datacenter según la norma.

Debido a la importancia del tipo de instalación se recomienda alojar el equipamiento en un centro de datos que cumpla con los lineamientos del tipo Tier III, asegurando además que todo el equipamiento de procesamiento de datos y comunicaciones posea como mínimo redundancia N+1 en fuentes de alimentación y a su vez que las mismas se encuentren conectadas a circuitos de UPS-online distintos.

5.6.2 Lineamientos de Servidores

Un punto importante a la hora de seleccionar y dimensionar el hardware es el uso de una plataforma de virtualización. Siendo que el uptime requerido implica la utilización casi obligada de dicha solución, se deberá utilizar hardware que se encuentre optimizado para ello y que a su vez cumpla con la certificación de compatibilidad del desarrollador de la plataforma de virtualización.





Para cumplir con los requerimientos de disponibilidad la solución de servidores a implementar deberá tener la mayor cantidad de componentes redundantes. En ningún momento deberá existir un único punto de falla, por ello todo equipamiento crítico deberá estar replicado y/o redundando dependiendo el caso.

En definitiva, se deberá cumplir con los siguientes puntos siempre que sea posible:

Los servidores deberán poseer fuentes de alimentación redundante (al menos N+1) conectadas a circuitos de alimentación independientes.

Los servidores deberán tener conexiones redundantes hacia los equipos de almacenamiento.

Los servidores deberán estar conectados a las redes a través de múltiples caminos.

Los equipos de comunicaciones deberán ser redundantes y estar correctamente configurados.

Se deberá implementar una solución de hardware en la que la prioridad sea la redundancia del equipamiento orientada a lograr el mayor uptime posible dentro del presupuesto asignado.

5.6.3 Lineamientos de almacenamiento

Las estructuras de intercambio de datos necesarias son muy extensas, complejas y orientadas a reportes. Las mismas pueden ser oscilografías, lista de eventos o archivos de configuración SCL y de las estructuras de datos de protecciones que son parte del SLRP.

Para estimar el espacio requerido para el almacenamiento se deberá partir de las estructuras de datos de protecciones. Estas están compuestas en forma genérica (No hay estándar que permita determinar este valor con exactitud) por las siguientes estructuras:

1) 20 kb de datos para transmitir la estructura completa SCL para la definición de datos de configuración de las protecciones. El valor se toma a partir del reporte “Common Format for IED Configuration Data del IEEE PSRC WG H5”.

2) 80 kb de datos para transmitir la estructura completa de oscilografías por perturbaciones en la red o por actuación de las protecciones. El valor se toma del cálculo de tamaño que tiene una Archivo COMTRADE configurado como se establece en el Anexo ¨Sistema de Monitoreo de la NT SyCS¨.





Valor Aproximado de Elementos del SLRP Indices

de Falla Fallas Año

Estimación de Equipos que ven la falla

Número de Oscilografías

por año SIC SING Totales Coefic. Cálculo

Líneas 127 67 194 1,1125 215,825 7,8 3 x (2,6Rz) 1683,435

Generadores 52 112 164 3,43 562,52 6,6 2Rg + 2,6Rz +

2Rt 3712,632

Transformadores 194 54 248 1,05625 261,95 7,2 2Rt + 2 x (2,6Rz) 1886,04

7282,107

Tabla 5.6. Estimación aproximada del número de eventos registrados por año en el SLRP.

Por otro lado y para poder determinar la capacidad de almacenamiento de los servidores se requiere conocer el número de eventos que se reportaran en el SLRP por año. Para ello se ha realizado una estimación de las fallas que podrían presentarse en el sistema en base a índices de falla de sistemas similares. Para ello se estudiaron estadísticas de fallas de líneas, transformadores y generadores del Sistema de Transmisión de la Región de Cuyo (a lo largo de 16 años). Se han elegido elementos del sistema similares a los que supervisará el SLRP, en cuanto a políticas de mantenimiento, zona climática o geográfica, y estado de carga, entre otras. Estos índices estadísticos se extienden a los sistemas SIC y SING. En la tabla 5.6 se muestran los resultados.

Para el cálculo se ha considerado lo siguiente:

Para fallas en líneas registran oscilografías:

2,6 protecciones de línea (promedio de relés por línea según Catastro SIC).

Protecciones de línea fallada más dos líneas adyacentes.

Para fallas en transformadores registran oscilografías:

Dos protecciones de transformador (principal y respaldo).

Protecciones de dos líneas adyacentes.

Para fallas en generadores registran oscilografías:





Dos protecciones de generador.

Dos protecciones de transformador.

Protecciones de una línea.

Del total de 100kb de almacenamiento estimado por protección, teniendo en cuenta la estimación de 10000 lecturas completas por cada año, resulta lo siguiente:

100[kbyte]*1024[bytes/kbyte]*10000[eventos/año]= 1024000000 bytes/años =

1024 Gbytes/año

Con un factor de seguridad de 10, que es lo típico para este tipo de estimaciones, se estima un requerimiento de capacidad de Almacenamiento (solamente para las bases de datos y sin tener en cuenta el resto de los sistemas del SLRP) de:

10TB/ año

Esta cantidad permitiría resguardar los datos de todas las protecciones por un año. Pasado ese tiempo, los datos más antiguos se irían reemplazando por los nuevos de manera de mantener el almacenamiento constante para las bases de datos de las protecciones.

La NT SyCS en su Anexo Técnico ¨Sistema de Monitoreo¨ es mandatoria respecto de las necesidades de resguardo de los datos del Módulo SGP de las protecciones del SLRP por 60 días en las instalaciones del CDEC. En cuanto al Módulo CRE el requisito es de 2 meses en las instalaciones de los CDEC y de 9 meses en las instalaciones de los Coordinados.

El valor de 10Tb de información que deberá ser almacenada al año es relativamente bajo. Por ello no se hace necesario recurrir a equipos de almacenamiento de gran envergadura.

Sin embargo debido a la criticidad de la información se recomienda la utilización de equipamiento de primera marca que cumpla con las siguientes características:

RAID 10 o RAID 5.

Almacenamiento de estado sólido SSD (ofrece mayor velocidad y confiabilidad).

Fuentes redundantes.

Tarjetas de comunicación redundantes (Fibre Channel o Ethernet).





A su vez dependiendo de los requerimientos de almacenamiento de largo plazo deberá implementarse una solución de cinta para el almacenamiento de ciertos eventos que requieren periodos de archivo estables superiores al año.

5.6.4 Lineamientos de Red

Una correcta organización en el esquema de comunicaciones implica mayor disponibilidad de las redes ya que simplifica su administración y evita problemas que suelen suceder por configuraciones incorrectas.

Se recomienda seguir los lineamientos de la RFC1918 y las mejores prácticas definidas por Cisco para el direccionamiento de redes privadas. En ellos se define un direccionamiento organizado con previsión de crecimiento y fácil implementación haciendo uso de CIDR y VLSM para optimizar el uso de direcciones disponibles.

A continuación se propone una implementación ejemplo, utilizando los lineamientos antes mencionados.

Se definen direcciones IP por región y luego se subdividen esas direcciones según cada sitio particular. De esta forma se comienza con 9 direcciones /15 para luego subdividirlos en unidades menores.

Ubicación Red Datacenter Principal 10.0.0.0/15 Disaster Recovery 10.2.0.0/15

Centro de Control y Despacho 10.4.0.0/15 Zona Norte Grande 10.10.0.0/15 Zona Centro Norte 10.20.0.0/15 Zona Centro Sur 10.30.0.0/15

Tabla 5.7. Esquema de Direccionamiento IP a nivel global para el SLRP.

Cada sitio se subdivide según sea conveniente, por ejemplo el datacenter principal utiliza la dirección 10.0.0.0/15, que permite contener más de 130.000 host. Para hacer un uso más eficiente de la misma





se la subdivide en subredes /24, que permite la creación de 512 subredes de 254 host cada una. Este rango de subredes permite gran segmentación de la red, limitando los horizontes de broadcast y mejorando el rendimiento y seguridad de la misma.

Utilizando la misma lógica se deberá definir el direccionamiento para el datacenter de Disaster Recovery y el centro de control. El esquema resultante para ambos sitios será muy similar al del datacenter principal.

Por otra parte se define el direccionamiento regional que consiste en subdividir las direcciones para cada LDC regional. Por ejemplo para la zona Norte Grande, se utiliza la dirección 10.10.0.0/15 que permite la creación de 128 subredes /22, es decir 128 sitios LDC. Cada sitio, puede a su vez ser subdividido en 8 subredes de 128 host, lo que permite la creación de distintas subredes para cada equipamiento en el sitio.

Locación VLAN Subred Servicio Comentarios

Datacenter Principal

10.0.0.0/15

Rango: 10.0.0.0/24- 10.1.255.0/24

100 10.0.0.0/24 Administración

Datacenter Controles de acceso, servers, UPS,

A.A.

102 10.0.2.0/24 Administración Comunicaciones

Red de administración (comunicaciones)

104 10.0.4.0/24 DC - Wired Data 108 10.0.8.0/24 DC - Wired Voice 110 10.0.10.0/24 DC - Wireless Data 114 10.0.14.0/24 DC - Wireless Voice 118 10.0.18.0/24 DC - Servidores 120 10.0.20.0/24 DC - WAN 200 10.0.200.0/24 Reservado N/D 10.1.255.0/24 Ultima subred para el rango

Tabla 5.8. Esquema de Direccionamiento IP a nivel datacenter para el SLRP.





Región Subdivisión

VLAN Subred Servicio Comentarios

Zona

Nor

te G

rand

e

10.1

0.0.

0/15

CLDP-1-1-SLRP

10.10.0.0/22 Rango: 10.10.0.0/22 - 10.10.3.128/22

N/A 10.10.0.0/25 Loopbacks

101 10.10.0.128/25 Administración CLDP -

1-1-SLRP Controles de acceso, servers, UPS,

comunicaciones 102 10.10.1.0/25 Wired Data 103 10.10.1.128/25 Wired Voice 104 10.10.2.0/25 Sensor Array 105 10.10.2.128/25 Actuator Array 106 10.10.3.0/25 Servidores 200 10.10.3.128/25 Reservado

CLDP -1-2-SLRP

10.10.4.0/22 Rango: 10.10.4.0/22 - 10.10.7.128/22

N/A 10.10.4.0/25 Loopbacks




CLDP -1-128-SLRP

10.11.252.0/22 Rango: 10.11.252.0/22 -

10.11.255.128/22

N/A 10.11.252.0/25 Loopbacks




Tabla 5.9. Esquema de Direccionamiento IP a nivel regional para el SLRP.





Zona Centro NorteIp Zonal: 10.20.0.0/15

Zona Centro SurIp Zonal: 10.30.0.0/15

Zona Norte GrandeIp ZONAL: 10.10.0.0/15

Datacenter Principal CDECRed 10.0.0.0/15

Centro de control y despachoRed 10.4.0.0/15

Datacenter Secundario – Disaster RecoveryRed 10.2.0.0/15

BD

CCDP (100)


10.20.0.0/25

Coord


10.20.4.0/25

Coord


Coord


10.30.0.0/25

Coord


10.30.4.0/25

Coord


Coord


10.10.0.0/25

Coord


10.10.4.0/25

Coord


Coord

SLRP

APLICAC SLRPSCADA/EMS

BD

CCDP (100)SLRP

Figura 5.1. Esquema Lógico de aplicación para la Red Global del SLRP.

5.6.5 Lineamientos de virtualización

En cuanto al requerimiento de alta disponibilidad necesaria es indispensable implementar una solución de virtualización de primer nivel.

La virtualización consiste en la creación a través de software de una versión virtual de algún recurso tecnológico, como puede ser una plataforma de hardware, un sistema operativo, un dispositivo de almacenamiento u otros recursos de red.





En definitiva lo que se realiza es la división de un recurso físico en uno o más entornos de ejecución. De esta manera un servidor que anteriormente ejecutaba un solo sistema operativo mediante la virtualización puede ejecutar múltiples sistemas operativos (Windows, Linux, OS X, entre otros), dentro de los cuales pueden ejecutarse a su vez múltiples aplicaciones.

Figura 5.2. Virtualización de Sistemas.

La virtualización de los servidores y aplicaciones permite la obtención de importantes ventajas:

Mejora la disponibilidad.

Facilita la administración.

Logra tolerancia a fallos y alta disponibilidad de manera independiente del sistema operativo y las aplicaciones.

Gana en abstracción del hardware.

Permite que aplicaciones antiguas puedan continuar funcionando en hardware reciente.

Facilita la recuperación en casos de falla total (Disaster Recovery).

Reduce costos de operación y mantenimiento.

Reduce requerimientos del hardware y optimiza recursos.

Simplifica la replicación de un datacenter en otro sitio.

Utilizando procedimientos de virtualización se puede prevenir de manera relativamente sencilla fallas en los servicios debido a problemas de hardware.





Por ejemplo implementando Fault Tolerance (FT), la falla de un servidor que se encuentra ejecutando aplicaciones críticas no tiene ningún impacto sobre las aplicaciones y/o usuarios ya que automáticamente retoma el funcionamiento en otro servidor. Todo ello de forma automática y transparente para las aplicaciones, usuarios y sistemas.

Esto es posible gracias a cierta tecnología de VMware que permite ejecutar dos máquinas virtuales iguales en dos servidores distintos perfectamente sincronizadas entre sí. Al fallar el servidor primario el supervisor se encarga automáticamente de que la máquina virtual que se encuentra “clonada” en el servidor secundario se haga cargo de las tareas que se estaban llevando a cabo en el servidor primario.

Figura 5.3. Servidores Virtuales Redundantes en esquema FT.

Para servicios que no son de tan elevada criticidad VMware ofrece una tecnología denominada High Availability (HA). Las máquinas virtuales configuradas en HA consumen menos recursos que las configuradas en FT ya que no se encuentran en ejecución en dos servidores al mismo tiempo. Con HA, al fallar un servidor sus máquinas virtuales configuradas, si están configuradas en HA, son iniciadas nuevamente en otro servidor. El downtime suele ser equivalente al necesario para que la máquina virtual inicie desde un estado de apagado no planificado (alrededor de 2 a 10 minutos).

En la figura 5.4 se pueden apreciar ambas tecnologías en acción. Las VMs configuradas en HA, al fallar el servidor principal, son reiniciadas en el secundario, mientras que la VM configurada en con FT, no tiene downtime y resume inmediatamente sus labores en el servidor secundarios.





Figura 5.4. Servidores Virtuales Redundantes en esquema HA.

Figura 5.5. Redundancia de Centro de Cómputos.

A su vez VMware permite la réplica completa de una infraestructura virtual en otro centro de cómputos. En este caso cuando el centro de cómputos principal sufre una falla catastrófica el centro de cómputos de réplica asume las funciones del principal sin necesidad de interacción humana y asegurando que los servicios provistos sigan disponibles.





De esta forma se puede tener una réplica de los servidores críticos en un datacenter de respaldo sin grandes costos, ya que al no estar en ejecución simultánea no se deben afrontar gastos de licenciamiento extras de aplicaciones de alta disponibilidad ni sistemas operativos.

En la figura que se muestra a continuación se pueden apreciar las siguientes aplicaciones virtualizadas y replicadas en los dos centros de cómputos.

Ruggedcom Crossbow Active Directory server (AD) Application virtualization Server

Figura 5.6. Redundancia de Storage.

Siendo que las aplicaciones del Centro de Cómputos principal se encuentran activas y las del centro de cómputos secundarios inactivas, ante una falla en el sitio principal, las máquinas virtuales alojadas en el centro de cómputos secundario asumen las tareas.

Implementar una solución de virtualización en un datacenter suele ser una tarea relativamente sencilla gracias a la existencia de herramientas de conversión. Estas herramientas convierten maquinas físicas en máquinas virtuales automáticamente sin grandes dificultades.





A modo de conclusión en las siguientes ilustraciones se puede apreciar la diferencia entre la implementación de una arquitectura tradicional y una virtualizada usando como ejemplo la plataforma Ruggedcom Crossbow.

En la arquitectura tradicional se requiere gran cantidad de servidores independientes, lo que implica mayores puntos de falla y elevados gastos de administración.

Figura 5.7. Ejemplo Crossbow SAM con virtualización.

Figura 5.8. Redundancia de Servidores. Ejemplo Crossbaw SAM.

Se puede apreciar que en la implementación de Ruggedcom Crossbow en plataforma virtualizada no se requiere gran cantidad de hardware. Además los equipos son capaces de funcionar en modo FT





por lo que en caso de falla del servidor principal, todas las aplicaciones siguen ejecutándose en el secundario sin downtime para los usuarios.

En definitiva las características de VMware mencionadas anteriormente hacen que sea indispensable su instalación e implementación en el Centro de Cómputos si se desea lograr un uptime superior al 99.7%.

5.7 Requerimientos para la Seguridad Informática

En el Anexo N°II del presente documento se presenta un estudio orientado a seguridad informática donde se trata la problemática, estándares y buenas prácticas en el tema.

A continuación se reescriben las acciones recomendadas para lograr cada uno de estos objetivos planteados en el Anexo

Riesgos Propuestas de mitigación

Accesos no autorizados a la red de

la S/E

Seguridad multicapa y segmentación de la red Firewalls y VPN´s UDP_S Deshabilitación de puertas y servicios no utilizados Accesos vía equipos de comunicación

Confidencialidad VPN o encriptación del enlace Integridad VPN o encriptación del enlace

Disponibilidad Exposición limitada de los enlaces de comunicación Estados y notificaciones en tiempo real Chequeos y validación de la disponibilidad

Tabla 5.10. Propuestas para la seguridad de la red del SLRP.

A continuación se resumen las medidas de seguridad específicas que deberá prever el SLRP:

Separación física de redes: Dentro de una instalación es normal que convivan equipos de uso corriente con acceso a internet, servidores con las aplicaciones SCADA y dispositivos





inteligentes, entre otros. En este ambiente colocar en distintas redes los equipos con diferentes funciones provee una medida de seguridad adicional, ya que no se puede acceder lo que no está conectado.

Bloqueo físico de conexiones: El bloqueo físico de los puertos de conexión libres y el aseguramiento de las conexiones existentes dificultan la capacidad de infiltración por parte de atacantes internos a las instalaciones. Adicionalmente es posible deshabilitar por software los conectores en desuso de los distintos switches, routers y demás equipos de la infraestructura de comunicaciones.

Uso de redes virtuales (VLAN): El uso de redes virtuales para la separación en grupos funcionales de los distintos dispositivos utilizados en una instalación eléctrica es una eficiente medida a la hora de reducir la vulnerabilidad a amenazas informáticas. El uso de VLAN permite imponer un control estricto sobre la comunicación entre dispositivos, dificultando gran variedad de ataques típicos que intentan explotar vulnerabilidades inundando la red con falsa información.

Gestión de usuarios: Es importante configurar usuarios y contraseñas únicos para cada dispositivo electrónico inteligente, y terminal remota que se encuentre dentro de una instalación eléctrica ya que esto minimiza el grado de exposición. Luego es posible brindar un control de acceso a los usuarios que lo requieran por medio de gateways encargados de establecer una conexión con propósitos administrativos entre usuarios autenticados y los distintos dispositivos. El control de acceso basado en roles (RBAC) es una capacidad que deben cumplir todos los equipos de la S/E con posibilidades de acceso remoto.

Encriptación de comunicaciones: Si bien la encriptación de las comunicaciones dentro de una instalación supone una carga excesiva y puede afectar las características de tiempo real de las mismas, esto no es cierto para todas las comunicaciones que se mantienen hacia afuera. Por lo tanto es de vital importancia el uso de conexiones encriptadas en las conexiones con instalaciones, centros de control, entes reguladores y cualquier otra comunicación de características similares.

Eliminar puertas traseras: Una práctica bastante común es el mantenimiento de conexiones secundarias, normalmente inseguras, para la tarea de soporte y actualización de equipos por parte del fabricante. Es sumamente prioritario eliminar este tipo de conexiones y reemplazarlas por el uso de permisos de acceso temporales garantizados exclusivamente en el momento que sean necesarios y revocados una vez que terminen las tareas a realizar.





5.8 Referencias

Estándar ANSI/TIA-942-A

Norma ICREA-STD-131-2015

RFC 1918

Cisco Addressing Guide Revisión: H1CY11

vSphere Availability Guide Revisión: 001435-01

ISO/IEC 27002:2005, Tecnología de la información - Técnicas de seguridad –

Código para la práctica de la gestión de la seguridad de la información

ISO/IEC 27032:2012, Information technology -- Security techniques -- Guidelines for cybersecurity

ISO/IEC 27033-5:2013, Information technology -- Security techniques -- Network security -- Part 5: Securing communications across networks using Virtual Private Networks (VPNs)

ISO/IEC 27035:2011, Information technology -- Security techniques -- Information security incident management

IEEE PSRC Subcommittee H9 Understanding Comm Tech for Protection -20130113 D8F





Capítulo 6. ESPECIFICACIONES MÍNIMAS REQUERIDAS PARA LOS EQUIPOS DEL SLRP PERTENECIENTES AL COORDINADO.

En esta sección, se resumen todas las características mínimas que deberá cumplir el Coordinado en sus instalaciones para incorporar los relés de protección de su propiedad al SLRP.

IED

Eventos a registrar

a) Cambio de parámetros / ajustes b) Activación / desactivación de la protección c) Cambio de estado del interruptor asociado d) Falla / Actuación de la protección e) Telecomandos.

Puerto Frontal Deberá tener un puerto USB o Ethernet RJ45 frontal para realizar ajustes y adquirir información localmente.

Puertos traseros Para acceso remoto, los relés deben tener dos puertos Ethernet configurables en forma independiente. La velocidad de transferencia de información deberá ser de 100 /1000 Mbps.

Redundancia Los puertos Ethernet deben soportar el protocolo de redundancia IEC 62439-3-Parallel Redundancy Protocol (PRP) o bien el protocolo RSTP IEEE 802.1w.

Sincronismo Mediante GPS. Se deberá utilizar una unidad de reloj externo con salida IRIG-B no modulada capaz de alimentar al menos 4 equipos.

Protocolos de comunicaciones

El protocolo de comunicación de los puertos traseros deberá ser IEC 61850. Se deberá permitir el acceso al relé para la descarga de todos los ajustes (protecciones y comunicación), y opcionalmente oscilogramas, eventos y fallas a través de protocolo FTP o variantes que permitan realizar lo mismo.

Seguridad informática

El relé deberá proporcionar niveles de seguridad tales como contraseña, autentificación y autorización, de tal forma que permita el acceso sólo al personal autorizado.





Alimentación El relé deberá soportar energía de alimentación universal CA (100-300) y CC (100-300) y doble fuente de alimentación.

Certificaciones El proveedor deberá demostrar cumplimiento de las certificaciones.

Concentrador Local

Gestión de reportes de

eventos

El Concentrador deberá: a) Gestionar conexiones a los diferentes IED b) Administrar de usuarios con capacidad de acceso basada en roles. c) Gestionar archivos COMTRADE. d) Soportar estándar de nombre completo.

Gestión de la información de las protecciones

El Concentrador deberá: a) Gestionar conexiones a los diferentes IED b) Administrar de usuarios con capacidad de acceso basada en roles. c) Interpretar archivos SCL dependientes de los distintos fabricantes.

Agragación y mez-clado de

reportes

El concentrador deberá poder ejecutar agregación y mezclado de datos de reportes provenientes de múltiples IED.

Sincronía El concentrador deberá poder realizar sincronización horaria mediante GPS a través del reloj externo con salida IRIG-B no modulada propuesto para los IED instalados en el mismo sitio que el propio concentrador.

Validación de Datos

El concentrador deberá soportar validación de datos. En este caso, el proveedor deberá indicar alcance y condiciones bajo las cuales se soporta la validación ofrecida.

Servidor de archivos

El concentrador deberá actuar como servidor de archivos de reportes, ajustes y otra información relativa a los relés de protección de importancia hacia el concentrador corporativo correspondiente.

Sistema de backup

Deberá incluir también, funciones de almacenamiento fuera de línea (backup) a los fines de cumplir la reglamentación vigente en cuanto a vigencia de disponibilidad de los reportes.





Protocolos y formatos

soportados

FTP IEC 61850 MMS Lenguaje de Configuración del Sistema COMTRADE

Otras características

a) El concentrador deberá soportar fuente de alimentación universal: AC (100-300) y CC (100-300)

b) El concentrador deberá proveer doble puerto de red Ethernet a los fines de poder conectarse a la red LAN en topología de anillo redundante.

c) El concentrador deberá contar con almacenamiento Hot Swap 2 x 3 Tbytes como mínimo.

d) El concentrador deberá utilizar preferentemente hardware virtualizado con procesador de 2 núcleos y 4 GB de RAM como mínimo.

Equipos de comunicaciones

Routers

a) Deberán contar con puertos 10/100/1000 Mbps (UTP) para conectarse a la red, en caso de 1000 Mbps tienen además puertas ópticas.

b) Deberán permitir agregar rutas a la tabla de ruteo en forma estática y dinámica (a través de algún protocolo de ruteo dinámico).

c) Deberán ser modulares y permitir agregar interfaces con puertas en switch de tal forma que en la red los dispositivos se puedan conectar directamente al router.

d) Encapsulación Ethernet 802.1q VLAN

Point-to-Point Protocol (PPP)

e) Manejo de tráfico QoS Class-Based Weighted Fair Queuing (CBWFQ) Weighted Random Early Detection (WRED) Hierarchical QoS Policy-Based Routing (PBR) Performance Routing (PfR)





Routers

Protocolos

IPv4: RFC 791 IPv6: RFC 2460 Static routes Open Shortest Path First (OSPF): RFC 1131 o Border Gateway

Protocol (BGP): RFC 1654 oBGP Router Reflector: RFC 1966 Intermediate System-to-Intermediate System (IS-IS) Multicast Internet Group Management Protocol (IGMPv3) Protocol Independent Multicast sparse mode (PIM SM) PIM Source Specific Multicast (SSM) Distance Vector Multicast Routing Protocol (DVMRP) IPSec Generic Routing Encapsulation (GRE): RFC 2784 Bi-Directional Forwarding Detection (BVD) IPv4-to-IPv6 Multicast MPLS L2TPv3: RFC 3931 IEEE 802.1ag

L2 and L3 VPN

Tabla 6.1 Resumen de Especificaciones mínimas para los equipos SLRP del Coordinado





Capítulo 7. IMPLEMENTACIÓN DEL SLRP

7.1 Introducción En este apartado se propone y conceptualiza una lista de pasos a seguir o un plan de trabajo para la implementación del Sistema de Lectura Remota de Protecciones que se especifica en este estudio. También se hace una estimación de la duración de cada tarea y la interrelación entre las mismas.

El apartado está enfocado en las actividades que deberá llevar a cabo el CDEC como realizador del proyecto del sistema central o ¨Módulo de Registro de Eventos¨, y por otra parte en las actividades como Coordinador en la integración de los proyectos asociados a los Coordinados.

A modo de ejemplo y con intención de obtener una perspectiva global del proyecto se incluye además un cronograma genérico con las actividades que este consultor prevé para que los Coordinados realicen sus proyectos.

7.2 Descripción de las tareas

En resumen se puede sintetizar el proyecto en cinco grandes grupos de tareas para la realización del proyecto:

I. Gestión del Proyecto: Comprende las tareas necesarias para planificar el proyecto (o terminar de planificarlo). Involucra todas las tareas necesarias para:

Organizar y administrar los recursos y establecer una estrategia para la realización de los proyectos de incumbencia CDEC, incumbencia Coordinados y la coordinación e integración entre los mismos.

Preparar y lanzar el proyecto a licitación para la implementación del proyecto CDEC, y asistir a la o las empresas interesadas para valorizar y delimitar sus soluciones.

Producir los documentos y realizar las gestiones para la realización de los proyectos de los Coordinados.





II. Ingeniería y Proyección del Proyecto: Comprende la realización de planos y documentos técnicos por parte de la o las empresas adjudicatarias del proyecto para especificar, construir y probar el SLRP. Se recomienda la participación en forma activa del CDEC en las etapas de ingeniería del proyecto, para garantizar que los documentos de ingeniería respondan a los requerimientos técnicos, y los sistemas finales sean construidos en virtud a la excelencia y el cumplimiento de las normas.

III. Adaptación/Construcción del Sistema: Implica para el CDEC la responsabilidad de auditar a la o las empresas adjudicatarias del proyecto ante la construcción y adaptación de los servicios existentes que comprenden del sistema central o concentrador de registros. Para el rol de auditoría se recomienda la contratación de empresas consultoras con especialidad en cada área y/o etapa de trabajo.

IV. Puesta en Marcha del Sistema: La puesta en marcha del sistema comprende para el CDEC la participación activa como auditores en las actividades que desarrollen las empresas contratistas en la integración y ensayos del sistema. Por otra parte, ejercer el rol de coordinador entre las partes en las actividades de interconexión e integración de los nodos de monitoreo al sistema central.

V. Recepción/Entrega del sistema: Comprende la entrega del sistema de la contratista al CDEC en las condiciones óptimas pactadas para su correcto funcionamiento y sin observaciones que apliquen a cambios, modificaciones o tareas pendientes en el proyecto. Por otro lado comprende las tareas complementarias de entrega de documentos CAO y Capacitación.

Las tareas más relevantes del plan de implementación se especifican en los siguientes apartados:

7.2.1 Establecimiento del plan de implementación del SLRP

El objetivo es estudiar, evaluar y definir un plan de implementación para la construcción del sistema, su prueba y puesta en servicio. Este punto comprende la evaluación del proyecto propiamente dicho, y todos los factores internos y externos que afectarán al mismo en forma directa e indirecta.

En el plan de implementación deben definirse los agentes implicados para la Implementación y Alcances para el SLRP. Esto compete definir con exactitud todos los agentes que participarán en el proyecto y su rol o actividad en el SLRP. En síntesis, deben seleccionarse/definirse:





Personas, Organismos o Empresas responsables de llevar a cabo cada etapa por parte de los CDEC: Oferta, Ejecución, Auditoría, etc. Junto a ello su alcance y responsabilidad.

Entes que tendrán acceso al sistema y su rol: jerarquías, niveles de acceso, funciones, etc.

Lugar de emplazamiento del sistema central y los centros de monitoreo, considerando condiciones de emplazamiento, localización, servicios, enlaces disponibles, etc.

Por otra parte deberá realizarse una estrategia a seguir para la implementación del SLRP. En este punto deben evaluarse o reevaluarse todos los factores internos y externos que tendrán influencia en el desarrollo del proyecto: los recursos necesarios financieros y de personal, el marco regulatorio, la asignación y delimitación de responsabilidades de cada una de las partes, los mecanismos de comunicación entre las mismas, la modalidad definitiva de adquisición, la oferta de empresas proveedoras de los sistemas, los cronogramas de trabajo, los proyectos de agenda, y las dependencias de cada elemento del sistema con otros proyectos que puedan condicionar o facilitar el plan de implementación, entre otros.

Después de este análisis se recomienda elaborar un documento que refleje este plan de implementación, una vez definidas todas las variables propias y ajenas que afectarán al proyecto. También se recomienda la elaboración de un cronograma tentativo para la implementación del SLRP, o el ajuste del que se propone en este estudio.

7.2.2 Delineamiento de los Proyectos de Coordinados

Este Estudio, más los eventuales requisitos adicionales que pueda tener el CDEC, entrega a los Coordinados las especificaciones técnicas o requisitos técnicos mínimos con que deben contar sus sistemas para que los nodos de adquisición de la información y los enlaces mantengan la compatibilidad con el centro de registro de eventos.

Junto a las especificaciones técnicas a entregar a los Coordinados deberá entregarse a los mismos toda la documentación con los requerimientos contractuales del proyecto. En estos documentos deben definirse los plazos, sistemas de multa, alcances y responsabilidades, entre otros factores que incumben a las partes en el proyecto. El documento de requerimientos contractuales deberá definir también un sistema de organización para establecer las fechas y los requerimientos de conexión e integración de cada Coordinado con el sistema central de monitoreo. Se propone establecer ventanas de tiempo y ponerlas a disposición de los Coordinados para que estos acuerden según su





disponibilidad sus turnos para conectarse al sistema central del CDEC. Si bien la interconexión e integración de los Coordinados con el sistema central es factible de realizarse aún después de estar en servicio el sistema integral (de hecho así se hará para incluir futuros puntos de monitoreo), se aconseja incluir a la mayor cantidad posible de nodos recolectores en el ensayo integral. De esta manera se tiende a evitar futuros inconvenientes por la intervención del sistema para incorporar nuevos puntos de acceso.

El CDEC permitirá la interoperación de Coordinados en nodos concentradores regionales. Esto es muy útil para facilitar la integración de Coordinados con pocos relés dentro del SLRP. De esta manera se reducen significativamente los costos de sus proyectos y se facilita la integración al módulo concentrador corporativo del CDEC, en especial se reducen significativamente los tiempos de integración.

7.2.3 Lanzamiento de Licitación para Implementación del SLRP

Este proceso comprende el lanzamiento de la licitación para implementación del sistema de lectura remota de protecciones según los términos de referencia del proyecto, en lo referente al sistema central a implementar por el CDEC. Para ello se utilizarán las especificaciones técnicas que se desarrollan en la etapa C de este estudio como modelo para que las empresas proveedoras de hardware y servicios evalúen sus propuestas.

El proyecto implica para el sistema SLRP la integración de recursos y servicios de distintas áreas o especialidades: sistemas de comunicaciones, sistemas de monitoreo, energía, montaje e interconexionado, ensayos, etc. Por esta razón se recomienda priorizar empresas que puedan comprobar experiencia en este tipo de proyectos integrados.

Por último, es muy importante resaltar la importancia del constante feedback con la o las empresas adjudicatarias de la construcción del sistema desde incluso esta etapa de oferta. Esto se hace importante fundamentalmente por que las soluciones actuales de monitoreo existentes en el mercado no están completamente enfocadas a la funcionalidad requerida para este sistema de monitoreo. Por lo que la solución definitiva puede requerir ajustes, desarrollos o actualizaciones por parte de los proveedores, especialmente los de software, en el caso que los CDEC opten por la compra de un sistema tipo ënlatado¨ y no por el desarrollo de un software propio a medida. Esto puede repercutir, al igual que en el punto anterior en el cronograma de ejecución en función a las posibilidades que presenten los desarrolladores de producto.





7.2.4 Desarrollo de Ingeniería Básica

La ingeniería básica es el primer hito de la empresa adjudicataria del proyecto por parte del CDEC. Comprende la realización de documentos técnicos que bosquejen conceptualmente el SLRP que se va a construir, y cierren los criterios de diseño que se darán como äbiertos¨ en la especificación técnica del Sistema. Entre ellos: diagramas de principio, requisitos técnicos, listado de documentos a entregar, arquitecturas de comunicación físicas, memorias técnicas de funcionamiento, ingeniería de integración, etc.

Previo a la ingeniería básica se recomienda una etapa de relevamiento en el lugar de emplazamiento de los equipos del centro de monitoreo para constatar todos los aspectos vinculados al traslado, montaje, instalación, interconexión y funcionamiento del SLRP: servicios auxiliares disponibles, servicios de comunicación, espacio físico para los equipos, traza de los conductores y enlaces, etc.

7.2.5 Desarrollo de Ingeniería de Detalle

Comprende el desarrollo de todos los documentos con el mayor grado de detalle para la construcción del sistema: arquitectura de comunicaciones definitivas, esquemas de distribución de SSAA, esquemas constructivos de gabinetes, planillas de alambrado, planos de distribución de equipos, protocolos de ensayo, lista de equipos y materiales, etc.

Además se deben realizar los documentos para el cumplimiento de otros planes y procedimientos que apliquen según el marco regulatorio: planes de calidad, gestión de medio ambiente, certificación de normas, procedimientos de seguridad, etc.

7.2.6 Ensayos FAT

Comprende las pruebas de fábrica o laboratorio de las partes del SLRP, pautadas de antemano con los CDEC en la ingeniería de detalle, y acordes a la ingeniería aprobada. Las pruebas deben garantizar al CDEC el correcto funcionamiento de las partes del sistema en criterios de seguridad eléctrica, seguridad informática, almacenamiento confiable, conectividad, compatibilidad, redundancias, funcionalidad, etc.





7.2.7 Montaje e Integración

Comprende el traslado en forma segura los equipos al lugar donde se emplazará el sistema central y al lugar o los lugares definidos como sitios de acceso al SLRP. Además comprende el montaje y conexionado de los equipos y los enlaces de comunicación y servicios auxiliares.

7.2.8 Integración de los Sistemas

Comprende la integración, configuración y ajuste de los equipos del sistema central para permitir la integración de los equipos físicos extremos de los enlaces de nodos adquisidores de los Coordinados.

7.2.9 Ensayos de Sitio Integrales

Comprende realizar los ensayos requeridos para comprobar el funcionamiento correcto del ¨sistema integrado¨ con las conexiones eléctricas y de comunicaciones dispuestas y conectadas en el lugar de emplazamiento.

7.2.10 Habilitación de los Sistemas

Comprende realizar todas las acciones para que el sistema quede en condiciones de ser operado correctamente a partir de ese momento. Además incluye las siguientes funciones complementarias.

Capacitación del Personal: comprende la realización de cursos de capacitación a operadores que entrarán en contacto con el sistema en funciones de monitoreo, análisis, mantenimiento y administración del sistema.

Entrega de Manuales: Comprende el desarrollo y entrega de manuales y procedimientos de operación y mantenimiento con instructivos para manejo de las funcionalidades más comunes, como así también los databooks que contienen toda la información de equipos y materiales del sistema provisto.

Entrega de Ingenierías y As Built: Comprende entrega de las ingenierías conforme a obra del sistema en las condiciones y formatos pactados.





7.2.11 Marcha Blanca

Dado que el SLRP no está reemplazando un sistema existente ni es un sistema de acción crítico como si lo es un automatismo de protección en área amplia (DAC o DAG), en principio no se justificaría un procedimiento de marcha blanca. No obstante, si bien el sistema no es crítico directamente, pueden ser considerables los efectos de las acciones que se desprenden de la interpretación de la información, tanto en aspectos técnicos como en administrativos y legales, entre otros.

Por este motivo, se aconseja llevar a cabo una marcha blanca en donde se contraste permanentemente la información que entrega el SLRP con el sistema actual de adquisición de oscilografías y ajustes vía plataforma web con que cuenta el CDEC.

7.3 Plazos

En esta sección se evalúa un plazo y cronograma tentativo para la realización del proyecto SLRP en función a la experiencia de este consultor en proyectos similares. En el Anexo IV se expone un diagrama de Gantt con los plazos estimados para cada actividad. La estimación supone:

Duración estimada del proyecto (Sin integración de Coordinados) de 193 días hábiles.

Duración estimada de tiempos de integración de Coordinados 140 días hábiles.

Duración de marcha blanca de 120 días hábiles.

Para la estimación del plazo total de integración de los Coordinados se han relevado los catastros entregados por el SIC y el SING. En las tablas que se muestran en capítulo 1 se resumen los equipos y Coordinados de cada zona, para ilustrar el peso de cada Coordinado en el SLRP y sus necesidades de recursos para la integración. No obstante, tanto el orden de los Coordinados como el tiempo que cada uno requiera para integrarse dependerán de los criterios de organización y acuerdos entre el CDEC y los Coordinados.

A modo de ejemplo se incluye en el Anexo IV un cronograma genérico con las actividades previstas para un Coordinado arbitrario. Se ha seleccionado el caso más crítico, es decir el primer Coordinado que se conecta al sistema, el cual posee el menor tiempo para realizar su proyecto.

Junto a este estudio se entregan los archivos de los proyectos compatibles a Microsoft Project, con los que se realizaron estas estimaciones.





ANEXO I

DESCRIPCIÓN DE ARCHIVOS COMTRADE





Desde la aceptación del estándar COMTRADE en 1991 (C37.111), sólo un pequeño número de usuarios tuvieron éxito al utilizar los datos digitales de una falla para analizar la respuesta de los relés a los disturbios del sistema de potencia. El uso de los archivos COMTRADE para las pruebas de protección se facilita en la medida en que el usuario final de dicha información comprende los formatos que se utilizan. También es importante en la medida que la nueva herramienta se encuentre disponible, tener la posibilidad de crear nuevos archivos, o bien de modificar uno ya existente a fin de realizar pruebas con los relés de protección

Hoy, el procedimiento normal que se utiliza para el uso de este tipo de reportes se describe a continuación:

El usuario instala un grabador digital de fallas (DFR: digital fault recorder) para capturar los eventos que ocurren en el sistema de potencia.

Los datos capturados son entonces utilizados para analizar dichos eventos.

Como resultado del análisis, el usuario puede hacer algún ajuste necesario a los parámetros del relé, interruptores o transformadores de potencia asociados.

Por otro lado, los datos capturados también pueden ser utilizados para el análisis de actuaciones o no actuaciones de los esquemas de protección vigentes.

En el pasado no era ni conveniente ni efectivo en costo la reproducción de los datos almacenados para evaluar el funcionamiento de las protecciones dentro de los esquemas de protección. El equipo de prueba y la programación necesaria era dominio únicamente del fabricante.

El usuario necesitaba solicitar al fabricante las pruebas, viajar hasta las instalaciones del proveedor y finalmente realizar la tarea. Dos factores evitaban que el usuario realizara las pruebas por él mismo. Primero el equipo de simulación disponible era complicado y demasiado costoso para los usuarios. El segundo factor era la falta de un acuerdo en cuanto al formato para el almacenamiento de datos.

Hoy COMTRADE es un estándar del IEEE lo suficientemente difundido al punto de ser de uso común y los instrumentos de prueba digitales basados en microprocesadores han llegado a ser costeables para los usuarios.

Estos instrumentos de prueba proveen al usuario de un medio cómodo para reproducir las señales a los relevadores, y también de suficiente potencia como para realizar las pruebas. Con el formato de





datos estándar y los instrumentos de prueba modernos, el usuario es ahora capaz de probar todo el esquema de protecciones de una instalación eléctrica, y con la reproducción de eventos del sistema de potencia en la ubicación que el usuario desee.

Pruebas transitorias: Las pruebas transitorias proveen una simulación con exactitud de los eventos del sistema de potencia. Es una poderosa herramienta que el usuario tiene para realizar una completa evaluación de la operación del esquema de protección.

Las pruebas transitorias pueden ser realizadas usando los datos creados por un programa de simulación de fenómenos eléctricos EMTP (Electro Magnetic Transients Program), datos grabados por los DFRs o bien grabados por DPRs.

Los dos últimos, tienen una vinculación con el SLRP del presente Estudio y sus reportes de oscilografías por eventos o por perturbaciones en la red, son recabados en forma automática por el sistema.

Las pruebas transitorias son utilizadas generalmente para:

Evaluar el esquema de funcionamiento o como una prueba de aplicación, para verificar el funcionamiento del esquema de protección bajo condiciones esperadas.

Analizar la operación o no operación del esquema de protección durante un disturbio del sistema de potencia.

Evaluar varias opciones del esquema de protección para seleccionar el esquema apropiado para una determinada aplicación.

Los archivos COMTRADE ayudan al usuario a realizar pruebas transitorias. Los equipos modernos DFR y las protecciones digitales pueden almacenar eventos del sistema de potencia en este formato. Además es posible crear archivos COMTRADE utilizando programas de simulación como EMTP y ATP.

Todos los instrumentos digitales de prueba son adecuados para reproducir eventos en el sistema de potencia. El formato COMTRADE es una colección de datos de un evento, almacenados a intervalos





regulares de tiempo, para definir las características de voltaje, corriente y el estado de los canales digitales antes, durante y después de un evento.

Estos archivos pueden ser reproducidos a través de instrumentos de prueba digitales, utilizando una computadora para fielmente reproducir los datos almacenados punto a punto.

Resumen del estándar COMTRADE

El estándar define un formato de archivo para almacenar las formas de onda, las entradas digitales de eventos y para describir los datos.

Un conjunto de archivos COMTRADE para un evento dado consiste de 3 archivos con las siguientes extensiones: El archivo *.DAT almacena los datos de la oscilogrfía. El archivo *.CFG almacena la configuración de la misma. Por último, el archivo *.HDR (opcional) es el archivo de cabecera del registro.

El archivo *.DAT es el archivo de datos el cual contiene las muestras de los eventos almacenados o simulados. Contiene muestras digitales de los valores instantáneos tanto de los canales analógicos como de los digitales. Los canales analógicos son generalmente voltajes y corrientes, mientras que los canales digitales son típicamente estados de los contactos del relevador. Los canales digitales tienen únicamente 2 estados: Activo ó Inactivo cada uno de los cuales es representado por “1” (activado) ó un “0” (desactivado).

La estructura del archivo de datos es una serie de filas y columnas, similar a una hoja de cálculo donde cada fila representa una muestra a un tiempo determinado. Por otro lado, e l número de columnas en el archivo de datos depende del número de canales analógicos y digitales incluidos en la grabación. El número de filas depende de la frecuencia de muestreo y de la longitud de la grabación.

El último valor almacenado de la última columna correspondiente a un canal muestreado, termina con un retorno de carro. Cada fila contiene una columna adicional para el número de muestra, el tiempo de inicio de la grabación en milisegundos y una columna para cada canal digital y análogo. Por ejemplo una fila con seis canales análogos y un canal digital tendrá nueve columnas. Las filas de muestras secuenciales están separadas por retorno de carro.

Un ejemplo para la versión ASCII del estándar, se muestra en la siguiente figura:





Figura AI.1. Ejemplo de archivo de Datos en Formato COMTRADE.

Los datos pueden ser almacenados ya sea en formato ASCII o binario. Los datos almacenados en formato ASCII le permiten al usuario ver y analizar los datos en un programa de cálculo de su elección. Un software de hoja de cálculo estándar, puede también ser usado para crear archivos de datos COMTRADE. Los archivos de datos binarios usan la misma estructura que los archivos ASCII. Cada muestra de datos almacenados en forma binaria es de la manera siguiente:

a) Número de la muestra: 4 bytes.

b) Tiempo de la muestra:4 bytes.

c) Canal de datos: 2 bytes (análogo).

d) Canal de datos: 2 bytes (valores de los estados de 16 entradas digitales en cada palabra de 16bits).

Los datos ASCII son legibles y un usuario o analista puede fácilmente visualizarlo utilizando un editor de texto cualquiera, tal como Notepad de Windows o un programa de cálculo como EXCEL.

El archivo .CFG actúa como la guía de traducción del archivo de datos. Contiene la información necesaria para representar el evento del sistema de potencia. Además, contiene la siguiente información:

a. Nombre de la estación e identificación.

b. Número total de canales analógicos.

c. Número total de canales digitales.





d. Nombre de la variable para cada canal análogo en líneas separadas.

e. Nombre de la variable para cada canal digital en líneas separadas.

f. Frecuencia de la Línea de Transmisión.

g. Frecuencia de muestreo y número de muestras.

h. Fecha y tiempo del primer punto de datos.

i. Fecha y hora del punto de disparo.

j. Tipo del archivo de datos (ASCII o binario).

Un archivo típico de configuración es como se muestra en la figura 4.2.

Los canales análogos contienen información tomando en cuenta la escala de los datos análogos. Para cada canal analógico se presenta la información siguiente:

a. Número de canal.

b. Nombre del canal.

c. Fase.

d. Circuito.

e. Unidades.

f. Escala (Factor "a").

g. Offset (Factor "b").

h. Asimetría.

i. Valor mínimo de los datos del canal.

j. Valor máximo de los datos del canal.

k. <CR/LF>

Los archivos de datos y los archivos de configuración son los archivos obligatorios. El archivo .HDR es opcional. El archivo de cabecera es un archivo de texto conteniendo información del evento que es almacenado en el archivo .DAT.





El archivo .HDR Puede contener información tal como las condiciones del sistema de potencia antes del disturbio, el nombre la estación, el nombre de la línea, la fuente de los datos, detalles del transformador, número de disquetes requeridos para la grabación, etc.

Figura AI.2. Ejemplo de archivo de Configuración en Formato COMTRADE.

Figura AII.3. Ejemplo de archivo de Configuración de Canal Análogo en archive CFG de Formato COMTRADE.





ANEXO II

SEGURIDAD EN LAS REDES





Problemática

Un grado de conectividad como el presentado en este capítulo favorece el intercambio de información y la operación en tiempo real del sistema, pero a la vez lo hace vulnerable a los diferentes tipos de amenazas informáticas. Esta clase de ataques tienen la capacidad de interrumpir el servicio, provocando un inmenso daño económico.

Por lo tanto, es preciso establecer la mejor manera de proteger los sistemas de información y los servicios de comunicación involucrados en el sistema eléctrico. Es decir, definir lineamientos y medidas concretas aplicables a las redes eléctricas.

Estándares internacionales de seguridad

El rápido crecimiento de sistemas de información interconectados a lo largo de grandes extensiones ha propiciado que las disciplinas de seguridad informática y seguridad de comunicaciones hayan surgido con numerosas organizaciones profesionales que comparten los objetivos de garantizar la seguridad y fiabilidad de los sistemas de información. Los principios básicos de la seguridad de la información se pueden resumir en los siguientes:

Confidencialidad de la información Integridad de los datos Disponibilidad

Debido a ello, y con el fin de poder garantizar estos principios básicos, las instituciones y los agentes de mercados involucrados en los diferentes procesos industriales han desarrollado distintos criterios para garantizar que el proceso de especificación, implementación y evaluación de un producto en cuanto a seguridad de la información y las comunicaciones que lleva asociado. Estos criterios vienen definidos de manera rigurosa dentro de estándares.

Los estándares de seguridad aseguran que los usuarios de equipos electrónicos y sistemas puedan especificar sus requisitos funcionales de seguridad y garantía. Al mismo tiempo permiten que los proveedores de estos equipos puedan implementar y hacer afirmaciones sobre los atributos de seguridad de sus productos, y los puedan ensayar en laboratorio a fin de determinar si efectivamente estos atributos se cumplen. El uso generalizado de Internet para la comunicación dentro de la toma de decisiones en tiempo real, el seguimiento de los procesos y el control de sistemas industriales





y de negocios, incluidas infraestructuras clave como las redes de energía, hace vulnerable sus distintos sistemas ante los ataques.

Por ello, la seguridad de los sistemas de control industriales deberá ser compatible con los requisitos de tiempo real de los propios sistemas. Desde finales del siglo pasado, muchas organizaciones industriales han iniciado la publicación de documentos de interés general para de seguridad informática.

A los fines de la presente especificación, se recogen las características de varios de los principales estándares en materia de seguridad para los sistemas de información y comunicación:

ISO 27000 [14] [15] [16] [17] [18] NIST 800-53[19] NERC CIP [20] ANSI/ISA 99 [21] and IEC 62443 [22] IEC 62351 [23] ISO 27002, 27032 y 27033

En general los procedimientos que dichas normas recomiendan seguir abarcan los siguientes aspectos:

Gestión de riesgos

Gestión de procesos

Seguridad de los sistemas de información

Seguridad de la infraestructura de red

Seguridad de datos

Auditoría de datos

Respuesta a incidentes

Continuidad de operaciones

Importancia de la Seguridad





Aunque el SLRP no es crítico para todos los sectores de la industria eléctrica, sus redes, que tienen alcance global podrían ser utilizadas en el futuro en aplicaciones de planificación, protección y control. El papel que entonces jugarían estos sistemas podría ser crítico para todos los actores del sistema eléctrico y particularmente para los operadores del mismo. Dado que las redes de comunicaciones no se implementan desde cero sino que existe una transición gradual sobre la base instalada con anterioridad, muchos de los nuevos proyectos de implementación deben utilizar los sistemas y la infraestructura existentes tanto como sea posible, maximizando el beneficio de dicha infraestructura. En consecuencia podría darse el caso en el que los sistemas que se están desarrollando en el presente, y que son declarados como no críticos, sean parte muy importante de los sistemas críticos del hacia el futuro.

Bajo este concepto es aconsejable tratar a este sistema como si fuera crítico desde el comienzo para evitar problemas posteriores en la implementación de las etapas de diseño relacionadas con la seguridad.

Aunque esto no significa que cada sistema necesita hoy ser clasificado como un activo crítico (desde el punto de vista de la seguridad) en términos de cumplimiento con los requerimientos normativos de seguridad (que Chile aún no posee; pero que en USA corresponden al Critical Infrastructure Protection (CIP), se recomienda aplicar estos requerimientos tanto como sea posible, en la medida que sea técnica y económicamente factible. Hacer esto hoy no solo reducirá el riesgo de tener vulnerabilidades en los sistemas críticos del futuro sino que también se facilitará el cumplimiento de los futuros requerimientos de seguridad cibernética.

Recomendaciones Generales

Algunas recomendaciones generales para el desarrollo del sistema de seguridad son las siguientes:

Desarrollar un conjunto de objetivos específicos de seguridad cibernética para la red SLRP del CDEC que sean aplicados a todos actores del sistema eléctrico.

Confección de guías de buenas prácticas de seguridad cibernética de redes SLRP y que sean desarrolladas a partir de los estándares ya existentes, de manera que simultáneamente se asegure la flexibilidad e interoperabilidad de las futuras arquitecturas de comunicaciones.





Los objetivos y requerimientos de seguridad cibernética necesitan ser definidos en un contexto global dado que se trata de una aplicación sobre sistemas “end-to-end” transversales a todos los actores del sistema y es necesaria la armonización de todas las normativas involucradas.

Se deberá tener en cuenta que una política de seguridad cibernética deberá poder extenderse más allá de la organización que la genere, sobre todo considerando que la información entregada por las redes SLRP deberían poder ser utilizadas por todos los actores del sistema eléctrico.

Las políticas de seguridad, de diseño, de implementación y de pruebas en redes SLRP, deben considerar y reconocer que hay diferencias con las metodologías que hoy aplican a infraestructuras de tecnología de la información.

Uno de los primeros pasos en el establecimiento de un plan de seguridad informática consiste en la identificación de las potenciales amenazas y riesgos dentro de los sistemas de la información involucrados. El siguiente cuadro, resume las principales vulnerabilidades presentes en la normal operación de un sistema eléctrico.

Dentro de las instalaciones

Algunos dispositivos utilizados en la normal operación de una S/E son de particular interés para un atacante informático; algunos objetivos estratégicos son los IED, las RTU y el SCADA.

Los DFR utilizan sistemas de posicionamiento global para sincronizar los reportes de eventos, ajustes y configuraciones. Estas señales pueden ser interferidas fácilmente. Si esto ocurre, entonces es probable que se genere un error en las estampas de tiempo de los datos. Una estampa de tiempo inválida provoca pérdida de datos.

Entre las instalaciones

Actualmente las comunicaciones entre instalaciones utilizan una amplia variedad de tecnologías que van desde el satélite hasta la fibra óptica con el propósito de integrar un número cada vez mayor de funciones y dispositivos entre dos o más puntos remotos. Por lo tanto, la interrupción de estas conexiones puede derivar en fallas en cascada por parte de los sistemas de la red eléctrica.





Entre el centro de control y la

S/E

Los centros de control se comunican con las distintas instalaciones para la operación normal del sistema interconectado. En la actualidad, dado que los centros de control no tienen la capacidad de lidiar con la creciente cantidad de información generada, se deberá hacer uso de equipamiento ubicado en las instalaciones de la S/E con dicho propósito; dicho canal de comunicaciones puede proveer de un medio adecuado para un ataque malicioso. Otro punto de particular interés es el canal de comunicaciones entre instalaciones y el ente regulador.

Entre el centro de control

principal y el secundario

Se suele hacer uso de centros de control secundarios como medida de seguridad adicional. Si bien esto es favorable para la seguridad operativa del sistema estos sitios comparten accesos a bases de datos y otras fuentes de información crítica. Adicionalmente este tipo de operaciones se suelen llevar a cabo a través de la red corporativa. Por lo tanto, si un atacante consiguiera vulnerar la seguridad de uno de los sitios, no le llevaría mucho tiempo más, ganar acceso al otro.

Tabla AII.1. Guía para la evaluación de riesgos en sitio.

Objetivos de la Seguridad

Los tres aspectos principales de los datos del SLRP que se requiere proteger son los siguientes:

Confidencialidad: se refiere a que los datos no pueden ser vistos por personas no autorizadas.

Integridad: se refiere a que el dato recibido es idéntico al que fue enviado por la fuente original.

Disponibilidad: se refiere a que los datos son medidos y despachados a los clientes que los requieren en forma oportuna y coherente.

El siguiente cuadro resume las acciones recomendadas para lograr cada uno de estos objetivos:





Riesgos Propuestas de mitigación

Accesos no autorizados a la red de la S/E

Seguridad multicapa y segmentación de la red Firewalls y VPN´s UDP_S Deshabilitación de puertas y servicios no utilizados Accesos vía equipos de comunicación

Confidencialidad VPN o encriptación del enlace Integridad VPN o encriptación del enlace

Disponibilidad Exposición limitada de los enlaces de comunicación Estados y notificaciones en tiempo real Chequeos y validación de la disponibilidad

Tabla A.II.2. Propuestas para la seguridad de la red del SLRP.

Medidas de seguridad específicas recomendadas

Una vez que se han establecido las amenazas más relevantes y trazado los objetivos de seguridad es posible identificar un conjunto de medidas concretas para asegurar los sistemas involucrados. A continuación se mencionan algunas de las medidas más relevantes a tener en consideración.

Separación física de redes: Dentro de una instalación es normal que convivan equipos de uso corriente con acceso a internet, servidores con las aplicaciones SCADA y dispositivos inteligentes, entre otros. En este ambiente colocar en distintas redes los equipos con diferentes funciones provee una medida de seguridad adicional, ya que no se puede acceder lo que no está conectado.

Bloqueo físico de conexiones: El bloqueo físico de los puertos de conexión libres y el aseguramiento de las conexiones existentes dificultan la capacidad de infiltración por parte de atacantes internos a las instalaciones. Adicionalmente es posible deshabilitar por software los conectores en desuso de los distintos switches, routers y demás equipos de la infraestructura de comunicaciones.

Uso de redes virtuales (VLAN): El uso de redes virtuales para la separación en grupos funcionales de los distintos dispositivos utilizados en una instalación eléctrica es una eficiente medida a la hora de reducir la vulnerabilidad a amenazas informáticas. El uso de VLAN





permite imponer un control estricto sobre la comunicación entre dispositivos, dificultando gran variedad de ataques típicos que intentan explotar vulnerabilidades inundando la red con falsa información.

Gestión de usuarios: Es importante configurar usuarios y contraseñas únicos para cada dispositivo electrónico inteligente, y terminal remota que se encuentre dentro de una instalación eléctrica ya que esto minimiza el grado de exposición. Luego es posible brindar un control de acceso a los usuarios que lo requieran por medio de gateways encargados de establecer una conexión con propósitos administrativos entre usuarios autenticados y los distintos dispositivos. El control de acceso basado en roles (RBAC) es una capacidad que deben cumplir todos los equipos de la S/E con posibilidades de acceso remoto.

Encriptación de comunicaciones: Si bien la encriptación de las comunicaciones dentro de una instalación supone una carga excesiva y puede afectar las características de tiempo real de las mismas, esto no es cierto para todas las comunicaciones que se mantienen hacia afuera. Por lo tanto es de vital importancia el uso de conexiones encriptadas en las conexiones con instalaciones, centros de control, entes reguladores y cualquier otra comunicación de características similares.

Eliminar puertas traseras: Una práctica bastante común es el mantenimiento de conexiones secundarias, normalmente inseguras, para la tarea de soporte y actualización de equipos por parte del fabricante. Es sumamente prioritario eliminar este tipo de conexiones y reemplazarlas por el uso de permisos de acceso temporales garantizados exclusivamente en el momento que sean necesarios y revocados una vez que terminen las tareas a realizar.





ANEXO III

TIPOS DE DATACENTER





En la norma ANSI/TIA-942 del Uptime Institute se definen 4 niveles de Centros de Cómputo categorizados según el uptime:

Tier I: Centro de datos básico – Uptime 99.671%

Un datacenter TIER I es una instalación que no tiene redundadas sus componentes vitales (climatización, suministro eléctrico) y que por tanto perderá su capacidad de operación ante el fallo de cualquiera de ellas.

Puede o no puede tener suelos elevados, generadores auxiliares o UPS.

Del mismo modo las operaciones de mantenimiento derivarán en tiempo de no disponibilidad de la infraestructura.

Tier II: Centro de datos redundante – Uptime 99.741%

Los datacenters de esta categoría tienen redundados sistemas vitales, como la refrigeración, pero cuentan con un único camino de suministro eléctrico.

Componentes redundantes (N+1) Tiene suelos elevados, generadores auxiliares o UPS. Conectados a una única línea de distribución eléctrica y de refrigeración. Se trata por tanto de instalaciones con cierto grado de tolerancia a fallos y que permiten algunas operaciones de mantenimiento “on line”.

Tier III: Centro de datos concurrentemente mantenibles – Uptime 99.982%

Un datacenter TIER III, además de cumplir los requisitos de TIER II, tiene niveles importantes de tolerancia a fallos al contar con todos los equipamientos básicos redundados incluido el suministro eléctrico, permitiéndose una configuración Activo / Pasivo.

Todos los servidores deben contar con doble fuente (idealmente) y en principio el datacenter no requiere paradas para operaciones de mantenimiento básicas. Componentes redundantes (N+1) Conectados múltiples líneas de distribución eléctrica y de refrigeración, pero únicamente con una activa.





Es requisito también que pueda realizar el upgrade a TIER IV sin interrupción de servicio.

Tier IV: Centro de datos tolerante a fallas – Uptime 99.995%

Esta es la clasificación más exigente en implica cumplir con los requisitos de TIER III además de soportar fallos en cualquier de sus componentes que inhabilite una línea (suministro, refrigeración).

Múltiples líneas de distribución eléctrica y de refrigeración conectados con múltiples componentes redundantes 2 (N+1). Lo que indica que se deberá contar 2 líneas de suministro eléctrico, cada una de ellos con redundancia N+1.

Tabla AIII.1 Comparación entre las diferentes categorías de Centros de Cómputo en cuanto a su implementación.





Tabla AIII.2. Comparación entre las diferentes categorías de Centros de Cómputo en cuanto a sus componentes.





ANEXO IV

PROGRAMA DE IMPLEMENTACIÓN DEL SLRP

Documents

SLRP-A Y B€¦ · DOC.N° SEIS EO Unificación Parte A y B para el CDEC 28/12/16 J.P.T. E.D. M.P. M.C. A.D. REVISION DESCRIPCIÓN FECHA REALIZÓ REALIZÓ REALIZÓ REVISÓ APROBÓ