estudio slrp documento unificado de: … · estudio de diseÑo, especificaciÓn y programa la...

Folha 1 de 228

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.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.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.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, ¨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¨. 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 ¨Estado 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.

https://scadahacker.com/library/Documents/ICS_Protocols/Rockwell%20-%20Enet%20Design%20Considerations%20for%20Control%20Systems%20(2007).pdf

http://www.cisco.com/c/en/us/td/docs/solutions/Verticals/EttF/EttFDIG.html

https://www.sans.org/reading-room/whitepapers/ICS/secure-architecture-industrial-control-systems-36327

https://cdn.selinc.com/assets/Literature/Publications/Technical%20Papers/6474_ApplicationEthernet_MR_20110201_Web.pdf?v=20150812-081851

https://cdn.selinc.com/assets/Literature/Publications/Technical%20Papers/6474_ApplicationEthernet_MR_20110201_Web.pdf?v=20150812-081851

http://cybertesis.urp.edu.pe/bitstream/urp/66/1/toscano_ma.pdf


http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/4022/Tesis.pdf?sequence=1


http://www02.abb.com/global/gad/gad02465.nsf/59bddcf5e4536d06c125778c0028fa3c/0bccb6b99be39eda83257a8b0056716c/$FILE/Process+Bus.pdf

http://www.elp.com/articles/powergrid_international/print/volume-16/issue-2/features/iec-61850-multivendor-substation-applications-whats-working-in-europe.html

http://www.elp.com/articles/powergrid_international/print/volume-16/issue-2/features/iec-61850-multivendor-substation-applications-whats-working-in-europe.html

https://library.e.abb.com/public/4107eafc615552c5c1257688003a068a/47-52%204M919_SPA_72dpi.pdf





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

https://es.wikipedia.org/wiki/Protocolos_de_red

https://es.wikipedia.org/wiki/Vinton_Cerf

https://es.wikipedia.org/wiki/Robert_E._Kahn

https://es.wikipedia.org/wiki/Robert_E._Kahn

https://es.wikipedia.org/wiki/Década_de_1970





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.

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

Mosqueda Gerardo.

http://www1.frm.utn.edu.ar/comunicaciones/modelo_osi.html

http://www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf

http://blyx.com/public/docs/pila_OSI.pdf

http://aceps.mines.edu/storage/presentations/2009_PSCE.pdf

http://aceps.mines.edu/storage/presentations/2009_PSCE.pdf

https://scadahacker.com/library/Documents/ICS_Protocols/ProSoft%20-%20Power%20Industry%20Comm%20Protocol%20Features%20and%20Benefits.pdf

http://www.axongroup.com.co/protocolo_modbus.php

http://www.axongroup.com.co/protocolo_dnp.php

http://www.axongroup.com.co/protocolo_61850.php

https://www.dnp.org/AboutUs/DNP3%20Primer%20Rev%20A.pdf

http://www.zenithtek.co.kr/data/IEC61850-TASE2-Seminar-Korea%20March%202006.pdf

http://www.gegridsolutions.com/multilin/journals/issues/spring09/iec61850.pdf

http://bibing.us.es/proyectos/abreproy/70641

http://bibing.us.es/proyectos/abreproy/70641









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.

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

Mosqueda Gerardo.

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.





https://cdn.selinc.com/assets/Literature/Product%20Literature/Data%20Sheets/351-567-PS_DS_20160715.pdf?v=20160815-104752

https://cdn.selinc.com/assets/Literature/Product%20Literature/Data%20Sheets/351A-PS_DS_20160715.pdf?v=20160815-104845

https://library.e.abb.com/public/4c1cd2b731aa42de8da94fc9a12b02e0/RTU500%20series%20catalog_2016_WEB2.pdf

http://www.vfservis.cz/files/000289_RTU560_Sales_Brochures.pdf

https://www.gegridsolutions.com/alstomenergy/grid/Global/Grid/Resources/Documents/Automation/Reason%20products/MU320-manual-en-epslanguage=en-GB.pdf

http://www.netcontrol.com/files/2614/0500/0098/M00277-BR-EN-4_Netcon_GW502-iM_Brochure.pdf

http://www.gegridsolutions.com/products/brochures/energy/d400.pdf





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.

http://arantxa.ii.uam.es/~jms/pfcsteleco/lecturas/20140526FernandoGarciaGutierrez.pdf

http://arantxa.ii.uam.es/~jms/pfcsteleco/lecturas/20140526FernandoGarciaGutierrez.pdf

http://digitalcommons.mtu.edu/etds/647/

http://www.cooperindustries.com/content/dam/public/powersystems/products/grid_automation/resources/Making_the_most_out_of_substation_IEDs.pdf

http://www.hirschmann.com/en/Hirschmann_Produkte/Industrial_Ethernet/news/Creating_an_effective_Substation_Automation_System_SAS_with_HirschmannuE2u84uA2/index.phtml

https://scadahacker.com/library/Documents/ICS_Vulnerabilities/EPRI%20-%20ICCP%20Protocol%20-%20Threats%20to%20Data%20Security%20and%20Potential%20Solutions.pdf

https://scadahacker.com/library/Documents/ICS_Vulnerabilities/EPRI%20-%20ICCP%20Protocol%20-%20Threats%20to%20Data%20Security%20and%20Potential%20Solutions.pdf

https://www.sans.org/reading-room/whitepapers/ICS/secure-architecture-industrial-control-systems-36327

http://www.ieee-pes.org/presentations/td2014/td2014p-000723.pdf

http://iectc57.ucaiug.org/wg15public/Public%20Documents/White%20Paper%20on%20Security%20Standards%20in%20IEC%20TC57.pdf





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.

http://new.abb.com/docs/librariesprovider101/default-document-library/1kha001069-sen-substation-automation-solutions-sas-600-series.pdf

https://library.e.abb.com/public/ced043fae5f1446e81830058b070f83f/ABB%20RTU560%20Fact%20Sheet_low%20res.pdf

http://www04.abb.com/global/seitp/seitp202.nsf/0/1254d81532cde6c1c1257d9400487c1f/$file/SDM600_salespresentation.pdf

https://library.e.abb.com/public/9e6d95db39c0e2a4c1257d650042933f/DMS600_System_Overview_757322_ENb.pdf

https://library.e.abb.com/public/4ed069f271cffb43c1257425003dc40f/DMS600_42_System%20Overview_755272_ENe.pdf

https://library.e.abb.com/public/bc7beb5bdf924b17a5341ee42692cb5b/2015-10-14-RTU560_SDM600_brochure.pdf

http://www.kalkitech.com/wp-content/files/AN_Transmission_Substation_Automation_Using_SYNC-3000_and_SYNC-2100.pdf

http://www.kalkitech.com/wp-content/files/CS_AMR%20for%20enabling%20Online%20Availability%20Based%20Tariff.pdf

http://www.kalkitech.com/wp-content/files/CS_AMR%20for%20enabling%20Online%20Availability%20Based%20Tariff.pdf

http://www.kalkitech.com/wp-content/files/CS_%20Enabling_Large-Scale_Substation_Automation_using_Kalkitech’s_DCU_SYNC%203000.pdf

http://www.kalkitech.com/wp-content/files/CS_%20Enabling_Large-Scale_Substation_Automation_using_Kalkitech’s_DCU_SYNC%203000.pdf

http://www.technolec.be/images/files/2010_substationautomation_casestudy.pdf





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 subfrecuencia

59N/64GN Sobretensión residual 21/21N/21T Distancia de fases y residual 27 subtensión

40/40G Sobrexcitación del generador 67/67N/67L Sobre corriente direccional de fases y residual ? señal específica

32/32R Potencia inversa 50/50BF Falla de interruptor

40/40G Pérdida de excitación 50/51/50N/51N Sobre corriente de fases y residual

46/47/60 Desbalance 59/27 Sobre tensión y baja tensión

49/49G Protección térmica del estator 68 Bloqueo antioscilaciones de potencia

21/21N Sobrecorriente falla a tierra o distancia residual 68 SOFT

21/21G Sobrecorriente de estator o distancia de fase

5959G Sobretensión

25/25S Pérdida de sincronismo

81/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)

http://sirep.cdec.cl/





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 ¨Estado 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

GB

GB

GB

GW/ Concentrador

de Datos

Ruggedcom RX1500

TI

TV

AN

ILLO

1 6

18

50

GO

OSE

/SV

/M

MS

AN

ILLO

2/M

MS/

MB

TCP

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.


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.


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 ZIV

Crossbow SAC/SAM/ELAN SYNC2000/4000/5000 Synchro WAVe / acSELerator Power System Server SGR

Gestión de la información de protecciones. Cumple Cumple Cumple Cumple Cumple

Gestión de reportes de eventos. Cumple Cumple Cumple Cumple Cumple

Gestion conexiones IED Cumple Cumple Cumple Cumple Cumple

Gestion de acceso basada en roles Cumple Cumple Cumple Cumple Cumple

Gestion de archivos COMTRADE Cumple Cumple Cumple Cumple Cumple

Soporte protocolos y formatos SLRP Cumple Cumple Cumple Cumple Cumple

FTP Cumple Cumple Cumple Cumple Cumple

IEC 61850 MMS Cumple Cumple Cumple Cumple Cumple

Lenguaje de Configuración del Sistema Cumple Cumple Cumple Cumple Cumple

COMTRADE Cumple Cumple Cumple Cumple Cumple

Agregación y mezclado de reportes. Cumple Cumple

Sincronía. Cumple

Validación de datos. Cumple Cumple Cumple

Virtualizable 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





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 =

3430 archivos oscilográficos por año por protección. Se requieren 100 kb para la transmisión

completa de la información de protecciones. Entonces utilizando la conocida fórmula bps = 1,2 (nn x

L 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*(100[kbytes]*1024[bytes/kbytes]*12[bits/byte]*[3,43 * 1000/(365 * 24 *3600 seg]) =

=160 bits/seg =20bps=0.02kbyte/s

0.02kbyte/s por protección considerando 1000 retransmisiones de los eventos repartidos durante el

año debido a la congestión de la red. Con un factor de seguridad de 2 que es lo usual en estos cálculos

debido a sobrecarga administrativa de los protocolos de red, se deberá reservar 0.04 kbps de ancho de

banda compartidos, no dedicados, en la red para la transmisión de datos relativos a las protecciones

eléctricas.

A los fines prácticos, se tomaran como válidos anchos de banda de la red del SLRP superiores a 0.1

kbps no dedicados por protección.





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í


dependientes de las condiciones

geográficas del enlace.

Enlace en la banda de

5.8 Ghz Sí Sí Sí


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

Nort

e G

rande

1

0.1

0.0

.0/1

5

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


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


1-2-SLRP


comunicaciones

102 10.10.5.0/25 Wired Data

103 10.10.5.128/25 Wired Voice

104 10.10.6.0/25 Sensor Array

105 10.10.6.128/25 Actuator Array

106 10.10.7.0/25 Servidores

200 10.10.8.128/25 Reservado

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


1-64-SLRP


comunicaciones

102 10.11.253.0/25 Wired Data

103 10.11.253.128/25 Wired Voice

104 10.11.254.0/25 Sensor Array

105 10.11.254.128/25 Actuator Array

106 10.11.255.0/25 Servidores

200 10.11.255.128/25 Reservado

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 ¨enlatado¨ 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 ¨abiertos¨ 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

Id Nombre de tarea Duración1 SLRP - CDEC 457 días

2 Gestación del Proyecto 52 días

3 Estudio y Desarrollo de Plan de Implementación 13 días

4 Finalización de Evaluación de Implementación 8 días

5 Desarrollo de Documentos de Implementación, Plan, Cronograma, Etc.

5 días

6 Lanzamiento del SLRP 5 días

7 Elaboración y Lanzamiento Doc. Contractual Coordinados 5 días

8 Lanzamiento de Licitación para Implementación CDEC 5 días

9 Proceso de Licitación del Proyecto CDEC 34 días

10 Plazo Realización de Ofertas y Rondas de Consulta 20 días

11 Análisis de Ofertas 10 días

12 Proceso de Adjudicación para Construcción del Sistema 4 días

13 Ingeniería y Proyección del SLRP 82 días

14 Inicio de Actividades 5 días

15 Revisión y Firma de Contratos 5 días

16 Reunión de Lanzamiento 1 día

17 Análisis de Proyectos 18 días

18 Levantamiento para Instalación en el CDEC 3 días

19 Análisis y Consultas de Proyectos de Coordinados 17 días

20 Reunión Post Levantamiento, Ajustes y Aclaraciones 1 día

21 Ingeniería Básica 32 días

22 Desarrollo de Ingeniería Básica y de Integración 24 días

23 Revisión, Reajuste y Aprobación de Ingeniería Básica e Integración

7 días

24 Reunión de Presentación de Ingeniería Básica 1 día

25 Ingeniería de Detalle 28 días

26 Desarrollo de Ingeniería de Detalle 20 días

27 Revisión, Reajuste y Aprobación de Ingeniería de Detalle 7 días

28 Reunión de Presentación de Ingeniería de Detalle 1 día

29 Construcción del SLRP 58 días

30 Compras y Abastecimiento 17 días

31 Realización de Procedimientos de Compras 5 días

32 Abastecimiento de Equipos, Software e Insumos 12 días

33 Integración y Ajuste 31 días

34 Construcción de Plataforma Datacenter y Centro de Monitoreo 17 días

35 Configuración de Equipos del Sistema 5 días

36 Ensayos FAT 6 días

37 Aprobación de Ensayos, Reunión pre Comisionado 3 días

38 Comisionamiento 173 días

39 Montaje e Interconexión 20 días

40 Transporte 2 días

41 Montaje de Tableros de Comunicación y Centro de Monitoreo 5 días

42 Montaje e Integración de Sistemas Auxiliares 9 días

43 Prueba y Energización de Sistemas 5 días

44 Integración de los Coordinados el SLRP 140 días

45 Cordinados en Orden a Definir 140 días

46 Ensayos SAT 13 días

47 Ensayo Integral del Sistema 10 días

48 Aprobación de Ensayos y Habilitación del Sistema 3 días

49 Entrega Sistema 120 días

50 Ajuste y Entrega de Manuales y Documentos CAO 5 días

51 Capacitación para Operación y Mantenimiento 10 días

52 Reunión de Cierre 1 día

53 Marcha Blanca 120 días

SLRP - CDEC

Gestación del Proyecto

Estudio y Desarrollo de Plan de Implementación

Finalización de Evaluación de Implementación

Desarrollo de Documentos de Implementación, Plan, Cronograma, Etc.

Lanzamiento del SLRP

Elaboración y Lanzamiento Doc. Contractual Coordinados

Lanzamiento de Licitación para Implementación CDEC

Proceso de Licitación del Proyecto CDEC

Plazo Realización de Ofertas y Rondas de Consulta

Análisis de Ofertas

Proceso de Adjudicación para Construcción del Sistema

Ingeniería y Proyección del SLRP

Inicio de Actividades

Revisión y Firma de Contratos

Reunión de Lanzamiento

Análisis de Proyectos

Levantamiento para Instalación en el CDEC

Análisis y Consultas de Proyectos de Coordinados

Reunión Post Levantamiento, Ajustes y Aclaraciones

Ingeniería Básica

Desarrollo de Ingeniería Básica y de Integración

Revisión, Reajuste y Aprobación de Ingeniería Básica e Integración

Reunión de Presentación de Ingeniería Básica

Ingeniería de Detalle

Desarrollo de Ingeniería de Detalle

Revisión, Reajuste y Aprobación de Ingeniería de Detalle

Reunión de Presentación de Ingeniería de Detalle

Construcción del SLRP

Compras y Abastecimiento

Realización de Procedimientos de Compras

Abastecimiento de Equipos, Software e Insumos

Integración y Ajuste

Construcción de Plataforma Datacenter y Centro de Monitoreo

Configuración de Equipos del Sistema

Ensayos FAT

Aprobación de Ensayos, Reunión pre Comisionado

Comisionamiento

Montaje e Interconexión

Transporte

Montaje de Tableros de Comunicación y Centro de Monitoreo

Montaje e Integración de Sistemas Auxiliares

Prueba y Energización de Sistemas

Integración de los Coordinados el SLRP

Cordinados en Orden a Definir

Ensayos SAT

Ensayo Integral del Sistema

Aprobación de Ensayos y Habilitación del Sistema

Entrega Sistema

Ajuste y Entrega de Manuales y Documentos CAO

Capacitación para Operación y Mantenimiento

Reunión de Cierre

Marcha Blanca

-9 -1 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240 248 256 264 272 280 288 296 304 312 320 328 336 344 352 360 368 376 384 392 400 408 416 424 432 440 448 456 464 472 480 488 496 504 512 520 528 536 544 552 560 568 576 584 592 600 608 616 624 632 640 648 656 664 672

Tarea ResumenProyecto: SLRP Rev B

Id Nombre de tarea Duración1 SLRP - COORDINADOS 457 días

2 Ajuste y Organización de Proyectos 60 días

3 Recepción de Documentación Contractual y Técnica del CDEC 22 días

4 Estudio de Factibilidad de Proyectos Propios 15 días

5 Reuniones, Consultas y Ajustes de Proyectos con CDEC y Otros Coordinados

12 días

6 Construcción de Sistemas Propios 124 días

7 Lanzamiento de Proyectos Propios 1 día

8 Ingeniería de Nuevas Implementaciones o Adaptación de Sistemas Existentes para el Cumplimiento del Proyecto

70 días

9 Compra y Abastecimiento de Equipos, Software e Insumos 15 días

10 Construcción y Configuración de Sistemas Integrales 17 días

11 Ensayos FAT Sistemas Integrales 3 días

12 Montaje e Interconexionado de Sistemas Locales 15 días

13 Ensayos SAT en Sistemas Locales 4 días

14 Integración al SLRP 140 días

15 Montaje e Interconexionado de Sistemas del Lado CDEC 3 días

16 Ensayos de Equipos del Lado CDEC y Enlaces de Comunicación 2 días

17 Pruebas Funcionales 2 días

18 Entrega de Documentación Técnica al CDEC 1 día

19 Integración del Resto de los Coordinados 135 días

20 Finalización del Proyecto 133 días

21 Ensayos Integrales y Entrega del Sistema 13 días

22 Marcha Blanca 120 días

SLRP - COORDINADOS

Ajuste y Organización de Proyectos

Recepción de Documentación Contractual y Técnica del CDEC

Estudio de Factibilidad de Proyectos Propios

Reuniones, Consultas y Ajustes de Proyectos con CDEC y Otros Coordinados

Construcción de Sistemas Propios

Lanzamiento de Proyectos Propios

Ingeniería de Nuevas Implementaciones o Adaptación de Sistemas Existentes para el Cumplimiento del Proyecto

Compra y Abastecimiento de Equipos, Software e Insumos

Construcción y Configuración de Sistemas Integrales

Ensayos FAT Sistemas Integrales

Montaje e Interconexionado de Sistemas Locales

Ensayos SAT en Sistemas Locales

Integración al SLRP

Montaje e Interconexionado de Sistemas del Lado CDEC

Ensayos de Equipos del Lado CDEC y Enlaces de Comunicación

Pruebas Funcionales

Entrega de Documentación Técnica al CDEC

Integración del Resto de los Coordinados

Finalización del Proyecto

Ensayos Integrales y Entrega del Sistema

Marcha Blanca

-9 -1 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240 248 256 264 272 280 288 296 304 312 320 328 336 344 352 360 368 376 384 392 400 408 416 424 432 440 448 456 464 472 480 488 496 504 512 520 528 536 544 552 560 568 576 584 592 600 608 616 624 632 640 648 656 664 672 680 688

Tarea Resumen

Página 1

Proyecto: SLRP Coordinados