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.