Captulo 4

Desarrollo y Resultados del Plan de Trabajo

A continuacin se presenta un compendio del protocolo IEC 61850 de

forma general y particular. Los tpicos particulares se seleccionaron debido a
su relevancia en las soluciones de ingeniera que ofrece la empresa PLC
Services S.A. Cabe destacar que dicho compendio de informacin fue
basado en su mayora en el documento oficial del estndar IEC 61850

Paralelamente a sta investigacin sobre dicho protocolo, se

realizaron otras actividades durante el perodo de las pasantas, 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 metodolgico del capitulo tres para el

desarrollo de este proyecto, se comenz por realizar una revisin general del
protocolo IEC 61850 con la finalidad de determinar los aspectos de inters
para su aplicacin en sistemas de control numrico, obteniendo los
siguientes resultados.

4.1 Aspectos Generales del Protocolo IEC 61850

Las subestaciones elctricas estn mayormente automatizadas hoy en

da. Estos sistemas automatizados utilizan computadoras y equipos

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
dinmica propia de la empresa.

26

electrnicos inteligentes para optimizar el funcionamiento de los equipos de

proteccin, con la mnima intervencin humana.

Antes, los sistemas de automatizacin de subestaciones utilizaban un

conjunto de equipos donde cada uno de ellos cumpla funciones especficas.
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 subestacin
elctrica. En la figura 1, se puede observar la situacin que haba antes de la
aparicin del protocolo IEC 61850, donde entre otras cosas, los diferentes
protocolos podan ser utilizados para diferentes funciones dentro de la
subestacin.

Nivel de
Estacin

Nivel de
Baha
Nivel de
Proceso
Figura: 1. Situacin antes de IEC 61850. Fuente: IEC 61850 Short Tutorial, Klaus-Peter Brand

27

Debido a esta falta de capacidad para comunicarse entre los

diferentes equipos en las subestaciones elctricas, la mayora de las
empresas fabricantes de equipos y prestadoras de servicio, reconocieron la
necesidad de un estndar unificado internacional que apoyara una
cooperacin fluida entre los productos de diferentes empresas, este sera el
estndar IEC 61850.

El IEC 61850 es un estndar global para redes y sistemas de

comunicaciones en subestaciones elctricas. Este describe: un protocolo de
comunicaciones (cliente/servidor y punto a punto); diseo y configuracin de
las sub estaciones elctricas; modelos representativos de los equipos de la
subestacin; estndares ambientales, parmetros para la realizacin de
proyectos y procesos de comprobacin para verificar que todo haya sido
configurado de manera correcta, entre otros aspectos. Fue publicado por
primera vez en el 2004, como una unin de elementos del Instituto Nacional
Estadounidense de Estndares (ANSI), y la Comisin Electrotcnica
Internacional (IEC) en Europa. Cabe acotar que entre los encargados de
realizar el IEC 61850, estn los mayores proveedores de tecnologa de
automatizacin de sub estaciones elctricas en el mundo.

El objetivo del estndar es especificar los requisitos y la estructura para

lograr la interoperabilidad entre los equipos electrnicos inteligentes (IEDs)
de diferentes fabricantes.

El primer lanzamiento del estndar IEC 61850 consta de ms de 1400

pginas, dividido en diez grandes secciones, donde las primeras tres
secciones proporcionan una idea general del protocolo. La seccin cuatro
trata sobre los requisitos del proyecto y del sistema, mientras que la siguiente
seccin habla de los requisitos para las comunicaciones de funciones y
28

modelos de equipos, de igual manera se presenta una sexta seccin donde

se define un lenguaje basado en XML para la configuracin de IEDs llamado
Lenguaje de Configuracin de Subestaciones (SCL). La seccin siete es el
alma del estndar, esta se subdivide a su vez en cuatro partes, estas son:
Principios y Modelos, Interfaz de Servicios de Comunicacin Abstracta
(ACSI), Clases de Datos Comunes (CDC), Clases de Nodos Lgicos
Compatibles y Clases de Datos. Luego en la seccin ocho habla acerca de
cmo asignar los objetos internos a la capa de presentacin y a la capa de
enlace de datos. La novena seccin describe la asignacin de Sampled
Measured Values (SMV) a un esquema de comunicaciones Ethernet, para
as llegar a la ultima seccin 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 deban 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. Adems
de definir la forma en que se transmiten los datos, tambin suministra un
modelo exhaustivo de cmo los equipos utilizados en las subestaciones
deben organizar la informacin de tal manera que sea consistente a travs
de todos los tipos y marcas de equipos.

El protocolo se ha ido implementando paulatinamente alrededor del

mundo desde su aparicin. Una de las compaas fabricantes que se ha
identificado con este protocolo es General Electric, la cual ha hecho que sus
productos orientados al sector de subestaciones elctricas sean compatibles
con el estndar. Segn el documento IEC 61850 Experience in Substation
Automation Projects de General Electric Multilin (2006), General Electric ha

29

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, (Espaa)

CFE, (Mexico)

Ethekwini Electricity, Durban, (Sudfrica)

Cuando se disea un sistema de automatizacin y control de una

subestacin elctrica, los objetivos principales son la confiabilidad, reduccin
de costos y tiempo. Este nuevo sistema tiene mltiples ventajas sobre los
viejos sistemas de control con equipos electro mecnicos. La tecnologa
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, proteccin y monitoreo en
una subestacin elctrica.

A continuacin se compara en la tabla 1, ciertos aspectos del nuevo

estndar con otros protocolos anteriores.

30

Tabla 1. Comparacin de algunos protocolos de comunicaciones. Fuente:

Arthur Pereira Neto SIEMENS MERCOSUR
IEC
60870-5103
Si

Profibus
FMS

DNP V
3.0

Modbus

UCA 2

IEC 61850

Si

Si

Si

Si

Capacidad de
realizar
Comandos

Si

Si

Si

Si

Valores medidos

Si

Si

Si, sin
estampa
de
tiempo
Si

Si, sin
estampa
de
tiempo.
Si, sin
estampa
de
tiempo
Si

Si

Si

Sincronizacin
de tiempo*

Si

Si

Si

No

Si

Si

Certificado
internacional de
interoperabilidad
Bus de
Comunicaciones
del proceso
Modo de
comunicacin

Si

No

No

No

Si

Si

No

No

No

No

No

Si

Maestro/
Esclavo

Maestro/
Esclavo

Maestro/
Esclavo

Maestro/
Esclavo

Orientado
a eventos

Orientado
a eventos

0.19

12

0.12

0.12

100

100si

Capacidad de
Indicacin

Velocidad de
transmisin
(Mbit/s)

Una vez observada la situacin que exista antes de la aparicin del

protocolo IEC 61850, y su comparacin con otros protocolos ya existentes,
se presenta la figura 2, donde se muestra la representacin lgica de
comunicaciones del nuevo estndar. 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 subestacin con
los de nivel de Baha, llamado Bus de Subestacin (Station bus). Por otro
lado se tiene un bus que comunica a los equipos de nivel de baha con los
equipos de nivel de proceso, llamado Bus de Proceso (Process bus),
31

Nivel de
Estacin
Bus de
Subestacin
Nivel de
Baha
Bus de
proceso
Nivel de
Proceso

Figura: 2. Esquema de comunicaciones usando IEC 61850. Fuente: IEC 61850 Short
Tutorial, Klaus-Peter Brand

Por ejemplo, el Bus de Subestacin, es el que se encarga de

interconectar los IEDs que realizan la proteccin y control (nivel de baha)
con el IHM (nivel de estacin). Por otro lado, el Bus de Proceso es el que se
encarga de interconectar los medidores, sensores y dems equipos de
campo (Nivel de proceso) a los IEDs (nivel de baha). Las caractersticas
especficas de estos buses variaran segn la topologa de construccin de la
subestacin elctrica.

Luego de realizar la revisin general del protocolo IEC 61850, se

determinaron los aspectos de inters para su aplicacin en sistemas de
control numrico, y se seala en la seccin 4.2-

32

4.2 Aspectos Resaltantes del Protocolo

A continuacin se mencionan ciertos aspectos que se consideraron

relevantes para el mejor entendimiento de esta norma, as como para la
implementacin del protocolo por parte de la empresa.

4.2.1 Lenguaje de configuracin de subestaciones (SCL).

Siendo, la estandarizacin de las comunicaciones entre los diferentes

equipos, el objetivo final de la norma, fue necesario que se estandarizaran
tambin los mtodos que iban a describir las compatibilidades de
comunicacin entre los IEDs. De esto se encarga el Lenguaje de
Configuracin de Subestaciones (SCL). El lenguaje consta de la elaboracin
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 subestacin completa
Este conjunto de archivos se utiliza para describir la configuracin de
los equipos de una subestacin. Por ejemplo, la informacin del diagrama
unifilar de una subestacin se almacena en el archivo de Descripcin de las
Especificaciones del Sistema (SSD). Por otro lado, cada dispositivo tiene un
archivo de descripcin de compatibilidad (ICD), por ltimo, la configuracin
completa de la subestacin se almacena en el archivo de Descripcin de la
Configuracin de la Subestacin (SCD). El archivo SCD es la combinacin
de los archivos ICD individuales y el archivo SSD.

33

4.2.2 Tipos de comunicaciones.

El estndar IEC 61850 define una estructura de comunicacin

bastante elaborada, definiendo cinco tipos de comunicaciones como se
muestra en la figura 3.

Estn:
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

34

Los SMV o como tambin se le denomina SV sampled values, son la

forma de comunicacin 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 informacin es
ms rpido y por consecuencia su transmisin tambin lo es.

De acuerdo a Liang (2008) se extrae que estos mensajes rpidos

siguen siendo efectivos, a pesar de sus pocos elementos de confiabilidad. El
objetivo de este tipo de comunicacin es el de enviar los datos ledos por los
medidores en campo a los IEDs a travs de la tecnologa Ethernet, para as
evitar las cientos de complicadas y obsoletas conexiones de cobre.

Los mensajes GOOSE quizs son los ms nombrados al hablar del

protocolo IEC 61850. Al igual que los SMV, los mensajes GOOSE son una
forma rpida 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 transmitirn a travs del Bus de Subestacin. Estos
mensajes cumplen una funcin parecida a la los SMV, y es que buscan
reemplazar la lgica convencional de conexiones de cobre (hardwired) en los
IEDs, o tambin llamados rels o equipos fsicos (Physical Device, PD). La
cantidad de datos que sern generados luego de un evento dependern de
la topologa de la red, el nmero 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.

35

Los mensajes GSSE son similares a los GOOSE, pero se diferencian

en el tipo de informacin que intercambian entre los IEDs. En el caso de los
mensajes GOOSE, estos pueden transmitir una gran cantidad de informacin
organizada, mientras que los mensajes GSSE solo pueden hacer uso de una
lista especfica de estados de informacin. Dicha lista se limita a valores de
estado de informacin, por ejemplo: abierto, cerrado, en transicin o estado
invlido.

Una vez explicados, los primeros tres tipos de comunicacin que

posee este estndar, se consigue un cuarto, el de sincronizacin de tiempo
(TimeSync), el cual, se utiliza para sincronizar los tiempos de envi de
informacin. Dicho tipo de comunicacin se realiza a travs 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 travs de la cual las
aplicaciones (por ejemplo, la Interfaz humano maquina) se comunican con
los IEDs, y donde se define la semntica del intercambio de informacin
entre ellos, por lo tanto es la mayor parte del estndar. A travs de esta se
puede manipular y acceder a la informacin, por ejemplo, este tipo de
comunicacin se puede hacer a travs de una pgina web para acceder a la
informacin de un IED. En el caso de General Electric y sus rels de la serie
UR, se accede a la informacin y programacin a travs del programa
Enervista UR Setup.

36

4.2.3 Comunicacin entre IEDs.

En la norma todo el sistema de la subestacin esta modelado como un

sistema distribuido, que consiste en la interaccin de nodos lgicos. Se
entiende por nodo lgico la parte ms pequea de una funcin que
intercambia informacin entre IEDs, definindose en l sus datos y atributos.

En la figura 4 se puede visualizar mejor la idea. Las funciones (F)

contienen uno o ms equipos fsico (PD), los cuales a su vez contienen
nodos lgicos (LN). Los nodos lgicos estn enlazados por las conexiones
lgicas (LC). Cuando se habla de conexiones lgicas se est hablando del
concepto lgico de conexin entre dos nodos lgicos, las cuales pueden ser
directas, indirectas o incluso una combinacin de varios canales de
comunicacin. Es decir, estas conexiones lgicas son parte de las
conexiones fsicas (PC) entre los equipos fsicos (PD)

Es muy importante especificar y estandarizar las interacciones entre

los diferentes nodos lgicos de una manera genrica, ya que es imposible
definir todas las funciones que se utilicen y que se utilizaran en un futuro.

Figura: 4. Comunicacin entre IEDs. Fuente: IEC 61850-5

37

4.2.4 Interoperabilidad.

Es la capacidad de dos o ms IEDs del mismo, o distinto fabricante,

de cruzar informacin y utilizar esa informacin para la correcta operacin y
funcionamiento de una subestacin elctrica.

Los nodos lgicos y los datos contenidos en los equipos lgicos son
cruciales para la descripcin e intercambio de informacin para los sistemas
de automatizacin de las subestaciones elctricas, 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 jerrquica del modelo de datos.

El protocolo de comunicaciones IEC 61850 describe un modelo

jerrquico complejo, que se puede observar en la figura 5. Un dispositivo
fsico puede contener uno o ms dispositivos lgicos (LD). Cada dispositivo
lgico puede contener varios nodos lgicos (LN). A su vez, cada nodo lgico
puede contender varios Objetos de Datos o Data (Object). Cada Data
(Object) est compuesto por atributos de datos, y por componentes de los

38

atributos de datos. Los servicios estn disponibles en cada nivel para realizar
diferentes funciones, tales como: lectura, escritura, comandos de control y
reportes.

Figura: 5. Estructura jerrquica. Fuente: Germn Pugliese, IEC 61850 el estndar de

integracin elctrica del futuro

El nivel ms alto de esta estructura jerrquica es el equipo fsico (IED)

o tambin definido como servidor. Tericamente un IED puede contener
varios servidores, pero en la prctica usualmente contiene uno solo. Cuando
se habla de servidor, se refiere bsicamente al programa que corre en cada
IED, este sirve de unin entre el equipo fsico y los dispositivos lgicos.

Luego se tienen los dispositivos lgicos (LD), que bsicamente son un

grupo de nodos lgicos realizando funciones similares

39

Por otra parte, las funciones o equipos utilizados en sistemas de

potencia estn representados conceptualmente por nodos lgicos (LN). Estos
pueden estar ubicados en uno o ms equipos fsicos Cada nodo lgico est
organizado de una manera estandarizada y de ser necesario se pueden
crean nuevos LN de acuerdo a las reglas definidas en el estndar.

Dolazilec (2005) describe que:

Un nodo lgico es una coleccin 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
lmites de una entidad y su estado y comportamiento. (p.5)
El intercambio de datos entre los nodos lgicos 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 tambin tienen la propiedad de caracterizar o

delimitar su uso especfico a travs de las Limitaciones Funcionales
(Functional Constraints, FC), estas juegan un papel crucial en la definicin de
los modelos de informacin, y en los servicios de acceso a las varias partes
del modelo de informacin. En vez de agrupar los atributos de datos por
Data (Objects) las FC suministran una manera de organizar todos los
atributos segn 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 quizs hasta ms, debido a que los Data (Objects) son solo
colecciones de atributos de datos mientras que los atributos de datos son

40

correspondencia directa lgica del mundo fsico. Los Data (Objects) son
una manera conveniente de manejar e intercambiar los valores de los
atributos de datos de una misma funcin.

Aparte de los Data (Objects), el estndar 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 lgico o del mismo Data (Object), esto hace que la
informacin sea manejada de una manera ms flexible.

Los Data Set se clasifican en permanentes y no permanentes, los

permanentes

residen

en

los

nodos

lgicos

no

sern

borrados

automticamente a menos que el cliente lo desee explcitamente. Los no

permanentes a diferencia de los otros residen exclusivamente en las
asociaciones creadas, y sern borrados automticamente cuando la
asociacin termine.

4.2.6 Referenciando Instancias.

Con

el

fin

de alcanzar

los

objetivos

de

estandarizacin

interoperabilidad, la norma propone un sistema estructurado de cmo deben

ser nombrados y/o referenciados sus objetos de datos o Data (Objects) y
atributos. Por atributo se entiende, un elemento de informacin nombrado de
un tipo especfico.

Para empezar, el estndar diferencia entre los nombres de objetos y

las referencias de objetos (Entendindose objeto, como la instancia de una
clase cualquiera). Los nombres de objetos identifican una instancia de una
clase en un nivel jerrquico. Por ejemplo, Mod en el nivel de Data (Objects)
41

o Q0XCBR1 en el nivel de nodo lgico. Q0 es un prefijo y el 1 es un

sufijo del nombre XCBR. La norma IEC 61850 clasifica los nodos lgicos en
grupos segn su funcin como se muestra en la tabla 2. La primera letra de
cada nombre de nodo lgico indica a que grupo pertenece, en el caso de
XCBR la X significa que es un equipo de conmutacin, mientras que
CBR es el nombre que le da el protocolo a un interruptor (Circuit Breaker).
Luego de haber explicado la raz de cada una de las partes de los nombres
de los objetos, se puede decir que concatenacin de todos los nombres de
objetos

forman

la

referencia

MyLD/Q0XCBR1.Mode.stVal

42

de

objeto,

por

ejemplo:

Tabla 2. Lista de nodos lgicos.

INDICADOR
L

GRUPOS DE NODOS LOGICOS

Nodo lgico del sistema

CANTIDAD
3

Funciones de Proteccin

28

Funciones Relacionadas con Proteccin

10

Control Supervisor

Referencias de Funciones Generales

Interfaz e Archivado

Control Automtico

Medicin y Medida

Sensores y Monitoreo

Equipo de Conmutacin

Instrumento Transformador

Transformador de Potencia

Equipos Futuros (equipo de potencia)

15

TOTAL de Nodos Lgicos

92

Ahora bien, la referencia de un atributo de dato identifica un atributo

de dato especfico 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.

43

Como se vi anteriormente, el nombre de nodo lgico XCBR puede

ser prolongado por un prefijo, (por ejemplo Q0), y un sufijo (por ejemplo 1)
para construir el nombre del nodo lgico (Q0XCBR1). La estandarizacin de
la sintaxis de los prefijos y sufijos est fuera del alcance del estndar 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 estn definidos en
IEC 61850-7-4.

Esta forma de referenciar las instancias en el IEC 61850, sustituye el

antiguo

mtodo

de

mapping

que

utilizaban

otros

protocolos

de

comunicaciones como son: DNP y MODBUS. Este mtodo consista en

grandes tablas donde se relacionaban las variables del proceso con
direcciones numricas

A continuacin 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 lgico (LD)
MyLD; luego el nombre del nodo lgico (LN) Q0XCBR1, posteriormente el
nombre del dato Mod y por ultimo el nombre del atributo de dato stVal,

Figura: 6. Ejemplo de referencias. Fuente: Estndar IEC

61850-7-1

44

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 tamao
de las definiciones de datos en el estndar. La definicin de datos no
necesita enumerar todos los atributos, solo necesita hacer referencia a la
clase de datos comn. Las clases de datos comunes son tambin muy tiles
para mantener las definiciones de los atributos de datos coherentes.

Por ejemplo, la informacin con respecto a la posicin (Pos) tiene gran

cantidad de atributos de datos que se pueden encontrar en muchas otras
aplicaciones especficas de conmutacin. Dichos atributos representan
cuatro estados: estado intermedio, apagado, encendido e invlido, estos
cuatro estados (representados por lo general con dos bits) son comnmente
conocidos como "doble punto de informacin. El conjunto de todos los
atributos de datos definidos para Pos es una clase de dato comn llamada
doble punto controlables (DPC).

IEC 61850-7-3 define las clases de datos comunes para una amplia
gama de aplicaciones conocidas. El ncleo comn de clases de datos se
clasifica en los siguientes grupos:

Informacin de estado

Informacin medida

Informacin sobre estados controlables

Informacin analgica controlable

Configuracin de estados

45

Configuracin analgica

Informacin de descripcin

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 continuacin se
muestra en la figura 7 un ejemplo del modelo de estructura jerrquica de un
objeto y sus interrelaciones con los nodos lgicos y sus atributos de datos.
En este caso se tomar el objeto de dato Posicin (Pos) del nodo lgico
XCBR

Figura: 7. Estructura jerrquica del nodo lgico XCBR. Fuente:

Estndar IEC 61850-7-1

46

El objeto Pos es ms que un simple valor, est constituido por varios

atributos de objeto que a su vez estn clasificados de la siguiente manera:

Control (estados, valores medidos, configuracin)

Estado.

Substitucin.

Configuracin, descripcin y extensin.

El objeto Pos tiene aproximadamente 20 atributos. Por ejemplo el

atributo Pos.ctVal, representa la informacin controlable (puede activarse o
desactivarse). Por otro lado, el atributo Pos.stVal representa la posicin 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 tambin tiene atributos que indican cundo se debe procesar el

comando de control (tiempo de operacin), la accin que origin el comando,
el numero de control, la calidad y la informacin de la etiqueta de tiempo; que
indican la validez actual del valor del estado y el tiempo de la ltima
modificacin del valor de su estado.

4.3.3 Modelo de clase del nodo lgico.

A continuacin se describirn algunas de las caractersticas que deben

tener los nodos lgicos del protocolo IEC 61850. Cada uno de ellos deben
contener una composicin de informacin, Data Set, BRCB, URCB, LOG,
SGCB, GoCB, GsCB, MSVCB y USVCB, que se explicaran a continuacin.

47

Los atributos de la clase de nodo lgico son:

LNNAME: (nombre del nodo lgico) Identifica los nodos lgicos de una
manera precisa dentro del alcance de un dispositivo lgico.
LNRef: (referencia de objeto del nodo lgico) Es la nica ruta en el
nombre del nodo lgico. Por ejemplo la referencia de objeto de LNRef
debera ser:
LDName/LNName

Data: (Informacin) Identifica la informacin contenida en el nodo

lgico.
DataSet: (grupo de informacin) Se refiere a un Data Set que este
contenido en un nodo lgico.
BufferedReportControlBlock: (bloque de control de reportes con
buffer) que este contenido en el nodo lgico.
UnbufferedReportControlBlock: un URCB (bloque de control de
reportes sin buffer) que este contenido en un nodo lgico.
LogControlBlock: Identificara un LCB (bloque de control de registros)
contenido en el nodo lgico.

48

 SettingGourpControlBlock: Este atributo deber identificar el SGCB

(bloque de control de configuracin de grupos) que este contenido en
el nodo lgico 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 lgico.

Para los nodos lgicos 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

49

para el cliente. Para hacer uso de este servicio se deben tomar en

cuenta los siguientes parmetros:

LNReference: Debe contener la referencia de objeto LNRef del nodo

lgico.

ACSIClass: Este parmetro 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 parmetro indica que la solicitud de servicio se ha

logrado. De haberse logrado de manera satisfactoria, el resultado
deber regresar el parmetro InstanceName. Este debe contener un
nombre de objeto de un modelo de clase ACSI solicitado. En el caso
que el nodo lgico 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 lgico.

Response- : Este parmetro 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 informacin hecha visible y por lo tanto accesible para el
cliente del nodo lgico referenciado. De igual forma que en el servicio

50

anteriormente explicado se deben tomar en cuenta los siguientes

parmetros:

LNReference: Este parmetro debe contener la referencia de objeto

LNRef del nodo lgico.

FunctionalConstraint: Este debe contener el parmetro de la limitacin

funcional (FC) para filtrar los respectivos atributos de dato de todos los
datos contenidos en el nodo lgico.

Response +: Este parmetro debe indicar que la solicitud de servicio

fue exitosa. Un resultado exitoso resultara en los parmetros,
mostrados en la tabla 3 a continuacin.

Tabla 3. Atributos de solicitud de servicio exitosa.

DataAttributeReferente: Este parmetro debe contener la referencia
de objeto de un atributo de dato contenido en un nodo lgico que
podr ser retornado de acuerdo al valor de la limitante funcional (FC)
recibida en la solicitud.

DataAttributeValue: Este parmetro debe contener el valor de un

atributo de dato de la informacin contenida en el nodo lgico
referenciado. Solo los valores de aquellos atributos de datos que
estn igual al valor del parmetro FunctionalConstraint en la
solicitud del servicio, sern retornados.

Response-: Este parmetro debe indicar que la solicitud de servicio

fallo, devolviendo un error de servicio.

51

Es importante resaltar que en el anexo C se puede observar las

definiciones de clase de los nodos lgicos 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 lgicos sean

capaces de interactuar entre ellos, deben tener la capacidad de interpretar y
procesar la informacin recibida y los servicios de comunicacin utilizados.
Por esta razn es necesario estandarizar los objetos de datos asignados a
los nodos lgicos y su identificacin dentro de los mismos.

Los datos y servicios de una aplicacin pueden ser modelados en tres

niveles. El primer nivel describe modelos abstractos y servicios de
comunicaciones usados para intercambiar informacin entre los nodos
lgicos. Los niveles 2 y 3 definen especficamente el modelo de los objetos.
Esto incluye la descripcin de las clases de datos con sus atributos y su
relacin con los nodos lgicos.
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,
tambin permite otras operaciones, tales como la de controlar equipo
primario.
Nivel 2: clases de datos comunes (CDC)

52

El segundo nivel define las clases de datos comunes Common Data

Classes. Estas definen informacin estructurada con uno o ms atributos. El
tipo de dato de un atributo puede ser uno bsico, 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 aplicacin
Nivel 3: clases de nodos lgicos compatibles y clases de datos
Este nivel define un modelo de objeto compatible especificando las
clases de nodos lgicos y clases de datos. No hacen falta ms
especificaciones que las definiciones del nodo lgico y la clase de datos.

A continuacin se presenta la tabla 4 con los tipos de clases de datos

y la cantidad de cada uno de ellos:
Tabla 4. Clases de datos del estndar. Fuente: Estndar IEC 61850
CLASES DE DATOS

CANTIDAD

Informacin del sistema

13

Informacin del equipo fsico

11

Medibles Measurands

66

Valores medidos

14

Data controlable

36

Informacin de estados

85

Configuracin

130

TOTAL

355

53

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 caractersticas de los reportes, y se
dejar a un lado las caractersticas 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 automticamente luego de algn cambio de
estado, o peridicamente de manera independiente. Estos pueden agrupar
los atributos de datos que se consideren importantes en estructuras lgicas
llamadas Data Set. Estos Data Set son utilizados como base para la
elaboracin de los reportes y registros.

Los Data Set especifican qu objetos y qu atributos irn en los

reportes y registros.

El proceso de generacin y transmisin de los reportes es controlado

por un bloque de informacin llamado Bloque de Control de Reportes (RCB).
Un RCB mantiene la informacin necesaria para generar un reporte, tales
como: campos que deben ser incluidos en el reporte, eventos que activan la
generacin de un reporte, orden de secuencia del reporte, entre otros.
Normalmente el RCB controla los reportes generados de uno o ms nodos
lgicos hacia un solo cliente. Para permitir que mltiples clientes reciban los
mismos valores de datos, mltiples instancias de la clase RCB deben ser
habilitadas. A continuacin se puede observar la figura 8 donde se

54

representa el proceso de elaboracin de los reportes (Reports) y registros

(Logs)

Figura: 8. Modelo conceptual del proceso de elaboracin de reportes y registros

Fuente: Estndar IEC 61850-7-1

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 configuracin

del bloque de control de reportes. Para que sean habilitados cualquiera de
55

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 caracterstica 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 prdida de comunicacin, el proceso de elaboracin de reportes
continuar apenas se restablezca la comunicacin otra vez, y enviar todos
aquellos reportes almacenados en el buffer durante la perdida de
comunicacin, de esta manera no se pierden datos generados en el
momento de la prdida de comunicacin. Adicionalmente el bloque de control
de reportes buffered garantiza secuencia de eventos (SoE) hasta algunos
limites prcticos (por ejemplo, tamao de buffer y tiempo mximo de
interrupcin).

Para una mejor comprensin del mecanismo bsico de un reporte

buffered y el ejemplo de prdida de comunicacin, se muestra la figura 9.

56

Figura: 9. Representacin conceptual del bloque de control de reportes

buffered. Fuente: Estndar IEC 61850-7-1

Los bloques de control de reportes buffered poseen varios atributos

que controlan el proceso de elaboracin 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

elaboracin de los reportes.

DatSet: Hace referencia al conjunto de datos, al cual sus valores sern

incluidos en el reporte.

57

ConfRev: Contiene la revisin de la configuracin para indicar si algn

miembro del Data Set ha sido eliminado o la reorganizacin 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.
Razn para la inclusin (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 debera generar un reporte independiente.

58

Ampliando un poco ms sobre las caractersticas del atributo de

tiempo de buffer (BufTm), se puede sealar que gracias a esta propiedad,
el servidor puede reducir el nmero de reportes generados. Esto se debe a
que luego de un primer evento, otros eventos se producirn 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 especfico).
En la figura 10 se puede ilustrar mejor la idea del tiempo de buffer

Figura: 10. Funcionamiento del buffer time. Fuente: Estndar IEC 61850-7

SeqNum: Es el nmero actual en la secuencia de los reportes. Este

nmero 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), Actualizacin de datos (dupd), Cambio de
calidad de un atributo de dato en un nodo lgico (qchg) o un periodo
de integridad (Integrity)

59

IntgPd (periodo de integridad): realiza un reporte con los valores

iniciados por el servidor en un periodo de tiempo pre establecido, de
manera automtica sin que ningn 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

fenmeno que ocurre cuando se satura la capacidad de almacenamiento, se
trata del desbordamiento del buffer o (buffer overflow). Este puede suceder
cuando existe una prdida 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 antigedad, dndole
prioridad a los reportes mas recientes. El cliente tambin puede hacer uso
del atributo PurgeBuf para que limpie la memoria del burffer

En el caso de que una segunda notificacin de un mismo miembro del

Data Set haya ocurrido antes de la expiracin 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.

60

 Para datos analgicos 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 comunicacin se activa automticamente el atributo

PurgeBuf, borrando as, toda la informacin del buffer.

No puede enviar repotes segmentados

Cualquier cliente puede tener acceso a los reportes

Puede ser ubicado en cualquier nodo lgico.

El envi de datos en este tipo de reportes se hace bajo un sistema de

mximo 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 comunicacin 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 continuacin, todos los
dems atributos sern igual a los del bloque de control de reporte con
buffer.

61

URCBName: Este atributo deber ser el nombre del URCB, que lo

identifique de forma no ambigua en el nodo lgico

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 emisin de reportes.

Mientras el bloque de control de reportes sin buffer, se encuentre

habilitado para la emisin de reportes, no se podr cambiar o modificar
valores de los atributos del URCB, a excepcin de desactivar y activar las
opciones generales de disparo.

Si la comunicacin se pierde con el cliente, el cual haba 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 debern estar autorizados
para modificar cualquier atributo de ese URCB.

62

Si el atributo Resv no est configurado a TRUE, entonces al

establecer el campo RptEna a TRUE reservara el URCB implcitamente.

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
especfico). Por lo tanto la referencia de objeto se puede obtener de la
definicin del Data Set

Si se envan 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 disposicin para determinar a qu miembros del Data Set
pertenecen estos valores. La SCSM specific comunication service mapping
define uninclusion-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.

63

Figura: 11. Miembros del data set y el bitstring de inclusin. Fuente: Estndar
IEC61850-7-1

4.5 Configuracin del IEC 61850 en los Rels UR de General Electric

4.5.1 Rels UR de GE

Los rels de la serie Universal Relay (UR) de General Electric son

equipos digitales constituidos por una arquitectura modular y diseados para
ser multi-funcionales. Para esto tiene una unidad central de procesamiento
(CPU) que maneja mltiples tipos de seales de entradas y salidas. Los URs
pueden comunicarse a travs de una red de rea local (LAN), con un
operador a travs de una interfaz, con un equipo de programacin, o con otro
dispositivo UR.

64

Segn el manual tcnico del UR-L90, las entradas de este equipo

aceptan una variedad de seales digitales o analgicas provenientes de
campo. El equipo asla y convierte estas seales externas en seales lgicas
usadas por el rel. Con respecto a las salidas del equipo, este convierte y
asla las seales lgicas generada por el rel en seales analgicas o
digitales que pueden ser usadas por dispositivos de control de campo.

Este dispositivo es el encargado de realizar la proteccin y/o control de

forma automatizada en las subestaciones elctricas, mediante algoritmos
lgicos que vienen programados de fbrica. Aunque tambin puede
personalizarse su lgica interna utilizando ecuaciones lgicas en su entorno
de programacin, el FlexLogic.

Se habla de una familia de rels UR, ya que hay diferentes

configuraciones y caractersticas en cada uno de ellos. Segn su uso, por
ejemplo tenemos:

F60: Rel de Proteccin de Alimentador

C60: Controlador de Baha

C30: Controlador

D60: Rel de Proteccin de Distancia

D30: Rel de Proteccin de Distancia

L90: Rel de Diferencial de Lnea

B90: Rel de Proteccin de Barra

T60: Rel de Proteccin de Transformadores

65

4.5.2 Nodos lgicos disponibles en los URs L90 con firmware versin 5.7.

La norma establece una gran cantidad de nodos lgicos, de los cuales

algunos los contienen los rels UR de General Electric. Cabe destacar que
no toda la familia de rels UR tienen los mismos nodos lgicos disponibles.
Esto depende del tipo de rel, es decir, de las caractersticas especificas de
cada rel de la familia UR. Por ejemplo, el nodo lgico de proteccin de
distancia (PDIS) esta disponible solo en el rel de distancia UR D60.

A continuacin se facilita un listado de los nodos lgicos disponibles

en el UR L90 de General Electric.

Nodos Lgicos del sistema.

LPHD: Contiene informacin acerca del L90 como dispositivo fsico.
LLNO: Contiene informacin acerca del L90 como equipo lgico.

P: Nodos Lgicos para funciones de proteccin.

PDIF
PDIS
PIOC
PTOC
PTOV
PTRC
PTTR
PTUV

R: Nodos Lgicos para funciones relacionadas con proteccin.

RBRF

66

RFLO
RPSB
RREC

G: Nodos Lgicos para referencias generales

GGIO: Es el tipo de nodo lgico 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 dems nodos disponibles en el rel. Los nodos lgicos
GGIO se pueden a su vez subdividir en varios como son: GGIO1, GGIO2 y
GGIO3.

El nodo lgico GGIO1, que refleja los valores de estado digital, est
disponible en el L90 para dar acceso a un mximo 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 tambin 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

67

recomiendan solo para uso local de estados. Este dispositivo facilita las
herramientas de configuracin para permitir la seleccin del nmero de
estados digitales disponibles y para permitir la seleccin de los operandos del
FlexLogic del L90 que manejas los estados del GGIO1.

El nodo lgico GGIO2 refleja los valores de controles digitales, que

estn 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 travs
de los servicios del modelo de control del estndar IEC61850 (ctlModel), que
se enlista a continuacin:

Status only.

Control directo con seguridad normal.

Control SBO con seguridad normal.

Los ajustes de configuracin estn disponibles para seleccionar el

modelo de control para cada punto. Segn su manual tcnico (GE Industrial
Systems, 2008), cada entrada virtual usada a travs de las GGIO2 debera
tener su funcin de entrada virtual programada como habilitada (enabled) y
su ajuste correspondiente

GGIO2 CF SPSCO 1(64) CTLMODEL

programado a la configuracin de control apropiada.

Ahora bien, por otro lado, el nodo lgico GGIO3, refleja los estatus
digitales y valores anlogos disponibles para proveer el acceso de los
clientes a los valores recibidos va mensajes GOOSE configurables. Los

68

valores de las indicaciones de estatus digital y de valores analgicos en

GGIO3 se originan en los mensajes GOOSE enviados por otros dispositivos.

M: Nodos Lgicos para mediciones y medidas

MMXN
MMXU

X: Nodos Lgicos para el SWITCHGEAR

XCBR
XSWI

4.5.3 Reportes en el UR.

Segn su manual tcnico UR L90 (GE Industrial Systems, 2008), en

los rels UR los reportes con buffer y sin buffer se encuentran disponibles
en los nodos lgicos GGIO1 para valores de estados binarios, y en los nodos
que van desde el MMXU1 hasta el MMXU6 para los valores analgicos
medidos. Los reportes se pueden configurar haciendo uso del programa de
General Electric EnerVista UR Setup, algn programa de configuracin de
subestaciones o a travs de un cliente IEC61850.

En este dispositivo electrnico 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.

69

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).

70

4.5.4 Tipos de comunicaciones 61850 que soporta el UR de General

Electric.

Comunicaciones tipo Cliente/ Servidor

Este es un tipo de comunicacin orientada a conexin. El enlace es

iniciado por el cliente, as como la comunicacin que tambin 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 subestacin, tales como por ejemplo: rels de proteccin,
medidores, RTU, transformadores o controladores de baha compatibles con
el IEC 61850.

Comunicaciones del tipo Peer to Peer o (P2P).

Este es un tipo de comunicacin de alta velocidad que no est

orientado a la conexin, usualmente se utiliza entre los equipos de campo de
la subestacin. Los mensajes GSSE y GOOSE son mtodos de
comunicacin 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 configuracin de UR offline en el EnerVista UR Setup siguiendo
los siguientes pasos:

71

1. Haciendo click en el botn derecho del mouse, en el rel UR

conectado o en la configuracin de UR offline, y luego
seleccionando del men la opcin Create ICD File.(Figura 12)

Seccin de
configuracin
online

Seccin de
configuracin
del UR offline

Figura: 12. Ejemplo de creacin de un archivo ICD. Fuente: Manual del rel UR L90

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 travs de la configuracin offline de los URs, se crea el archivo ICD

mucho ms rpido que si se hace directamente del rel.

72

4.5.6 Como importar un archivo SCD con EnerVista UR Setup.

El siguiente procedimiento describe como actualizar un rel UR con

una nueva configuracin 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 cmo importar un archivo SCD. Fuente: Manual del
rel UR L90

73

2. Seleccione el archivo SCD guardado y haga click en Open.

3. El programa abrir el archivo SCD y pedir al usuario guardar un URseries setting file, seleccione una ubicacin y luego dele nombre al
archivo URS (UR-series relay settings)
4. Luego que el archivo URS es creado, modifique cualquier
configuracin (si es necesario).
5. Para actualizar el rel con la nueva configuracin, haga click derecho
en el archivo de configuracin (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 configuracin

se actualizar en el dispositivo seleccionado.

(Figura 14)

Figura: 14. Ejemplo de cmo importar un archivo SCD 2.

Fuente: Manual del rel UR L90

74

4.5.7 Configuracin general del protocolo IEC 61850 en los rels UR

de GE

A la hora de realizar cualquier configuracin en estas ventanas del

EnerVista UR Setup, se debe proceder a guardar los cambios antes de cerrar
la ventana, de lo contrario no se harn efectivos los cambios. Para esto se
debe hacer clic en el botn Save, como lo ilustra la figura 15.

Para realizar la configuracin 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

conexin 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. Configuracin del servidor

75

2. Para configurar las seales de campo se utiliza el nodo lgico GGIO1, que
se ubica en el mismo sub. men de IEC 61850. (Figura 16).

Figura: 16. Configuracin seales de campo.

3. Para configurar los mandos en el UR, se hace uso del nodo lgico GGIO2.
(Figura 17).

Figura: 17. Configuracin de los mandos del UR.

76

4. Para realizar la configuracin de los reportes, se accede a Report Control

Configuration. En esta ventana se podr encontrar diferentes tipos de
reporte segn el modelo de UR que se este utilizando. (Figura 18)

Figura: 18. Configuracin de reportes.

77