JWG IEC 61850

Grupo de Trabajo Conjunto IEC 61850 – RIAC

(Región Ibero-Americana de Cigré)

Informe Técnico

Tecnologías necesarias para implementación de subestaciones IEC 61850

Agosto 2010

Página 1 de 83
El Grupo de Trabajo Conjunto ó Joint Working Group (JWG IEC 61850) de la Región
Iberoamericana (RIAC) de Cigré, fue creado en la Bienal de París en 2006, comenzando su
tarea en 2007.

Lo integran representantes de los Comités de Estudio (CEs) ó SCs (Study Committees)

internacionales B3, B5, y D2 de la Región Iberoamericana

El objetivo del JWG IEC 61850 es profundizar el estudio de las tecnologías necesarias para
implementación de subestaciones que respondan a la norma IEC 61850, intercambiar
experiencias de implementación de Sistemas de Automatización de Subestaciones (SAS,
Substation Automation System) en las Empresas Eléctricas de la Región, y difundir esas
experiencias.

Integrantes del JWG IEC 61850

Nombre SC País Empresa
Ing. Carlos Samitier Otero Presidente D2 ES GNE S.L.
Ing. Rodolfo Pellizzoni Secretario D2 AR Transener S.A.- Transba S.A.
Ing. Allan Cascaes Pereira Miembro Regular B5 BR UERJ/ONS
Ing. Fernando González Miembro Regular B5 AR Transener S.A.- Transba S.A.
Ing. Luis Funes Miembro Regular B5 AR Transener S.A.- Transba S.A.
Ing. Enrique Dufour Miembro Regular B5 AR Transener S.A.- Transba S.A.
Ing. Pablo Luis D´Amore Miembro Regular D2/B5 AR Siemens S.A.
Ing. Roberto Vignoni Miembro Regular D2 AR Facultad de Ingeniería - UNLP
Ing. Guillermo Galarza Miembro Regular D2 AR ABB
Ing. Marcelo Kovalenko Miembro Observador B3 AR ABB
Ing. Cristian Carlsson Miembro Regular B5 AR ABB
Ing. Ezequiel Schiavino Miembro Observador B5 AR ABB
Ing. Guillermo Domínguez Stagnaro Miembro Regular B5 AR EDENOR
Ing. Sebastián López Miembro Regular B5 AR Artec Ing.
Ing. Luis Choque Miembro Regular AR Artec Ing.
Ing. Fabián Fernández Miembro Regular B5 AR AREVA T&D Argentina
Ing. Fernando Alonso Miembro Observador AR AREVA T&D Argentina
Ing. Fernando Calero Miembro Regular D2 BO SELINC
Ing. Mauricio Rivera Miembro Regular B5 BO TDE
Ing. Claudio Trigo de Loureiro Miembro Regular D2 BR FURNAS
Ing. Marcelo Edgard de Carvalho Paulino Miembro Regular B5 BR ADIMARCO
Ing. Juan Carlos Sánchez Martín Miembro Regular B3/B5 ES REE
Ing. Felipe Álvarez Cuevas Figueirola Miembro Regular D2 ES ENDESA
Ing. Gloria Marina García Prudencio Miembro Regular D2 ES ENDESA
Ing. Cuitlahuac Picasso Blanquel Miembro Regular D2 MX IIE
Ing. Joaquín García Miembro Observador D2 MX IIE
Ing. Ricardo Cartazo Miembro Regular B5 PT REN
Ing. Luiz Francisco Anarmo Miembro Observador B5 BR ELETROSUL
Ing. Fernando Rodríguez Miembro Observador BR ABB
Ing. André Stefanello Somavilla Miembro Observador BR CEEE
Ing. Joao Ricardo da Mata Soares de Souza Miembro Observador BR COPEL

Página 2 de 83
 Indice

1. Introducción
2. Criterios de diseño de subestaciones

3. Requerimientos de comunicaciones

4. Comunicaciones – Mensajes – Pila de protocolos (stack)

5. Herramientas de ingeniería y documentación

6. Validación del sistema

 Ensayos de conformidad
 Ensayos de interoperabilidad
 Ensayos de funcionalidad

7. Migración. Actualización (retrofit) y ampliación

8. Mantenimiento. Instrumentación, formación, explotación del sistema

ANEXO A. Ethernet

ANEXO B. Ejemplos de implementación – Proyectos Piloto

 ANEXO B.1 – Experiencia SC B5 Argentina – Universidad de Buenos Aires

(UBA)

 ANEXO B.2. – Proyecto Piloto E.T. MERCEDES 132/33/13,2 kV – Transba S.A. -

Argentina

ANEXO B.3. – Experiencias S.E. LA VENTA

(Ing. Cuitlahuac Picasso)

ANEXO B.5. – Experiencia “Integra”

(Ing. Ricardo Cartazo)

ANEXO B.6. – Experiencias REE-IBERDROLA

(Ing. Juan Carlos Sánchez)

Página 3 de 83
 Informe Técnico

Tecnologías necesarias para implementación de subestaciones IEC 61850

1. Introducción
El presente informe tiene por objetivo brindar una visión conceptual de la norma IEC 61850,
orientado a los especialistas de la Empresas Eléctricas que deban implementar por primera vez
Sistemas de Automatización de Subestaciones (SAS) con IEDs (Intelligent Electronic Devices)
con funciones de protección, control y medición que cumplan con la norma.

Previo a la descripción de aspectos particulares de la norma ó serie IEC 61850, se realiza una
descripción de sus aspectos más salientes con el fin de brindar una visión general del espíritu
de la norma destacando sus ventajas como así también las dificultades que pueden
presentarse en su implementación.

Este informe no solamente está destinado a los especialistas de control, comunicaciones y

protecciones, sino muy especialmente a los especialistas de subestaciones, quienes en un
futuro cercano, seguramente deberán proyectar las nuevas subestaciones con esta tecnología,
lo que implicará un sustancial cambio en el diseño de las mismas.

En el capitulo 1, se brinda un panorama conceptual del alcance de la norma, abarcando sus

principales aspectos. El capitulo 2 trata sobre los criterios de diseño de Sistemas de
Automatización (SAS) de subestaciones. En los capítulos 3 y 4 se brinda un amplio y detallado
panorama de los requerimientos de comunicaciones, comenzando con los aspectos
introductorios y prácticos para profundizar en los puntos principales del tema. En el capitulo 5
se analizan los importantes aspectos de las Herramientas de Ingeniería, resaltando carencias y
retos existentes en la Ed.1 de la norma en este tema. El capitulo 6 trata otro tema de particular
importancia como son los ensayos de conformidad, interoperabilidad y funcionales. En el
capitulo 7 se analizan aspectos de migración, actualización y ampliación de subestaciones
existentes a subestaciones IEC 61850. El capitulo 8, correspondiente a Seguridad, a pesar de
ser un tema de vital importancia, no se ha desarrollado, sino que se hace referencia a las
publicaciones de IEC existentes sobre el tema.

En el Anexo A, se brinda una breve síntesis de Ethernet, indicando los aspectos más
importantes vinculados con la norma.

En los Anexos B, se han incorporado la descripción de experiencias prácticas y proyectos

Piloto, entendiendo que pueden ser de ayuda para aquellos especialistas de Empresas
Eléctricas que realicen sus primeras implementaciones de subestaciones IEC 61850, conocer
las ventajas de esta nueva norma, pero también las dificultades que han surgido en la
implementación práctica de la misma.

1.1 Aspectos importantes de la norma IEC 61850

El objetivo básico de la norma IEC 61850 (Communication networks and systems in

substations-Ed.1), "Redes y sistemas de comunicaciones en subestaciones", publicada a fines
de 2004, aplicable a los Sistemas de Automatización de Subestaciones (SAS), es estandarizar
la comunicación entre IEDs", es decir la comunicación, entre Dispositivos Electrónicos
Inteligentes (IEDs) de distintos fabricantes. En otras palabras, el objetivo es definir un Sistema
de Automatización de Subestación que permita la interoperabilidad entre IEDs de diversos
fabricantes, o más precisamente, entre funciones a ser realizadas por el equipamiento
residente en la subestación, es decir en dispositivos físicos, de diferentes fabricantes.
Interoperabilidad es la habilidad de dos ó más IEDs del mismo fabricante, o de diferentes
fabricantes, de intercambiar información, y utilizar esa información para una cooperación

Página 4 de 83
correcta. No se debe confundir interoperabilidad con "intercambiabilidad", concepto y
funcionalidad más amplia que no está incluida en el objetivo de la norma.

Un Sistema de Automatización de Subestaciones, SAS, opera, protege, monitorea, etc., la

subestación, es decir el sistema primario. Para este propósito utiliza totalmente tecnología
numérica y enlaces seriales de comunicación (sistema de comunicación).

Las funciones de un “substation automation system” se refieren a tareas que deben ser
realizadas en la subestación. Estas son funciones para controlar, monitorear y proteger el
equipamiento de la subestación y sus alimentadores. Además, existen funciones, que son
necesarias para mantener el SAS, por ej., para configuración del sistema, gestión de
comunicaciones o gestión del software.

Es importante resaltar, que la norma no tiene como objetivo lograr intercambiabilidad entre
IEDs, ni la completa configuración de los equipos en una subestación, sino únicamente
interoperabilidad en lo que respecta a las comunicaciones entre dispositivos.

Para ello, define,

1. La “suite” o conjunto de protocolos más adecuados y la forma de utilizarla para cumplir

con los requisitos necesarios.
2. Los modelos de datos que se utilizarán para intercambiar información en tiempo real
(Logical Nodes).
3. El formato de los archivos o ficheros de configuración de las comunicaciones
necesarios para conseguir interoperabilidad.

Communication

Configuration Data Model

Figura 1. Componentes fundamentales

Aunque la norma está evolucionando e incorporando nuevas funcionalidades, es un error

frecuente intentar utilizar los archivos ó ficheros de configuración para estandarizar la completa
configuración de los IEDs, así como ampliar los LN que se han definido para intercambiar
información en tiempo real con nuevos atributos con el fin de configurar todos los parámetros
de los IEDs. Es importante entender que estos dos puntos están fuera del alcance de esta
norma, para utilizar correctamente las posibilidades que esta ofrece.

Los archivos ó ficheros de configuración son para intercambiar información de comunicaciones

entre las diferentes herramientas de ingeniería, y los LN tienen por finalidad intercambiar
información en tiempo real entre servidores y clientes en el sistema. Por ejemplo, los atributos
del tipo ST (Settings) en un nodo lógico (LN) deberían utilizarse únicamente cuando es
necesario cambiar parámetros de los equipos en tiempo real, y no utilizarlos para construir una
lista completa de parámetros de un equipo.

Esto no significa, que el concepto no pueda extenderse, pero si debería quedar claro la función
de cada parte de la norma para diferenciar funciones y utilizar cada parte en su justa medida.
Históricamente, se han utilizado protocolos serie en configuraciones punto a punto o punto
multipunto para realizar estas funciones. Estos planteamientos, precisaban diferenciar servicios

Página 5 de 83
o subsistemas en redes diferentes por lo que la arquitectura de comunicaciones, aunque
simple, acababa convirtiéndose de una topología inflexible y complicada de mantener. Más
aún, en las automatizaciones mas modernas de subestaciones es cada vez mas común la
utilización de dispositivos electrónicos de control y protección, a veces especializado y a veces
multifunción, pero la realidad es que el número de dispositivos de este tipo crece en cada
nueva generación de subestaciones en un número importante, con lo cual las antiguas
topologías de comunicaciones ya no son tan eficaces.

El alcance de la serie IEC 61850, no se limita a la interoperabilidad, sino que es mucho más
amplio, ya que propone no sólo un nuevo concepto de automatización en subestaciones,
basado en una nueva arquitectura de
System Aspects
comunicaciones, sino que también define
Part 1: Introduction and Overview modelos de información, y lenguajes de
Part 2: Glossary configuración basados en el lenguaje
Part 3: General Requirements “EXtensible Markup Language” (XML).
Part 4: System and Project Management Asimismo estandariza la utilización de redes
Ethernet con prioridad, define el intercambio
Part 5: Common Requirements for Functions
and Device Models de mensajes críticos denominados “Generic
Object Oriented Substation Event” (GOOSE),
Configuration como así también valores muestreados
Part 6: Configuration description Language for
Communication in Electrical Substation
(Sampled Values) para las mediciones de los
related IEDs transformadores de medida de corriente y
tensión. Estas mediciones pueden realizarse
a través de nuevos modelos de
transformadores de medición, cuyos valores de salida son digitales o mediante unidades
específicas que convierten las mediciones analógicas convencionales en información digital
denominadas “merging units”.

Los modelos de información y los servicios de comunicaciones son independientes del

protocolo, y la utilización del protocolo “Manufacturing Message Specification” (MMS) en la
capa aplicación y servicios de web, permitirán el crecimiento y vigencia de esta norma al
permitir incorporar nuevas tecnologías de comunicaciones.

La Ed.1 de la serie, conformada por 14 Publicaciones (Tabla 1), es novedosa no sólo en cuanto
al enfoque que propone en cuanto a modelos de dispositivos de la subestación, sino también
en lo relativo al modelado de las comunicaciones que requiere la definición de objetos y
servicios provistos por los objetos.

Data Models

Tabla 1 – Publicaciones serie IEC 61850 – Part 7-4: Compatible Logical Nodes Classes and
Ed.1 Data Classes
Part 7-3: Common Data Classes
Abstract Communication Services
Part 7-2: Abstract Communication Services (ACSI)
La definición de un Lenguaje de Configuración Part 7-1: Principle and Models
de Subestación (SCL), y un ensayo de Mapping to real Communication Networks (SCSM)
conformidad normalizado, complementan la Part 8-1: Mapping to MMS and to ISO/IEC 8802-3
serie. Part 9-1: Sampled Values over Serial
Unidirectional Multidrop Point-to-Point
La norma define cuatro aspectos básicos: link
protocolos de comunicación IP y MMS Part 9-2: Sampled values over ISO 8802-3
(Manufacture Message Specifications), Testing
modelado de los dispositivos de la subestación, Part 10: Conformance Testing
normalización de nombres de objetos y normalización de servicios, como así también nuevas
herramientas de ingeniería. Los modelos de objetos y servicios son independientes de los
protocolos de comunicación.

Página 6 de 83
 Con respecto a las comunicaciones en la subestación, quedan definidos dos sentidos de
transmisión de información. Uno vertical de tipo cliente –servidor, y otro horizontal de tipo par-
a-par ó peer-to-peer.

Cliente 1 Cliente 2

Servidor Servidor
1 2

Figura 1 – Comunicaciones cliente - servidor

La gran difusión de la tecnología Ethernet ha motivado que en la norma IEC 61850 se adoptara
esta tecnología para las LAN (Local Area Networks) ó redes de área local en las
subestaciones.

Otra característica novedosa, es que en la norma se sugieren las Partes de interés de la Serie
para los diversos actores de las empresas eléctricas, como se muestra en la Tabla 2.

USUARIO Parte 1 Parte 5 Parte 7-1 Parte 7-2 Parte 7-3 Parte 7-4 Parte 6 Parte 8 y 9
Introducción Requerimientos Principios Servicios Clases de Nodos Lógicos SCL Comunicación
Datos
Protecciones Gerente x N.A. Cap. 5 N.A. N.A. N.A. N.A. N.A.
Ingeniero x x x En parte x x x N.A.
Comunicaciones Gerente x N.A. N.A. N.A. N.A. N.A. N.A. x
Ingeniero x x Cap. 5 X N.A. N.A. x x

Tabla 2.

1.2 Arquitecturas pre y post IEC 61850

Las arquitecturas utilizadas hasta la publicación de la norma IEC 61850, hacían difícil
implementar sistemas redundantes. Como conocido, en las mencionadas arquitecturas el
mantenimiento se realiza mediante una red paralela y separada o localmente.

Para solucionar este problema, la norma IEC propone construir el sistema de automatización
sobre una red de área local (LAN) Ethernet teniendo en cuenta la madurez alcanzada por esta
tecnología. Esto nos permite virtualizar un número importante de conexiones peer-to-peer
sobre la misma infraestructura física garantizando redundancia, anchos de banda, latencia,
fiabilidad y seguridad.

Diferentes topologías de red son posibles. En la figura, se muestra una topología anillo simple.
Es de destacar que basándose en la tecnología Ethernet, la norma permiten integrar en una
misma red de comunicaciones diferentes servicios (MMS, GOOSE, FileTransfer, SNTP, SNMP,
etc.) garantizando redundancia y fiabilidad (RSTP para redundancia, SNMP para supervisión,
etc.).

Página 7 de 83
 Armario RTU
Armario AT2
Armario AT1

Anillos AT

Anillos MT

MT1 MT2 MT9 MT10

cubicle cubicle cubicle cubicle
….

Figura 1.2 Ejemplo de arquitectura

1.3 Estructura de los datos

Otro aspecto importante en la nueva concepción de automatización propuesta por la norma, se

relaciona con la estructura de los datos que los diferentes equipos se intercambian. Mientras
los protocolos clásicos suelen funcionar bajo un concepto de direccionamiento numérico y
lineal, la norma IEC trabaja con un modelo de datos estructurado. La aproximación lineal,
aunque simple vuelve a ser insuficiente para las necesidades actuales. Dada esta estructura de
direccionamiento lineal (difícil de mantener) cada punto de control precisa una dirección
arbitraria e individual. Mediante la novedosa aproximación del IEC 61850, los datos de tiempo
real son:

 Direccionados estructuradamente. Ej. en un IED controlando dos seccionadores,

tendríamos XSWI1$Pos y XSWI2$Pos, frente dos IOAs (Input-Output Addreses)
arbitrarias 100 y 107, o combinaciones de números de los protocolos IEC 60870-5-
xxx, ó DNP 3.0.
 Por tanto, auto descriptivo.
 Los datos son calificados en origen (Ej. Escala de magnitudes analógicas).
 Se contemplan todas las necesidades de tipos de datos. (Posición, Curva, Magnitud
Analógica, Número de serie, Descripción, …)

Para poder definir cualquier dato, se distinguen las siguientes categorías:

o Basic DC (Basic Data Class): Tipos de datos básicos: entero, real…

o Composite DC (Composite Data Classes): Tipos de datos compuestos: Escala,
Calidad…
o CDC (Common Data Class): Tipos de datos comunes: Medida, Digital simple…
o LN: Nodos Lógicos: Interruptor, seccionador, transformador de instrumentación o
medida, protección de distancia, etc.

La figura 1.3 muestra de forma esquemática, cómo un nodo lógico del tipo transformador de
intensidad (TCTR) está compuesto de varios atributos (Loc: Mando Local, Amp: Valor
instantáneo de la intensidad…). Este último valor es una clase de datos comunes (CDC,
Common Data Class) del tipo SAV (Sampled Value) que está compuesto a su vez por un
conjunto de atributos (instMag: Magnitud instantánea, sVC: Escala…). Este último campo a su

Página 8 de 83
vez consiste en un tipo de datos compuesto formado por dos atributos (factor de escala y
offset). Cada uno de estos últimos consiste en un tipo de datos simple del tipo FLOAT32 (real
en coma flotante de 32 bits).

LN: TCTR

Loc
Amp CDC: SAV
Artg
instMag
HzRtg
q
t
units
sVC Composite DC:
ScaledValueConfig

scaleFactor
offset Base DC: FLOAT32

mantissa
exponente

Figura 1.3 – Estructura de datos

Lo objetos de control, son ahora variables con nombre y se direccionan según la siguiente
estructura:

Rele1/XCBR1$ST$Loc$stVal

Atributo
Dato

Restricción Funcional

Nodo Lógico

Dispositivo Lógico
Figura 1.4 – Estructura de nombres

Por último, con el fin de intercambiar información de comunicaciones entre los diferentes
equipos (principalmente entre clientes y servidores) se define una sintaxis de archivos ó
ficheros de configuración que permiten configurar automáticamente los equipos.

1.4 Configuración

Página 9 de 83
En el enfoque clásico, cada IED se configura localmente mediante herramientas particulares de
cada fabricante. No es posible compartir la información de configuración de comunicaciones
entre las diferentes herramientas de ingeniería.

IED
IED
Configurat
IEDConfigurat
Espacio de or
Configurador
Ingeniería or

Propietario
Substation
Automation
System (SAS)
IEDs

Figura 1.4 - Configuración

En la nueva aproximación, los IEDs con categoría de servidor (típicamente equipos de

protección) estarán definidos con archivos o ficheros de configuración estándar concretos (pre-
configurados en una serie de proyecto-tipo) pero no instanciados, (no asignados a un campo ó
una bahía concreta), todavía no están calificados, las variables (en realidad el dispositivo
lógico) todavía no tienen nombre. Archivos ó ficheros *.ICD.

El proceso de ingeniería de particularizar un equipo a un campo ó bahía determinada será tan

simple como dar nombre al dispositivo lógico, asignarle una dirección IP y poca cosa más. En
este proceso obtenemos un archivo ó fichero de configuración instanciado (*.CID) que servirá
para configurar el IED concreto dentro de la subestación y para configurar los clientes de datos
(típicamente el interfase Hombre máquina y el gateway de subestación).

Lado SERVIDORES Lado CLIENTES

side
preconfigured instantiated
IEDs IEDs
ITMI

ITCI

IHMI
*.ICD *.CID System
*.ICD *.CID *.SCD
*.ICD *.CID Configurator

Figura 1.5 – Proceso de configuración

1.6 Arquitectura general de una subestación.

En la figura 1.6, se muestra la arquitectura de referencia de una subestación con IEC 61850.

Página 10 de 83
 10
CC2 1 CC1
0
WAN
Nivel de Subestación

7
1 ING1
7 0
1
0 7

6 1 6 6 1
Nivel de Bahía

3 2

5
Control

Protección
Nivel de Proceso

Teleprotección

Aparamenta

Sistemas de
5 Control y
mantenimiento

4
4

Figura 1.6 – Arquitectura de la subestación

Los números en círculos distinguen la naturaleza de los datos que se intercambian según sean
los equipos que se conectan a nivel lógico. De esta forma tenemos:

1
Datos de protección entre nivel de estación y nivel de posición.
2
Datos de protección entre teleprotecciones.
3
Datos internos (sin especificar) del nivel de posición.
4
Datos de medida (de TV y TI) entre nivel de proceso y nivel de posición.

Página 11 de 83
 5
Datos de control entre nivel de proceso y nivel de posición.
6
Datos de control entre nivel de estación y nivel de posición.
7
Datos de teleconfiguración y telesupervisión.
8
Datos de protección entre niveles de posición.
9
Datos de control internos de nivel de estación.
10
Datos de control entre nivel de estación y los centros de control.

2 10
La norma IEC-61850 alcanza todas las interfaces excepto la y la .

2
Actualmente la interfaz se realiza mediante protocolos propietarios de los fabricantes de
las teleprotecciones y está fuera del alcance de la norma IEC 61850 Ed. 1, debido a sus
especiales requisitos de fidelidad y obediencia. Sin embargo el WG 10-TC 57 se encuentra
redactando la Ed. 2 de la norma que considerará la transmisión de datos entre subestaciones,
por lo que se normalizará sobre la utilización de IEC 61850 para funciones de teleprotección lo
cual constituirá la parte IEC 61850-90-1, que se incluirán en la Ed.2 de la norma.

10
La interfaz es la definida para comunicar el/los centros de control con cada una de las
subestaciones.

Como puede verse en la figura x que refleja la arquitectura de referencia, al utilizarse una red
WAN (típicamente una red IP) el sistema de telecontrol permite conectar varios centros de
control o de ingeniería con las instalaciones, típicamente mediante protocolos IEC 60870-5-
101, IEC 60870-5-104 (TCP/IP), ó DNP 3.0. A efectos de lograr que el Centro de Control pueda
dialogar con las subestaciones, es necesario instalar en éstas un “traductor de protocolo” ó
“gateway” que permita transformar la información de IEC 61850 a los protocolos que utiliza el
Centro de Control. La estandarización de esta comunicación que implica no solamente la
comunicación entre ambos niveles sino también una adecuación de los modelos de datos
utilizados en el Centro de Control, se encuentra en la etapa de elaboración por parte del WG
10-TC 57, como IEC 61850-90-2, que se incluirán en la Ed.2 de la norma.
.

En la misma figura se muestra la descomposición funcional en tres niveles que plantea la

norma:

 Nivel subestación: con dispositivos que tienen visibilidad y agregan datos sobre todas
las posiciones.
 Nivel bahía ó campo: con dispositivos que agregan información principalmente de una
bahía ó campo.
 Nivel proceso: captación de muestras directamente del equipamiento primario.

Los dos primeros niveles están suficientemente maduros para su utilización industrial, sin
embargo, en cuanto a los dispositivos de nivel de proceso (Transformadores de medida
digitales, merging units...) todavía no se ha alcanzado un nivel de maduración suficiente para
ser utilizados. Cabe mencionar al respecto que las interfases 4 y 5 entre niveles de proceso y
de bahía puede ser digital (IEC 61850-9-1 y IEC 61850-9-2) o por cableado convencional. En
este caso el nivel de proceso está integrado en los equipos de nivel de bahía ó campo.

1.7 Dispositivos: Clientes y servidores. Proxies y Gateways. Físicos y Lógicos.

Página 12 de 83
1.7.1 Clientes y servidores
Por definición, un servidor es aquel dispositivo que contiene datos, y cliente el que los lee.
Como ejemplos típicos de clientes tenemos, el gateway de telecontrol y la Consola de Control
Local SCADA (HMI). A nivel físico, un dispositivo, puede actuar como cliente y como servidor.
Por ejemplo una Consola de Control Local SCADA puede actuar a la vez de cliente de datos
para todos los IEDs servidores y como servidor de unos pocos datos (LN IHMI: estado, salud,
numero de placa...) contra el gateway de subestación.

Dispositivo Físico 1 Dispositivo Físico 2 Dispositivo Físico 3

Rol de cliente Rol de servidor

datos

Rol de servidor Rol de cliente Rol de servidor

datos datos

Figura 1.7 – Relación Cliente-Servidor

Los LN definen los datos que ofrece un servidor y los archivos o ficheros de configuración
definen de la misma forma los servidores. Los datos recibidos y las configuraciones en los
clientes son por ello los duales de los de los servidores.

1.7.2 Dispositivos Físicos y Lógicos

Un IED representa un dispositivo físico. Una entidad física con propiedades concretas (numero
de serie, estado (salud), etc. Estos dispositivos se modelan mediante el concepto de dispositivo
lógico (LD). Entonces un IED puede contener varios dispositivos lógicos. Un dispositivo lógico a
su vez debe contener al menos dos nodos lógicos obligatorios a saber:

LLN0: Nodo lógico cero. Contiene la información sobre el dispositivo lógico y los bloques de
control de comunicaciones. También suele contener los grupos de datos para las
comunicaciones. Por lo tanto es un contenedor para todas aquellas informaciones y datos
necesarios para el funcionamiento del protocolo.

LPHD: Contiene información referente al dispositivo físico. Número de serie, descripción,

salud...

Por este motivo, por lo general, un IED no suele contener más de un dispositivo lógico, salvo
en el caso de Gateways y Proxies como veremos en la siguiente sección.

1.7.3 Proxies y Gateways

En ocasiones será necesario modelar un conjunto de dispositivos existentes (Protecciones,
RTUs, etc.) en IEC 61850 con el fin de exportar sus datos al resto de la subestación utilizando
IEC 61850. Para estos casos se ha dispuesto el concepto de Gateway. Un IED que realice
funciones de gateway contendrá un dispositivo lógico para cada dispositivo físico del que hace
de traductor de protocolos (entre protocolo existente e IEC 61850). Para cada dispositivo lógico
representando, la información de otro dispositivo, el LN LPHD contendrá información sobre el

Página 13 de 83
dispositivo físico origen (numero de serie, descripción, salud...). También tendremos un
dispositivo lógico que representa al gateway mismo, en este caso el LPHD contiene
información del gateway. Este concepto se muestra en la figura 1.8.

Proxy/gateway

LD0

LPHD

LLN0
PHD “A”

LD1 LD1

LPHD LPHD

LLN0 LLN0

LN(1) LN(1)
LN(n) LN(n)

LD2 LD2

LPHD LPHD

LLN0 LLN0

LN(1) LN(1)
LN(n) LN(n)

LD5
PHD “B”

LD6
LD5

LD7
LD6
LPHD

LLN0

LN(1)
LN(n)

Figura 1.8 – Mapeado de LN en Gateway/Proxy

Caso especial para la implementación de un control local que accede a las informaciones de
las bahías sin necesidad de comunicarse con los IEDs físicos ya que todos los LN necesarios
están mapeados en el Proxy del control local (Servidor de la unidad de subestación)

Este mismo concepto puede utilizarse en caso de que sea interesante agrupar una serie de
dispositivos en IEC 61850 en un único dispositivo. En este caso, dado que no existe traducción
de protocolos se denomina proxi.

1.8 Nodos Lógicos. Conceptos generales

Página 14 de 83
Con el fin de estructurar la base de datos de una subestación se define el concepto de nodo
lógico (LN). Un nodo lógico es la representación abstracta de una funcionalidad necesaria para
la automatización de una subestación. Su característica fundamental es que esta función no
puede ser descompuesta en otras más elementales. Podríamos decir que se trata de una
función atómica.

Un nodo lógico agrupa atributos de estado (ST), medida (MX), substitución (SV), descripción
(DC), “settings” (SE, SG, SP), configuración (CF) y extensión (EX).

Los grupos de datos de estado, medida, y descripción son bastante clásicos por lo que no
merece la pena entrar en detalles.

En el grupo de datos de substitución encontramos los valores necesarios cuando se sustituye

un valor (su valor sustituido, calidad sustituida, etc.).

En el grupo de datos “settings”, encontramos parámetros de los equipos que puede ser
interesante modificar en tiempo real (lo que en otros protocolos se llama consignas, o set points
(SP) o existe la posibilidad de definir unos pocos conjuntos de ajustes que podremos conmutar
según nos convenga Setting Group (SG, SE) (por ejemplo por cambio en las condiciones en
una línea, cambios en la época del año...).

En el grupo de datos de configuración encontramos valores que puede ser interesante

configurar en tiempo real, por ejemplo el time-out de un mando, el límite superior de un valor,
etc. Sin embargo, no debería usarse ese grupo de datos para configurar por completo un IED.

Por último, se utiliza el grupo de datos de extensión para ampliar atributos de un logical node o
para crear logical nodes nuevos. En efecto, en el caso en que se creen campos o nodos
nuevos, es necesario crear un “Namespace” e incluirlo en la información de tiempo real de
nodo. De esta forma es posible distinguir una variable con el mismo nombre pero que sea una
extensión con significado diferente utilizado por dos fabricantes diferentes. Una correcta
implementación de IEC 61850 debe mirar en primer lugar estos atributos, si no están, se
considera que forma parte de la norma original.

Un LN puede hacer referencia a un equipo real (un interruptor), una parte de un dispositivo
multifunción (protección electrónica) o a un dispositivo auxiliar (un registrador en papel). Pero
de una forma virtual se refiere siempre a una función atómica para la automatización de una
subestación.

Dejando de lado el aspecto funcional, se podría considerar que un sistema de automatización

de una subestación consiste en una base de datos distribuida. Para racionalizar todas las
funciones de automatización, esta base de datos es orientada a objetos. Estos objetos son
nodos lógicos. Los procedimientos de comunicaciones que se emplean para mantener la
consistencia de esta base de datos tendrán en cuenta la naturaleza de los datos que se
intercambian.

1.8.1 Modelado de funciones en nodos lógicos

En primer lugar es necesario identificar las funciones de automatización que son de interés en
una subestación con el objetivo de realizar nuestro sistema de control. En el futuro se pueden
crear algunos nodos lógicos y campos de datos que nos darán un modelo completo de
nuestras necesidades de datos, si bien no es recomendable abusar de esta opción y crear los
estrictamente indispensables.

Por ejemplo, el caso de un interruptor con carro insertado a doble barra puede ser modelado
utilizando un interruptor XCBR y dos seccionadores XSWI que representan a que barra está
conectado el interruptor. Otro ejemplo es el devanado auxiliar de un transformador utilizado

Página 15 de 83
para el circuito de servicios auxiliares. En ese caso se puede modelar mediante un
transformador de potencia YPTR más un devanado de una red auxiliar ZAXN.

En el caso de IEDs multifunción bastará con agrupar en el IED todas las funciones de
protección y medida que se implementan en el dispositivo. La figura x muestra un ejemplo
típico para un alimentador de media tensión con reenganche y una protección de
sobreintensidad temporizada.

LAN de subestación

IED
LPHD

LLN0

XSWI
XSWI CSWI
CSWI

RREC

XCBR CSWI

TVTR MMXU PTOC

XSWI CSWI

XSWI CSWI

TCTR MMXU

Figura 1.9 – Ejemplo de LN en un IED

Como puede verse, el concepto de nodos lógicos resulta una poderosa herramienta para
diseñar y documentar ingenierías de detalle de una subestación automatizada

La figura 1.10 muestra otro ejemplo para un transformador con un regulador de tensión.
.

Página 16 de 83
 LAN de subestación

UCP LPHD
IED
LLN0

TCTR MMXU

TVTR MMXU

XCBR CSWI

YPTR

YLTC ATCC

TCTR MMXU

Figura 1.10 – Ejemplo de LN en un IED

1.8.2 Funciones no normalizadas

En ciertos casos, puede ser necesario definir nuevos nodos lógicos o ampliar los datos de los
existentes, ya que puede surgir la necesidad de utilizar funciones que no se encuentran
definidas en los nodos lógicos existentes. Para ello existen dos nodos lógicos especiales para
las funciones que no están incluidas en la norma, GGIO y GAPC.

Para los casos en que los equipos que se utilicen no dispongan de nodos lógicos
específicamente definidos, se puede usar una combinación de nodos lógicos del tipo GGIO y
GAPC para crear un nodo lógico diferente.

La figura 1.11 muestra cómo crear un nodo lógico del tipo genérico XCBR incluir en su
estructura de datos la medida de energía acumulada durante el despeje de una falla. En este
caso es necesario la combinación de nodos lógicos del tipo XCBR y GGIO (Estándar). Esta
ampliación que se denominará XCBR_A requiere que el nuevo tipo de datos “A2Sum” sea
definido en la parte de DATA TYPE del archivo .icd correspondiente.

XCBR_A

XCBR GGIO/A2Sum

Figura 1.11 – LN ampliado

La figura 1.12 muestra una forma para ampliar los datos de un nodo lógico del tipo regulador de
batería de condensadores mediante la combinación de nodos lógicos del tipo GAPC y GGIO
creando un nuevo LN que se denomina en el ejemplo ABBC.

Página 17 de 83
 ABBC

GAPC GGIO/RCtrBand

GGIO/LTCBlk

Figura 1.12 – Combinación de LN

De esta es posible utilizar siempre nodos lógicos concretos (no genéricos como GGIO) con las
extensiones de atributos que nos interesen.

1.8.3 Recomendaciones en el uso de nodos lógicos

1.8.3.1 Tratamiento de agrupaciones de alarmas

Dado que el agrupamiento de alarmas tiene como objetivo sintetizar las alarmas para el Centro
de Control de la red, en este ejemplo, este agrupamiento se realiza en la Unidad de Estación.
Si falla la Unidad de Estación, no se realizan agrupamientos ni para la Consola de Control
Local, ni consecuentemente para el Centro de Control pero la instalación debe ser operada en
forma local.

A la Consola le llegan las alarmas adquiridas por la Unidad de Bahía a través de la red. En
caso de falla de la unidad de estación, es posible realizar mandos directamente desde la
Consola.

En la figura 1.13 se puede apreciar como la información de alarmas disponible en la red

(Líneas rojas) es adquirida tanto por la Unidad de Estación como por la Consola. Las alarmas
sintetizadas por la Unidad de Estación son enviadas tanto al Centro de Control como a la
Consola.

WAN

Consola LPHD Unidad de Estación LPHD

LLN0 ITCI ITMI

LLN0
CALH
CALH IARC
IHMI IARC CALH

LAN de subestación

Unidad
bahía XCBR

LLN0

LPHD

Página 18 de 83
 Figura 1.13

Referencias:
TLO: Terminal Local de Operación (Consola de Control Local) IHMI
UCS: Unidad de Control de Subestación (CCU ó CPU de la RTU)
UCP: Unidad de Control y Protección (IED)

Las flechas rojas representan los mensajes que se envían en primer término, y las azules en
segundo término.

Es decir una alarma se envía primero a todos los clientes:

o TLO.IHMI
o TLO.IARC
o UCS.IARC
o UCS.CALH

Y a continuación se envía desde el nodo lógico de agrupación de alarmas (UCS.CALH) hacia

sus cuatro clientes que son:

o TLO.IHMI
o TLO.IARC
o UCS.IARC
o UCS.ITCI

Aunque pueda parecer que el hecho de enviar múltiples veces cada alarma puede ser
ineficiente, las ventajas compensan sobradamente este sobrecosto.

1. No hay ningún elemento crítico. Si falla un elemento, el resto sigue funcionando.

2. A cada cliente se envían las alarmas de forma adaptada a sus necesidades.
(Requisitos de tiempo, con/sin buffer, si cambia el valor o la calidad…).

1.8.3.2 Tratamiento del mando local

Respecto al mando local, el planteamiento genérico es el siguiente: Cada nivel (Estación,

Posición y Proceso) puede tener un mando local. Cuando un nivel está en mando local, sólo se
aceptan mandos de ese nivel y no de niveles superiores.

Página 19 de 83
 IHMI ITCI

IHMI.Loc IHMI.Loc

Nivel Estación

CSWI

CSWI.Loc
Nivel Bahía

XCBR

XCBR.Loc Equipos Proceso

Figura 1.14 – Tratamiento del mando

Por ejemplo:

1. Si una subestación está en mando local, sólo aceptará mandos de la Consola de

control local. Si la subestación está en remoto no se aceptan mando de la Consola de
control local y sí del Centro de Control.
2. Cuando la posición está en remoto, acepta mandos de cualquier nivel superior, de la
Consola de estación o del Centro de Control.
Si un campo ó bahía ó un aparato de maniobra está en mando local (Sala/Local), solo
aceptará mandos desde el campo o al pié del aparato (Caja de Mando).

La denominación del mando en función de donde se ejecuta, depende de la normalización de

cada Empresa Eléctrica, un ejemplo se indica a continuación:

En Tablero: Local/Telecontrol ó Local /Distancia

En Local: por predispositor
En Telecontrol ó Distancia: por Consola de Control Local (IHMI) y por Centro de Control

En aparato de maniobra (XCBR, CSWI): Local/Remoto

En Local: desde caja de mando aparato de maniobra
En Remoto: desde Sala estación transformadora ó desde Centro de Control

Algunos IEDs poseen display y botonera o display sensible al tacto permitiendo ejecutar
maniobras sobre los aparatos primarios, por lo que se designan en este informe como “Consola
de Mando Local en el IED”

La tabla 3 resume este comportamiento:

CENTRO
CONTROLADOR CONTROLADOR DE
IED BAHÍA Estación CONTROL
Proceso en SI NO NO NO
Local
Posición en SI SI NO NO
Local
Estación en SI SI SI NO

Página 20 de 83
 Local

Proceso en NO SI SI SI
Remoto
Posición en SI NO SI SI
Remoto
Estación en SI SI NO SI
Remoto

Tabla 3 -

1.8.3.3 Tratamiento del tiempo

Las marcas de tiempo (Time stamp), pueden tener una precisión variable; aunque por
normalización fijaremos la precisión de las marcas de tiempo de control a que en la actualidad
se fijan en 1 ms. (Clase T1) como mínimo.

Para nuestros sistemas la mejor elección será trabajar en tiempo local. Puesto, que la mayoría
de sistemas GPS informan acerca del número de segundos insertados necesarios para corregir
el tiempo GPS en UTC.

Utilizando UTC, se simplifican en gran medida las conversiones de tiempo, aunque los cálculos
de diferencias horarias en intervalos que contengan segundos insertados pueden complicarse.

El ajuste del horario de verano se realizará localmente a efectos de visualización.

Esta representación no debe utilizarse para almacenar el reloj real sino únicamente para
representarlo.

1.8.3.4 Ejecución de comandos

Los comandos digitales pueden ejecutarse según diferentes formas, a saber:

Según se supervise si el comando ha producido el cambio de estado esperado se pueden

clasificar en comandos con seguridad normal (no se supervisa) y con seguridad mejorada (se
supervisa el cambio de estado para informar al origen del mando.

Según el comando se realice con el procedimiento de selección y ejecución, o por el

procedimiento de ejecución directa.

De esto obtenemos cuatro clases de comandos.

1. Comandos directos con seguridad normal:

2. Comandos SBO (Select Before Operate) con seguridad normal:
3. Comandos directos con seguridad mejorada:
4. Comandos SBO con seguridad mejorada:

La mejor elección es la última (4) debido a:

1. Por motivos de integridad de datos, los comandos requieren una integridad de clase I3
(IEC 60870-4), que en ciertas condiciones solo se consigue mediante el procedimiento
de SBO.

Página 21 de 83
 2. La Especificación Técnica IEC 61850-80-1, que trata el mapeo (“mapping”) de IEC
60870-5-101 e IEC 60870-5-104 a IEC 61850, solamente se contemplan los comandos
con seguridad mejorada.

1.8.3.5 Origen de comandos

Este atributo se utiliza para identificar el origen de los comandos con la finalidad de permitir o
no permitir los comandos según su procedencia y según esté activada la señal de comando
local.

La filosofía es que pueden generarse comandos de forma manual o de forma automática (por
algún automatismo). En cualquier caso el origen del comando puede ser:

o Centro de Control.
o Control Local
o Bahía

El modelo de mando local en IEC 61850 es jerárquico en los niveles anteriores, es decir,
cuando un nivel está en mando local sólo acepta mandos procedentes de su mismo nivel y los
rechaza cuando vienen de niveles superiores.

Nótese que a efectos de aplicar el comportamiento de comando local, es necesario distinguir

entre comandos procedentes de un automatismo y comandos convencionales. Los comandos
procedentes de automatismos no están sujetos al bloqueo del comando local como se muestra
en la tabla xxx.

Originator
Nombre Tipo Comentarios
orCat ENUM
Valor Descripción
not-supported No se soporta esta prestación.

bay-control El mando procede de un dispositivo de nivel

de bahía.

station-control El mando procede de un dispositivo de nivel

de estación.

remote-control El mando proviene del NCC

automatic-bay Mando de un automatismo del nivel de

bahía.

automatic-station Mando de un automatismo del nivel de

estación.
automatic-remote Mando de un automatismo del NCC.
Maintenance Mando de mantenimiento.
Process Cambio de estado generado
espontáneamente, sin que haya habido una
acción de control.

orIdent OCTET_STRING64 Según la norma, la dirección de enlace (MAC), transporte

(IP) o de aplicación (nombre de LD).

Lo más conveniente es la dirección de aplicación.

1.8.3.6 Gateway

Página 22 de 83
El gateway, entre otras funciones, permite la “traducción” de protocolos”. Típicamente se instala
un gateway en la subestación a los fines de permitir la vinculación de IEDs con protocolo IEC
61850 y dispositivos de control y protecciones existentes que funcionan con protocolos
anteriores, como por ej. IEC 60870-5-103, IEC 60870-5-104, y DNP 3.0.

Las recomendaciones para implementar un dispositivo de este tipo están recogidas en la

Especificación Técnica IEC 61850-80-1_Ed.1. Básicamente es una guía que trata el
intercambio de información de un modelo de información basado en CDC utilizando IEC 60870-
5-101 ó IEC 60870-5-104, e incluye los siguientes ítems [1]:

1. Modelo conceptual del gateway.

2. Mapping de comandos de IEC 60870-5-104 a IEC 61850.
3. Mapping de CDC (Common data classes) de IEC 61805 a ASDUs (Application Service
Data Unit) IEC 60870-5-104. Un ejemplo puede verse en la siguiente tabla.

Tipo de ASDU
CDC Dirección de Monitor Dirección
de Control Comentarios
Evento Periódico GI
SPS Estado Digital Simple Con y Sin Marca de
30 1 Tiempo
DPS Estado Digital Doble Con y Sin Marca de
31 3 Tiempo
INS 11 Medida Escalada Sin Marca de Tiempo
BCR 15 Totales Integrados Sin Marca de Tiempo
SPC 30 1 45 Comando Digital Simple
DPC 31 3 46 Comando Digital Doble
BSC 5 Posición de Paso y Comando de Paso de
47 Regulación
ASG 11 Medida escalada y Comando de Consigna
49 Valor Escalado

4. Mapeo (“Mapping”) de atributos de datos de CDC a Tipos de datos en IEC 60870-5-

104. Un ejemplo puede verse en la siguiente tabla

SPS
Atributo Mapping Tipo
IEC 61850 IEC 61850 IEC 60870-5-101/104 IEC 60870-5-101/104
stVal FALSE 0 SPI
TRUE 1
q good IV=0 QDS
invalid IV=1
overflow OV=1
t CP56Time2a
5. Mapping de los servicios de IEC 61850 en servicios de IEC 60870-5-104.

Servicio Servicio
IEC 61850 IEC 60870-5-101/104
TI Nombre
GetAllDataValues 100. 1, 3, 5, 11 Interrogación General.
Calificador 20 (Global).
SelectActiveSG 45 Comando Simple.
Report 1, 3 Transmisión Espontánea.
(COT=3).
SelectWithValue 45, 46, 47, 48, 50 Comando (s/e=1).
Operate 45, 46, 47, 48, 50 Comando (s/e=0).

Página 23 de 83
6. Ampliación de la sintaxis de ficheros SCL en secciones privadas para incluir la
asociación entre datos IEC 61850 e IOAs (Information Object Address).

Página 24 de 83
2. Criterios de diseño de subestaciones

2.1 Comunicaciones

2.1.1 Topología
Debido a las amplias posibilidades que esta tecnología ofrece son varias las posibles
topologías que pueden adoptarse. Las decisiones están basadas en criterios de nivel de
tensión, disponibilidad, monto de inversión, etc. A continuación se muestra un esquema de una
posible topología con ventajas interesantes en subestaciones de distribución. Para
instalaciones de transporte en Ultra Alta Tensión, tal como 500 kV, deben considerarse otros
aspectos como sistema de protección primario y secundario. Una subestación de distribución
puede poseer una configuración compuesta por una playa AT, con un número reducido de
bahías, y una playa MT con un número importante de bahías o campos. En otras
configuraciones la subestación AT/MT, puede estar compuestas por campos ó bahías AT
exteriores y celdas ó tableros MT interiores, cuyo número depende de la importancia de la
subestación. Para cada bahía ó campo se dispone de un armario o tablero de control con
varios dispositivos electrónicos inteligentes. En este caso una de las arquitecturas utilizadas se
basa en la instalación de un switch con conexiones RJ45 para conectar los equipos dentro del
armario, es decir conexiones de Cu en el tablero y conexiones de fibra óptica en topología
anillo para cada nivel de tensión de la subestación.

RTU Tablero
HV2 Tablero
HV1 Tablero

AT Anillo

MT Anillo

MV1 MV2 MV9 MV10

Tablero Tablero Tablero Tablero
….

Figura 2.1 – Topología anillo simple principal anillo simple secundario

Se pueden tener también otras configuraciones de subestaciones, en las cuales existen

múltiples bahías MT. Típicamente con un único dispositivo inteligente en cada armario de
control. En este caso, puede optarse por usar una topología de estrella con un solo switch para
todas las posiciones, o bien construir un anillo con todos los equipos. En el primer caso se
minimiza la inversión pero se pierde redundancia, en el segundo se maximiza la redundancia,
pero se incrementan también la inversión.

2.1.1.1 Switch
En el mercado existen IEDs que poseen switch integrados en el dispositivo, permitiendo la
construcción de una topología en anillo simple. Con esta topología se pueden vincular los
anillos de MT y de AT en dos puntos para lograr una redundancia adicional.

Página 25 de 83
La resolución de la reconfiguración de los anillos debido a fallas en equipos o enlaces se
realiza con el protocolo RSTP (Rapid Spanning Tree Protocol), que es un protocolo
normalizado internacionalmente (IEEE 1D-2004) y disponible en la mayoría de los switch.

En el mercado, existen actualmente dos tipos de switches, los denominados administrables

(managed) y aquellos no administrables (unmanaged). Se diferencian en que los primeros
poseen una serie de características importantes para un SAS que los segundos no poseen.
Entre las características más salientes de los switches administrables, se pueden mencionar
las siguientes:

- Operación full-duplex, para asegurar que no existan colisiones en los segmentos de red
interconectados por los switches (IEEE 802.3x)
- Señalización que permite priorizar el tráfico en la red a nivel de capa 2 (IEEE 802.1p)
- Filtrado del tráfico tipo multidifusión (broadcast)
- Posibilidad de implementar redes virtuales, permitiendo aislar IEDs con operación en
tiempo real crítica de otros IEDs menos críticos (IEEE 802.1q)
- Soportan RSTP (Rapid Spanning Tree Protocol)
- Posibilidad de monitorear el número de paquetes recibidos y enviados en cada puerto,
identificar patrones de tráfico y verificar que los puertos están trabajando de forma
adecuada
- Posibilidad de activar o desactivar los puertos, determinar la velocidad y efectuar el
control de flujo de los puertos para eliminar potenciales cuello de botella.

Otro punto importante a tener en cuenta es que existen infinidad de herramientas de

supervisión y gestión de red gráficas mediante SNMP que pueden dejarse instaladas en la PC
de control (IHMI) posibilitando obtener una valiosa información en tiempo real sobre el
funcionamiento de la red. Lo mismo ocurre con herramientas de transferencia de archivos ó
ficheros, con las que es posible desde la computadora central ó consola de control local (IHMI)
de la subestación tener acceso a las configuraciones y archivos de datos de todos los IED sin
tener que manipular ningún equipo.

2.1.1.1 Latencia

La latencia es el tiempo que transcurre entre el instante que el dispositivo fuente transmite un
paquete hasta que el dispositivo destino lo recibe.

Es importante hacer algunas consideraciones acerca de la latencia de la red y del tiempo

necesario de reconfiguración en caso de falla de algún equipo.

Un switch Ethernet puede verse conceptualmente como el siguiente modelo

tt ta tb tc

Input Output
Interface Pre-process Post-process Interface

Figura 2.2 – Modelo conceptual de switch

Página 26 de 83
Donde:

tt es el tiempo de transmisión y depende del tamaño del mensaje. Por ejemplo un mensaje de
tamaño máximo de Ethernet (MTU, Maximum Transmission Unit) tardará 150 microsegundos
aprox. (100 Mbps).
tb es el tiempo en cola y dependerá de la ocupación de la red.
ta y tc son los tiempos de procesado de switch y dependerán de la tecnología del switch.

Es difícil obtener estos valores de los fabricantes, por lo que a falta de esta información es
posible medirlos según el esquema siguiente:

x 20

RTD: Round Trip Delay IP

PING IP

Figura 2.3 – Medición tiempo de latencia

Donde el retardo de cada Switch viene dado por:

ta + tc= (RTD-20 * tt) / 20

Se debe considerar que en la norma IEC 61850 se define el “tiempo de transferencia”, como la
suma de los tiempos de los procesamientos individuales en cada dispositivo físico, incluyendo
el tiempo de proceso de las aplicaciones y el tiempo de espera, más el tiempo utilizado por los
switch y otros dispositivos de la red.

Debido a que la transmisión de mensajes GOOSE requiere la configuración de VLANs en la red

Ethernet, sólo podrán utilizarse Switches gestionables puesto que es imprescindible configurar
la funcionalidad de las VLAns y su prioridad asociada para poder garantizar el correcto
funcionamiento de los mensajes GOOSE.

2.1.1.1.2 Sincronismo
La parte IEC 61850-8-1_Ed.1, de la norma establece la utilización del protocolo SNTP v.4
(Simple Network Control Protocol), no obstante en la Ed. 2 se está analizando la utilización del
protocolo IEEE 1558 “Precision Time Protocol” ó PTP, que permitiría precisiones en el orden de
los microseg. IEC publicará el protocolo PTP como IEC 61558. La necesidad de una
sincronización con tiempos del orden de los microseg., se debe a los requerimientos que
imponen las nuevas protecciones de área extensa ó Wide Area Protection.

Para el caso de la sincronización SNTP, dependerá de la distribución de tráfico, ya que la

asimetría de latencia entre los dos sentidos de transmisión entre el servidor de tiempos y el
equipo que se sincroniza puede afectar a la precisión del reloj. Debido a que esta
sincronización se realiza en el entorno de una red LAN sin routers, la diferencia de latencia
entre ambos sentidos será prácticamente inapreciable. En la práctica mayoría de los casos se
puede garantizar una precisión del 1 ms.

Página 27 de 83
2.1.1.1.4 Direccionamiento
Sin duda alguna el direccionamiento de los IEDs debe ser estático, direcciones IP fijas. Para el
acceso remoto puede utilizarse un servidor VPN o en su defecto NAT en el gateway de
subestación. Se debe considerar que la utilización de una VPN provee el nivel de seguridad
necesario para este tipo de servicio.

2.1.1.1.5 Supervisión
La supervisión de la red local puede realizarse mediante cualquier gestor SNMP. Dichas
aplicaciones proporcionan información de detalle sobre las comunicaciones de los equipos,
Todas ellas requieren la existencia de una red con conectividad IP. Mediante SNMP podemos
conocer con detalle, entre otras cosas:

 Estado de todos los enlaces.

 Estadísticas de ocupación de todos los enlaces.
 Estado del RSTP.
 Etc, etc…

2.1.1.1.6 Mantenimiento
Actualmente es posible transferir y recuperar todos los archivos o ficheros de configuración y
leer los oscilos e históricos a través de la WAN (Intranet) empresarial. Desde una PC o
Notebook es posible acceder a TODOS los equipos con lo que en el futuro, todos los procesos
de configuración y verificación se simplificarán notablemente. Lo importante de esta nueva
tecnología es que hace posible la integración del control y mantenimiento sobre la misma red.

Parte del mantenimiento puede realizarse utilizando las facilidades de la norma tales como la
transferencia de archivos tanto utilizando el servicio de MMS como mediante FTP.

3. Requerimiento de comunicaciones

3.1 Medio Físico

En este apartado se describen características técnicas relacionadas con los requerimientos
prácticos del sistema de comunicaciones. En la parte 5 se amplía estos aspectos y se
describen los diversos tipos de mensajes definidos por la norma.

La LAN debe funcionar preferentemente a 100 Mbit/s ó 1 GB, en los casos se considera
necesario utilizar fibra óptica en segmentos de la LAN entre “quioscos” ó salas de equipos de
protección y control, y eventualmente entre armarios si las distancias así lo justifican. En
aquellos casos que todos los armarios estén en una misma sala, incluyendo la Consola de
Control Local, es aceptable la conexión a través de UTP (Unshilded Twisted Pair) ó STP
(Shielded Twisted Pair). En el interior de un armario es común utilizar cable de Cu de Cat-5 ó
superior y conectores RJ45 (1000Base-T).

La fibra puede ser monomodo (10/125) o multimodo (50/125, 62,5/125). La diferencia

fundamental radica en el tamaño del alma cristalina del cable 10 micrones para la primera y 50
o 62,5 en la segunda. A mayor radio del núcleo más sencillo resulta el montaje del conector.

Debido a las distancias involucradas en las subestaciones, menos de 1 Km, generalmente se

utiliza fibra multimodo. Esta elección hace que el montaje del conector resulte mucho más
sencillo. Por este último motivo se utiliza preferentemente la fibra 62,5/125, no obstante se está
comenzando a utilizar la fibra 50/125. Las frecuencias pueden ser de 850 nm o 1300 nm. Por
consideraciones vinculadas con la menor atenuación es preferible utilizar 1300 nm.

Página 28 de 83
Es necesario destacar que lo que se encuentra menos estandarizado son los conectores. Si
bien es cierto que es bastante común que los fabricantes de equipos de comunicaciones,
ofrezcan varias alternativas de conector físico de F.O. Entre los equipos IED, el conector más
utilizado es el ST.

Tipo de
conector Acoplamiento Pérdidas (dB) Utilización preferente
ST Bayoneta 0,4 Edificios, Seguridad
FC Guía+Rosca 0,15 Comunicaciones
SC Push-Pull 0,15 Comunicaciones
LC Push-Pull 0,2 Interconexiones de alta densidad
FDDI Push-Pull 0,2 Redes Locales
SMA Rosca 0,5 Comunicaciones

Página 29 de 83
En las siguientes figuras puede apreciarse el detalle de estos conectores típicos.

Conector ST Conector SC
Conector FC/PC

Conector LC

Conector FDDI

Conector SM

Figura 3.4 - Conectores

Página 30 de 83
De nuevo, por motivos prácticos de montaje se recomiendan los conectores ST, aunque deberemos estar
preparados para cualquier combinación pues no descartaremos un equipo por el conector que tenga.

En forma de resumen, nuestras recomendaciones son las siguientes:

Característica. Valor Razón

Tipo Multimodo Práctica por el montaje del conector
Longitud de onda 1300 nm Atenuación
Dimensiones del núcleo 62,5/125 ó Práctica por el montaje del conector
50/125
Conector LC En los nuevos switch la tendencia será este
tipo de conector

4. Comunicaciones – Mensajes – Protocolos de la pila (stack)

La norma IEC 61850 define como topología de comunicación en la subestación, una LAN Ethernet. No se
define en la Ed. 1 de la norma una topología particular de la LAN, dejando abierta la posibilidad de adoptar
la topología que mejor se adapte a cada subestación en función de su configuración eléctrica y magnitud, y
a las características de cada Empresa Eléctrica.

No obstante en un informe técnico que formará parte de la Ed. 2 de la norma, que se encuentra en la etapa
de elaboración, se describen una serie de topologías simples y duplicadas, como asimismo se brinda
información sobre tipos de fibra y conectores. Por otra parte la topología está directamente ligada a la
seguridad, y confiabilidad, aspectos que poseen una fuerte dependencia con las inversiones que esté
dispuesta a realizar la Empresa Eléctrica.

4.1 Tipos de mensajes

En una subestación IEC 61850, existen dos sentidos de circulación de los distintos tipos de mensajes. Un
sentido es vertical desde la Consola a los IEDs y viceversa, y otro sentido es horizontal, entre IEDs. En el
caso de la transmisión vertical, el modo de transmisión es de tipo cliente-servidor. En el caso de la
transmisión en sentido horizontal, el modo se denomina par a par ó “peer-to-peer”.

Por otra parte, la norma distingue diferentes tipos de mensajes según sea su naturaleza, es decir los
diferentes servicios por la misma red. En la Tabla x, se indican los mensajes normalizados.

Utilización
Tipo Descripción preferente Observaciones
1 Mensajes Protección Disparo de interruptores.
rápidos
1A Disparos Protección Mandos digitales.
2 Mensajes de Control Mensajes y mandos típicamente de telecontrol
rapidez media (mandos, alarmas, medidas…).
3 Mensajes lentos Supervisión,
configuración
4 Captación, Bus de Proceso Captación de muestras analógicas y digitales a
muestreo una velocidad de hasta 400 veces la frecuencia
de red.
5 Transferencia de Supervisión,
archivos ó configuración
ficheros
6 Sincronización Control Utilizando SNTP es posible obtener una
de tiempo precisión de milisegundos en una red local.

La norma define el tiempo de transferencia, como el tiempo necesario para la transmisión completa de un
mensaje incluyendo las necesarias gestiones en ambos extremos, como se muestra en la Fig. 4.1.

* IIE Calle Reforma 113 Col. Palmira, Cuernavaca, Mor., 62480 México – e-mail (picasso@iie.org.mx)
 f1 f2

Figura 4.1 - Tiempo de Transferencia

Este tiempo se comienza a contar desde el momento que el transmisor coloca el contenido de
información en la cima de su “pila” (“stack”) de transmisión hasta el momento que el receptor extrae la
información de su “pila” de transmisión, como se muestra en la Fig. 4.2

Modelos de información
Intercambio de información, ACSI

Aplicación MMS (ISO 9506)

Presentación ASN.1/Presentación
Sesión Sesión
Transporte TCP
Red IP
Enlace Ethernet, …
Física Física

Figura 4.2. Pila de protocolos IEC 61850

Como se ha mencionado existen mensajes cuyo tiempo de transferencia debe ser muy rápido, como por
ejemplo los mensajes GOOSE, para los cuales la norma define un camino “abreviado” ó “reducido” si se
relaciona el Modelo que presenta la norma, comparado con el Modelo de Referencia OSI/ISO, como se
muestra en la Figura x. El principio de estos mensajes que transitan un camino “reducido” es en cierta
medida similar al utilizado en los protocolos de la serie IEC 60870-5, que utilizan el Modelo EPA (Enhanced
32
Protocol Architecture), basado solamente en tres capas ó niveles, con el objeto de reducir los tiempos
necesarios para la comunicación entre dos dispositivos. Es así como los mensajes “peer-to-peer”, o
GOOSE, no recorren los distintos niveles del Modelo sino que son directamente entregados a la capa
Enlace

4.2 Conjunto de protocolos

Según el tipo de mensaje, que se encuentran vinculados con diferentes servicios, la norma adopta un
conjunto de protocolos existentes y de amplia utilización, para efectuar las diferentes funciones.

La figura 4.3, muestra en forma más específica, que existen algunos tipos de mensajes que debido a las
exigencias de tiempo de transferencia mínimo que poseen, en virtud de su naturaleza de “misión crítica”,
son mapeados directamente a la capa ó nivel Enlace de Datos. Es el caso de los mensajes GOOSE, y SV.

Utilización
Eventos
Tipo de
de Sincronización Núcleo del
mensaje
Captación protección Horaria protocolo GSE

4 1, 1A 6 2,3,5 1, 1A
Nivel
Aplicación SNTP MMS GSSE
Nivel
Transporte
ISO CO GSSE
SV GOOSE TCP/IP T-Profile T-Profile
+ Red
UDP/IP
Nivel T-Profile Nivel Enlace
Enlace ISO/IEC 8802-2
Nivel Físico Nivel Físico Ethernet ISO/IEC 8802-3

Figura 4.3 – Perfil de protocolos

Se recomienda utilizar únicamente protocolos de transporte con TCP/IP y evitar los protocolos de
Transporte ISO cuando sea posible, ya que los primeros están más extendidos que los segundos.

 Perfil para comunicaciones Peer-to-Peer

En los mensajes GOOSE (Generic Object Oriented Substation Event), la información es configurable
aplicando “data set” referenciando cualquier información. Los mensajes GSSE (Generic Susbtation Status
Even), solamente soportan una estructura fija de información de estado a ser publicada, y realizan una
función similar a los mensajes GOOSE aunque se mantienen por compatibilidad con UCA 2.0.

Cuando se genera un evento, el servidor GOOSE codifica el conjunto de datos asociado con el evento en
un paquete denominado T-DATA y lo transmite como “multicast”. En la Figura 4.4, se muestra la
característica de transmisión de un mensaje GOOSE

33
 Tiempo de Transmisión

T0 (T0) T1 T1 T2 T3 T0

Instante del evento

Figura 4.4 – Transmisión de un mensaje GOOSE

T0: indica que se producen retransmisiones en condiciones de estabilidad, no se han producido eventos
durante un largo período de tiempo

(T0): indica que el período de retransmisiones en condiciones estables puede resultar acortado al
producirse un evento.

T1: es el menor tiempo de transmisión de un evento. Como vemos se retransmite el mensaje

inmediatamente.

T2 y T3: son los tiempos de retransmisión que se van duplicando hasta retornar a condiciones estables.

Si bien la norma permite las dos opciones, es aconsejable evitar el transporte ISO para los mensajes del
tipo MMS. Por lo tanto resulta el stack de protocolos reducido, como se muestra en la Figura x, en la cual se
indica un conjunto de protocolos con los que podremos realizar todas las funciones requeridas, y que resulta
más sencilla y manejable. A continuación se irá particularizando esta suite de protocolos para los diferentes
servicios.

Utilización
Tipo de Eventos de Sincronización Núcleo del
mensaje Captación protección Horaria protocolo

4 1, 1A 6 2,3,5
Nivel Aplicación SNTP MMS
Nivel Transporte + SV GOOSE TCP/IP
Red + Enlace UDP/IP
T-Profile
Nivel Físico Nivel Físico Ethernet ISO/IEC 8802-3

Figura 4.5 – Suite de protocolos

De la tabla anterior se pueden hacer diferentes vistas todavía más simplificadas según sea el bus de datos
(de estación o de proceso) y según sea la funcionalidad (protección o control). Al final llegamos al conjunto
de protocolos mínimo sin nivel de proceso.

Utilización
Tipo de Eventos de Sincronización Núcleo del
mensaje protección Horaria protocolo

34
 1, 1A 6 2,3,5
Nivel Aplicación SNTP MMS
Nivel Transporte + GOOSE TCP/IP
Red + Enlace UDP/IP
T-Profile
Nivel Físico Nivel Físico Ethernet ISO/IEC 8802-3

Figura 4.6 – Suite simplificada de protocolos

 Perfil para sincronización horaria

La sincronización horaria se efectúa mediante el protocolo SNTP.

El protocolo SNTP se transporta mediante el protocolo UDP. Como se ha mencionado, el protocolo TCP
(Transmission Control Protocol) es un protocolo orientado a conexión, mientras que UDP, es un protocolo
sin conexión, para aplicaciones que no requieren el secuenciamiento TCP o control de flujo.

 Perfil para comunicaciones Cliente-Servidor

Para el modo de comunicación Cliente-Servidor se utiliza el protocolo de aplicación MMS junto con el perfil
tipo “T”. (Perfil tipo transporte).

La implementación de MMS realizada por los fabricantes puede no ser completa, sin embargo en orden de
prioridad debería cumplir:

1. Sincronización horaria (SNTP)

2. Buffered Reporting.
3. Control with enhanced Security (La Especificación Técnica IEC 61850-104 no contempla mandos
sin seguridad mejorada).
4. File Transfer. Preferiblemente FTP.
5. UnBuffered Reporting.
6. Logging.

Los mensajes definidos mediante el protocolo ASN.1 en el Nivel Presentación, se codifican mediante un
conjunto de reglas denominadas “Basic Encoding Rules” (BER). La figura 4.7 muestra el detalle de todos los
niveles del protocolo, así como el detalle del conjunto de protocolos utilizados en lo que se denomina T-
Profile.

Nivel MMS (ISO 9506-2)

Aplicación ACSE (ISO 8650)
Presentación Presentación con conexión (ISO 8823-1)
Nivel
Presentación
Especificación ASN.1 (ISO/IEC 8824-1)
Codificación BER (ISO/IEC 8825-1)
Sesión Sesión con conexión ISO/IEC 8327-1

ISO Transporte sin conexión TP0. ISO/IEC 8073

Nivel
Transporte
Adaptación RFC-1006

TCP ICMP, TCP (RFC-792, RFC-793)

Nivel Red IP (RFC-791)

Nivel Enlace RFC-894, RFC-826 (ARP)
Ethernet ISO/IEC 8802-3 Ethernet ISO/IEC 8802-3
Nivel Físico
10Base-T/100-BaseT (cobre) 100-BaseFX (fibra)

Figura 4.7 – Protocolos en los diversos niveles

35
Como mencionado, la norma adopta en los diferentes niveles de su modelo, relacionándolo con el Modelo
de Referencia OSI/ISO, protocolos estandarizados, de amplia difusión y por consiguiente muy probados,
como se muestra en la Figura x.
En lo que sigue, se describirán los protocolos adoptados en cada capa ó nivel, así como sus características
más salientes.

4.3.1 Nivel Físico

El estándar ISO/IEC 8820-3 es una versión adaptada del IEEE 802.3, creado con anterioridad y en el que se
definen todos los aspectos relativos al protocolo Ethernet. Particularmente interesan las partes de estos
estándares que definan las conexiones físicas de par trenzado de cobre y las conexiones de fibra óptica.

Cada dispositivo equipado con Ethernet opera de forma independiente del resto de los dispositivos de la
red, las redes Ethernet no hacen uso de un dispositivo central de control. Al inicio de esta tecnología, todos
los dispositivos estaban conectados a un canal de comunicaciones de señales compartidas por lo que era
necesario definir Ethernet el modo de acceso al medio físico conocido como CSMA/CD (Carrier Sense
Multiple Acces with Collision Detection) para poder gestionar correctamente el acceso a este medio de
comunicaciones de señales compartidas donde además todos los dispositivos conectados podían escuchar
la transmisión.

En la actualidad, se dispone de equipos de conmutación inteligente que permiten evitar las colisiones y por
otra parte utilizar las transmisiones full-duplex con lo cual ha desaparecido el problema antes mencionado.

4.3.2 Nivel de Enlace

En el Nivel Enlace, básicamente define (RFC 894) cómo se deben encapsular los datagramas IP del nivel
superior en las tramas Ethernet. En el formato estándar que tiene una trama Ethernet, particularizaremos
algunos datos tales como:

- Campo tipo: se pondrá el valor “0800 hex. (0x.0800)” que indica que lleva un datagrama IP
- Longitud campo de datos: debe ser como mínimo de 46 bytes, por lo que en caso necesario el
campo de datos deberá completarse para llegar a este valor. Como máximo puede tener una
longitud de 1500 bytes.

Otro tema a tener en cuenta al encapsular un datagrama IP sobre Ethernet, es la asociación de direcciones;
tendremos que asociar direcciones IP que constan de 32 bits con direcciones Ethernet que constan de 48
bits, con esta asociación lo que se logra es proporcionar a un elemento físico tangible con una dirección
Ethernet que lo identifica a nivel de enlace o Ethernet de forma única dentro de una subred una dirección de
red o dirección IP que le permitirá comunicarse con otros equipos que están ubicados en otras redes. En
general las direcciones MAC viene preconfiguradas por los fabricantes. Se debe considerar que las
direcciones MAC son un asignadas por un organismo internacional que garantiza que no existan
duplicaciones por lo que no se deben modificar las direcciones de origen a menos que el usuario disponga
de sus propias direcciones.

4.3.3 Nivel de Red

Las funcionalidades del nivel de Red vendrán dadas por el Internet Protocol (IP), al cual nos referiremos a
partir de ahora como protocolo IP, definido en la RFC 791.

El protocolo IP proporciona los medios necesarios para la transmisión de bloques de datos llamados
datagramas desde el origen al destino, donde origen y destino son equipos identificados por direcciones de
longitud fija (direcciones IP). Este protocolo también se encarga, si es necesario, de la fragmentación y el
reensamblado de datagramas grandes para su transmisión a través de redes de trama pequeña. El
protocolo IP no implementa mecanismos que aumenten la fiabilidad de los datos entre los extremos, ni el
control de flujo, secuenciamiento u otros servicios que normalmente se encuentran en protocolos host-a-
host, es lo que se conoce como protocolo no seguro.

El protocolo IP implementa dos funciones básicas: direccionamiento y fragmentación.

36
Un módulo IP usará las direcciones de la cabecera del datagrama IP para buscar el camino hacia el destino,
siendo esta función de búsqueda del camino lo que se denomina enrutamiento ó encaminamiento. Hay
equipos de red intermedios, los routers, que mediante protocolos específicos son los que se encargan de
desarrollar e implementar esta función de enrutamiento.

El protocolo IP trata cada datagrama como una entidad independiente no relacionada con ningún otro
datagrama, no existen conexiones o circuitos lógicos que unan dos extremos de forma que los datos que se
transmiten pasen a través de ellos; los datagramas IP entre dos equipos pueden recorrer diferentes caminos
para realizar el mismo trayecto.

4.3.4 Nivel Transporte

A nivel general el Nivel Transporte actuará como nexo entre el nivel Red e inferiores y superiores
(Aplicación + Sesión) en los cuales se ocupan de cómo hacer llegar los datos de un equipo a otro y el nivel
de Sesión y superiores, en el cual lo más importante es cómo se adaptarán los datos a las aplicaciones
específicas que hay definidas.

En este caso, el Nivel Transporte consta de 3 sub-niveles: TCP, Adaptación e ISO.

4.3.4.1 Subnivel TCP

El Protocolo de Control de Transmisión (Transmission Control Protocol, TCP) está pensado para ser
utilizado como un protocolo host-a-host muy fiable entre equipos de redes de comunicación por medio de
intercambio de paquetes y en un sistema interconectado.

La unidad de datos del protocolo TCP es el segmento TCP, que a su vez será el contenido del campo de
datos de los datagramas IP en la arquitectura que estamos viendo. El datagrama IP será el que se encargue
de direccional los segmentos a las máquinas correctas tal como se ha visto anteriormente mediante las
direcciones IP. Aparte de la información del origen y destino de los datos, el protocolo IP llevará información
sobre la prioridad, clasificación de seguridad y compartimentación de los segmentos TCP, de tal forma que
esta información pueda ser comunicada extremo a extremo entre múltiples redes.

El protocolo TCP será capaz de transferir un flujo continuo de bytes en cada sentido entre sus usuarios
empaquetando un cierto número de octetos en segmentos para después transmitirlos. Si hay un momento
en que desde la aplicación superior se necesita la certeza de que los datos entregados al módulo TCP han
sido enviados, podrá hacer uso de la función TCP “push” que hace que los datos que tiene los envíe
inmediatamente.

El protocolo TCP proporciona mecanismos de fiabilidad y control de flujo. TCP se vale de un número de
secuencia de los segmentos que manda con sus ACKs para saber si ha llegado o no la información y en
destino poder ordenar los segmentos y de un checksum para detectar cuándo llegan datos corruptos. El
control de flujo se realiza añadiendo una ventana al ACK que se utiliza para verificar la recepción de los
datos. TCP es capaz mediante estos mecanismos de recuperar los errores que se puedan dar en los niveles
inferiores.

Otra de las características del protocolo TCP es la multiplexación; mediante el uso de los puertos, TCP
permite que varios procesos o aplicaciones puedan comunicarse de forma simultánea desde un mismo host.

Para paliar el hecho de que la capa sobre la que descansa el protocolo TCP, la capa IP, no ofrece un
servicio fiable de transmisión de los datos, en el subnivel TCP se puede hacer uso del Protocolo de
Mensajes de Control Internet (Internet Control Messages Protocol, ICMP) cuya función será suministrar
información sobre los problemas en el entorno de comunicación. Este protocolo se define en la RFC 792.

4.3.4.2 Subnivel Adaptación

Todo equipo que elija implementar servicios de transporte ISO sobre TCP deberá implementar el Estándar
definido en la RFC 1006, en consecuencia, a partir del nivel de transporte se usarán estándares ISO. Para
la implementación de este subnivel de adaptación, el RFC-1006 provee un modo de interoperatividad en el
que se usa el TCP/IP para emular TP0 a fin de soportar aplicaciones OSI.

37
5.3.4.3 Protocolo de transporte TP0. ISO/IEC 8327-1
El nivel de transporte de ISO ofrece 5 niveles de servicio (TP0, 1, 2 3 ,4) según ofrezca más prestaciones
(ordenación, paquetización, re-fragmentación…). En este caso, como usamos TCP/IP conseguimos un nivel
de servicio equivalente al nivel 4 con conexión, pero utilizando el nivel de transporte ISO más bajo (TP0). Es
decir se envían mensajes sin confirmación.

Para este servicio existe un establecimiento de conexión en el que se pactan los tamaños máximos de los
mensajes y los servicios utilizados, y un procedimiento de desconexión.

4.3.4.4 Protocolo de Sesión. ISO/IEC 8073

El nivel de sesión de ISO comienza con un establecimiento de conexión (de sesión) en el que se pactan los
tamaños máximos de los mensajes y los servicios utilizados, y finaliza con un procedimiento de desconexión
tal como muestra la figura siguiente.

4.4 Nivel de Presentación

El nivel de presentación se encarga de la codificación de los datos en los mensajes.

4.4.1 Codificación (Basic Encoding Rules: BER)

El contenido de los mensajes definidos mediante ASN.1 debe codificarse para transmitirse en línea. En ISO
existen diferentes métodos de codificación, pero para los protocolos que nos ocupan se utilizan las reglas
de codificación básicas (Basic Encoding Rules BER).

TAG LEN VAL

1 byte 1,2,.. bytes LEN bytes

Figura 1: Codificación de un mensaje MMS.

Codificación BER
Campo Descripción
TAG (Etiqueta) Indica el contenido.

bits contenido Valores

6y7 Tipo de Indica el ámbito en el que es válida esa etiqueta (no
Tag se repite).

Valor Ámbito
00 UNIVERSAL
10 CONTEXTO

5 No Si vale 0 es un tipo primitivo (INTEGER, BOOL…).

Primitivo
0..4 Valor del Indica el tipo de dato. En la siguente tabla se
Tag muestran los valores de tipo primitivo que tendrán
sentido cuando el bit 5 valga 0

Valor Tipo
0x01 BOOLEAN
0x02 INTEGER
0x03 BITSTRING
0x04 OCTETSTRING
0x05 NULL
0x06 OBJECT IDENTIFER
38
 0x10 SEQUENCE
0x16 IA5STRING
0x17 UTCTIME
0x18 GENERALIZETIME
0x1A VISIBLESTRING

Cuando el bit 5 tome el valor de 1 el valor del tag

(bits 0-4) dependerá de cada gramática

LEN (Longitud) Representa un dato disponible de la base de datos distribuida.

o Si la longitud es menor que 128, entonces este campo es de 1 byte

y contiene la longitud.
o Si es mayor, entonces el primer byte es 0x8F y los dos siguientes
bytes contienen la longitud (hasta 65383).
o Etc..

VAL (Valor) Representa el valor (LEN bytes) a descodificar según corresponda.

4.4.2 Notificación abstracta. (Abstract Syntax Notation One: ASN.1)

Para definir el contenido de los mensajes, la orientación ISO es realizarlo utilizando una sintaxis (lenguaje)
de definición independiente de la codificación utilizada. Es en la particularización del protocolo donde se
escoge cuál es la forma idónea de codificar los mensajes definidos con ASN.1.

Esta notación nos permite especificar el contenido del mensaje mediante un lenguaje formal.

4.5 Nivel de aplicación

4.5.1 ACSE: Aplication Control Service Element

Para poder conectar el nivel de aplicación con el resto de niveles inferiores necesitamos una función de
conexión (de aplicación) y de desconexión. A este nivel, se le llama ACSE.
1
4.5.2 MMS: Manufacturing Message Specification
La especificación de mensajes para fabricación, consiste en la especificación de nivel de aplicación de los
servicios y procedimientos necesarios con el fin de intercambiar información entre dispositivos del tipo de
los que se instalan en las cadenas de producción. Básicamente, los servicios que pueden hacerse con MMS
son escrituras, lecturas y descripciones (directorios) de las variables (en nuestro caso consistirán en
conjuntos de atributos de nodos lógicos) y de archivos ó ficheros (transferencias de bloques de bytes de
forma transparente sin concretar más que su tamaño).

Estos servicios, trasladados a nuestro caso concreto se traducen al reporte de alarmas, ejecución de
mandos y consignas, auto descripción de los objetos y transferencia de ficheros.

4.5.2.1 Objetos
La siguiente tabla muestra la analogía entre objetos MMS y objetos IEC 61850.

IEC 61850 MMS

1
La nomenclatura proviene de su origen para uso en procesos de fabricación, pero dado su éxito se ha
extendido a otros ámbitos y usos.
39
 Server VMD (Virtual Manufacturing Device)
Dispositivo Lógico Dominio
Nodo lógico Variable con nombre
Dato Variable con nombre
Conjunto de Datos Lista de variables con nombre
Setting Control Block Variable con nombre
Report Control Block Variable con nombre
Log Journal
Log Control Block Variable con nombre
Goose Control Block Variable con nombre
Gsse Control Block Variable con nombre
Control Variable con nombre
Files Files

4.5.2.2 Servicios

Para describir las posibilidades y servicios de los MMS, se debe comenzar definiendo los objetos que se
manejarán en este nivel del protocolo. Es necesario recordar también que ahora se actúa en un nivel de
aplicación.

Objetos MMS
Objeto Descripción
Dispositivo de fabricación Representa un dispositivo.
Virtual (VMD).
Variable con Nombre. Representa un dato disponible de la base de datos distribuida.
Lista de variables con Representa una lista de variables.
nombre.
Ficheros.

En el caso de IEC 61850, una variable con nombre es:

o El contenido de un nodo lógico.

o El atributo de un nodo lógico (una clase de datos compatible).
o El conjunto de datos del atributo de un nodo lógico de una misma restricción funcional.
o Un campo concreto.
o Etc…

IEC 61850 MMS

LogicalDeviceDirectory GetNameList
GetAllDataValues Read
GetDataValues Read
SetDataValues Write
GetDataDirectory GetNameList
GetDataDefinition GetVariableAccessArrtibutes
GetDataSetValues Read
SetDataSetValues Write
CreateDataSet CreateNamedVariableList
DeleteDataSet DeleteNamedVariableList
GetDataSetDirectory GetNameList
Report InformationRequest
GetBRCBValues/GetURCBValues Read
GetBRCBValues/GetURCBValues Write
GetLCB Read

40
 SetLCB Write
QueryLogByTime ReadJournal
QueryLogAfter ReadJournal
GetLogStatusValues GetJournalStatus
Select Read/Write
SelectWithValue ReadWrite
Cancel Write
Operate Write
Command-Termination Write
TimeActivated-Operate Write
GetFile FileOpen/FileRead/FileClose
SetFile ObtainFile
DeleteFile FileDelete
GetFileAttributeValues FileDirectory

Para darle nombre a estas variables, la norma especifica un algoritmo concreto e inequívoco que
básicamente consiste en separar los campos o camino desde el nodo lógico hasta la variable separando los
campos con el signo “$”.

Una vez conocemos lo que son nuestras variables, las operaciones posibles sobre ellas se definen en la
tabla siguiente.

Métodos MMS
Método Descripción
Get Obtiene el valor de una variable.
Set Escribe el valor de una variable.
Query Obtiene la descripción de un objeto.
Create Crea un objeto temporal.
Delete Borra un objeto temporal.

Por último sólo es necesario describir el contenido de los mensajes o APDU (Application Protocol Data Unit,
Unidad de datos de nivel Aplicación). Para ello, como se ha mencionado anteriormente se utiliza un
lenguaje formal llamado ASN.1. La siguiente figura muestra la definición de un mensaje para una petición de
lectura.

O Read-request::= SEQUENCE
{
O SpecificationWithResult [0] IMPLICIT BOOLEAN DEFAULT FALSE
O VariableAccessSpecification [1] VariableAccessSpecification
O }

Cuando dentro de un mensaje se deba especificar una variable, se hace según se muestra en la siguiente
figura. Como se muestra en la Fig., esta forma de describir los mensajes aunque es altamente complicada
brinda un alto grado de flexibilidad.

41
O VariableAccessSpecification::= CHOICE
{
O listOfVariable [0] IMPLICIT SEQUENCE OF SEQUENCE
O {
O variableSpecification VariableSpecification,
O alternateAccess [5] IMPLICIT AlternateAccess OPTIONAL
}
O variableListName [1] ObjectName
}

Por último, se pueden relacionar los métodos empleados a nivel de aplicación con los servicios según se
muestra en la siguiente tabla.

Get Set Query Create Delete

VMD Rename
Variable GetVariableAccessAttrib DefineNamedVaria DeleteVariableAcc
utes ble ess
Lista
Fichero FileRead FileRename FileDirectory FileOpen FileDelete
FileClose

5. Herramientas de ingeniería y documentación

Una de las tecnologías en las que está basada la norma IEC 61850 es el lenguaje de descripción XML. En
base a esta tecnología el capítulo 6 de la norma define el lenguaje de configuración de subestaciones
(SCL).

El lenguaje SCL se utiliza para describir la configuración de la subestación incluyendo la descripción de las
capacidades de cada dispositivo. El principal objetivo es permitir el intercambio de la información de
configuración entre las herramientas de configuración de los dispositivos de una forma interoperable entre
aplicaciones y dispositivos de diferentes fabricantes.

El diseño de una subestación IEC 61850 requiere por lo tanto de una herramienta que a partir de los
archivos ó ficheros de cada dispositivo generen los ficheros de configuración de cada dispositivo y el de
configuración del proyecto.

Además dicha herramienta debe ser capaz de generar la documentación de la funcionalidad y la operativa
de la subestación de forma que se simplifiquen las tareas de puesta en marcha, pruebas de funcionamiento
y el posterior mantenimiento.

5.1 Alcance de la norma

La norma IEC 61850 en su parte 6 describe el lenguaje de configuración de subestaciones SCL que es la
base sobre la que se desarrollan los procesos de configuración de dispositivos y del conjunto de la
subestación y que describe las reglas genéricas de formación de todos los ficheros ó archivos necesarios en
el proceso de configuración.

De hecho la norma se limita a describir el proceso de configuración de los dispositivos IEC 61850 de una
subestación y especifica el formato de los ficheros que deben intercambiarse.

La configuración de los dispositivos IEC 61850 parte de los archivos o ficheros tipo “icd” que describen las
capacidades de cada dispositivo en términos de la norma y de acuerdo a las reglas establecidas en el
lenguaje SCL. Estos ficheros permiten crear modelos normalizados de cada dispositivo que cuando son
utilizados en un proyecto concreto se complementan con los datos específicos de la subestación en la que
deben operar. El fichero que contiene todos los datos de configuración de un dispositivo toma la extensión
“cid”.

42
Una vez que se ha terminado el proyecto y se han configurado todos los parámetros de los dispositivos y
del sistema de comunicaciones, incluidas las conexiones GOOSE, se puede generar el fichero “scd” que
contiene dicha información.

En resumen, la norma especifica los siguientes tipos de ficheros:

- icd. Plantilla que describe las capacidades de un modelo de dispositivo IEC 61850.
- cid. Fichero de configuración de un dispositivo en un proyecto de subestación concreto.
- ssd. Describe la arquitectura de la subestación incluyendo el unifilar y los nodos lógicos asociados a
cada dispositivo primario. Representa la arquitectura genérica y se utiliza para generar modelos de
proyectos a partir de los cuales se puede realizar un proyecto concreto.
- scd. Describe el proyecto concreto de una subestación incluyendo la información del fichero ssd y
toda la información que contiene cada uno de los ficheros cid de los dispositivos incluidos en el
proyecto. Además, describe la parte de comunicaciones incluyendo las direcciones IP y las
informaciones relativas a los mensajes GOOSE.

5.2 Carencias y retos

Si bien el objetivo y alcance fijado por la norma en su parte 6 es muy ambicioso, éste no cubre las
necesidades reales del proceso de ingeniería de subestaciones ya que parte de un supuesto que no refleja
la realidad del mercado ni el alcance real de los proyectos de subestaciones.

Carencias:

La principal carencia es que no se ajusta a la realidad del mercado. Se ha fijado un objetivo de

interoperabilidad para IEDs que cumplen la normativa pero no se han considerado los casos en que el
cumplimiento es limitado y por lo tanto los archivos o ficheros de configuración sólo reflejan unos
aspectos del proyecto pero no el conjunto de funciones que debe realizar cada dispositivo ya que ciertas
funciones siguen realizándose de forma tradicional.

La norma no contempla el caso habitual de que exista un conjunto de equipos de subestación basados
en otras tecnologías pero relacionados con equipos IEC 61850 y que deben intercambiar información
con ellos.

Otra carencia es la falta de definición sobre como obtener una documentación inteligible para los
ingenieros eléctricos, de protección, control, telecomunicaciones, etc. La documentación generada en
base a la norma en el fichero ssd no tiene una utilidad clara ya que es una visión parcial y muy sesgada
de la funcionalidad de la subestación.

La falta de una metodología clara para la definición de tipos de datos y del proceso de definición del
sistema hace que la interoperabilidad entre fabricantes no se obtenga de forma automática sino que
habitualmente requiera de un proceso de depuración que en muchos casos no queda documentado lo
cual redunda en una mayor complejidad en el posterior mantenimiento y ampliación del sistema.
Además, las pruebas del sistema y el cumplimiento de la normativa por parte de los dispositivos no
queda relacionada con la especificación y la estructura de datos por lo que en muchos casos resulta
difícil saber a priori si un dispositivo podrá interoperar en un entorno determinado.

En función de las carencias identificadas se pueden señalar que los principales retos son los descritos a
continuación.

Retos:

- ¿Cómo tratar los IEDs que no cumplen de forma completa la normativa?

- ¿Cómo integrar dispositivos no relacionados con la norma?
- ¿Cómo integrar otras tecnologías tales como las de comunicación o de automatismos?
- ¿Cómo documentar la configuración de forma inteligible?
- ¿Cómo garantizar el correcto funcionamiento del sistema cuando se interrelacionan diferentes
tecnologías?

Conclusión: es muy importante disponer de un entorno de diseño y documentación integrado que permita
mantener y aumentar el conocimiento de la empresa a la vez que genera la documentación necesaria para
afrontar las tareas de mantenimiento y las futuras tareas de reingeniería de la subestación.

43
5.3 Requisitos de un entorno de trabajo integrado
La posible solución a las carencias apuntadas en el apartado anterior y una forma de afrontar los retos
identificados es disponer de un entorno de trabajo integrado capaz de unificar tecnologías y de generar
tanto la documentación como las configuraciones de los dispositivos en la norma y formato que se requiera.

Otros
Requerimientos de Operación
Ficheros
ENTORNO Modelado de Equipos
INTEGRADO
.scd Diseño funcional
.cid
.ssd

Documentación
Documentación
del
Tradicional
Conocimiento

Figura 5.1 – Entorno de trabajo integrado

El entorno integrado garantiza que la documentación generada a partir del proyecto refleja exactamente el
diseño y que el diseño se ha realizado en base a los modelos normalizados, los requisitos de operación
establecidos, etc.

Los principales requisitos para este entorno de trabajo son:

- Cumplimiento con la norma. Implica capacidad de leer y generar archivos o ficheros en el formato
especificado en la parte 6.
- Entorno de diseño integrado e integrador de diferentes tecnologías. Hay funciones de control y
automatismos que se definen utilizando otras normas y que por lo tanto quedan excluidas de los
ficheros IEC 61850 de descripción de la subestación. El entorno de trabajo debe ser capaz de
integrar varias normas y varias tecnologías de forma transparente al usuario.
- Lógicas de protección y simulaciones funcionales. (Gestión del conocimiento)
- Reutilización del conocimiento. Normalización de proyectos y de métodos
- Capacidad de creación de documentación. (Tradicional, según norma, para mantenimiento, etc.)
- Trazabilidad del proyecto y Gestión documental. Entorno de trabajo que garantice que tanto los
documentos generados como los ficheros de configuración reflejan el diseño sin modificaciones y
que no han sido alterados con posterioridad.
- Configuración. Capacidad para generar los ficheros de configuración especificados por la norma
IEC 61840 junto con otros ficheros de configuración que puedan ser necesarios en función de las
tecnologías integradas además de un informa de los aspectos que no han sido incluidos en los
ficheros de configuración por falta de información sobre algún dispositivo o por incluirse dispositivos
que no cumplen totalmente con la normativa. Se requiere que a partir de la información unificada del
proyecto se pueda segregar las configuraciones que corresponden a cada norma y a cada
tecnología.
- Simulación multifuncional. Capacidad de realizar diferentes simulaciones lógicas de forma que se
pueda verificar el correcto funcionamiento del sistema en las situaciones que se consideren más
críticas. De esta forma se pueden anticipar problemas de compatibilidad entre tecnologías o de
implementaciones particulares.
- Capacidad de definición de un entorno de tipos de datos.
- Documentación de las redes internas de comunicación LANs y otros adaptadores incluyendo su
configuración.

Las herramientas de ingeniería deben ser capaces de generar la siguiente documentación:

44
 - Esquemas funcionales incluyendo unificares, descriptivos de los esquemas de protección, medida y
control.
- Esquemas desarrollados de las posiciones y los detalles de conexionado.
- Esquemas de las conexiones lógicas tanto las realizadas mediante señales GOOSE como las
establecidas utilizando el protocolo MMS.
- Listas de cableados
- Listas de materiales
- Listas de señales lógicas configuradas mediante los ficheros IEC 6850
- Listas de señales lógicas no incluidas en los ficheros IEC 61850 tales como las realizadas mediante
MMS.
- Documentación explicativa del contenido de los ficheros cid de cada dispositivo y del fichero scd
del proyecto.
- Documentación de las lógicas y de sus simulaciones.
- Documentación de las comunicaciones.
- Documentación de las bases de datos de telecontrol.

Además de generar la documentación en el formato tradicional, es una ventaja importante disponer de la

capacidad de exportar dicha información en ficheros XML. Esto facilita la interconexión con otros sistemas
de gestión, mantenimiento, etc.

6. Validación del sistema

6.1 Validación del sistema

No desenvolvimento e produção de um IED, vários requisitos específicos de um cliente são agregados ao
projeto original. Portanto, um sistema para assegurar a qualidade desse IED e a validade de sua aplicação
devem envolver um grupo de teste confiáveis.
Os testes internos realizados durante o desenvolvimento de um IED resultam em teste de tipo, também
chamado de teste de nível unitário por abranger um elemento a ser testado, ou seja, um elemento de prova
de um grupo a ser produzido.
Após a definição do IED (hardware e aplicativos internos) têm-se os testes de rotina, realizados de forma
contínua durante uma cadeia de produção. Esses são necessários para garantir a permanente qualidade
dos dispositivos entregues de acordo com os procedimentos de qualidade do fabricante.
Após a fabricação tem-se o teste de conformidade. Este é o teste de tipo para a comunicação. Uma vez que
a comunicação estabelece um sistema, o teste do IED também é direcionado para a sua integração em
sistemas. Com o advento de uma norma de comunicação global, a norma IEC 61850 inclui testes de
conformidade padrão para assegurar que todos os fornecedores atendam os requisitos aplicáveis. Isto
melhora as possibilidades para a interoperabilidade entre os dispositivos individuais integrados no sistema,
fornecendo o máximo de confiança ao cliente de que o dispositivo interoperará com outros dispositivos
certificados, além de realizar um teste de tipo da interface de comunicação de um SAS.
Testes de tipo e testes de conformidade não garantem completamente que todos os requisitos funcionais e
de desempenho sejam atendidos. Entretanto, quando propriamente executados tais testes reduzem
significativamente os riscos de problemas custosos durante a integração do sistema na fábrica ou em
campo.
Testes de conformidade não substituem testes relacionados ao sistema específico de projeto, tais como o
FAT e o SAT, além dos testes funcionais. Os FAT e SAT são baseados em requisitos específicos do cliente
para um sistema de automação dedicado a um sistema ou subestação.
Os IEDs submetidos a testes de interoperabilidade e testes funcionais são considerados conformes.
A interoperabilidade ou capacidade de operar em diferentes funções do sistema entre IEDs de diferentes
fabricantes se tornou uma necessidade imprescindível para esses dispositivos obterem sucesso. Assim o

45
teste de interoperabilidade atesta a habilidade de o IED operar em um sistema com diversos dispositivos de
diferentes fabricantes.
O objetivo do teste de um elemento funcional é determinar se o elemento testado tem o comportamento
esperado sob diferentes condições de testes reais, enquanto os testes de sistema olham o desempenho
completo do sistema sob um ponto de vista de um observador externo Os elementos funcionais no teste do
sistema são considerados unidades, ou seja, os menores componentes do sistema que tem interface visível
e comportamento definido.

6.1.1 Ensayos de conformidad

A Norma IEC 61850, em sua Parte 10, estabelece os procedimentos e as ferramentas para os testes de
conformidade a serem realizados em um IED ou em um SAS. O objetivo do teste da conformidade é
assegurar que a IEC 61850 com todos seus modelos e serviços sejam executados corretamente. Isto
melhora as possibilidades para a interoperabilidade entre os dispositivos individuais integrados no sistema,
fornecendo o máximo de confiança ao cliente de que o dispositivo interoperará com outros dispositivos
certificados, além de realizar um teste de tipo da interface de comunicação de um SAS.

Testes de conformidade devem levar em consideração os seguintes aspectos:

 Um importante item para os testes é a complexidade dos testes a serem realizados. Para cobrir
todas as situações possíveis, tanto de operação quanto do funcionamento sob falha, em um sistema
é necessário a descrição de um número muito grande de cenários de teste. Pode ser possível a
cobertura de todos os casos de operação normal, mas não se podem afirmar o mesmo todos os
casos de falha.
 Não é possível testar todas as configurações com todos os diferentes fornecedores de IEDs, em
todo mundo. Entretanto, uma arquitetura padrão, utilizando simuladores, dever ser usada. Isto
implica na utilização de uma configuração padrão e procedimentos de teste predeterminados para
obter repetibilidade de teste e resultados.
 A padronização da comunicação não implica na padronização das funções desempenhadas pelo
sistema ou equipamento sob teste. Ainda, os modos de falha dessas funções estão fora do escopo
da norma IEC61850. Entretanto, a resposta do sistema mediante essas falhas tem relação direta no
fluxo de dados.

O teste de conformidade estabelece que a comunicação do sistema ou equipamento sob teste funciona de
acordo com a série norma IEC61850, portanto a norma foca a interoperabilidade usando dados, funções e
modelos dos dispositivos incluindo todos os serviços acima ou no nível de aplicação (ACSI – Abstract
Communication Service Interface – Interface do Serviço de Comunicação Abstrata). Tem-se que classes de
desempenho também são endereçadas.
Uma vez que a norma IEC61850 não define novas pilhas de comunicação, a conformidade a todas as sete
camadas ISO/OSI pode ser comprovada por documentação de que o software, compatível com a pilha de
comunicação com as especificações correspondentes, é implementado e pode ter sido previamente testado
e, opcionalmente, certificado. No teste de conformidade padrão, somente a aplicação feita de acordo com a
ACSI pode ser testada.

O Teste de Conformidade deve incluir o seguinte:

 Documentação e controle de versão, conforme IEC 61850 Parte 4, contendo:

46
 o Arquivo MICS – (Model Implementation Conformance Statement), o arquivo
Estabelecimento de Conformidade de Implementação do Modelo que detalha os elementos
dos modelos de objeto de dados padrão suportado pelo IED ou SAS a ser testado.
Basicamente corresponde ao resumo das possibilidades de comunicação do IED ou SAS.
o Arquivo PIXIT – (Protocol Implementation eXtra Information for Testing), o documento de
Informações Adicionais na Implementação do Protocolo para Teste contem informações
específicas do sistema ou dispositivo relativas às capacidades de comunicação do sistema
ou dispositivo a ser testado e que estão fora do escopo das norma IEC 61850. O PIXIT não
está sujeito a normatização.
o Configuração (SCL), conforme IEC 61850 Parte 6 . A definição da linguagem de
configuração de subestação (SCL) permite especificar facilmente a relação da comunicação
entre as unidades que compõem o SAS através da geração de arquivos formatados em
XML – Extensible Markup Language – versão 1.0. Isto permite que a descrição da
configuração de um IED seja passada a uma ferramenta de engenharia de aplicação e
comunicação, no nível de sistema, e retorna com a descrição da configuração do sistema
completo para a ferramenta de configuração do IED. Assim, o processo de especificação
oferece um enorme potencial para racionalização das diferentes praticas existentes na
implementação dos projetos utilizando os arquivos:
 SSD (System Specification Description): Descrição XML dos dados do Sistema. O
arquivo SSD possui a descrição dos dados de todo sistema, contém o diagrama
unifilar com as funções alocadas, e é o ponto de partida para gerar a SCD.
 SCD (Substation Configuration Description) Descrição XML de uma subestação. A
descrição da configuração da subestação (arquivo SCD), gerado pela ferramenta
de configuração do sistema, contem os ICDs da subestação e descreve a
configuração completa da subestação incluindo a rede de comunicação e
informações sobre o fluxo de dados de comunicação.
 ICD (IED Capability Description) Descrição XML dos itens aplicados em um IED. A
Descrição da Capacidade do IED (arquivo ICD) descreve as capacidades e pré-
configurações dos IEDs, gerados pela ferramenta de configuração de descrição dos
IEDs. Neles estão descritas todas as funções que poderão ser utilizadas no
sistema.
 CID (Configured IED Description) Descrição XML da configuração de um IED
especifico. A Descrição da Configuração do IED (arquivo CID) pode ser usada para
configurar um IED. Neste arquivo estão descritas as funções parametrizadas ou
habilitadas pelo usuário no IED.
o Modelo de objeto de dados, conforme IEC 61850 Partes 7-3 e 7-4.
o Serviços de comunicação, conforme IEC 61850 Partes 7-2, 8-1, 9-1 e 9-2

Os testes de conformidade devem ser ajustados para cada IED ou Sistema sob teste baseado nas
capacidades identificadas nos arquivos fornecidos pelo fabricante: PICS, PIXIT e MICS. Para a realização
do teste, devem estar à disposição:

 IED ou Sistema pronto para testes;

 Arquivo de Declaração de Conformidade de Implementação de Protocolo (Protocol Implementation
Conformance Statement – PICS), com referência IEC 61850-7-2, Anexo A;
 Arquivo de Declaração de Informação Extra de Implementação de Protocolo (Protocol
Implementation eXtra Information for Testing – PIXIT);

47
  Arquivo de Declaração de Conformidade a Modelo de Implementação (Model Implementation
Conformance Statement – MICS);
 Manuais do IED ou Sistema sob teste, com detalhes de instalação e operação.

As condições para o teste de conformidade ocorrem nas seguintes categorias:

 Condições de conformidade estáticas (definem as condições que a implementação deve propiciar);

 Condições de conformidade dinâmicas (definem as condições que se originam de um protocolo
usado para implementação apropriada).

As condições estáticas e dinâmicas devem ser definidas em uma Declaração de Conformidade de

Implementação de Protocolo (PICS). Este PICS é útil para três propósitos:

 Escolher o conjunto de testes apropriado;

 Assegurar-se de que os testes apropriados para uma chamada de conformidade são
desempenhados
 Fornecer a base para revisão da conformidade estática

Um PICS padrão deve ser fornecido. Um ou mais PICS concretos devem ser definidos para o Mapeamento
do Serviço de Comunicação Específica (Specific Communication Service Mapping – SCSM).
Uma Declaração de Conformidade a Modelo de Implementação (MICS) deve ser fornecida detalhando os
elementos de modelo de objeto de dados suportado pelo sistema ou dispositivo. O MICS é implementado
no arquivo SCD (Descrição de Configuração de Subestação) de acordo com a Linguagem de Configuração
de Subestação SCL definida na norma IEC 61850, parte 6. Adicionalmente ao PICS, um documento de
Informações Extra de Implementação de Protocolo para Testes (PIXIT) deve ser fornecida.

A figura 6.1 mostra o processo do teste de conformidade definido pela IEC 61850-10.

48
 Figura 6.1 – Proceso de ensayo de conformidad definido por IEC 61850-10

6.1.2 Ensayos de interoperabilidad

A interoperabilidade é habilidade de IEDs de um ou vários fabricantes trabalharem em conjunto. Isto implica

que os IEDs que compõem o sistema sob teste sejam capazes de exportar informação e usar a informação
de outros IEDs para aplicar sua funcionalidade.
O teste de interoperabilidade é usado para detectar qualquer problema potencial de interoperabilidade entre
os elementos funcionais e/ou subfunções que são integradas no IED ou no sistema sob teste.
Isto não testa somente a compatibilidade durante a operação dessas funções e a eficiência no aplicativo
utilizado pelos fabricantes de IEDs do sistema, mas também observa as trocas entre os diferentes
componentes integrados no sistema.

6.1.3 Ensayos funcionales

O teste functional executa a verificação das características de IEDs ou Sistemas através de dispostivo de
teste capaz de simular as condições de teste correspondente aos dados técnicos de operação do sistema
sob teste. O objetivo do teste funcional é determinar se o elemento testado tem o comportamento esperado
sob diferentes condições de teste reais
Dependendo da complexidade do sistema, seus componentes podem ser elementos funcionais simples,
subsistemas ou uma combinação dos dois. Um subsistema é definido como um conjunto de elementos, que
é um sistema próprio, e também uma parte de todo o sistema. A hierarquia de sistemas complexos é
mostrada na figura 2 com um diagrama UML. Pode ser visto que o sistema pode conter de 1 a muitas
funções, que podem ter diversas camadas contendo de 1 a muitas subfunções e assim em diante – a
subfunção pode conter de 1 a muitos elementos multifuncionais. Os elementos multifuncionais
correspondem aos nós lógicos da IEC 61850.

Fig. 6.2 Diagrama da jerarquía del sistema en UML

49
O dispositivo de teste conduz o teste por completo, no sistema de automatização de subestação integrado,
em um subsistema ou em uma função distribuída. Seu objetivo é avaliar a conformidade do sistema com
suas exigências requeridas.
De acordo com a hierarquia apresentada, o teste pode ser conduzido de dois modos:

 O teste de aceitação em fábrica (FAT) tem por objetivo provar que o modelo de dados, os serviços
de comunicação e o desempenho definido como padrão estão de acordo com a especificação de
projeto. Neste caso o teste inicia primeiro com as partes individuais do sistema – os elementos
funcionais. Eles são então agrupados para formar subfunções ou funções, que estão em fila ligados
dentro de funções mais complexas até que o sistema completo seja testado.
 O teste de aceitação local (SAT) é a verificação de cada dado e pontos de controle, e da
funcionalidade correta desses elementos dentro do Sistema de Automação de Subestação. Verifica
ainda a funcionalidadde do SAS e seu ambiente de operação na planta instalada. Esse teste é
realizado com a parametrização e ajustes finais de operação do sistema testado. O SAT é uma pré-
condição para a colocação em operação do sistema. Neste caso, seja em testes de
comissionamento ou manutenção, é considerado que os elementos funcionais individuais estão
operando corretamente, especialmente se não existem alarmes em nenhum dos IEDs que são
incluídos no sistema de teste. Neste caso uma abordagem de sistema para o elemento funcional é
indicada, desde que o interesse seja o desempenho completo das funções do sistema testadas e
não no comportamento dos componentes do sistema. Isto significa que temos uma perspectiva
externa do objeto sob teste para derivar os casos de teste e analisar os resultados.

Testes funcionais de qualquer função ou subfunção necessitam que o programador do teste selecione o
ajuste das entradas válidas ou inválidas e determine a saída esperada para cada condição de teste
definidas no plano de teste. Isto irá servir para definir o critério de avaliação para determinar se o teste é
APROVADO ou REPROVADO.

6.1.4 Diretrizes para Dispositivo de Teste Universal

Um dispositivo de teste deve permitir um ensaio apropriado, adequado às exigências do sistema de

proteção e comunicação a ser testado, simulando as características da subestação e do sistema elétrico.
Para tal, deve possuir as seguintes funções:

 Simulação de sinais analógico de correntes e tensões aos IEDs testados;

 Simulação de sinais amostrados na rede (SMV) de acordo com IEC 61850 9-2;
 Simulação dos sinais digitais que representam as mudanças do estado do disjuntor e dos sinais de
controle remoto, tais como saídas tradicionais para os IEDs;
 Simulação de mensagens GSSE/GOOSE a fim de verificar a operação de outros IEDs conectados à
rede da subestação.
 Análise de mensagem GSSE/GOOSE que monitoram e registram o tempo das mensagens recebidas
proveniente dos IEDs em teste a fim de avaliar o desempenho/resposta dos relés.
 Simulação de rede, com ferramentas de configuração que permitam ao usuário configurar o
equipamento de teste para os requisitos dos IEDs testados e enviar mensagens GSSE/GOOSE
simuladas para múltiplos IEDs incluídos no sistema de proteção, operando com comunicações de alta
velocidade ponto-a-ponto distribuídas.

50
  Simulação de processo, com ferramenta de teste que permita a configuração flexível das seqüências
de teste solicitadas e simulações que utilizam as funções acima, com inserção das corrente e tensões
correspondentes a estados de pré-falta, falta e pós-falta, em regime permanente ou transitório.
 Contadores de tempo e registradores de eventos.
 Ferramenta de teste com modelos de carga, modelos de configuração e modelos de rede, capazes
de comparar e avaliar os dados de modelo com os resultados dos testes.

O desenvolvimento e implementação de equipamentos e sistemas de automação baseados na norma

IEC61850 requerem uma nova geração de equipamentos de teste especializados assim como de métodos
para testes funcionais para os diversos componentes de sistema. Esses equipamentos devem obedecer às
seguintes diretrizes:

 A simulação do barramento de processo da subestação e o monitoramento do funcionamento dos

dispositivos testados ou do controle distribuído e das funções de proteção são totalmente diferentes.
O ensaio convencional necessita de uma fiação de cobre entre o equipamento de teste e o objeto sob
teste, enquanto no caso das aplicações baseadas no padrão IEC 61850, podem-se utilizar parcial ou
completamente os canais de comunicações;
 O equipamento de teste deve estar apto a atender à simulação do processo convencional com sinais
analógicos (tensões, correntes, sinais lógicos binários);
 O equipamento deve simular sinais de falta em regime permanente ou transitório, fornecendo para o
sistema sob teste sinais analógico ou digitais amostrados na rede segundo a norma IEC 61850 9-2;
 O equipamento de teste deve simular, mapear, capturar, ler, medir, comparar e checar os sinais de
comunicação, sejam ele sinais convencionais binários utilizando fiação rígida ou mensagens
GSSE/GOOSE via rede Ethernet. Essas funções devem ser realizadas pelo equipamento de teste e
não por dispositivos de controles acoplados ao sistema.

6.1.5 Concepção de Conjunto Completo de Teste

O teste completo das funções dos barramentos de processo e estação baseados somente em comunicação
(IEC 61850 8-1 ou IEC 61850 9-2) será realizado de forma similar ao teste de IEDs individuais. A diferença
principal é que neste caso haverá múltiplos dispositivos de teste com simuladores virtuais ou saídas
analógicas. A simulação do ambiente da subestação e do sistema irá requerer a simulação de múltiplas
unidades de Conformação de Dados (Merging Units baseadas na IEC 61850 9-2) e outros IEDs (interface
IEC 61850 8-1).

51
 Fig. 6.3 Diagrama en bloques simplificado del sistema de ensayo

A avaliação do desempenho das funções distribuídas neste caso estará baseada na subscrição dos
componentes do sistema de teste para as mensagens GOOSE dos diferentes IEDs envolvidos. Se estes
dispositivos tiverem também relés de saída com fiação rígida para os dispositivos de teste, sua operação
deverá ser monitorada também a fim de avaliar o desempenho do sistema testado. Se necessário, deve
comparar os resultados utilizando rede de comunicações e os dados obtidos com fiação rígida. Um
diagrama de bloco simplificado deste sistema do teste é mostrado na figura 3.

Testes de dispostivos e sistemas de automação de subestação baseados na IEC 61850 requerem um bom
entendimento da norma IEC 618150 e das caractisticas funcionais do sistema testado, tais como:

 As condições nas quais os elementos estarão operando

 A funcionalidade do sistema
 A hierarquia do sistema
 Os dispositivos utilizados
 A arquitetura de comunicação
 Os princípios de operação ou algoritmos utilizado
 Os princípios do sistema de teste
 A funcionalidade das ferramentas de teste

Os testes devem ser realizados o mais próximo possível das condições reais de operação para qual o
dispositivo ou sistema sob teste foi projetado.

O teste de conformidade realiza a verificação dos canais de comunicação do IED de acordo com IEC61850-
10. O resultado do teste de conformidade é uma declaração da capacidade do IED em realizar a
comunicação definida pela norma, assegurando que a IEC 61850 com todos seus modelos e serviços sejam
executados corretamente. Os IEDs submetidos a testes de interoperabilidade e testes funcionais são
considerados conformes.

A interoperabilidade ou capacidade de operar em diferentes funções do sistema entre IEDs de diferentes

fabricantes se tornou uma necessidade imprescindível para esses dispositivos obterem sucesso. Assim o
teste de interoperabilidade atesta a habilidade de o IED operar em um sistema com diversos dispositivos de
diferentes fabricantes.

52
O objetivo do teste de um elemento funcional é determinar se o elemento testado tem o comportamento
esperado sob diferentes condições de testes reais, enquanto os testes de sistema olham o desempenho
completo do sistema sob um ponto de vista de um observador externo Os elementos funcionais no teste do
sistema são considerados unidades, ou seja, os menores componentes do sistema que tem interface visível
e comportamento definido.

7. Migración. Actualización y Ampliación

El objetivo de la norma IEC-61850 es la interoperabilidad entre IEDs del mismo fabricante y de diferentes
fabricantes, pero además proveer un lenguaje común para que fabricantes y usuarios obtengan la
interoperabilidad requeridas en los sistemas modernos.

En las instalaciones existentes las Empresas Eléctricas han realizado inversiones de magnitud, por lo que
no es posible cambiar una cantidad importante de dispositivos en forma relativamente rápida, ya que es
conocido no solamente el criterio conservador que sostienen desde el punto de vista del equipamiento, sino
también y muy especialmente es necesario considerar los aspectos de la vida útil del equipamiento, que en
el caso del equipamiento primario, y en alguna medida el equipamiento secundario se extienden por
décadas.

El objetivo de esta sección es el de describir el problema, proponer soluciones y sugerir una migración
ordenada de la tecnología tradicionalmente utilizada en la integración de IEDs en subestaciones. El
concepto de ‘Gateway’ será utilizado en la propuesta de soluciones por ser el nexo necesario entre los
sistemas de comunicación tradicionales y los nuevos sistemas IEC-61850.

7.1 Tecnología tradicional

En la actualidad en subestaciones de los sistemas de potencia, encontramos diversidad de dispositivos que

proveen distintas funciones, tales como protección, control, y mediciones. Algunos proveen una sola
función, mientras que los más modernos son multifuncionales. Con respecto a la comunicación, los nuevos
dispositivos de protección, poseen una buena capacidad de comunicación, mientras que dispositivos más
antiguos aún instalados en la red eléctrica no poseen esa capacidad. El propósito de esta sección es
repasar los dispositivos y tecnologías relevantes para la migración hacia la norma IEC-61850.

7.1.1 Dispositivos sin capacidad de comunicación

En muchas subestaciones existentes todavía funcionan dispositivos diseñados con tecnología

electromecánica o de estado sólido. Por sus características constructivas, no es posible comunicarse con
estos dispositivos, pero existe en ellos información relevante que puede ser compartida en un sistema
integrado de la subestación.

Los contactos de salida son la única información que puede ser leída de estos dispositivos. La funcionalidad
de estos contactos esta de acuerdo al diseño y puede significar una estado anómalo (sobre-temperatura de
un transformador, por ejemplo), un disparo (salidas de los relés de protección electromecánicos, por
ejemplo), una posición (los contactos de posición de un cambiador de Taps o la posición de un interruptor,
por ejemplo.)

Algunos dispositivos generan salidas analógicas (4-20 mA, por ejemplo) que son mediciones de ciertos
parámetros (temperatura, presión, potencia, etc.) Estas salidas analógicas son informaciones que deben
ser integradas y mostradas en las interfases gráficas y alarmas en una subestación.

Es además importante el reconocer que muchos de estos dispositivos son controlables. Ellos reciben
comandos simples para efectuar acciones de acuerdo a entradas de contactos (generalmente la presencia
del voltaje de la batería de la subestación o la ausencia de este) o entradas analógicas (4-20 mA, por
ejemplo) para accionar ciertos parámetros en la subestación. El accionar de estos dispositivos es importante
todavía en un sistema integrado de subestación.

Ejemplos de este tipo de dispositivos son:

53
 - Relés electromecánicos
- Relés de estado sólido
- Cambiadores de taps
- Monitores de transformador
- Monitores de presión SF6
- Estados de interruptor
- Posiciones de seccionadores
- Alarmas

Es muy fácil el encontrar algún dispositivo en la subestación que este en esta categoría. Diseños antiguos y
aparatos electromecánicos son típicos ejemplos de esta categoría.

La única forma de integrar este tipo de dispositivos en la arquitectura IEC 61850 es mediante dispositivos
especiales que permiten convertir las señales binarias y analógicas en datos de LN y mensajes
normalizados de IEC 61850. En cualquier caso es necesario evaluar la conveniencia de continuar utilizando
este equipamiento en lugar de afrontar una renovación que podría implicar un costo muy elevado y difícil de
amortizar por la antigüedad de los equipos.

7.1.2 Dispositivos con capacidad de comunicaciones

Muy pocos son los dispositivos de subestación diseñados con microprocesadores que no tengan alguna
capacidad de comunicación digital. Esta habilidad hace que se puedan implementar sistemas de
recolección de datos para el monitoreo y control de subestaciones. La consideración más grande, sin
embargo, es que a pesar de que se tiene esa capacidad de comunicaciones, los dispositivos solamente se
comunicaran con otros dispositivos que hablen el mismo idioma, o protocolo. Los protocolos de
comunicaciones son las reglas que deben seguirse, tanto en el hardware como en el formato de
transmisión, para que dos equipos se comuniquen. Es entonces una gran consideración el determinar el tipo
de comunicación posible con el dispositivo.

7.1.3 Integración de datos y comandos

Con dispositivos existentes, es muy probable que existan limitaciones para la incorporación a una red
Ethernet con la norma IEC-61850. Con el uso de “Gateways” es posible integrar la información de
estos y hacerlas visibles.

7.1.4 Auto-Descripción

La auto-descripción es propiedad de pocos protocolos conocidos en la actualidad. La norma IEC-61850 ha

definido nodos lógicos, nomenclatura, tipos de datos, etc. de tal manera que la descripción de los datos en
un dispositivo (ya sea lógico o físico) sea estándar. Todos los dispositivos en una red IEC-61850 tienen la
capacidad de auto-describirse. El “Gateway” que implemente IEC-61850 deberá exponer los datos en forma
de Nodos Lógicos, como lo define la norma.

54
 IEC-61850
GATEWAY
Dispositivo Logico Dispositivo Logico Dispositivo Logico

LN
LN LN

LN LN
Nodo Logico

OPC Por Ejemplo

Protocolo Tradicional

IED

Contacto

Figura 7.1 – “Gateway” a la red IEC-61850

La Figura 7.1 ilustra la implementación de un dispositivo que podría ser del tipo “Gateway” donde los
Dispositivos Lógicos (LD) y Nodos Lógicos se estructuran basados en la información recolectada del
IED con otro protocolo. Los datos en los Nodos Lógicos serán llenados con la información almacenada
en una pequeña base de datos que refleja la información leída del IED.

Este dispositivo deberá tener la suficiente flexibilidad para formar nodos lógicos con la información de la
base de datos del IED. En implementaciones recientes existe un mecanismo interno para mover los
datos del proceso de lectura (del IED) hacia el proceso que controla los Nodos Lógicos. Este
mecanismo es por ejemplo el protocolo OPC, como se muestra en la Figura.

Con dispositivos que no tienen ninguna capacidad de comunicación (dispositivos electromecánicos, por
ejemplo), es posible incorporarlos como muestra la Figura XXX.6. Monitoreando la posición del contacto
y llevando la información a un nodo lógico, como muestra la figura. Muchos dispositivos electro-
mecánicos, como cambiadores de tap de transformador existentes, pueden ser integrados a una red
IEC-61850 como muestra la figura.

7.1.5 SCADA/Reporte

La figura 7.2 muestra la funcionalidad requerida para presentar la información de reportes a SCADA y/o
HMI. Nótese de nuevo que los nodos lógicos serán llenados y configurados con los datos leídos del IED.
En la configuración del dispositivo se podrán configurar los nodos lógicos y los reportes asociados.

7.1.6 SCADA/Control

La figura .37 también puede ser utilizada para interpretar comandos que vendrían por el puerto IEC-
61850 hacia el dispositivo tradicional. Los comandos de control procedentes del centro de control o de
la consola de operación local son ‘escritos’ en un DO de un nodo lógico. El dispositivo tipo ‘Gateway’
automáticamente trasferirá esta información al registro apropiado del protocolo tradicional.

55
 7.1.7 Comandos rápidos (GOOSE)

A pesar de que existe por lo menos un protocolo serial que comunica de punto a punto señales de
control rápidos (en milisegundos), la funcionalidad de los mensajes GOOSE no existe en protocolos de
subestación tradicionales. En este sentido, no hay una equivalencia entre la Norma IEC-61850 y los
protocolos de subestación tradicionales.

IEC-61850 GOOSE
GATEWAY

Contacto - ENTRADA

Contacto - SALIDA

Contacto

Figura 7.3 – Incorporación de entradas y salidas a mensajes GOOSE

Sin embargo, es posible el incorporar contactos de salida de dispositivos de subestación como muestra
la Figura 7.3 Un contacto de un dispositivo de subestación puede ser la salida de un relé
electromecánico, una posición de interruptor, etc. Incluyen señales que necesitan ser comunicadas
rápidamente (en milisegundos). Estos contactos pueden ser transformados en mensajes GOOSE para
ser incorporados a la red de la subestación. De la misma manera, el dispositivo tipo ‘Gateway’ puede
recibir mensajes GOOSE de la red y convertir ese mensaje en una salida de contacto, como se muestra
en la Figura XXX.8.

La funcionalidad descrita arriba se la implementa en un ‘bloque de salidas/entradas’ que son

dispositivos dedicados a monitorear contactos y a activar salidas.

7.1.8 Muestreo de Valores Analógicos (SMV)

Existen dispositivos que adquieren de los transformadores de medición de corriente y tensión
convencionales, valores analógicos y los transforman en valores digitales. Estos dispositivos que la
norma denomina “Mergin Unit”, ya se encuentran disponibles en el mercado.

7.1.9 Estrategias de migración

Para enfrentar un trabajo de migración, renovación o nueva instalación de cualquier tipo de equipo es
necesario definir la serie de pasos a seguir.

Se considera muy importante que el Grupo de Trabajo en la Empresa, sea integrado por especialistas de
protecciones, control, comunicaciones, estaciones, y sistemas, tratando así de lograr un intercambio de
ideas de un equipo multidisciplinario experimentado que lleve adelante el emprendimiento de Migración.

Las principales ventajas que nos ofrece, la norma IEC 61850, son la posible aplicación de nuevas y
avanzadas funciones de control y protección que engloben a los dispositivos que conforman el sistema y,
por supuesto, una significativa reducción de costos entre ingeniería, construcción, operación y
mantenimiento. Todo esto gracias a un muy necesario estándar que facilite, optimice y explote al máximo
las bondades de la automatización de subestaciones.

Eventualmente es necesario pensar la implementación de un SAS (Substation Automation System) que

cumpla con IEC 61850 en distintas etapas. Una primera etapa puede ser solamente incorporando a la
información de control para el SCADA, y una segunda incorporando las funciones de protecciones.

56
 Pensemos en las funciones actuales de la subestación y cuáles de ellas se pueden mejorar, por ejemplo:
1. Funciones de Medida que involucran:
a. Medida de parámetros del sistema
b. Indicación de parámetros del sistema
c. Registro de perturbaciones y oscilografía
2. Funciones de Administración y Control
a. Administración y seguridad de acceso de usuarios
b. Despliegue de información y datos
c. Monitoreo del sistema y sus equipos
3. Funciones de Protección y Control
a. Nuevos esquemas de protección
b. Enclavamientos simplificados
c. Verificación de Sincronismo
d. Sincronización horaria

7.1.10 Subestaciones nuevas

Cuando se trate de subestaciones nuevas, la implementación del IEC 61850 será más sencillo. Se trata
de elegir los equipos necesarios y de preferencia del usuario, que ahora deberá preocuparse de la buena
comunicación e interoperabilidad entre los mismos. Sin embargo debemos tener claro que se trata de un
cambio radical en la arquitectura de nuestras subestaciones, un cambio radical que nos ofrecerá
flexibilidad y estabilidad a largo plazo. Para este tipo de subestaciones una solución integral será lo más
adecuado.

7.1.11 Subestaciones existentes

Si todavía no se cuenta con ningún tipo de automatización, las soluciones integrales como en las
subestaciones nuevas puede ser lo más apropiado. A pesar de que el presupuesto podría limitar este
tipo de implementación, no será necesario declinar la migración a IEC 61850 porque puede llevarse a
cabo por partes o etapas. La parte más importante y la base de la automatización con IEC 61850 es por
supuesto el conjunto de IEDs con los que cuenta la subestación, su capacidad para comunicarse y si
están preparados para el estándar; si no lo están, se tendrá que consensuar con cada fabricante la
manera de hacerles una actualización o para su cambio definitivo efectuar un estudio de costo-beneficio
tomando en cuenta fechas de instalación, tiempo de vida útil, depreciaciones, y otros factores técnico-
económicos. Otra solución sería agrupar los equipos de un mismo fabricante bajo un concentrador que
garantice la buena comunicación entre ese grupo y conectar este último a un Gateway integrador IEC
61850, que a su vez nos garantice la buena comunicación con el resto de los dispositivos en la
subestación. Esta etapa la complementará el control remoto y local a través de un “gateway” que enlace
la subestación con el centro de control y un HMI (Human Machine Interface) y/o computador local que
nos permitan realizar el monitoreo y operación correspondiente del sistema.

La siguiente etapa será hacia el patio o playa, donde todavía el desarrollo tecnológico al presente no
ofrece productos o dispositivos completamente maduros.

7.1.12 Ejemplo

Para ilustrar mejor las etapas propuestas para la integración de una subestación existente con la norma
IEC-61850 será dado un ejemplo de una subestación genérica como la de la figura 7.4.

Suponga que la protección de los transformadores (50 ó PIOC, 51 ó PTOC y 87 ó xxxx) están
implementadas en relés digitales que utilizan un protocolo de comunicación diferente del IEC-61850,
que la protección 87B ó xxxx de la barra de alta tensión está implementada en un relé estático sin
ninguna capacidad de comunicación digital y que las protecciones de las líneas (21 ó PDIS y 67N) están
implementadas en relés electromecánicos sin comunicación digital. Suponga también que los estados

57
de los interruptores y de los seccionadores de los circuitos de alta y baja tensión de los transformadores
son supervisados por los relés digitales de sobrecorriente de los transformadores y los otros
interruptores, seccionadores y los contactos de los relés electromecánicos y estáticos son supervisados
por remotas que pueden comunicar por medio de un protocolo diferente del IEC-61850.

Figura 7.4 – Diagrama unifilar de la subestación genérica utilizada en el ejemplo

Así, en la primera etapa los equipos que desease integrar deben ser clasificados de acuerdo con la
tabla que se sigue:

Equipos sin comunicación digital Equipos con protocolos deferentes del IEC-
61850
 Relés de protección electromecánico  Relés de protección digitales de los
de las líneas de transmisión transformadores
 Relés de protección estático de la barra  Remotas

Después de definido los equipos que desease integrar las posibles topologías deben ser verificadas,

conforme la tabla que se sigue:

Topología Descripción

1  Todos los equipos serian cambiados por nuevos equipos que se comunican
por la norma IEC-61850

58
 2  Todos los relés electromecánicos y el relé estático seria cambiado por relés
digitales que se comunican por la norma IEC-61850 y que puedan
comandar y supervisar todos los interruptores y seccionadores, eliminando
las remotas
 Los relés de los transformador serian integrados por medio de dos
dispositivos tipo gateways específicos, un por transformador
3  Las remotas y los relés digitales de los transformadores serian integrados
en la red IEC-61850 por medio de un concentrador de datos y un dispositivo
tipo gateway especifico
 La interfase entre los relés electromecánicos y el relé estático con la red
seria realizada por las remotas

Definidas las tres topologías, las siguientes etapas serán las pruebas de interoperabilidad y el análisis
económico para, finalmente, definir la mejor opción desde el punto de vista técnico-económico.

7.1.13 Recomendaciones

Las etapas descritas en el ítem anterior no son fijas. Después del análisis económico, por ejemplo,
puede surgir la necesidad de adoptar otra topología. Así, sería necesario hacer nuevos ensayos de
interoperabilidad para validarla.

Otro punto al cual se debe prestar atención es la especificación de los “switch”. Ellos son cruciales para
el desempeño de la red. Por eso son necesarios los ensayos de interoperabilidad y capacidad de la red
considerando diversos escenarios operativos.

8. Seguridad

El WG 15 del Technical Committee 57-IEC ha elaborado y publicado la serie de IEC 62351 “Data and
Communication Security” que trata el tema seguridad por lo que no se desarrollará en este informe.

59
 Anexo A

Ethernet
El núcleo del nuevo sistema de comunicaciones de la subestación, es una LAN Ethernet. La topología no se
define en la norma, y depende de las características y requerimientos de disponibilidad y confiabilidad que
se adopten en cada caso particular.

En la Figura A.1, se muestra una trama IEEE 802.3

Bytes 7 1 2 ó 6 2 ó 6 2 0-1518 0-46 4

Dirección Dirección Datos Pad Checksum

Preámbulo D.C.
nodo destino nodo origen

Comienzo del Longitud del

delimitador del campo de datos
mensaje

Figura A.1

Donde:

Preámbulo: 7 Bytes de 1 y 0 alternados Sincronización

D.C. (Delimitador de comienzo): 1 Byte todos unos
Dirección física del nodo destino (MAC): 6 bytes
Dirección del nodo origen (MAC): 6 bytes
Longitud de los datos o tipo de mensaje (>05DC): 2 Bytes
Datos: 0 a 1500 Bytes
Padding: 0 a 46 Bytes
Checksum: 4 Bytes

En la Fig. A.2, se muestra una trama Ethernet, según IEEE 802.3 p,q que incluye las funcionalidades de
VALN y prioridades y que utiliza ciertos campos para transmitir informaciones de los mensajes GOOSE.

7B 1B 6B 6B 2B 2B 2B 2B 2B 2B 2B mB xB 4B

P S DA SA TPID TCI Ethertype APPID Longitud R1 R2 APDU P FC

Figura A.2. Trama para mensajes GOOSE

Donde:

P: Preámbulo (igual al original).

S: Limitador de comienzo (igual al original).
DA: Dirección de destino (igual al original).
SA: Dirección de emisor del mensaje (igual al original).
TPID: Tag Protocol Identifier (difiere del original).
TCI: Tag Control Information (difiere del original).
Ethertype: (difiere del original).
APPID: Aplication Identifier (difiere del original).

60
Length: Longitud (difiere del original).
R1 y R2: Reservados para uso futuro, se deben considerar 0x0 (difiere del original).
APDU: Application Protocol Data Unit (difiere del original).
P: Padding (igual al original).
FCS: Frame Check Sequence (igual al original).

La dirección “broadcast” debe ser utilizada como un valor por defecto ó “default” para una dirección de
destino que consistirá de todos “1” en el campo de dirección de destino.

El etiquetado prioritario ó “priority tagging” de acuerdo con IEEE 802.1Q es utilizado para clasificar los
diferentes tipos de tráfico, aplicaciones relevantes de protecciones de aplicaciones de baja prioridad, y
garantizar mediante el sistema de prioridades estrictas el cumplimiento de los tiempos de transmisión
requeridos para cada servicio.

La estructura del encabezado de la etiqueta, se muestra en la Figura A.3.

Octetos 8 7 6 5 4 3 2 1

1
TPID 0x8100
2

3 User priority CFI VID

TCI
4 VID

Figura A.3

TPID (Tag Protocol Identifier): el valor asignado es 0x8100 (1111 0001 0000 0000) que permite identificar
los mensajes Ethernet codificados para redes virtuales.

TCI (Tag Control Information): consta de 3 campos, los primeros 3 bits corresponden a la prioridad de los
mensajes determinada por el usuario. El nivel de prioridad va del 1 al 7 siendo este último el más alto.
User priority: el valor de este campo debe ser asignado por configuración para separar los valores
analógicos muestreados y los mensajes GOOSE de tiempo critico de las protecciones de la carga del bus
de baja prioridad.
CFI (Canonical format identifier): es el indicador de forma canónica, que para este estándar 61850 debe ser
“0”.
VID (VLAN Identifier): es opcional. Si se utiliza este mecanismo el identificador de VLAN (VID) debe ser
asignado por configuración. De otra forma el VID es asignado por default igual a “0”.

Octetos 8 7 6 5 4 3 2 1

1 1 1 1 1 0 0 0 1
TPID
|
2 0 0 0 0 0 0 0 0

3 User priority 0 0 0 0 0
TCI
4 VID

61
Ethertype

Un Ethertype basado en ISO/IEC 8802-3 MAC – Sublayer ha sido registrado por la “IEEE Authority
Registration”. El valor Ethertype registrado es “88-BA” (Hexadecimal) ó 0x88BA.
El “buffer” actualizado del valor analógico muestreado es mapeado directamente a la Ethertype reservada y
la Ethertype PDU.

La estructura de la Ethertype PDU, se muestra en la Figura x

Octetos 8 7 6 5 4 3 2 1

1
0
1
1
…

Length: no solo indica la longitud de los datos sino que agrega ocho octetos contando desde el identificador
de aplicación APPID. El octeto y medio restante es utilizado para el identificador de red virtual, debe se
configurado en la inicialización del sistema. Para el caso de no utilizar redes virtuales, debe configurarse
como nulo.
Ethertype: utiliza dos octetos para definir el valor reservado para cada uno de los servicios GOOSE,
Valores Muestreados, etc.
APPID: Es el identificador de aplicación de dos octetos que permiten seleccionar tramas ISO/IEC 8802.3
que contengan mensajes GOOSE y GSSE.
Length: no solo indica la longitud de los datos sino que agrega ocho octetos contando desde el identificador
de aplicación APPID
APDU: Es el campo de datos denominado (Aplication Protocol Data Unit), tiene una longitud igual o menor a
1492 octetos.

62
Los distintos tipos de mensajes que son definidos en la norma en función de su funcionalidad y velocidad
de transmisión requerida, se pueden visualizar en un Modelo de Referencia, como se muestra en Fig. A.3.
Los mensajes más críticos, como los mensajes GOOSE, y SV, son directamente entregados a la red, sin
pasar por niveles ó protocolos intermediarios.

Sampled GOOSE Time MMS Protocol Suite GSSE

Values Sync 63
(Multicast) (SNTP)
(Type 2, 3 y 5) (Type 1, 1A)
(Type 1, 1A) (Type 6)
(Type 4)

UDP/IP TCP/IP ISO CO GSSE

 Anexo B. Ejemplos de implementación – Proyectos Piloto.

ANEXO B.1 – Experiencia SC B5 Argentina – Universidad de Buenos Aires (UBA)

El proyecto piloto IEC 61850 de laboratorio realizado por el SC B5 Argentina, fue desarrollado con cuatro
IEDs de distintos proveedores. El objeto del trabajo fue el de generar conocimiento práctico acerca de la
implementación del estándar IEC 61850, en particular su aplicación a esquemas de protección utilizando
mensajes GOOSE (IEC 61850-8-1).

El grupo de estudio creyó conveniente efectuar la aplicación de la Norma IEC 61850, en paralelo con las
técnicas conocidas y vigentes hasta el momento (cableado y lógicas con relés auxiliares), con el fin de
poder efectuar comparaciones.

Se obtuvo un procedimiento de configuración para la estación piloto que permitió analizar de formar práctica
la interoperabilidad a nivel de software y de IEDs. Se analizaron las diferencias que existen entre los
distintos proveedores en cuanto a la interpretación de la norma, contratiempos existentes con las
herramientas actualmente disponibles para el desarrollo de las aplicaciones, la necesidad de herramientas
de terceros para lograr la configuración final, alternativas para la documentación y finalmente se
comenzaron las primeras series de ensayos.

El proyecto piloto tuvo como objetivo principal la generación de conocimiento práctico en la implementación
de la norma, tanto para usuarios como para proveedores y para ello se escogió implementar un sistema de
protección de falla interruptor (PFI), realizando las lógicas de interdisparo a través de las facilidades dadas
por la IEC 61850. El hecho de disponer de IEDs de cuatro fabricantes distintos permitió, además, poner
énfasis en el concepto de INTEROPERABILIDAD.

La orientación del trabajo estuvo enfocada hacia una implementación práctica efectiva, con activa
participación de los fabricantes de los productos.

Otros puntos importantes que se consideraron fueron la determinación de conocimientos mínimos

necesarios para configurar y operar sistemas que se implementen bajo la norma y la delimitación de las

64
nuevas áreas de incumbencia de los especialistas de protecciones, comunicaciones y control o nuevos
grupos multidisciplinarios.

Para la realización del trabajo se tomaron en cuenta los siguientes lineamientos generales:

• Ejecución desde el punto de vista práctico, recurriendo a la norma sólo cuando fue necesario para
determinar el grado de conocimiento adecuado.

• Orientación hacia el punto de vista del especialista de protecciones.

• Simplicidad, ya que los objetivos son el aprendizaje y el análisis de la interoperabilidad. Por lo tanto en un
primer momento no se busco lograr la aplicación más eficiente sino una que cumpla con lo que se pide. En
las próximas etapas se evaluarán mejoras en la aplicación.

Se muestra en la Figura 1 el esquema eléctrico de la subestación simulada en laboratorio. Tanto el unifilar

como los nombres de los equipos de playa y el esquema de interdisparo se han tomado de la E.T. “Pico
Truncado” de 132kV. La misma está compuesta por cuatro campos, dos entradas de línea, acoplador y
acometida de transformador. La topología es de doble barra con transferencia como se puede apreciar en la
figura.

Figura 1 – Esquema unifilar simplificado de la E.T. Piloto

El unifilar fue reducido sólo a los equipos necesarios para desarrollar la aplicación, una vez definido se
fabricó un tablero mímico para la simulación de los equipos de maniobra de la ET. Se utilizaron llaves SI-NO
para simular a los seccionadores y relés biestables con indicación luminosa por leds para simular a los
interruptores.

En cada IED se cablearon las señales de posición de los equipos de su propio campo, a su vez cada IED
también emite la señal de disparo al interruptor que tiene asociado. Se agregó, además, una llave en serie
con el circuito de disparo para interrumpirlo con el objeto de forzar la falla del interruptor. Sólo en el caso del
campo del acoplador la imagen de los seccionadores no se ha considerado ya que no interviene en el
esquema de interdisparo. Todas las señales y comandos entre los IEDs y el mímico fueron cableadas en la
forma tradicional, en corriente continua.

Los IEDs participantes son terminales multifunción orientados a la protección de líneas y alimentadores. En
particular todos incluyen las funciones de sobrecorriente instantánea no direccional (ANSI 50), protección de
falla de interruptor (ANSI 50BF) y la capacidad de programación lógica necesaria. Los IEDs utilizados en el
proyecto fueron:

• 7SJ62 - Siemens
• F60 – GE

65
• P543 – Areva
• REL670 – ABB

Todos los IEDs están certificados para IEC 61850-8-1 y disponen de uno o dos puertos ethernet en cobre o
fibra según la configuración de hardware.

Dado que no todos los equipos participantes disponen de doble puerto ethernet se definió que la topología
de
red sea radial para garantizar la igualdad de condiciones entre todos los IEDs. En consecuencia el esquema
de la red carece de redundancia,

El switch utilizado es modular y del tipo gerenciado o administrable. Dispone de 8 puertos en cobre y 8 en
fibra a 10/100 Mbs y un puerto Gigabit en cobre, este dispositivo cumple con los requisitos de IEC 61850.
Uno de los IEDs se vinculó por FO mientras que el resto de los dispositivos se conectaron mediante puertos
en cobre. A la red se agregaron dos PCs para supervisión y configuración. Todos los enlaces Ethernet
trabajan a la velocidad de 100 Mbs en modo Full-Duplex.

B.1.1 Herramientas de software de terceros

Se evaluaron programas de edición y visualización de archivos SCL en versión demo, en principio como
alternativa o complemento de los primeros y aplicaciones cliente del protocolo mediante las cuales se puede
navegar dentro del servidor de cada IED. Fuera de las aplicaciones específicas para IEC 61850 se
utilizaron:

• Software de edición de archivos XML.

• Editores de texto.
• Analizador de protocolo Ethereal.

La evaluación de estas herramientas se convirtió luego en una necesidad, en este sentido Ethereal fue una
herramienta indispensable para lograr la configuración de las comunicaciones, la detección de errores de
configuración y para la comprensión y evaluación del funcionamiento del sistema.

B.1.2 Planteo del esquema de interdisparo convencional (cableado y lógicas con relés auxiliares).

En un esquema convencional de interdisparo por PFI en T2, para una estación como la de la figura A.1,
existen
normalmente dos circuitos de disparo: “disparo Barra A” y disparo Barra B”. Los equipos de PFI, asociados a
cada interruptor, cuando emiten un disparo en T2 ponen una tensión positiva en el circuito correspondiente
a la barra a la que está conectado dicho interruptor. De esta manera se interdispara a través de este circuito
a todos los interruptores que estén conectados a la misma barra. La conducción de esta tensión hacia los
circuitos de disparo correspondientes se hace a través de circuitos de cobre distribuidos por la estación, que
se basan principalmente en contactos auxiliares de los interruptores y seccionadores. En el caso del
acoplador, como normalmente está conectado a ambas barras deberá abrir ante el disparo por cualquiera
de los dos circuitos.

En cada IED, utilizando compuertas lógicas, se emuló el esquema basado en contactos auxiliares descrito
en
el punto anterior. Esta lógica genera las señales “disparo barra A”, “disparo barra B” y “disparo acoplador”
que luego son enviadas por GOOSE. Al mismo tiempo cada IED recibe las mismas señales de disparo
generadas en los demás IEDs en función de las cuales enviará o no el disparo a su interruptor. Antes de
decidir esta forma de trabajo se plantearon varias alternativas, pero finalmente se decidió emular la
aplicación real porque se considera que es la más natural. Por lo tanto, para el esquema de interdisparo las
señales que debe enviar y recibir cada IED son:

• Disparo de barra A.
• Disparo de barra B.
• Disparo de acoplador (caso de campo transferido, todos la enviarán excepto el acoplador).
• Señal de prueba.

Se decidió incorporar la señal de prueba como herramienta de ayuda en el procedimiento de configuración

para detectar rápidamente si las comunicaciones entre los distintos IEDs estaban funcionando o no. La

66
señal se emite con una tecla de función en cada HMI y la recepción se acusa en el resto de los IEDs
mediante un led.

Con las señales definidas el siguiente paso fue determinar si los datos se debían enviar en uno o más
mensajes GOOSE. La idea de enviar un mensaje por dato quedó descartada dado que uno de los IEDs es
capaz de enviar solo un mensaje GOOSE con un máximo de 32 datos, por lo tanto, siguiendo los criterios
planteados, cada IED enviará un mensaje GOOSE con los cuatro datos

B.1.3 Determinación del tipo de datos y nodos lógicos

Las señales que se envían y reciben por GOOSE deben ser necesariamente “Data Objects” (DO) los cuales
residen en los diversos nodos lógicos (LNs). Los datos enviados en cada mensaje GOOSE se deben
agrupar previamente en un “DataSet” (DS) compuesto de al menos un DO. Por ejemplo en nuestra
aplicación se utilizaron funciones de sobrecorriente instantánea y protección de falla de interruptor cuyos
nodos lógicos asociados son PIOC y RBRF respectivamente. Dentro de los mismos se encuentran, entre
otros, el DO “operate”. Entonces para indicar la actuación de la función 50BF se podría enviar el dato
RBRF.Op (el punto es un separador, LN.DO) dentro del DS del GOOSE.

En el proyecto las condiciones de borde a las que nos debimos ajustar son dos y vienen dadas por:

• IEDs: Algunos IEDs participantes sólo pueden publicar y suscribir datos desde los nodos lógicos de
entradas y salidas generales denominados GGIO (Generic General Input Output).

• Aplicación de interdisparo. La norma no define un nodo lógico de interdisparo o disparo de barras. Se

podría enviar la señal de ejemplo indicada anteriormente (RBRF.Op) pero no llevaría información sobre que
barra se debe despejar por lo que se tendría que enviar, además, la información de posición de los equipos
del campo. En este caso no todos los IEDs disponen de esa cantidad de nodos lógicos de seccionadores
XSWI por lo que se deberían enviar sus posiciones como señales genéricas GGIO.

Para el proyecto se definió que las cuatro señales a enviar tendrían las funciones presentadas en el punto
B.1.2 y por lo tanto se enviarán desde el nodo lógico GGIO definido por la norma para señales generales. El
receptor deberá “comprender” el significado de cada uno de los datos ya que en si mismos no incluyen
información semántica, o expresado según el concepto de la norma, la información no es autodescriptiva.

Para proyectos reales esto implicaría trabajar del mismo modo que con protocolos seriales, como DNP,
donde emisor y receptor deben contar con el mismo mapa de señales para intercambiar información. La
elección adoptada es desde ya acorde con IEC 61850 y también lo es desde el punto de vista práctico pues
se
trata de pocas señales para configurar.

B.1.3 Manejo de archivos

Partiendo del procedimiento propuesto por la norma se fueron encontrando diversos problemas en la
importación de archivos. Las herramientas de distintos propietarios reportan algunas veces errores que
según el caso pueden llegar a abortar la incorporación de un determinado archivo. Además, cabe destacar
que un mismo archivo importado en distintos programas puede tener distintos resultados, producto de los
diferentes controles que hacen las herramientas en la importación. Para determinar en que casos los
errores eran correctamente indicados se debieron analizar los archivos mediante editores de texto o
visualizadores de archivos XML.

El primer desafío fue, entonces, llegar a integrar en un solo archivo a los cuatro IEDs sin reportes de error o
que al menos dichos errores no sean graves. Esto se logró mediante una herramienta de terceros donde se
integraron tres archivos ICD y luego importando este resultado en el software del IED restante. Hasta ese
momento sólo se había conseguido integrar los archivos en un solo proyecto sin configurar nada en cuanto
a
IEC 61850. Los editores de texto y XML comienzan a ser necesarios en algunos casos para lograr la
interoperabilidad entre software de distintos fabricantes.

B.1.4 Esquema de configuración

Previamente a la configuración de la comunicación por GOOSE se ajustó en cada IED la lógica del
esquema

67
de interdisparo y se habilitaron las funciones de protección con sus respectivos ajustes. Durante el proyecto
estos ajustes permanecerán constantes y en adelante sólo se irán modificando los parámetros que hacen a
las
comunicaciones en IEC 61850-8-1.

Para la configuración de las comunicaciones por GOOSE se partió del esquema teórico que brevemente
consiste en:

1- Generación de un archivo .ICD por cada IED en cada soft propietario.

2- Integración de los mismos en una herramienta de configuración de estación.
3- Creación de mensajes GOOSE y suscripción de los mismos.
4- Exportación del archivo de configuración de estación .SCD y opcionalmente un archivo .CID por
cada IED.
5- Importación de los archivos, .SCD o .CID, a las herramientas propietarias para incorporar esta
información de IEC 61850 a cada IED y luego bajarla al equipo.

Dos de los IEDs participantes tienen herramientas “integradoras” o “de estación” por lo tanto un primer
aspecto a determinar es en cual de ellas se desarrollará el paso 3. De los dos restantes uno permite
exportar el archivo ICD mientras que el otro provee una plantilla que en principio no es editable.

B.1.5 Configuración de IEDs y GOOSE

El paso siguiente fue configurar los IEDs (IEDName, IP, subnet, gateway), luego los mensajes GOOSE y
después suscribirlos en el resto de los IEDs. En las dos herramientas integradoras no fue posible editar los
IEDName definidos para el proyecto, pero si las direcciones IP y máscara. Durante la definición de los
mensajes se encontró que el IED que sólo envía un mensaje tiene todos sus parámetros de comunicación
predefinidos y mientras que en una herramienta se pueden editar en la otra no son visibles algunos de ellos.

Luego de configurar el resto de los mensajes GOOSE sólo se permitió la exportación en formato SCD (en
ambos software) para llevar la configuración a las herramientas propietarias.

Se puede generalizar y decir que en la mayoría de los casos la información de recepción realizada en
herramientas de otro proveedor no ha sido exitosa al intentar importarla en el software propietario. Por lo
tanto se buscaron alternativas para lograr un procedimiento exitoso. Como el GOOSE predefinido fue bien
interpretado por los demás software y dado que se debió comenzar la configuración desde cero en
reiteradas oportunidades, se planteó que los datos propios del IED y los parámetros de este GOOSE se
podrían configurar previamente en los ICD para que el proyecto sea coherente con los parámetros
establecidos inicialmente. En el caso del IED que provee un archivo ICD estándar fue necesario modificarlo
mediante un editor de texto o XML. En el otro caso se creó el GOOSE a enviar, se modificaron los valores
necesarios y se exportó un nuevo archivo ICD.

Reunidos nuevamente los IEDs en una de las herramientas integradoras se observó que, en general, los
parámetros predefinidos fueron respetados, en particular los referentes a los mensajes GOOSE. Las
diferencias se plantearon en cuanto a donde definir los mensajes de los IEDs que disponen de herramienta
de
configuración de estación. Se encontró que estos programas están muy bien preparados para realizar
configuraciones con IEDs propios pero el intercambio de información con IEDs de terceros no está al mismo
nivel. Para determinar cual de los softwares no está realizando correctamente sus tareas se deben emplear
editores de XML, buscar las secciones específicas y luego analizarlas. Este trabajo se multiplica por cada
relación entre los cuatro IEDs por lo que sólo es aceptable para un proyecto de investigación, no para uno
real.

Una vez obtenido un flujo de trabajo con los archivos SCL se determinó un punto que es común
denominador por lo menos hasta la fecha. La configuración de suscripción (o recepción) se debe realizar en
cada herramienta propietaria, con los inconvenientes que esto genera (no se corresponde con la norma,
aumenta la probabilidad de error, duplica el trabajo, resta capacidad de documentación, entre otros). Una
vez asumido se han configurado “localmente” las suscripciones a los mensajes GOOSE del proyecto y las
configuraciones fueron bajadas a los dispositivos físicos.

Luego de configurar el switch y repasar algunos detalles la comunicación por GOOSE fue establecida y la
aplicación de interdisparo comenzó a operar mostrándose estable (aún ante pérdidas de comunicaciones

68
forzadas y durante el arranque de los IEDs), sin disparos intempestivos y actuando correcta y
selectivamente
para todas las condiciones de falla y topologías de la estación planteadas.

No obstante encontramos algunos aspectos que nos muestran que las interpretaciones de la norma por
parte
de los distintos fabricantes no son exactamente iguales. Estos aspectos son:

• Limitaciones en la configuración: Las limitaciones en cuanto a parámetros de configuración de los

IEDs nos obligo a cambiar continuamente los valores de base del proyecto hasta lograr un conjunto
que satisfaga a todos.

• Limitaciones en la interoperabilidad entre softwares: Faltan ciertos parámetros de configuración

de los mensajes GOOSE tanto para el envío como para la recepción en algunos casos. Por otro lado
los parámetros que no se muestran son predefinidos por el software correspondiente.

• Necesidad de herramientas adicionales: producto del ítem anterior e inconvenientes en el manejo

de archivos entre herramientas propietarias.

• Problemas de inseguridad en la configuración: En el caso de tener establecida una comunicación

exitosa hemos encontrado casos en que al cambiar un parámetro en el emisor del GOOSE, aún así el
receptor lo sigue recibiendo y validando sus datos como correctos. Si bien la configuración no se debe
manipular a nivel del IED (se debe hacer en el .SCD) esto puede derivar en un problema de seguridad al no
detectar ciertos cambios. Implica además que no todos los parámetros son verificados en los mensajes
entrantes en algunos IEDs (en la recepción).

• Incompatibilidad entre las distintas herramientas: Archivos de formato SCL (ICD, SCD, CID, etc.)
verificados mediante distintas herramientas dan reportes diferentes en cuanto a la validación.

• Inconvenientes en la edición de parámetros: Algunas herramientas no restringen el ingreso de

parámetros fuera de la norma y permiten seguir adelante con la configuración. El problema se presentará en
el futuro al importar este dato en otro programa o bajarlo a un IED donde dará error o no funcionará
satisfactoriamente la aplicación. Esto demuestra una vez más que por el momento es necesario conocer la
norma e investigar puntualmente si las herramientas están haciendo lo correcto.

• Monomarca / Multimarca: aún en proyectos monomarca, al momento de realizar ampliaciones o

modificaciones con IEDs de otro proveedor se podrían encontrar limitaciones debido a la interpretación no-
homogénea de la norma.

ANEXO B.2 – Proyecto Piloto IEC 61850 en E.T. MERCEDES 132/33/13,2 kV, experiencia en Transba
S.A. – Transener S-A.

El objetivo del Proyecto Piloto IEC 61850, fue instalar en una E.T. 132/33/13,2 kV, IEDs de distintos
proveedores para lograr un mayor conocimiento de la nueva norma así como lograr una mayor capacitación
de los especialistas de control, comunicaciones y protecciones, y adquirir una mayor experiencia con esta
nueva tecnología de automatización de estaciones ó SAS (Substation Automation System), para poder
aplicarla en un adecuado grado a las nuevas estaciones tanto en el nivel de tensión 132 kV, como en nivel
500 kV.

La decisión de realizar el Proyecto Piloto en una E.T. en operación, se debió por una parte a la convicción
de los participantes que existían suficientes antecedentes de pruebas de laboratorio a nivel mundial y
latinoamericano. Por otra parte y tal vez la más importante es que se pretendía conocer y experimentar no
solamente con los nuevos IEDs sino que se pretendía obtener experiencia de campo con la instalación en
una E.T., con todos los desafíos que esto implica en cuanto a disposición de los IEDs y switches, instalación
en los tableros, cableado, etc.

En base a las premisas y objetivos planteados, y teniendo en cuenta que uno de los Laboratorios Elèctricos
de Transba S.A., está ubicado en el predio de la E.T. MERCEDES, se seleccionó esta estación como punto
de partida de la Experiencia ó Proyecto Piloto.

69
La E.T. MERCEDES 132/33/13,2 kV es una estación telecomandada, con una arquitectura concentrada, y
como tal posee una RTU que adquiere la información de campo, y la transmite al Centro de Control
Regional de la Empresa, y recibe desde el Centro de Control, los comandos para la operación de los
aparatos de maniobra, es decir posee una arquitectura de automatización clásica.

El Proyecto Piloto fue planificado en cuatro etapas que comprenden básicamente los siguientes objetivos:

 Instalación de la red Ethernet e IEDs de un único proveedor, con intercambio de mensajes GOOSE
entre IEDs.
 Instalación de IEDs de distintos proveedores con intercambio de mensajes GOOSE entre IEDs del
mismo proveedor.
 Intercambio de mensajes GOOSE entre IEDs de distintos proveedores
 Evaluación de funciones de protección y control.
 Evaluación de funciones de protección críticas
 Informe Final, y Recomendaciones a la Gerencia de Ingeniería de Transener S.A.-Transba S.A., sobre
el grado de implementación aconsejable, y programación tentativa de etapas.

B.2.1 Primera etapa

Como etapa inicial, se instaló una Red de Area Local (LAN) Ethernet de 100 Mbps, con IEDs de un solo
fabricante, con topología en estrella y anillo, utilizando como medio físico cables de Cu, y F.O., como puede
verse en la Figura 2. Asimismo se instaló una Unidad de Bahía, y una Unidad de Estación, como también
una Consola de Control Local. La consola de Control Local se vinculó a través de un enlace serie RS-232 a
la RTU existente en la estación para poder comparar y verificar la consistencia de la información adquirida y
transmitida por los IEDs.

En esta primera etapa del proyecto, los IEDs no se han instalado en línea con el proceso, sino que operan
fuera de línea, adquiriendo en línea solamente los valores tensión y corriente de los transformadores de
medición respectivos. Se han simulado un interruptor y un seccionador con relés biestables.

La red Ethernet, se ha conectado al switch y router de Intranet, por lo que a través de un web-server es
posible, desde cualquier PC de la empresa acceder a la LAN Ethernet, y visualizar los valores de alarmas, y
mediciones que proporcionan los IEDs instalados. Utilizando el software específicos de configuración ó
regulación de los iEDs, los especialistas de protecciones, a través de una clave ó password, acceden a la
posibilidad de regular los IEDs desde cualquier punto del Sistema Transener S.A./Transba S.A. que posea
los servicios de Intranet.

Previo a la configuración de una función que implicara la transmisión/recepción de mensajes GOOSE entre
IEDs, se realizaron numerosas pruebas configurando distintos tipos de mensajes GOOSE, y ensayando los
IEDs instalados mediante una valija de prueba conectada a la red.

Imáx Unidad de Bahía Distancia I

(Z) E
D
7
S
Fibra Optica
Cable UTPA
2 pares F.O. 5
(Par Trenzado)
2 70
2

SWITCH
RUGGEDCOM
 Figura 1 – Topología primera etapa

B.2.2 Pruebas realizadas

Una de las pruebas realizadas, además de “Reset LED” que es la más trivial, no obstante lo cual se realizó
para lograr alguna familiarización con la generación de mensajes GOOSE, se regularon los IEDs con
funciones de protección para realizar una prueba de recierre, mediante la utilización de mensajes GOOSE
entre un IED con funciones de Impedancia, y un IED con funciones de Sobrecorriente.

El objetivo es que la función de protección de distancia realizara el disparo sobre el interruptor pero que la
responsable de efectuar el recierre fuera la protección de Sobrecorriente.

Para lograr esta funcionalidad mediante el intercambio de mensajes GOOSE, se requirió realizar un
intercambio bidireccional de señales entre los IEDs de Impedancia y de Sobrecorriente, de manera de poder
contemplar las distintas alternativas que se pueden presentar. Se logró la funcionalidad requerida, mediante
tres mensajes GOOSE, como puede verse en la Figura 3.

71
 Figura 2 – Topología red Ethernet

Para lograr esta funcionalidad mediante el intercambio de mensajes GOOSE, se requirió realizar un
intercambio bidireccional de señales entre los IEDs de Impedancia y de Sobrecorriente, de manera de poder
contemplar las distintas alternativas que se pueden presentar. Se logró la funcionalidad requerida, mediante
tres mensajes GOOSE, como puede verse en la Figura 3.

Figura 3 – Mensajes GOOSE

Se crea en el IED con funciones de Impedancia un CFC (Continuous Function Chart) donde cualquier
disparo monofásico genera una señal de salida que tiene como destino el Sistema.

Esta señal “S_Rec” generada anteriormente en el grupo GOOSE, se conecta en el “System Configuartor”
( ) con la señal generada en el IED con funciones de Sobrecorriente, “recierre externo”.

72
La señal “recierre externo” tiene como destino CFC en el cual se conecta con la señal “>79 Start” que es
una señal interna que arranca el ciclo de recierre en el IED con funciones de Sobrecorriente.

Por medio de este mensaje GOOSE se logra que ante una falla monofásica presente en la línea el IED de
Impedancia realice el disparado despejando la misma y arranque el ciclo de recierre en el IED de
Sobrecorriente.

Para los casos en los que durante el tiempo muerto del recierre (ejecutandose en el IED Unidad de Bahía)
se genere una condición por la cual produzca el acople trifásico del disparo (ej. falla evolutiva) se configura
una señal al sistema del IED de Sobrecorriente que contempla lo anteriormente expuesto, la cual tiene
como destino el bloqueo del módulo de recierre en el IED de Sobrecorriente.

B2.3 Segunda etapa

En esta etapa, actualmente en desarrollo, se instalaron IEDs de cuatro distintos fabricantes (ABB, AREVA,
GE y Siemens), implementándose una Protección de Barras “virtual”. La designación de “virtual” es debido a
que la función de protección de barras se realiza con el intercambio de mensajes GOOSE entre los IEDs y
una lógica que reside en la Unidad de Bahía.

ANEXO B.4 – Ing. Ricardo Cartazo, experiencia “Integra” (?) En Madrid, Ricardo
ofreció participar en el capítulo Recomendaciones, a cambio de quitarse de este Anexo
(¿)

ANEXO B.5 – Ing. Fernando González, y Enrique Dufour, experiencia UBA

(Universidad de Buenos Aires)

ANEXO B.6 – Ing. Juan Carlos Sanchez, experiencias REE-IBERDROLA

73
 ANEXO B.7 – Ing. Cuitlahuac Picasso, Joaquin Garcia, experiencias caso Mexico

ANEXO B.7 – Experiencias de Implantación de Subestaciones Eléctricas 61850 en México

B.7.1 Experiencias prácticas en CFE para la automatización en nuevas subestaciones con base en IEC
61850.

En este anexo se presentan experiencias en proyectos desarrollados por y para Comisión Federal de
Electricidad (CFE) en México con base en IEC 61850, se comentan casos prácticos y lecciones aprendidas
durante la ejecución de dichos proyectos.

Justificación técnica - económica.

CFE considera importante la automatización de subestaciones de acuerdo con soluciones en las que se
aplican con robustez las tendencias tecnológicas como el caso para IEC 61850. Para ello se han realizado
proyectos piloto en IEC 61850, donde primeramente como lección aprendida es necesario considerar
establecer los requerimientos técnicos, en un enfoque hacia la seguridad de la operación, la disponibilidad
del servicio así como la reducción de tiempos de interrupción de usuarios.
 Principalmente la reducción de costos trabajos asociados en el reemplazo de cobre por fibras ópticas
para la señalización de alarmas y modos de control.
 Reducción de costos en trincheras y cableados para nuevas subestaciones. El número de cableado de
señales es limitado en las conexiones hacia los transformadores de potencial y de corriente y de
algunas señales de disparo.
 Disminución en costos de mantenimiento considerando que hay un número menor de equipos IED’s de
protección, control, medición y monitoreo.

Microsoft Office Outlook.lnk

 Reducción de relevadores auxiliares transfiriendo estas funciones a los
IED’s considerados de acuerdo con los establecidos en los requerimientos y especificación.
 Eliminación de paneles con botoneras, selectores y relevadores electromecánicos como por ejemplo el
86.

Retos del proyecto:

Derivado de la necesidad de especialistas interdisciplinaria implícito en el estándar IEC 61850, es un reto
conformar los grupos de trabajo de diferentes especialidades como protección, control, ingenieros de
automatización, esto para lograr la mejor arquitectura particular de automatización demanda en cada caso.
En cada especialidad es importante conocer los alcances y responsabilidades y metas para llevar a cabo la
interacción de la información requerida en cada especialidad, algunos de los problemas presentados son:
Identificar huecos de información que permitan mejorar los desarrollos y su implantación, por ejemplo la
inclusión de redes de área local virtual (VLAN), su configuración, su administración, el manejo de
información en los switches de la red Ethernet, conocimiento de nuevas herramientas de prueba,
configuración de los IED’s, claridad en los archivos de descripción .CID así como .SCD

Una clave de éxito en proyectos IEC 61850, es la elaboración de la documentación adecuada; así como
tener la información para el ajuste de la programación software en cada dispositivo, contar con los
diagramas lógicos, conocer como se manejan los mensajes GOOSE. Estos detalle son importante ya que
sin la documentación mínima requerida es casi imposible realizar mejoras en el rendimiento ejecutivo de las
funciones del sistema, considerando casos de falla o de una operación no propia.

En el siguiente caso se muestra la tabla de documentos de los mensajes GOOSE transmitidos. Cuando se
desarrolla la documentación de ingeniería, es importante contar con una lista maestra del direccionamiento
IP de direcciones IP para cada dispositivo IED que se integra al sistema incluyendo relevadores, medidores,
concentradores de comunicación de datos switches Ethernet entre otros.

74
 MULTICAST
APP VLAN VLAN
DEVICE DATASET MAC SIGNAL DESCRIPTION
ID ID PRIORITY
ADRESS

ESTADO 52a FASE A INTERRUPTOR A3Q00
ESTADO 52b FASE A INTERRUPTOR A3Q00
ESTADO 52a FASE B INTERRUPTOR A3Q00
ESTADO 52b FASE B INTERRUPTOR A3Q00
01-0C-CD-
TSA3Q00MES1 GOOSE016 1 0 1
01-00-12 ESTADO 52a FASE C INTERRUPTOR A3Q00
ESTADO 52b FASE C INTERRUPTOR A3Q00
PERDIDA SF6 INT A3Q00
RESORTE DE CIERRE DESCARGADO INT
A3Q00
BLOQUEO DE RECIERRE INT A3Q00
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind01.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind02.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind03.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind04.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind05.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind06.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind07.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind08.stVal
bit 0
TSPA3Q00MES1.GOOSE016.ANN.IN2GGIO9.Ind09.stVal
bit 0

Uno de los retos a resolver, fue no contar con herramientas para generar la documentación requerida. Para
este caso, se utilizó el OpenSCLConfigurator que contribuyó a mitigar la falta de tales herramientas propias,
pero no cubre todos los aspectos de IEC 61850 documentación. La mayoría de los vendedores
proporcionan herramientas flexibles para el establecimiento de su propio equipo, pero muchas de estas
herramientas no ayudan, cuando se aplica a un sistema de múltiples proveedores, por lo que la creación de
en su conjunto archivo SCD de una subestación fue un reto y exigente actividad. En algunos casos, esto
requiere cambios XML (Extensible Markup Language), archivos de configuración con editores de texto XML.

Figura: Archivo de configuración SCD y control de operación a través de cliente MMS

Lecciones aprendidas.
La Comisión Federal de Electricidad CFE adquirió lecciones prácticas que ayudaron a desarrollar mejores
especificaciones técnicas así como la definición de arquitectura de configuración de redes durante los
primeros proyectos, una de las primeras propuestas fue mejorar la eficiencia en la LAN Ethernet. La
propuesta de creación conexiones LAN distinta e independiente de acuerdo con los diferentes niveles de
voltaje en las subestaciones. Sin embargo, la interconexión de diferentes anillos ethernet genera aumento
en los tiempos de respuesta para reconfiguración durante una falla y pone en riesgo la seguridad
funcionamiento y disponibilidad del sistema eléctrico.

Una consideración importante representa la conexión en anillo ethernet redundante única, la cual influye en
el tiempo de reconfiguración de un sistema de falla la cual disminuye de manera significativa. La
reconfiguración de tiempo varía dependiendo principalmente sobre el número de switches ethernet que
integran la red LAN anillo. Para esta configuración se utilizó la fibra óptica 1000BASE-SX.

Desde esta experiencias la CFE aprendido a mejorar el sistema el rendimiento de ejecución de mensajes
así como la administración del sistema el cual ahora se especifica con un switch ethernet por panel En la
especificación ahora se indica el uso del cobre para conexiones dentro del panel y conexiones a los IED
adyacentes dentro del panel.

75
Conclusiones:
De la experiencia adquirida en los proyectos desarrollaos las mejoras quedan establecidas en las
especificaciones del sistema automatización. Estas especificaciones tienen los requisitos para los nuevos
proyectos incluyendo la definición de una forma de probar el sistema antes de la entrega y puesta en el
lugar. Los primeros proyectos fueron de mayor costo que una solución tradicional, principalmente debido a
la funcionalidad de la red, sin embargo, proporcionan una mayor flexibilidad para administrar el sistema,
junto con los que requieren menos mantenimiento y proporcionar un mejor control y rendimiento del
sistema.

Asimismo se toma en cuenta en se permite una manera más sencilla de ampliar los sistemas en el futuro.
Ellos aumentan la confiabilidad al tener cerca al IED conectado al proceso eléctrico a través de fibra óptica,
lo que reduce la puesta en marcha tareas y trabajos relacionados con la construcción. Importantes ahorros
se consiguieron en los proyectos posteriores de la reutilización de diseño de ingeniería y la clonación del
sistema.

La idea de CFE es compartir su experiencia con otras personas que están considerando proyectos de IEC
61850, sobre la base de sus sistemas. Para que otros puedan aprender de las implementaciones de la CFE,
ya que comienzan su diseño inicial del proyecto y pliego de condiciones.

Referencias.
Los autores principales de estas experiencia e información son los Ingenieros: Néstor Moreno and
Maycol Flores, Comisión Federal de Electricidad Luis Torres, Jorge Juárez, and David González,
Schweitzer Engineering Laboratories

Asi mismo se toman las siguientes referencias.

[1] Comisión Federal de Electricidad, http://www.cfe.gob.mx/lang/en/Pages/thecompany.aspx.
[2] Comisión Federal de Electricidad, “Transmission and Distribution.”
http://www.cfe.gob.mx/lang/en/Pages/thecompany.aspx.
[3] V. Flores, D. Espinosa, J. Alzate, and D. Dolezilek, “Case Study: Design and Implementation of IEC
61850 From Multiple Vendors at CFE La Venta II,” proceedings of the 9th Annual Western Power Delivery
Automation Conference, Spokane, WA, April 2007.
[4] Source Forge, “SCL Manipulation and Configuration Tools.” Available:
http://sourceforge.net/projects/opensclconfig/.
[5] Características Generales Aplicables a Sistemas de Automatización de Subestaciones Basados en la
Norma IEC 61850, Revisión 2, Comisión Federal de Electricidad, Enero 2009.
[6] Sistema de Información y Control Local de Estación (SICLE), Comisión Federal de Electricidad,
Diciembre 2006.

Néstor Moreno García received his BS in Electronics and Communications Engineering from Universidad
Autónoma de Baja California, Facultad de Ingeniería in 2002; an MBA from Universidad Anahuac del Sur in
2005; and an MS in Electrical Engineering from Instituto Politécnico Nacional in 2008. After graduation, he
worked for Comisión Federal de Electricidad as power line communication project leader, analyzing
programmable logic controller (PLC) technologies and developing two pilot projects with different PLC
technologies. In 2004, he was promoted to be responsible for the automation department, coordinating
project Sistema Integral de Información (SIME), elaboration and normalization of procedures and
specifications of automation specialty. In 2005, Mr. Moreno was promoted to be responsible for the
regulation department and currently is responsible for control specialty in transmission process

Rey David González Barrios received his BS in Electronic Systems Engineering from Instituto Tecnólogico
y de Estudios Superiores de Monterrey in 1993. After graduation, he worked for Video y Computación
Nacional as a SCADA software development and commissioning engineer. In 1998, he joined INELAP-PQE
as an integration engineer, responsible for technical support and integration and automation market
development. In 2000, he joined Schweitzer Engineering Laboratories, Inc. as an integration and automation
department manager to manage, engineer, and commission integration projects for electric utilities and
industrial customers. He currently works as head automation engineer and has been project leader for many
innovative systems. He has presented several papers at Reunion de Verano de Potencia (RVP-IEEE) and
Congreso Iberoamericano de Protecciones in México (CIP-UANL).

76
B.7.2 Metodología para establecer el perfil que define una Meta-Especificación que aplica a
Subestaciones de Distribución basada en el estándar IEC-61850.

Este proyecto consistió en la elaboración de un caso de estudio de automatización de subestaciones

eléctricas en la Comisión Federal de Electricidad (CFE) de México, tomando como referencia el estándar
IEC61850. El caso de estudio consistió en definir una meta-especificación para los sistemas de protección,
control, medición y comunicaciones requeridos por las subestaciones de distribución eléctrica. La
metodología establecida en este trabajo toma como base los sistemas legados y el entendimiento del
estándar IEC-61850, estos conceptos cubren funciones de protección, control, medición, diseño de la
arquitectura SAS, diagramas eléctricos unifilares, filosofía de operación, arquitecturas de comunicación, la
lista de señales y datos para su modelado con nodos lógicos, clases de datos comunes (CDC),
transferencia de información, valores de desempeño y disponibilidad, protocolos de comunicación hacia un
nivel superior, condiciones de operación como temperatura, normativa para establecer nombres de campos
y el manejo de los archivos .icd, .ssd, .scd y .cid.

Fig. 1 Metodología adoptada para establecer una meta-especificación

B.7.2.1 Desarrollo de la Meta-Especificación

B.7.2.1.1 Definición de los arreglos topológicos que aplican de la subestación

La definición del arreglo de topología de la subestación es importante para establecer los requerimientos en
la automatización de una subestación. En CFE distribución se utilizan cinco tipos de arreglos, estos arreglos
han sido definidos con base en las características técnicas operativas de la red de distribución de CFE y son
los que cuentan con altos índices en confiabilidad y seguridad para la red eléctrica. Los arreglos topológicos
son, tipo “H”, Barra Principal, Barra Principal y Transferencia, Anillo, y una subestación con cualquiera de los
cuatro arreglos indicados en SF6.

B.7.2.1.2 Nodos lógicos propuestos para los arreglos topológicos mencionados

Los nodos lógicos propuestos de acuerdo al estándar IEC-61850 para los arreglos topológicos típicamente
empelados se definen con base en las funciones de protección que se utilizan, esto es, si se utilizan por
ejemplo dos IEDs de protección para la protección de líneas de transmisión, tanto cortas como largas,
también se utilizan dos IEDs de protección con los nodos lógicos respectivos, para su protección. Con base
en este criterio, la cantidad de IEDs de protección que se utilizan cuando se define un sistema automatizado
con IEC-61850 para una subestación en particular es la misma, lo cual indica que la definición de los nodos

77
lógicos para las funciones de protección es similar con un sistema legado. Con este criterio de referencia,
se establecen los nodos lógicos obligatorios que se requiera para cada una de las bahías que integran una
subestación. Así se muestra un ejemplo de nodos lógicos que se utilizan de acuerdo a las funciones de
protección para cada una de las bahías se indican en las siguientes tablas.

Tabla I. Nodos lógicos para líneas de transmisión

Esquema Dispositivo
o equipo de Nodos lógicos
primario protección
IED1 PLDF
Lineas ≤10 IED2 PDOC/PDEF (RBRF),(RREC),
kM (PTUV), (PTOV),
(línea (RSYN),
corta) (PFRQ),(RFLO)
IED3 MMXU, MMTR, MHAI
IED1 PDIS RBRF, RREC,
Lineas >10
IED2 PDOC/PDEF PTUV, PTOV,
kM
RSYN, PFRQ,
(línea
RFLO
larga)
IED3 MMXU, MMTR, MHAI

Tabla III. Nodos lógicos para alimentadores de

Tabla II. Nodos lógicos para bancos de distribución
transformación Esquema o Dispositivo
Esquema o Dispositivo equipo de Nodos lógicos
equipo de Nodos lógicos primario protección
primario protección IED1 PIOC/PTOC,
IED1 PTOC, RBRF, RREC, PFRQ,
PFRQ PTUV, PDOC,
Transformador Alimentador
IED2 PTDF RFLO
de potencia
IED3 PTOC, PFRQ IED2 MMXU, MMTR,
IED4 MMXU MHAI

Tabla V. Nodos lógicos para protección de

barras

Tabla IV. Nodos lógicos para banco de Esquema o Dispositivo Nodos lógicos
capacitores equipo de
Esquema Dispositivo primario protección
o equipo de Nodos lógicos Barras IED1 PBDF
primario protección
Bco. de IED1 PIOC/PTOC, PTOV,
capacitores RBRF, PHIZ, PTUV
A.T. MMXU
Bco. de IED1 PTOV, MMXU
capacitores
M.T.

78
B.7.2.1.3 Clases de datos comunes (Common Data Class CDC) propuestos para su uso

Las clases de datos comunes (CDC) de acuerdo al estándar IEC-61850 se utilizan para estructurar la
información de una manera lógica, esto es el estatus de información dentro de los nodos lógicos de las
funciones de protección de un DEI. Los CDC indican dentro de su estructura informática los atributos, tipo de
atributos, el estatus, y si el atributo es mandatario u opcional. Es importante indicar que cuando los atributos de
un CDC deben ser para el sistema automatizado obligatorios, estos deben definirse como mandatario en cada
uno de los CDC. Los CDC que se utilizan de acuerdo a los requerimientos de una subestación de distribución,
son: SPS, DPS, INS, ACT, ACD, SEC, BCR, MV, CMV, SAV, WYE, DEL, HMV, HWYE, HDEL, SPC, DPC,
INC, BSC, ISC, APC, SPG, ING, ASG, CURVE, DPL, LPL, CSD.

En forma de ejemplo, la tabla VI, muestra el CDC ACT Class (Protection Activation Information).

Tabla VI. CDC ACT Class (Protection Activation Information)

B.7.2.1.4 Intercambio de información entre los nodos lógicos implementados para la SE

El intercambio de información para el SAS se realiza de acuerdo a los requerimientos para las funciones de
protección, control y medición, que se envían entre los diferentes nodos lógicos involucrados, definidos en la
configuración de una subestación de distribución.
En el siguiente ejemplo se muestran por bahía el nodo lógico fuente y los nodos lógicos de destino, el tipo de
PICOM por ejemplo (Trip command, Start indication, etc.), el tipo/modo de operación por ejemplo (Comando
Espontaneo, Evento Espontaneo, etc.), ID del PICOM (de acuerdo a tablas B.1, B.2, B.3 y B.4 de IEC 61850-5),
Tipo de mensaje (de acuerdo a tablas B.5 y B.6 de IEC 61850-5), y Tipo de comunicación (de acuerdo a tablas
B.5 y B.6 de IEC 61850-5, y tabla 1 de IEC 61850-1). Esta última columna muestra el protocolo MMS o GOOSE
que se debe implementar en cada intercambio de información entre nodos lógicos. La implementación de
servicios de Control, Protección, Automatismos, Reporting y Transferencia de Archivos para un SAS se debe
realizar de acuerdo al ejemplo mostrado.

Página 79 de 83 RIAC – JWG IEC 61850

 Tabla VII. Ejemplo de intercambio de información

B.7.2.1.5 Topología de las redes de comunicación

El modelo de la arquitectura del sistema SAS es considerado con base en el estándar IEC 61850: niveles de
estación, bahía y proceso. El nivel de la estación constituye el nivel más alto de la arquitectura, incluye al
menos dispositivos como: IHM, lugar de trabajo del operador (cuarto de control) e interfaces y equipos para
comunicación remota. El nivel de bahía debe estar compuesto por los componentes secundarios del sistema de
potencia (IEDs de protección, control, medición, etc.) ubicados típicamente en el cuarto de control de la
subestación. El nivel de proceso constituye el nivel más bajo de la arquitectura y debe estar compuesto por los
componentes primarios del sistema de potencia (interruptores, cuchillas, TC´s, TV´s, etc.) ubicados en el patio
de la subestación.

El SAS debe proporcionar todas las funciones de control, protección, medición, y supervisión requeridas para la
operación correcta y segura del equipo primario a ser instalado en la subestación, así como el mantenimiento
de los mismos. Además, debe incorporar interfaces de comunicaciones compatibles con el estándar IEC 61850
para la comunicación de la subestación con el centro de control.

En lo referente a la comunicación dentro de la subestación, la arquitectura SAS está basada en las siguientes
redes LAN:

 La red de estación (station bus)

 La red de proceso (process bus)

Dichas redes deben ser independientes y estar basadas en la tecnología Ethernet. La red de estación debe
proporcionar la interconexión de todos los IEDs de control, protección y medición; así como, la IHM local y otros
dispositivos encargados de las comunicaciones dentro y fuera de la subestación. La red de proceso debe
proporcionar la conexión de todos los elementos primarios del sistema de potencia de la subestación a los IEDs
correspondientes. La información transportada por esta red son muestras de voltaje, corriente y señales de
estado, entre otras. Tanto la red de estación como la red de proceso deben ser supervisadas, de tal forma que
cualquier degradación o falla de su desempeño debe ser incluida en el manejo de eventos y alarmas de la
subestación. Además, dichas redes serán administradas utilizando el protocolo SNMP. La Fig. 2 muestra un
ejemplo de la topología de la red de comunicaciones propuesta.

Página 80 de 83 RIAC – JWG IEC 61850

 Intranet
CFE

Ruteador

Switch IHM Switch L1,L2 Switch T1 Switch T2 Switch A1-A4 Switch A5-A8 Switch BC

A la UCM A. T.

Radios DEI1-L1 DEI1-T1 DEI1-T2 DEI-A1 DEI-A5 DEI-1

Gateway DEI1-L2 DEI2-T1 DEI2-T2 DEI-A2 DEI-A6 DEI-2

SCADA

DEI2-L1 DEI3-T1 DEI3-T2 DEI-A3 DEI-A7 MED-BC1

IHM

DEI2-L2 MED-T1 MED-T2 DEI-A4 DEI-A8 MED-BC2

GPS
M. T.

MED-L1 MED-SP MED-SP MED-A1 MED-A5 DEI-1

MED-L2 MED-A2 MED-A6 DEI-2

MED-A3 MED-A7 MED-BC1

Cable UTP MED-A4 MED-A8 MED-BC2

Anillo doble de
fibra óptica Dif. Barras

Enlace DEI-1
inalámbrico

Fig. 2 Ejemplo de la red de comunicaciones con doble anillo

B.7.2.1.6 Herramientas de software utilizadas para configurar y documentar el proyecto

Para la integración del SAS se considera la descripción del proceso de ingeniería y configuración de los IEDs a
través de un conjunto de archivos utilizados para especificar la configuración en sus diferentes etapas. El
Lenguaje de Configuración de Subestación (SCL) se utiliza para describir configuraciones de DEI y sistemas de
comunicación. El propósito principal de SCL es permitir el intercambio interoperable de los datos de la
configuración del sistema de comunicación entre herramientas de configuración de IEDs y herramientas de
configuración de sistema, aun siendo de distintos fabricantes. Por lo tanto estas herramientas deben apegarse
al modelo de objetos definido en el lenguaje, para la conformación de los distintos archivos SCL que definen en
la norma. Las herramientas deberán considerar el modelo de objetos definido por la norma para la descripción
de IEDs, sus conexiones de comunicación y su asignación a la subestación.
Las herramientas debe ser capaces de reconocer los 4 archivos SCL definidos, que son:

*.ICD (Descripción de características de IEDs)

*.SSD (Descripción de la especificación de sistema)
*.CID (Descripción de configuración de IEDs)
*.SCD (Descripción de la configuración de la subestación)

Las herramientas de ingeniería y configuración forman parte integrante del proyecto de una subestación por lo
que se consideran un componente más del sistema. El integrador proporciona el conjunto de herramientas
incluyendo licencias de aplicación y computadoras, así como los archivos de configuración del proyecto.
La siguiente figura muestra el proceso de ingeniería y configuración de un proyecto. El diseño de la
subestación comienza cuando se dispone de los modelos de todos los IEDs. En consecuencia un paso previo
es la obtención de los archivos tipo icd que describen las capacidades de los IEDs.
El diseño de ingeniería del proyecto se llevará a cabo mediante una herramienta de ingeniería y
documentación. Esta aplicación permitirá que el diseño se realice combinando tanto los modelos de DEI que
cumplen la norma IEC 61850 como otros modelos no incluidos en dicha norma. En consecuencia, la
herramienta no limitará el alcance del diseño ni el grado de detalle del mismo no limitándose a los aspectos
contemplados en la norma IEC 61850 y permitiendo, por lo tanto, que la ingeniería cubra todos los aspectos

Página 81 de 83 RIAC – JWG IEC 61850

necesarios para obtener una documentación completa y los archivos de configuración de todos los dispositivos
del sistema.
Una vez finalizado el diseño, la herramienta de ingeniería y documentación permitirá obtener la documentación
del mismo y la configuración de cada uno de los IEDs que forman el proyecto.
El integrador debe suministrar una herramienta de cómputo que incluya todas las aplicaciones necesarias para
conectarse con los IEDs del proyecto y poder descargar, actualizar y obtener los archivos de configuración
operativos. Está herramienta de configuración permitirá, a partir de los archivos de configuración generados por
la herramienta de ingeniería, configurar todos los equipos del proyecto. Así mismo, permitirá la introducción, de
forma manual y con la ayuda de aplicaciones específicas, de los ajustes de las protecciones y de otros ajustes
que puedan ser necesarios para obtener la funcionalidad descrita en la documentación y en los archivos de
configuración generados por la herramienta de ingeniería.

B.7.2.1.7 Descripción de los enlaces y protocolos de comunicación hacia el exterior de la SE

Conocida como comunicación a nivel superior a la comunicación entre el Servidor de Comunicaciones con el
protocolo de comunicación DNP 3.0 Nivel 2 y la Unidad Central Maestra de Operación (UCM), para envío de
información y atención a las solicitudes de la misma.
La transmisión de la información hacia la UCM y la del controlador de comunicaciones en la SE con los IEDs
con protocolo abierto son prioritarias. Actualmente el uso de protocolos de la norma IEC 61850 solo es para
usarse dentro de la subestación, y no se utiliza fuera de la misma. Los diseños todavía dependen de los
protocolos SCADA tradicionales y en servicio tales como DNP3 y algunos otros actualmente en uso.
Por estar limitada la aplicación de la norma IEC 61850 al interior de la subestación, es necesario el uso de una
computadora que recolecte los datos de los DEI’s vía los protocolos IEC 61850 y convierta estos datos a los
protocolos SCADA y proporcionarlos a las distintas consolas SCADA. Por lo tanto, además de actuar como un
convertidor de protocolo, la computadora es un concentrador de datos y un cliente/servidor. Para los
operadores es transparente el hecho de que los protocolos dentro y fuera de la subestación son diferentes.
Es necesario considerar que debido a que algunos de los nuevos protocolos IEC 61850 son más funcionales y
que tienen más características y atributos que no existen en otros protocolos como DNP3, es difícil convertir a
simple mensajes DNP3 para llevar a cabo acciones que son más elaborados en los protocolos IEC 61850. El
servidor de IHM debe incluir el servidor de FTP (File Transfer Protocol), que permita la configuración de
usuarios y privilegios de acceso desde el puesto remoto de ingeniería.

B.7.2.1.8 Beneficios de contar con una Meta-Especificación

En compañías eléctricas grandes como el caso de CFE-México, el contar con una meta-especificación que
define un perfil de referencia IEC-61850, permite homogenizar la filosofía de operación de subestaciones de
Distribución. Asimismo la asimilación del conocimiento permite una independencia para resolver problemas
técnicos sin una dependencia fuerte.

Por otro lado las compañías eléctricas pueden posicionarse en una asimilación y vanguardia de esta
tecnológica con el propósito que los fabricantes de IEDs y de otros equipos tomen como referencia operativa y
funcional dicha norma IEC-61850, asegurando que se estandarice con base en los requerimientos operativos.
Y finalmente muy importante es evitar inversiones costosas en la adquisición de la tecnología que los
fabricantes personalicen de acuerdo con sus líneas de desarrollo.

Página 82 de 83 RIAC – JWG IEC 61850

 ANEXO C. Tendencias y evolución (Esperar Reunión de Paris- Allan)

Referencias
[1] IEEE PSRC H6: Special Report, “Application Considerations of IEC61850/UCA 2 for Substation

Ethernet Local Area Network Communication for Protection and Control”, May 5, 2005.

Página 83 de 83 RIAC – JWG IEC 61850