Capitulo4
-
Upload
maylin-robaina -
Category
Documents
-
view
5 -
download
2
Transcript of Capitulo4
26
Capítulo 4
Desarrollo y Resultados del Plan de Trabajo
A continuación se presenta un compendio del protocolo IEC 61850 de
forma general y particular. Los tópicos particulares se seleccionaron debido a
su relevancia en las soluciones de ingeniería que ofrece la empresa PLC
Services S.A. Cabe destacar que dicho compendio de información fue
basado en su mayoría en el documento oficial del estándar IEC 61850
Paralelamente a ésta investigación sobre dicho protocolo, se
realizaron otras actividades durante el período de las pasantías, que
enriquecieron la experiencia socio-profesional, y en tal sentido, se desea
reportarlas. Éstas se incluyen en el Anexo E donde se describen y
especifican los productos obtenidos1”.
Siguiendo el procedimiento metodológico del capitulo tres para el
desarrollo de este proyecto, se comenzó por realizar una revisión general del
protocolo IEC 61850 con la finalidad de determinar los aspectos de interés
para su aplicación en sistemas de control numérico, obteniendo los
siguientes resultados.
4.1 Aspectos Generales del Protocolo IEC 61850
Las subestaciones eléctricas están mayormente automatizadas hoy en
día. Estos sistemas automatizados utilizan computadoras y equipos
1 Estas actividades se reportan en anexo y no en el cuerpo principal del informe por cuanto éstas no fueron formuladas dentro del plan de trabajo, sino que fueron surgiendo en la dinámica propia de la empresa.
27
electrónicos inteligentes para optimizar el funcionamiento de los equipos de
protección, con la mínima intervención humana.
Antes, los sistemas de automatización de subestaciones utilizaban un
conjunto de equipos donde cada uno de ellos cumplía funciones específicas.
Todos estos equipos se conectaban al IHM, donde normalmente no eran
capaces de inter-operar entre ellos, debido a que cada uno utilizaba
protocolos de comunicaciones diferentes, tales como: Modbus, DNP, LON
Profibus, entre otros. Todos estos incluso en una misma subestación
eléctrica. En la figura 1, se puede observar la situación que había antes de la
aparición del protocolo IEC 61850, donde entre otras cosas, los diferentes
protocolos podían ser utilizados para diferentes funciones dentro de la
subestación.
Figura: 1. Situación antes de IEC 61850. Fuente: IEC 61850 Short Tutorial, Klaus-Peter Brand
Nivel de Estación
Nivel de Bahía
Nivel de Proceso
28
Debido a esta falta de capacidad para comunicarse entre los
diferentes equipos en las subestaciones eléctricas, la mayoría de las
empresas fabricantes de equipos y prestadoras de servicio, reconocieron la
necesidad de un estándar unificado internacional que apoyara una
cooperación fluida entre los productos de diferentes empresas, este sería el
estándar IEC 61850.
El IEC 61850 es un estándar global para “redes y sistemas de
comunicaciones en subestaciones eléctricas”. Este describe: un protocolo de
comunicaciones (cliente/servidor y punto a punto); diseño y configuración de
las sub estaciones eléctricas; modelos representativos de los equipos de la
subestación; estándares ambientales, parámetros para la realización de
proyectos y procesos de comprobación para verificar que todo haya sido
configurado de manera correcta, entre otros aspectos. Fue publicado por
primera vez en el 2004, como una unión de elementos del Instituto Nacional
Estadounidense de Estándares (ANSI), y la Comisión Electrotécnica
Internacional (IEC) en Europa. Cabe acotar que entre los encargados de
realizar el IEC 61850, están los mayores proveedores de tecnología de
automatización de sub estaciones eléctricas en el mundo.
El objetivo del estándar es especificar los requisitos y la estructura para
lograr la interoperabilidad entre los equipos electrónicos inteligentes (IEDs)
de diferentes fabricantes.
El primer lanzamiento del estándar IEC 61850 consta de más de 1400
páginas, dividido en diez grandes secciones, donde las primeras tres
secciones proporcionan una idea general del protocolo. La sección cuatro
trata sobre los requisitos del proyecto y del sistema, mientras que la siguiente
sección habla de los requisitos para las comunicaciones de funciones y
29
modelos de equipos, de igual manera se presenta una sexta sección donde
se define un lenguaje basado en XML para la configuración de IEDs llamado
Lenguaje de Configuración de Subestaciones (SCL). La sección siete es el
alma del estándar, esta se subdivide a su vez en cuatro partes, estas son:
Principios y Modelos, Interfaz de Servicios de Comunicación Abstracta
(ACSI), Clases de Datos Comunes (CDC), Clases de Nodos Lógicos
Compatibles y Clases de Datos. Luego en la sección ocho habla acerca de
cómo asignar los objetos internos a la capa de presentación y a la capa de
enlace de datos. La novena sección describe la asignación de “Sampled
Measured Values” (SMV) a un esquema de comunicaciones Ethernet, para
así llegar a la ultima sección en donde se dan procedimientos para realizar
las pruebas de conformidad.
Los protocolos de comunicaciones usualmente han definido como se
deben transmitir los datos. Sin embargo no especificaban como debían ser
organizados los datos en los equipos. Es este precisamente el gran salto que
da el IEC 61850 con respecto a otros protocolos de comunicaciones. Además
de definir la forma en que se transmiten los datos, también suministra un
modelo exhaustivo de cómo los equipos utilizados en las subestaciones
deben organizar la información de tal manera que sea consistente a través
de todos los tipos y marcas de equipos.
El protocolo se ha ido implementando paulatinamente alrededor del
mundo desde su aparición. Una de las compañías fabricantes que se ha
identificado con este protocolo es General Electric, la cual ha hecho que sus
productos orientados al sector de subestaciones eléctricas sean compatibles
con el estándar. Según el documento “IEC 61850 Experience in Substation
Automation Projects” de General Electric Multilin (2006), General Electric ha
30
implementado el protocolo IEC 61850 en una variedad de proyectos
alrededor del mundo. Entre ellos tenemos:
• EDISON, Simeri Crichi, Calabria 2006, (Italia)
• Tennessee Valley Authority, TVA, Tennessee, (EEUU)
• Iberdrola, (España)
• CFE, (Mexico)
• Ethekwini Electricity, Durban, (Sudáfrica)
Cuando se diseña un sistema de automatización y control de una
subestación eléctrica, los objetivos principales son la confiabilidad, reducción
de costos y tiempo. Este nuevo sistema tiene múltiples ventajas sobre los
viejos sistemas de control con equipos electro mecánicos. La tecnología
disponible en la actualidad está basada en el uso de IEDs, que funcionan con
microprocesadores, facilitando las comunicaciones y permitiendo desarrollar
un nuevo concepto para los sistemas de control, protección y monitoreo en
una subestación eléctrica.
A continuación se compara en la tabla 1, ciertos aspectos del nuevo
estándar con otros protocolos anteriores.
31
Tabla 1. Comparación de algunos protocolos de comunicaciones. Fuente: Arthur Pereira Neto SIEMENS MERCOSUR
Una vez observada la situación que existía antes de la aparición del
protocolo IEC 61850, y su comparación con otros protocolos ya existentes,
se presenta la figura 2, donde se muestra la representación lógica de
comunicaciones del nuevo estándar. En este se busca que se hable el mismo
idioma (61850) en todas las áreas del proceso. Este modelo consta de dos
buses de datos, uno que enlaza a los equipos de nivel de subestación con
los de nivel de Bahía, llamado Bus de Subestación (Station bus). Por otro
lado se tiene un bus que comunica a los equipos de nivel de bahía con los
equipos de nivel de proceso, llamado Bus de Proceso (Process bus),
IEC 60870-5-
103
Profibus FMS
DNP V 3.0
Modbus UCA 2 IEC 61850
Capacidad de Indicación
Si Si Si Si, sin estampa
de tiempo.
Si Si
Capacidad de realizar
Comandos
Si Si Si, sin estampa
de tiempo
Si, sin estampa
de tiempo
Si Si
Valores medidos Si Si Si Si Si Si
Sincronización de tiempo*
Si Si Si No
Si Si
Certificado internacional de interoperabilidad
Si No
No
No
Si Si
Bus de Comunicaciones
del proceso
No
No
No
No
No
Si
Modo de comunicación
Maestro/ Esclavo
Maestro/ Esclavo
Maestro/ Esclavo
Maestro/ Esclavo
Orientado a eventos
Orientado a eventos
Velocidad de transmisión
(Mbit/s)
0.19 12 0.12 0.12 100 100si
32
Por ejemplo, el Bus de Subestación, es el que se encarga de
interconectar los IEDs que realizan la protección y control (nivel de bahía)
con el IHM (nivel de estación). Por otro lado, el Bus de Proceso es el que se
encarga de interconectar los medidores, sensores y demás equipos de
campo (Nivel de proceso) a los IEDs (nivel de bahía). Las características
específicas de estos buses variaran según la topología de construcción de la
subestación eléctrica.
Luego de realizar la revisión general del protocolo IEC 61850, se
determinaron los aspectos de interés para su aplicación en sistemas de
control numérico, y se señala en la sección 4.2-
Figura: 2. Esquema de comunicaciones usando IEC 61850. Fuente: IEC 61850 Short Tutorial, Klaus-Peter Brand
Nivel de Estación
Nivel de Bahía
Nivel de Proceso
Bus de Subestación
Bus de proceso
33
4.2 Aspectos Resaltantes del Protocolo
A continuación se mencionan ciertos aspectos que se consideraron
relevantes para el mejor entendimiento de esta norma, así como para la
implementación del protocolo por parte de la empresa.
4.2.1 Lenguaje de configuración de subestaciones (SCL).
Siendo, la estandarización de las comunicaciones entre los diferentes
equipos, el objetivo final de la norma, fue necesario que se estandarizaran
también los métodos que iban a describir las compatibilidades de
comunicación entre los IEDs. De esto se encarga el Lenguaje de
Configuración de Subestaciones (SCL). El lenguaje consta de la elaboración
de tres tipos de archivos, todos en formato XML. Estos son:
• Archivos ICD: archivo que describe el equipo.
• Archivos SSD: archivo que describe el sistema entero.
• Archivo SCD: archivo que describe la subestación completa
Este conjunto de archivos se utiliza para describir la configuración de
los equipos de una subestación. Por ejemplo, la información del diagrama
unifilar de una subestación se almacena en el archivo de “Descripción de las
Especificaciones del Sistema” (SSD). Por otro lado, cada dispositivo tiene un
archivo de descripción de compatibilidad (ICD), por último, la configuración
completa de la subestación se almacena en el archivo de “Descripción de la
Configuración de la Subestación” (SCD). El archivo SCD es la combinación
de los archivos ICD individuales y el archivo SSD.
34
4.2.2 Tipos de comunicaciones.
El estándar IEC 61850 define una estructura de comunicación
bastante elaborada, definiendo cinco tipos de comunicaciones como se
muestra en la figura 3.
Están:
• “Sampled measured value multicast” (SMV)
• “Generic object oriented substation event” (GOOSE)
• “Generic substation status event” (GSSE)
• “Time synchronization” (TimeSync)
• “Abstract communication service interface” (ACSI)
Figura: 3. Tipos de comunicaciones. Fuente: Liang & Campbell, Understanding and simulating the IEC 61850 standard
35
Los SMV o como también se le denomina SV “sampled values”, son la
forma de comunicación que se utiliza en el Bus de Proceso. Este tipo de
intercambio de datos se realiza entre los equipos de campo y los IEDs de
forma “multicast”. Como se puede apreciar en la figura anterior, este tipo de
mensaje solo lleva el encabezado de la capa de enlace de datos (no utiliza
direccionamiento IP). De esta manera el procesamiento de la información es
más rápido y por consecuencia su transmisión también lo es.
De acuerdo a Liang (2008) se extrae que estos mensajes rápidos
siguen siendo efectivos, a pesar de sus pocos elementos de confiabilidad. El
objetivo de este tipo de comunicación es el de enviar los datos leídos por los
medidores en campo a los IEDs a través de la tecnología Ethernet, para así
evitar las cientos de complicadas y obsoletas conexiones de cobre.
Los mensajes GOOSE quizás son los más nombrados al hablar del
protocolo IEC 61850. Al igual que los SMV, los mensajes GOOSE son una
forma rápida de intercambio de datos, ya que comunica a los diferentes IEDs
de forma punto a punto (P2P) enviando los datos de forma “multicast”. Esta
vez los datos se transmitirán a través del Bus de Subestación. Estos
mensajes cumplen una función parecida a la los SMV, y es que buscan
reemplazar la lógica convencional de conexiones de cobre (hardwired) en los
IEDs, o también llamados relés o equipos físicos (Physical Device, PD). La
cantidad de datos que serán generados luego de un evento dependerán de
la topología de la red, el número de IEDs y el tipo de evento. Por lo tanto los
mensajes GOOSE, tomando en cuenta las posibles colisiones de datos en
esta red, retransmite los datos varias veces.
36
Los mensajes GSSE son similares a los GOOSE, pero se diferencian
en el tipo de información que intercambian entre los IEDs. En el caso de los
mensajes GOOSE, estos pueden transmitir una gran cantidad de información
organizada, mientras que los mensajes GSSE solo pueden hacer uso de una
lista específica de estados de información. Dicha lista se limita a valores de
estado de información, por ejemplo: abierto, cerrado, en transición o estado
inválido.
Una vez explicados, los primeros tres tipos de comunicación que
posee este estándar, se consigue un cuarto, el de sincronización de tiempo
(TimeSync), el cual, se utiliza para sincronizar los tiempos de envió de
información. Dicho tipo de comunicación se realiza a través del Protocolo de
Datagrama de Usuario y del Protocolo de Internet (UDP/IP).
ACSI que significa “Interfaz para el servicio de comunicaciones
abstractas” es la interfaz principal de comunicaciones a través de la cual las
aplicaciones (por ejemplo, la Interfaz humano maquina) se comunican con
los IEDs, y donde se define la semántica del intercambio de información
entre ellos, por lo tanto es la mayor parte del estándar. A través de esta se
puede manipular y acceder a la información, por ejemplo, este tipo de
comunicación se puede hacer a través de una página web para acceder a la
información de un IED. En el caso de General Electric y sus relés de la serie
UR, se accede a la información y programación a través del programa
Enervista UR Setup.
37
4.2.3 Comunicación entre IEDs.
En la norma todo el sistema de la subestación esta modelado como un
sistema distribuido, que consiste en la interacción de nodos lógicos. Se
entiende por nodo lógico la parte más pequeña de una función que
intercambia información entre IEDs, definiéndose en él sus datos y atributos.
En la figura 4 se puede visualizar mejor la idea. Las funciones (F)
contienen uno o más equipos físico (PD), los cuales a su vez contienen
nodos lógicos (LN). Los nodos lógicos están enlazados por las conexiones
lógicas (LC). Cuando se habla de conexiones lógicas se está hablando del
concepto lógico de conexión entre dos nodos lógicos, las cuales pueden ser
directas, indirectas o incluso una combinación de varios canales de
comunicación. Es decir, estas conexiones lógicas son parte de las
conexiones físicas (PC) entre los equipos físicos (PD)
Es muy importante especificar y estandarizar las interacciones entre
los diferentes nodos lógicos de una manera genérica, ya que es imposible
definir todas las funciones que se utilicen y que se utilizaran en un futuro.
Figura: 4. Comunicación entre IEDs. Fuente: IEC 61850-5
38
4.2.4 Interoperabilidad.
Es la capacidad de dos o más IEDs del mismo, o distinto fabricante,
de cruzar información y utilizar esa información para la correcta operación y
funcionamiento de una subestación eléctrica.
Los nodos lógicos y los datos contenidos en los equipos lógicos son
cruciales para la descripción e intercambio de información para los sistemas
de automatización de las subestaciones eléctricas, todo esto para así
conseguir la interoperabilidad.
Para la interoperabilidad es necesario:
• Lenguaje (modelo de datos)
• Servicios (modelo de servicios)
• Protocolos
Cabe destacar que en este trabajo se abordó y explicó, los modelos de
datos y servicios, los cuales se abordaran en las siguientes secciones.
4.2.5 Estructura jerárquica del modelo de datos.
El protocolo de comunicaciones IEC 61850 describe un modelo
jerárquico complejo, que se puede observar en la figura 5. Un dispositivo
físico puede contener uno o más dispositivos lógicos (LD). Cada dispositivo
lógico puede contener varios nodos lógicos (LN). A su vez, cada nodo lógico
puede contender varios Objetos de Datos o “Data (Object)”. Cada “Data
(Object)” está compuesto por atributos de datos, y por componentes de los
39
atributos de datos. Los servicios están disponibles en cada nivel para realizar
diferentes funciones, tales como: lectura, escritura, comandos de control y
reportes.
El nivel más alto de esta estructura jerárquica es el equipo físico (IED)
o también definido como servidor. Teóricamente un IED puede contener
varios servidores, pero en la práctica usualmente contiene uno solo. Cuando
se habla de servidor, se refiere básicamente al programa que corre en cada
IED, este sirve de unión entre el equipo físico y los dispositivos lógicos.
Luego se tienen los dispositivos lógicos (LD), que básicamente son un
grupo de nodos lógicos realizando funciones similares
Figura: 5. Estructura jerárquica. Fuente: Germán Pugliese, IEC 61850 el estándar de integración eléctrica del futuro
40
Por otra parte, las funciones o equipos utilizados en sistemas de
potencia están representados conceptualmente por nodos lógicos (LN). Estos
pueden estar ubicados en uno o más equipos físicos Cada nodo lógico está
organizado de una manera estandarizada y de ser necesario se pueden
crean nuevos LN de acuerdo a las reglas definidas en el estándar.
Dolazilec (2005) describe que:
Un nodo lógico es una colección de “data objects”, “data set objects”, atributos descriptivos, objetos de control de reportes, objetos de control de registros y una lista de valores de muestreo que definen los límites de una entidad y su estado y comportamiento. (p.5)
El intercambio de datos entre los nodos lógicos esta modelado como
un “Data (Object)”. Cada “Data (Object)” es una instancia de una clase de
datos. Los “Data (Objects)” consisten de varios atributos de datos, que son a
su vez instancias de sus correspondientes clases de datos
Los atributos de datos también tienen la propiedad de caracterizar o
delimitar su uso específico a través de las Limitaciones Funcionales
(Functional Constraints, FC), estas juegan un papel crucial en la definición de
los modelos de información, y en los servicios de acceso a las varias partes
del modelo de información. En vez de agrupar los atributos de datos por
“Data (Objects)” las FC suministran una manera de organizar todos los
atributos según los distintos servicios que esta puede realizar, por ejemplo:
leer, escribir y sustituir un valor.
Estos atributos de datos son tan importantes como los “Data
(Objects)” o quizás hasta más, debido a que los “Data (Objects)” son solo
colecciones de atributos de datos mientras que los atributos de datos son
41
correspondencia directa lógica del mundo físico. Los “Data (Objects)” son
una manera conveniente de manejar e intercambiar los valores de los
atributos de datos de una misma función.
Aparte de los “Data (Objects)”, el estándar provee el concepto de
“Data Set”, como otra manera de manejar e intercambiar atributos de dato.
Los valores o estados incluidos en un “Data set” no necesariamente vienen
de un mismo nodo lógico o del mismo “Data (Object)”, esto hace que la
información sea manejada de una manera más flexible.
Los “Data Set” se clasifican en permanentes y no permanentes, los
permanentes residen en los nodos lógicos y no serán borrados
automáticamente a menos que el cliente lo desee explícitamente. Los no
permanentes a diferencia de los otros residen exclusivamente en las
asociaciones creadas, y serán borrados automáticamente cuando la
asociación termine.
4.2.6 Referenciando Instancias.
Con el fin de alcanzar los objetivos de estandarización e
interoperabilidad, la norma propone un sistema estructurado de cómo deben
ser nombrados y/o referenciados sus objetos de datos o “Data (Objects)” y
atributos. Por atributo se entiende, un elemento de información nombrado de
un tipo específico.
Para empezar, el estándar diferencia entre los nombres de objetos y
las referencias de objetos (Entendiéndose objeto, como la instancia de una
clase cualquiera). Los nombres de objetos identifican una instancia de una
clase en un nivel jerárquico. Por ejemplo, “Mod” en el nivel de “Data (Objects)
42
o “Q0XCBR1” en el nivel de nodo lógico. “Q0” es un prefijo y el “1” es un
sufijo del nombre “XCBR”. La norma IEC 61850 clasifica los nodos lógicos en
grupos según su función como se muestra en la tabla 2. La primera letra de
cada nombre de nodo lógico indica a que grupo pertenece, en el caso de
“XCBR” la “X” significa que es un equipo de conmutación, mientras que
“CBR” es el nombre que le da el protocolo a un interruptor (Circuit Breaker).
Luego de haber explicado la raíz de cada una de las partes de los nombres
de los objetos, se puede decir que concatenación de todos los nombres de
objetos forman la referencia de objeto, por ejemplo:
“MyLD/Q0XCBR1.Mode.stVal”
43
Tabla 2. Lista de nodos lógicos. INDICADOR GRUPOS DE NODOS LOGICOS CANTIDAD
L Nodo lógico del sistema 3
P Funciones de Protección 28
R Funciones Relacionadas con Protección 10
C Control Supervisor 5
G Referencias de Funciones Generales 3
I Interfaz e Archivado 4
A Control Automático 4
M Medición y Medida 8
S Sensores y Monitoreo 4
X Equipo de Conmutación 2
T Instrumento Transformador 2
Y Transformador de Potencia 4
Z Equipos Futuros (equipo de potencia) 15
TOTAL de Nodos Lógicos 92
Ahora bien, la referencia de un atributo de dato identifica un atributo
de dato específico de una instancia de datos, evitando que haya confusiones
si se presentara el caso de que dos atributos tengan el mismo nombre, pero
se refieran a dos entidades distintas.
44
Como se vió anteriormente, el nombre de nodo lógico “XCBR” puede
ser prolongado por un prefijo, (por ejemplo “Q0”), y un sufijo (por ejemplo “1”)
para construir el nombre del nodo lógico (“Q0XCBR1”). La estandarización de
la sintaxis de los prefijos y sufijos está fuera del alcance del estándar IEC
61850. Por otro lado, no son permitidos los sufijos y prefijos para los nombres
de dato y atributo de dato, que no sean otros que los que están definidos en
IEC 61850-7-4.
Esta forma de referenciar las instancias en el IEC 61850, sustituye el
antiguo método de “mapping” que utilizaban otros protocolos de
comunicaciones como son: DNP y MODBUS. Este método consistía en
grandes tablas donde se relacionaban las variables del proceso con
direcciones numéricas
A continuación se puede observar un ejemplo (Figura 6) de los
nombres de objetos y sus referencias. En la imagen se puede detallar la
forma ordenada con que primero se nombra el dispositivo lógico (LD)
“MyLD”; luego el nombre del nodo lógico (LN) “Q0XCBR1”, posteriormente el
nombre del dato “Mod” y por ultimo el nombre del atributo de dato “stVal”,
Figura: 6. Ejemplo de referencias. Fuente: Estándar IEC 61850-7-1
45
4.3 Modelos de Datos
4.3.1 Clases de datos comunes (Common data classes).
Las clases de datos comunes son un medio útil para reducir el tamaño
de las definiciones de datos en el estándar. La definición de datos no
necesita enumerar todos los atributos, solo necesita hacer referencia a la
clase de datos común. Las clases de datos comunes son también muy útiles
para mantener las definiciones de los atributos de datos coherentes.
Por ejemplo, la información con respecto a la posición (Pos) tiene gran
cantidad de atributos de datos que se pueden encontrar en muchas otras
aplicaciones específicas de conmutación. Dichos atributos representan
cuatro estados: estado intermedio, apagado, encendido e inválido, estos
cuatro estados (representados por lo general con dos bits) son comúnmente
conocidos como "doble punto” de información. El conjunto de todos los
atributos de datos definidos para “Pos” es una clase de dato común llamada
doble punto controlables (DPC).
IEC 61850-7-3 define las clases de datos comunes para una amplia
gama de aplicaciones conocidas. El núcleo común de clases de datos se
clasifica en los siguientes grupos:
• Información de estado
• Información medida
• Información sobre estados controlables
• Información analógica controlable
• Configuración de estados
46
• Configuración analógica
• Información de descripción
4.3.2 Objeto de datos “Data (Objects)”
Para poder exponer de una manera clara y sencilla los objetos de
datos a los cuales hace referencia el protocolo IEC-61850, a continuación se
muestra en la figura 7 un ejemplo del modelo de estructura jerárquica de un
objeto y sus interrelaciones con los nodos lógicos y sus atributos de datos.
En este caso se tomará el objeto de dato “Posición” (Pos) del nodo lógico
“XCBR”
Figura: 7. Estructura jerárquica del nodo lógico XCBR. Fuente: Estándar IEC 61850-7-1
47
El objeto “Pos” es más que un simple valor, está constituido por varios
atributos de objeto que a su vez están clasificados de la siguiente manera:
• Control (estados, valores medidos, configuración)
• Estado.
• Substitución.
• Configuración, descripción y extensión.
•
El objeto “Pos” tiene aproximadamente 20 atributos. Por ejemplo el
atributo “Pos.ctVal”, representa la información controlable (puede activarse o
desactivarse). Por otro lado, el atributo “Pos.stVal” representa la posición real
del interruptor (puede estar: cerrado, abierto, intermedio, o estado invalido),
cabe destacar, que este tipo de atributo no puede ser manipulado por el
operador.
“Pos” también tiene atributos que indican cuándo se debe procesar el
comando de control (tiempo de operación), la acción que originó el comando,
el numero de control, la calidad y la información de la etiqueta de tiempo; que
indican la validez actual del valor del estado y el tiempo de la última
modificación del valor de su estado.
4.3.3 Modelo de clase del nodo lógico.
A continuación se describirán algunas de las características que deben
tener los nodos lógicos del protocolo IEC 61850. Cada uno de ellos deben
contener una composición de información, Data Set, BRCB, URCB, LOG,
SGCB, GoCB, GsCB, MSVCB y USVCB, que se explicaran a continuación.
48
Los atributos de la clase de nodo lógico son:
• LNNAME: (nombre del nodo lógico) Identifica los nodos lógicos de una
manera precisa dentro del alcance de un dispositivo lógico.
• LNRef: (referencia de objeto del nodo lógico) Es la única ruta en el
nombre del nodo lógico. Por ejemplo la referencia de objeto de LNRef
debería ser:
• Data: (Información) Identifica la información contenida en el nodo
lógico.
• DataSet: (grupo de información) Se refiere a un Data Set que este
contenido en un nodo lógico.
• BufferedReportControlBlock: (bloque de control de reportes con
“buffer”) que este contenido en el nodo lógico.
• UnbufferedReportControlBlock: un URCB (bloque de control de
reportes sin “buffer”) que este contenido en un nodo lógico.
• LogControlBlock: Identificara un LCB (bloque de control de registros)
contenido en el nodo lógico.
LDName/LNName
49
• SettingGourpControlBlock: Este atributo deberá identificar el SGCB
(bloque de control de configuración de grupos) que este contenido en
el nodo lógico cero (LLN0)
• Log: Este atributo se refiere al LOG (registro) que este contenido en el
LLN0.
• GOOSEControlBlock: Este atributo identifica un GoCB (bloque de
control GOSSE) que este contenido en el LLN0.
• GSSEControlBlock: Este atributo identifica un GsCB (bloque de control
GSSE) que este contenido en el LLN0.
• MulticastSampledValueControlBlock: Este atributo se refiere a un
MSVCB (bloque de control de valores de muestra multicast) contenido
en un LLN0.
• Unicast SampledValueControlBlock: Este atributo deberá identificar un
USVCB (bloque de control de valores muestreados unicast) contenido
en el LLNO.
4.3.4 Servicios de clase de nodo lógico.
Para los nodos lógicos fueron definidos los siguientes servicios:
• GetLogicalNodeDirectory: Un cliente podrá utilizar el servicio para
obtener o recuperar una lista de las referencias de objeto de todas las
instancias de una clase solicitada hecha visible y por lo tanto accesible
50
para el cliente. Para hacer uso de este servicio se deben tomar en
cuenta los siguientes parámetros:
LNReference: Debe contener la referencia de objeto LNRef del nodo
lógico.
ACSIClass: Este parámetro debe contener el modelo de clase ACSI
seleccionado para el cual las referencias de objetos de todos los
modelos de clase ACSI deben ser retornados. En este caso el cliente
debe seleccionar uno de los siguientes modelos de clase ACSI: DATA,
DATA-SET, BRCB, URCB, LCB, LOG, SGCB, GoCB, GsCB, MSVCB
Y USVCB.
Response+: Este parámetro indica que la solicitud de servicio se ha
logrado. De haberse logrado de manera satisfactoria, el resultado
deberá regresar el parámetro “InstanceName”. Este debe contener un
nombre de objeto de un modelo de clase ACSI solicitado. En el caso
que el nodo lógico al cual se hace referencia no contenga la clase
ACSI solicitada, el servidor deberá indicar que no existe un modelo de
clase ACSI en el nodo lógico.
Response- : Este parámetro debe indicar que la solicitud de servicio
fallo devolviendo un “error de servicio”.
• GetAlldataValues: Un cliente podrá usar este servicio para recuperar
todos los valores de los atributos de datos (que tengan la misma FC)
de toda la información hecha visible y por lo tanto accesible para el
cliente del nodo lógico referenciado. De igual forma que en el servicio
51
anteriormente explicado se deben tomar en cuenta los siguientes
parámetros:
LNReference: Este parámetro debe contener la referencia de objeto
LNRef del nodo lógico.
FunctionalConstraint: Este debe contener el parámetro de la limitación
funcional (FC) para filtrar los respectivos atributos de dato de todos los
datos contenidos en el nodo lógico.
Response +: Este parámetro debe indicar que la solicitud de servicio
fue exitosa. Un resultado exitoso resultara en los parámetros,
mostrados en la tabla 3 a continuación.
Tabla 3. Atributos de solicitud de servicio exitosa.
DataAttributeReferente: Este parámetro debe contener la referencia de objeto de un atributo de dato contenido en un nodo lógico que podrá ser retornado de acuerdo al valor de la limitante funcional (FC) recibida en la solicitud. DataAttributeValue: Este parámetro debe contener el valor de un atributo de dato de la información contenida en el nodo lógico referenciado. Solo los valores de aquellos atributos de datos que están igual al valor del parámetro “FunctionalConstraint” en la solicitud del servicio, serán retornados.
Response-: Este parámetro debe indicar que la solicitud de servicio
fallo, devolviendo un “error de servicio”.
52
Es importante resaltar que en el anexo C se puede observar las
definiciones de clase de los nodos lógicos que maneja el equipo UR-L90 de
General Electric.
4.3.5 Modelos de datos y servicios.
Como se mencionó anteriormente, para que los nodos lógicos sean
capaces de interactuar entre ellos, deben tener la capacidad de interpretar y
procesar la información recibida y los servicios de comunicación utilizados.
Por esta razón es necesario estandarizar los objetos de datos asignados a
los nodos lógicos y su identificación dentro de los mismos.
Los datos y servicios de una aplicación pueden ser modelados en tres
niveles. El primer nivel describe modelos abstractos y servicios de
comunicaciones usados para intercambiar información entre los nodos
lógicos. Los niveles 2 y 3 definen específicamente el modelo de los objetos.
Esto incluye la descripción de las clases de datos con sus atributos y su
relación con los nodos lógicos.
• Nivel 1: interfaz de servicio de comunicaciones (ACSI):
ACSI especifica los modelos y servicios usados para el acceso a los
elementos del modelo de objeto. Los servicios de comunicaciones no solo
proveen mecanismos para la lectura y escritura de valores en los objetos,
también permite otras operaciones, tales como la de controlar equipo
primario.
• Nivel 2: clases de datos comunes (CDC)
53
El segundo nivel define las clases de datos comunes “Common Data
Classes”. Estas definen información estructurada con uno o más atributos. El
tipo de dato de un atributo puede ser uno básico, como por ejemplo un
“entero”, entre otros. Las clases de datos definidas en el nivel 3 son
especializaciones de los CDC, de acuerdo a su uso especifico en el contexto
de la aplicación
• Nivel 3: clases de nodos lógicos compatibles y clases de datos
Este nivel define un modelo de objeto compatible especificando las
clases de nodos lógicos y clases de datos. No hacen falta más
especificaciones que las definiciones del nodo lógico y la clase de datos.
A continuación se presenta la tabla 4 con los tipos de clases de datos
y la cantidad de cada uno de ellos:
CLASES DE DATOS CANTIDAD
Información del sistema 13
Información del equipo físico 11
Medibles “Measurands” 66
Valores medidos 14
Data controlable 36
Información de estados 85
Configuración 130
TOTAL 355
Tabla 4. Clases de datos del estándar. Fuente: Estándar IEC 61850
54
4.4. Reportes
El protocolo IEC 61850 cuenta con eficientes mecanismos para hacer
seguimiento de los cambios en los objetos del sistema, estos son, los
registros y reportes. Debido a los objetivos y alcances de este trabajo, se
estudiará y documentará solo los tipos y características de los reportes, y se
dejará a un lado las características de los registros.
Los reportes en vez de solicitar los valores y estados de los eventos
internos, (valores del proceso, valores que ocasionan los disparos de los
eventos, entre otros) se generan automáticamente luego de algún cambio de
estado, o periódicamente de manera independiente. Estos pueden agrupar
los atributos de datos que se consideren importantes en estructuras lógicas
llamadas “Data Set”. Estos “Data Set” son utilizados como base para la
elaboración de los reportes y registros.
Los “Data Set” especifican qué objetos y qué atributos irán en los
reportes y registros.
El proceso de generación y transmisión de los reportes es controlado
por un bloque de información llamado Bloque de Control de Reportes (RCB).
Un RCB mantiene la información necesaria para generar un reporte, tales
como: campos que deben ser incluidos en el reporte, eventos que activan la
generación de un reporte, orden de secuencia del reporte, entre otros.
Normalmente el RCB controla los reportes generados de uno o más nodos
lógicos hacia un solo cliente. Para permitir que múltiples clientes reciban los
mismos valores de datos, múltiples instancias de la clase RCB deben ser
habilitadas. A continuación se puede observar la figura 8 donde se
55
representa el proceso de elaboración de los reportes (Reports) y registros
(Logs)
El modelo de reporte posee dos tipos de bloques de control de reporte:
1) Bloque de Control de Reportes sin “buffer” (Unbuffered Report Control
Block, URCB)
2) Bloque de Control de Reportes con “buffer” (Buffered Report Control
Block, BRCB),
Los reportes “buffered” y “unbuffered” comienzan con la configuración
del bloque de control de reportes. Para que sean habilitados cualquiera de
Figura: 8. Modelo conceptual del proceso de elaboración de reportes y registros Fuente: Estándar IEC 61850-7-1
56
estos tipos de reportes, a los mismos se les debe activar el atributo de
“buffer” a verdadero (TRUE), si se configura como falso (FALSE) se detiene
el reporte.
4.4.1 Reportes buffered.
La característica singular del bloque de control de reportes “buffered”
es que continua almacenando (buffering) los datos de eventos a medida que
ocurren, de acuerdo a las opciones de disparo activadas. Por ejemplo, de
ocurrir una pérdida de comunicación, el proceso de elaboración de reportes
continuará apenas se restablezca la comunicación otra vez, y enviará todos
aquellos reportes almacenados en el “buffer” durante la perdida de
comunicación, de esta manera no se pierden datos generados en el
momento de la pérdida de comunicación. Adicionalmente el bloque de control
de reportes “buffered” garantiza secuencia de eventos (SoE) hasta algunos
limites prácticos (por ejemplo, tamaño de “buffer” y tiempo máximo de
interrupción).
Para una mejor comprensión del mecanismo básico de un reporte
“buffered” y el ejemplo de pérdida de comunicación, se muestra la figura 9.
57
Los bloques de control de reportes “buffered” poseen varios atributos
que controlan el proceso de elaboración del reporte, por ejemplo:
• RpdID: Suministrada por el cliente para identificar el bloque de control
de reporte “buffered”. Este atributo puede ser utilizado por los clientes
para distinguir entre reportes de varios BRCBs.
• RptEna: Permite activar/desactivar a distancia el proceso de
elaboración de los reportes.
• DatSet: Hace referencia al conjunto de datos, al cual sus valores serán
incluidos en el reporte.
Figura: 9. Representación conceptual del bloque de control de reportes “buffered”. Fuente: Estándar IEC 61850-7-1
58
• ConfRev: Contiene la revisión de la configuración para indicar si algún
miembro del “Data Set” ha sido eliminado o la reorganización de los
miembros.
• OptFlds: Indica los campos opcionales que van a ser incluidos en el
reporte. Esto pueden visualizarse en la tabla 5.
Tabla 5. Campos opcionales a ser incluidos en el reporte.
Numero de secuencia (Sequence-number): Para obtener el orden correcto
de los eventos
Etiqueta de tiempo del reporte (Report-time-stamp): Para informar al cliente
cuando fue hecho el reporte.
Razón para la inclusión (Reason-for-inclusion): Para indicar que disparo ha
causado que el valor sea incluido en el reporte.
Nombre del conjunto de datos (Data-set-name): Para indicar de que “data
sets” se han generado los valores.
Referencia de datos (Data-reference): Para incluir las referencias de los
objetos para los valores.
• BufTm: Contiene el tiempo que hay que esperar (en milisegundos) luego que
se produjo el primer evento dentro de un “Data Set”. Es como la ventana de
tiempo en la cual se está haciendo “buffer”. Este debe configurarse en
incrementos de 1 ms y debe ser capaz de transmitir hasta una hora de
tiempo de “buffer”. El valor 0 en el tiempo de “buffer” es un valor por defecto
el cual indica que no se utilizará el tiempo de “buffer”. Es decir cada evento
interno debería generar un reporte independiente.
59
Ampliando un poco más sobre las características del atributo de
tiempo de “buffer” (BufTm), se puede señalar que gracias a esta propiedad,
el servidor puede reducir el número de reportes generados. Esto se debe a
que luego de un primer evento, otros eventos se producirán en la misma
zona que el primero. Por lo tanto se generará un solo reporte al final del
tiempo de “buffer” (de acuerdo a las razones y definiciones de su
correspondiente “Data Set” para un bloque de control de reportes específico).
En la figura 10 se puede ilustrar mejor la idea del tiempo de “buffer”
• SeqNum: Es el número actual en la secuencia de los reportes. Este
número se incrementa en uno por cada reporte generado y enviado
por el BRCB.
• TrgOps (Trigger options): Contiene las razones que causan que el
bloque de control de reportes incluya un valor en su reporte. Las
razones para que un valor sea incluido en un reporte pueden ser:
Cambio en los datos (dchg), Actualización de datos (dupd), Cambio de
calidad de un atributo de dato en un nodo lógico (qchg) o un periodo
de integridad (Integrity)
Figura: 10. Funcionamiento del buffer time. Fuente: Estándar IEC 61850-7
60
• IntgPd (periodo de integridad): realiza un reporte con los valores
iniciados por el servidor en un periodo de tiempo pre establecido, de
manera automática sin que ningún disparo lo active.
• GI (Interrogatorio general): incluye en el reporte todos los valores
iniciados por el cliente.
• PurgeBuf: Configurado en verdadero (TRUE), borra todos los eventos
que no se hayan enviado hasta el momento.
Es conveniente acotar que en los reportes con “buffer” existe un
fenómeno que ocurre cuando se satura la capacidad de almacenamiento, se
trata del desbordamiento del “buffer” o (buffer overflow”). Este puede suceder
cuando existe una pérdida de comunicaciones muy prolongada. Al ocurrir
esto, se levanta una bandera que indica que ha ocurrido un desbordamiento,
y el sistema empezará a eliminar los reportes con mayor antigüedad, dándole
prioridad a los reportes mas recientes. El cliente también puede hacer uso
del atributo “PurgeBuf” para que limpie la memoria del “burffer”
En el caso de que una segunda notificación de un mismo miembro del
“Data Set” haya ocurrido antes de la expiración del “BufTm”, el BRCB,
realizara lo siguiente:
• Para datos booleanos deberá comportarse como si el “BufTm” hubiera
expirado e inmediatamente se enviará el reporte, se reiniciará el
temporizador con el tiempo de “BufTm” y se procesará el segundo
cambio de estado.
61
• Para datos analógicos puede comportarse como si el “BufTm” hubiera
expirado e inmediatamente se transmitirá el reporte, se reinicia el
temporizador con el tiempo de “BufTm” y se procesa el segundo
cambio de estado, o puede sustituir el valor actual por el nuevo en el
reporte que está en proceso.
4.4.2 Reporte unbuffered.
Los reportes sin “buffer” trabajan exactamente igual que los reportes con
“buffer” excepto por:
• En una perdida de comunicación se activa automáticamente el atributo
“PurgeBuf”, borrando así, toda la información del buffer.
• No puede enviar repotes segmentados
• Cualquier cliente puede tener acceso a los reportes
• Puede ser ubicado en cualquier nodo lógico.
El envió de datos en este tipo de reportes se hace bajo un sistema de
“máximo esfuerzo”, ya que hace lo posible por que lleguen los datos, pero no
dispone de un mecanismo para garantizar la entrega de los paquetes de
datos, en caso de que se produzca un problema de comunicación en la red.
En cuanto a los atributos que definen a este bloque de control de reportes
sin “buffer”, se puede decir que excepto por los atributos: URCBName,
URCBRef, RptEna, and Resv, que se explican a continuación, todos los
demás atributos serán igual a los del bloque de control de reporte con
“buffer”.
62
• URCBName: Este atributo deberá ser el nombre del URCB, que lo
identifique de forma no ambigua en el nodo lógico
• URCBRef: Este atributo deberá ser la única trayectoria del nombre
(path-name) del bloque de control de reportes sin “buffer”. La
referencia de objeto URCBRef deberá ser:
LDName/LNName.URCBName
• RptEna: Este atributo indica si el URCB está actualmente habilitado
para reportar valores de un “Data Set”. Si se configura a verdadero
(TRUE), el URCB deberá monitorear los valores referenciados de un
“Data-Set” y generará los reportes como se haya especificado
anteriormente. Si se configura en “FALSE” (falso), el URCB deberá
detener su emisión de reportes.
Mientras el bloque de control de reportes sin “buffer”, se encuentre
habilitado para la emisión de reportes, no se podrá cambiar o modificar
valores de los atributos del URCB, a excepción de desactivar y activar las
opciones generales de disparo.
Si la comunicación se pierde con el cliente, el cual había habilitado el
URCB, el servidor deberá modificar el atributo de RptEna a falso (FALSE).
Resv: Este atributo si se configura a verdadero (TRUE), deberá indicar
que el URCB está actualmente reservado exclusivamente para el cliente que
ha puesto el valor en “TRUE”. Otros clientes no deberán estar autorizados
para modificar cualquier atributo de ese URCB.
63
Si el atributo Resv no está configurado a “TRUE”, entonces al
establecer el campo RptEna a “TRUE” reservara el URCB implícitamente.
4.4.3 Diferentes formas de elaborar un reporte.
Los reportes pueden enviar los datos junto con las referencias de
objetos y atributos de los datos, o pueden enviar solo los valores sin sus
respectivas referencias de objetos (De acuerdo a las razones y definiciones
de su correspondiente “Data Set” para un bloque de control de reportes
específico). Por lo tanto la referencia de objeto se puede obtener de la
definición del “Data Set”
Si se envían los valores sin sus referencias de objeto, solo se debe
incluir en el reporte los valores de un subgrupo del “Data Set”, entonces se
suministra una disposición para determinar a qué miembros del “Data Set”
pertenecen estos valores. La SCSM “specific comunication service mapping”
define un”inclusion-bitstring” para indicar el miembro del “Data Set”. En la
figura 11 se puede observar un ejemplo con dos formas de generar el
reporte, donde el “Data Set” posee a dos miembros diferentes. El ejemplo de
reporte con el “inclusion-bitstring” tiene dos bits, los cuales indican de que
miembros son esos valores. Los reportes con “inclusion-bitstring” optimizan el
largo del mensaje de reporte, tal como se puede observar en la figura 11.
64
4.5 Configuración del IEC 61850 en los Relés UR de General Electric
4.5.1 Relés UR de GE
Los relés de la serie “Universal Relay” (UR) de General Electric son
equipos digitales constituidos por una arquitectura modular y diseñados para
ser multi-funcionales. Para esto tiene una unidad central de procesamiento
(CPU) que maneja múltiples tipos de señales de entradas y salidas. Los URs
pueden comunicarse a través de una red de área local (LAN), con un
operador a través de una interfaz, con un equipo de programación, o con otro
dispositivo UR.
Figura: 11. Miembros del “data set” y el “bitstring” de inclusión. Fuente: Estándar IEC61850-7-1
65
Según el manual técnico del UR-L90, las entradas de este equipo
aceptan una variedad de señales digitales o analógicas provenientes de
campo. El equipo aísla y convierte estas señales externas en señales lógicas
usadas por el relé. Con respecto a las salidas del equipo, este convierte y
aísla las señales lógicas generada por el relé en señales analógicas o
digitales que pueden ser usadas por dispositivos de control de campo.
Este dispositivo es el encargado de realizar la protección y/o control de
forma automatizada en las subestaciones eléctricas, mediante algoritmos
lógicos que vienen programados de fábrica. Aunque también puede
personalizarse su lógica interna utilizando ecuaciones lógicas en su entorno
de programación, el FlexLogic.
Se habla de una familia de relés UR, ya que hay diferentes
configuraciones y características en cada uno de ellos. Según su uso, por
ejemplo tenemos:
• F60: Relé de Protección de Alimentador
• C60: Controlador de Bahía
• C30: Controlador
• D60: Relé de Protección de Distancia
• D30: Relé de Protección de Distancia
• L90: Relé de Diferencial de Línea
• B90: Relé de Protección de Barra
• T60: Relé de Protección de Transformadores
66
4.5.2 Nodos lógicos disponibles en los URs L90 con firmware versión 5.7.
La norma establece una gran cantidad de nodos lógicos, de los cuales
algunos los contienen los relés UR de General Electric. Cabe destacar que
no toda la familia de relés UR tienen los mismos nodos lógicos disponibles.
Esto depende del tipo de relé, es decir, de las características especificas de
cada relé de la familia UR. Por ejemplo, el nodo lógico de protección de
distancia (PDIS) esta disponible solo en el relé de distancia UR D60.
A continuación se facilita un listado de los nodos lógicos disponibles
en el UR L90 de General Electric.
• Nodos Lógicos del sistema.
LPHD: Contiene información acerca del L90 como dispositivo físico.
LLNO: Contiene información acerca del L90 como equipo lógico.
• P: Nodos Lógicos para funciones de protección.
PDIF
PDIS
PIOC
PTOC
PTOV
PTRC
PTTR
PTUV
• R: Nodos Lógicos para funciones relacionadas con protección.
RBRF
67
RFLO
RPSB
RREC
• G: Nodos Lógicos para referencias generales
GGIO: Es el tipo de nodo lógico mayormente utilizado por la empresa,
ya que permite configurar a voluntad cualquier punto digital del relé e incluirlo
en un reporte (Buffered o Unbuffered) y “Data Set” pre-configurado, a
diferencia de los demás nodos disponibles en el relé. Los nodos lógicos
GGIO se pueden a su vez subdividir en varios como son: GGIO1, GGIO2 y
GGIO3.
El nodo lógico GGIO1, que refleja los valores de estado digital, está
disponible en el L90 para dar acceso a un máximo de 128 estados digitales
(status points), Etiquetas de tiempo (timestamps) asociadas y banderas de
cualidad (quality flags). Los datos contenidos en el nodo deben ser
configurados antes de que puedan ser utilizados.
El GGIO1 provee puntos de estado digitales para que los clientes
puedan acceder. En el manual del fabricante del UR (GE Industrial Systems,
2008), indica que los clientes deben utilizar los GGIO1 para poder acceder a
los valores de estado digitales del L90. El manual también especifica que los
clientes pueden utilizar los reportes con buffer y sin buffer disponibles en el
GGIO1, para así poder construir registros de secuencia de eventos (SOE) y
pantallas de un IHM. Recomiendan que se deba usar generalmente los
reportes con buffer para los reportes con secuencias de eventos, esto reduce
las probabilidades de que se pierdan datos. Los reportes sin buffer se
68
recomiendan solo para uso local de estados. Este dispositivo facilita las
herramientas de configuración para permitir la selección del número de
estados digitales disponibles y para permitir la selección de los operandos del
FlexLogic del L90 que manejas los estados del GGIO1.
El nodo lógico GGIO2 refleja los valores de controles digitales, que
están disponibles para proveer acceso a las entradas virtuales del L90. Las
entradas virtuales son valores de control discretas (binary single point) que
pueden ser escritas por los clientes. Estas son usadas generalmente como
entradas de control. GGIO2 provee acceso a las entradas virtuales a través
de los servicios del modelo de control del estándar IEC61850 (ctlModel), que
se enlista a continuación:
• Status only.
• Control directo con seguridad normal.
• Control SBO con seguridad normal.
Los ajustes de configuración están disponibles para seleccionar el
modelo de control para cada punto. Según su manual técnico (GE Industrial
Systems, 2008), cada entrada virtual usada a través de las GGIO2 debería
tener su función de entrada virtual programada como habilitada (enabled) y
su ajuste correspondiente GGIO2 CF SPSCO 1(64) CTLMODEL
programado a la configuración de control apropiada.
Ahora bien, por otro lado, el nodo lógico GGIO3, refleja los estatus
digitales y valores análogos disponibles para proveer el acceso de los
clientes a los valores recibidos vía mensajes GOOSE configurables. Los
69
valores de las indicaciones de estatus digital y de valores analógicos en
GGIO3 se originan en los mensajes GOOSE enviados por otros dispositivos.
• M: Nodos Lógicos para mediciones y medidas
MMXN
MMXU
• X: Nodos Lógicos para el “SWITCHGEAR”
XCBR
XSWI
4.5.3 Reportes en el UR.
Según su manual técnico UR L90 (GE Industrial Systems, 2008), en
los relés UR los reportes con “buffer” y sin “buffer” se encuentran disponibles
en los nodos lógicos GGIO1 para valores de estados binarios, y en los nodos
que van desde el MMXU1 hasta el MMXU6 para los valores analógicos
medidos. Los reportes se pueden configurar haciendo uso del programa de
General Electric “EnerVista UR Setup”, algún programa de configuración de
subestaciones o a través de un cliente IEC61850.
En este dispositivo electrónico inteligente se pueden configurar las
siguientes instancias:
• Opciones de disparo (TrgOps): Los bits que se pueden controlar con
el L90 , con respecto a las opciones de disparo que se muestran en la
tabla 6.
70
Tabla 6. Bits controlables por el L90 en cuanto a opciones de disparo.
Bit 1: data-change
Bit 4: integrity
Bit 5: general interrogation
• Campos opcionales (OptFlds): Los bits que se pueden controlar con el
L90 en forma opcional se muestran en la siguiente tabla (7).
Tabla 7. Bits de campos opcionales.
Bit 1: sequence-number
Bit 2: report-time-stamp
Bit 3: reason-for-inclusion
Bit 4: data-set-name
Bit 5: data-reference
Bit 6: buffer-overflow (solo para reportes con “buffer”)
Bit 7: entryID (solo para reportes con “buffer”)
Bit 8: conf-revision
Bit 9: segmentation
• IntgPd: Periodo de integridad (Integrity period).
• BufTm: Tiempo de buffer (Buffer time).
71
4.5.4 Tipos de comunicaciones 61850 que soporta el UR de General
Electric.
• Comunicaciones tipo Cliente/ Servidor
Este es un tipo de comunicación orientada a conexión. El enlace es
iniciado por el cliente, así como la comunicación que también es controlada
por el cliente. Los clientes en IEC 61850 son a menudo computadoras en las
subestaciones que manejan los programas de IHM, o programas de registros
de Secuencia de los eventos (SOE). Los servidores son usualmente equipos
de campo de la subestación, tales como por ejemplo: relés de protección,
medidores, RTU, transformadores o controladores de bahía compatibles con
el IEC 61850.
• Comunicaciones del tipo “Peer to Peer” o (P2P).
Este es un tipo de comunicación de alta velocidad que no está
orientado a la conexión, usualmente se utiliza entre los equipos de campo de
la subestación. Los mensajes GSSE y GOOSE son métodos de
comunicación P2P.
4.5.5 Como crear un archivo ICD con EnerVista UR Setup.
Un archivo ICD puede ser creado directamente de un UR conectado o
desde la configuración de UR “offline” en el EnerVista UR Setup siguiendo
los siguientes pasos:
72
1. Haciendo click en el botón derecho del mouse, en el relé UR
conectado o en la configuración de UR “offline”, y luego
seleccionando del menú la opción “Create ICD File”.(Figura 12)
2. El programa EnerVista UR Setup le pedirá guardar el archivo.
Seleccione la ruta al archivo y escriba el nombre para el archivo ICD, luego
haga click en OK para generar el archivo.
A través de la configuración “offline” de los URs, se crea el archivo ICD
mucho más rápido que si se hace directamente del relé.
Figura: 12. Ejemplo de creación de un archivo ICD. Fuente: Manual del relé UR L90
Sección de configuración
del UR “offline”
Sección de configuración
“online”
73
4.5.6 Como importar un archivo SCD con EnerVista UR Setup.
El siguiente procedimiento describe como actualizar un relé UR con
una nueva configuración de un archivo SCD con el programa EnerVista UR
Setup.
1. Haciendo click derecho en cualquier parte del panel de archivos se
desplegará un menú, en este seleccione “Import Contents From SCD
File”. (Figura 13)
Figura: 13. Ejemplo de cómo importar un archivo SCD. Fuente: Manual del relé UR L90
74
2. Seleccione el archivo SCD guardado y haga click en “Open”.
3. El programa abrirá el archivo SCD y pedirá al usuario guardar un “UR-
series setting file”, seleccione una ubicación y luego dele nombre al
archivo “URS” (UR-series relay settings)
4. Luego que el archivo “URS” es creado, modifique cualquier
configuración (si es necesario).
5. Para actualizar el relé con la nueva configuración, haga click derecho
en el archivo de configuración (settings file) en el menú de “settings” y
seleccione “Write Settings”,
6. El software pedirá el dispositivo de destino. Seleccione el dispositivo
de destino de la lista proporcionada y luego haga click en enviar. La
nueva configuración se actualizará en el dispositivo seleccionado.
(Figura 14)
Figura: 14. Ejemplo de cómo importar un archivo SCD 2. Fuente: Manual del relé UR L90
75
4.5.7 Configuración general del protocolo IEC 61850 en los relés UR
de GE
A la hora de realizar cualquier configuración en estas ventanas del
EnerVista UR Setup, se debe proceder a guardar los cambios antes de cerrar
la ventana, de lo contrario no se harán efectivos los cambios. Para esto se
debe hacer clic en el botón “Save”, como lo ilustra la figura 15.
Para realizar la configuración del protocolo de comunicaciones IEC
61850 entre el Gateway SMP y cualquier relé de la serie UR de General
Electric (Versiones de firmware 5.51 o superior) se deben seguir los
siguientes pasos.
1. Una vez abierto el programa Enervista UR Setup, y establecida una
conexión con un relé, se procede a buscar en el menú: Product Setup>
Communications> IEC 61850> Server Configuration. En esta ventana se
configura el servidor. (Figura 15)
Guardar
Figura: 15. Configuración del servidor
76
2. Para configurar las señales de campo se utiliza el nodo lógico GGIO1, que
se ubica en el mismo sub. menú de IEC 61850. (Figura 16).
3. Para configurar los mandos en el UR, se hace uso del nodo lógico GGIO2.
(Figura 17).
Figura: 17. Configuración de los mandos del UR.
Figura: 16. Configuración señales de campo.
77
4. Para realizar la configuración de los reportes, se accede a “Report Control
Configuration”. En esta ventana se podrá encontrar diferentes tipos de
reporte según el modelo de UR que se este utilizando. (Figura 18)
Figura: 18. Configuración de reportes.