See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/28139825

Más allá de la primera impresión: IEC 61850, más que una mera norma de
comunicación

Article · January 2006

Source: OAI

CITATIONS READS

0 319

2 authors, including:

Tatjana Kostic
Swissgrid AG, Laufenburg, Switzerland
28 PUBLICATIONS   269 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ADDRESS View project

All content following this page was uploaded by Tatjana Kostic on 21 May 2014.

The user has requested enhancement of the downloaded file.

Lo más brillante de la energía

Más allá de la
primera impresión
IEC 61850, más que una mera norma de comunicación
Christian Frei, Tatjana Kostic

En un entorno energético TI típico,

¿cómo se consigue que diversos
componentes y dispositivos de
diferentes fabricantes funcionen
juntos sin problemas? La respuesta
está en una rentable interfaz estándar
de comunicaciones, que hace posi-
bles infraestructuras abiertas e intero-
perabilidad de los dispositivos.

Un estándar de este tipo, el

CEI 61850, está considerado como
una importante norma internacional
para sistemas de automatización
de subestaciones, ya que define la
comunicación entre los dispositivos
de la subestación, así como los co-
rrespondientes requisitos del sistema
y el modelo de subyacente de datos.

ABB Corporate Research está apro-

vechando estas características de
CEI 61850 para proporcionar tecnolo-
gía ‘plug and play’ para aplicaciones
de automatización de subestaciones.

30 Revista ABB 4/2006


L as subestaciones eléctricas
son sistemas distribuidos
complejos –contienen equipos
1 Arquitectura simplificada de una aplicación ‘plug and play’ basada en
CEI 61850. Los números entre paréntesis indican la parte correspon-
diente de la norma. Un ejemplo de estas aplicaciones son los siste-
primarios heterogéneos como,
mas básicos de supervisión o control.
por ejemplo, aparamenta de
conexión, transformadores o
líneas– y están controladas por Ordenador
sistemas de automatización de
subestaciones (SAS). Un sistema
SAS consta de todo el equipo
electrónico1) necesario para
controlar, supervisar y proteger
de forma permanente la red.
Este equipo está interconectado
y ha de comunicarse a diferen-
tes niveles dentro y fuera de la
subestación (por ejemplo, hacia
el centro de control de la red).
ASCI (7-2)
Tradicionalmente, el trabajo de
ingeniería y configuración de
un sistema SAS ha sido consi-
derable. Estos esfuerzos tam-
bién han demostrado ser caros,
ya que (a) los costes de las entregas a
los clientes están condicionados por la
falta de configuraciones estandarizadas
entre dispositivos de diferentes vende-
dores, y (b) los costes del desarrollo de
productos dependen del número de pro-
tocolos de comunicaciones privados o
semiestándar que han de ser soportados.
Gracias a la norma CEI 61850, reciente-
mente adoptada [1], y en particular a
dos características singulares de la nor-
ma, los costes de ingeniería y configura-
ción se han reducido notablemente. Es-
tas características singulares compren-
den la autodescripción de dispositivos
electrónicos inteligentes (IED)2) en tiem-
po de ejecución (debido a sus modelos
de datos y servicios de comunicaciones)
y un lenguaje estandarizado de configu-
ración de subestaciones (SCL).
Estas dos características permiten a ABB
3)
emplear un sistema ‘plug and play’
(enchufar y listo) para aplicaciones de
automatización de subestaciones desti-
nado a reducir la costosa ingeniería de
proyectos para muchos clientes.
La norma CEI 61850
CEI 618504) es una norma de comunica-
ciones para la automatización de subes-
taciones. Su objetivo principal es permi-
tir la interoperabilidad sin fisuras de dis-
positivos IED (especialmente de diferen-
tes fabricantes de equipo original) den-
tro de la subestación. Se divide en
10 partes y trata cuatro aspectos princi-
pales: un modelo funcional del dominio
de aplicación de la automatización de
Revista ABB 4/2006
Más allá de la primera impresión
Lo más brillante de la energía
[4,5] del mismo se ha desarro-
llado en lenguaje UML (Uni-
fied Modelling Language)6) [3].
En este artículo nos referire-
mos a él como modelo UML.
En un sistema de automatiza-
ción de subestaciones hay dos
tipos de intercambio de datos:
Aplicación 1 Aplicación 2
intercambio de datos de apli-
caciones en tiempo de ejecu-
ción e intercambio (fuera de
Máquina con objetos significativos línea) de datos de configura-
ción. El intercambio de datos
en tiempo de ejecución tiene
Servidor ACSI
IED lugar a través de servicios de
(7-2, 8-1)
IED comunicaciones. La parte
Servidor ACSI MMS API IED 7-2 de CEI 61850 define un
(7-2, 8-1) sobre TCP/IP
conjunto de servicios abstrac-
API Servidor ACSI
Servidor tos de comunicaciones (ACSI)
MMS
(7-2, 8-1) que abordan los requisitos bá-
sicos del proceso de intercam-
bio de información. Estos ser-
vicios se pueden implementar
subestaciones (Parte 5), un modelo de como interfaz de programación de apli-
datos para SAS (Parte 7), protocolos de caciones (API, Application Programming
comunicaciones y sus servicios (Partes Interface), especificada en un lenguaje
7, 8 y 9) y un lenguaje descriptivo de la de programación dado, y/o como servi-
configuración de subestaciones (SCL - cios de la capa de aplicación de una
Parte 6), basado en XML [2]. pila determinada de comunicaciones.
En general, un modelo proporciona Como ejemplos de este tipo de inter-
determinadas informaciones sobre un cambio mencionemos la lectura de la
componente de equipo o sobre un pro- posición actual de un interruptor, un co-
ceso. En la comunicación de subestacio- mando de operador o el disparo de una
nes, un modelo que, por ejemplo, lista función de protección para cambiar la
los datos de entrada y salida de un posición del interruptor en tiempo de
transformador, se conoce como modelo ejecución. Estos servicios y la imple-
de datos; CEI 61850 tiene un modelo de mentación de los mismos son el ‘medio’
datos para cada función. Un dato ele- para el intercambio de datos.
mental tiene un nombre compuesto por El segundo tipo de intercambio de da-
tres partes normalizadas5), a saber, el tos, que se refiere a los datos de confi-
nodo lógico (LN), el objeto de datos y el guración de todas las aplicaciones y dis-
atributo. positivos SA, se realiza usando archivos
Puesto que la norma CEI 61850 define XML (eXtensible Markup Language),
el modelo de datos completo en un for- que siguen el lenguaje SCL7), descrito en
mato de texto y tabla, el modelo formal la norma. Estos archivos XML –en la fi-
Notas
1)
Según la norma CEI 61850, un sistema SAS consta generalmente de dispositivos electrónicos inteligentes
(IED) conectados por una red de comunicaciones.
2)
Por autodescripción de un IED se entiende la capacidad de éste para proporcionar cierta información, como
los datos de estado del proceso o los datos de configuración de entornos de protección (este último tipo de
datos no suele estar disponible en las normas anteriores SA sobre comunicación).
3)
Una aplicación se denomina ‘plug and play’ cuando es capaz de encontrar la funcionalidad de uno o más
dispositivos IED en tiempo de ejecución sin necesidad de configuración alguna y, a continuación, generar la
correspondiente interfaz gráfica de usuario a partir de dicha funcionalidad.
4)
ABB participa muy activamente en la definición y mantenimiento de la norma CEI 61850 (varios redactores de
dicha norma son empleados de ABB) y, en consecuencia, es uno de los principales proveedores en este cam-
po. Esto es fundamental actualmente, ya que muchos nuevos proyectos, especialmente en China e India,
requieren su uso.
5)
El nodo lógico, el objeto de datos y el atributo se ilustran mediante el ejemplo de un interruptor. El estado del
interruptor –en la terminología CEI 61850– se denomina XCBR.Pos.stVal, donde XCBR (el interruptor) es el
nodo lógico, Pos (posición del interruptor) es el objeto de datos y stVal (estado intermedio, conexión, desco-
nexión, estado incorrecto) es el atributo.
6)
El estándar de modelación de facto en ingeniería de software
31
Más allá de la primera impresión
Lo más brillante de la energía
gura se puede ver uno de ellos, resumi-
do– describen la configuración de los
dispositivos IED en términos de funcio-
nalidad (por ejemplo, control, medicio-
nes y valores de estado de los interrup-
tores), direcciones y medios de comuni-
caciones (por ejemplo, mensajes rápidos
a numerosos destinatarios, presentación
de informes), así como la distribución
de la subestación y su relación con las
funciones implementadas en los disposi-
tivos IED.
Aplicaciones inteligentes ‘plug and play’
En los párrafos siguientes se supone un
IED que cumple totalmente la norma
CEI 61850, concretamente, que debe
proporcionar para sus datos una interfaz
conforme con ACSI.
Las aplicaciones inteligentes ‘plug and
play’ pueden depender de las caracterís-
ticas de interoperabilidad normalizadas
por CEI 61850. El descubrimiento y la
recuperación de valores reales para los
datos del proceso y de confi-
guración se realizan del modo
2 Un navegador CEI 61850: aplicación que no necesita configuración
siguiente:
alguna pero puede descubrir el contenido de un dispositivo IED,
analizarlo semánticamente y autogenerar la visualización.
1. Enchufar el ordenador con
la aplicación de ejecución
en la red CEI 61850.
2. Proporcionar la dirección IP
del servidor residente en un
IED. (Este paso es el único
que no tiene totalmente ca-
rácter ‘plug and play’)
3. La aplicación recupera las
variables utilizando servi-
cios de directorio ACSI.
4. La interfaz de usuario de la
aplicación se genera auto-
máticamente de acuerdo
con estas variables y su se-
mántica.
5. La aplicación adquiere valo-
res actuales para todas las
variables de interés.
6. Si se necesitan valores ac-
tualizados de datos del pro-
ceso, la aplicación se suscri-
be a eventos adecuados.
Los pasos (2) a (6) se pueden
repetir tantas veces como sea
necesario. Puesto que el paso
(2) no se considera por com-
pleto ‘plug and play’ se puede
realizar escanear la red para
detectar varios servidores –
que responden a un puerto
32
predefinido- siempre que lo permitan
los mecanismos de seguridad en cada
IED.
La figura 1 muestra esquemáticamente
la arquitectura de un sistema ‘plug and
play’. Los servidores ACSI proporcionan
servicios definidos (Parte 7-2 de la nor-
ma) y permiten la abstracción de los
servicios con independencia de su im-
plementación específica. También per-
miten la ‘navegación’ de variables, la re-
cuperación y ajuste (donde proceda) de
ciertos valores y, finalmente, la recep-
ción de datos actualizados del proceso a
través de un mecanismo de registro de
eventos. El motor es la interfaz ‘semánti-
ca’ entre ACSI y la aplicación, y se ocu-
pa de convertir nombres de variables
MMS8) en objetos significativos de con-
formidad con las Partes 7-4 y 7-3. Los
derechos de acceso -lectura, escritura o
lectura/escritura– son identificados auto-
máticamente para cada atributo de da-
tos. El motor es también responsable de
registrar cualquier evento que propor-
cione datos reales (en vivo) del proceso
y, más tarde, también de actualizar los
valores correspondientes. Una aplica-
ción, por ejemplo un sistema básico de
supervisión, depende del motor para
adquirir el contenido de los servidores y
obtener y establecer valores. Puesto que
el tipo de datos se identifica claramente,
el motor puede proporcionar vistas para
datos del proceso (valores actuales, ana-
lógicos o digitales) o parametrización
(de funciones de protección). Además
se pueden registrar eventos y visualizar-
los para el usuario; algunos pueden in-
cluso ser interpretados automáticamente
como alarmas.
Más abajo describimos brevemente algu-
nas aplicaciones prototipo9) desarrolla-
das en el centro de investigación corpo-
rativa de ABB en Suiza en el marco del
proyecto ‘Zero-Configuration Substation
Monitoring System’.
Navegador CEI 61850 ‘plug and play’
En la figura 2 presentamos una imagen
de pantalla de un navegador
CEI 61850 ‘plug and play’. Es
posible crear un sistema de su-
pervisión elemental utilizando
únicamente la dirección (o di-
recciones)
IP del dispositivo (o dispositi-
vos). Provisto de esta dirección
IP, un usuario puede acceder
automática y autónomamente
al contenido del IED, es decir,
sin configurar previamente el
software. En el ejemplo presen-
tado en 2 se muestra el conte-
nido del nodo lógico QA1X-
CBR3 (que refleja la informa-
ción de un interruptor), junto
con su objeto de datos Pos
(posición del interruptor) y los
atributos de los datos (nom-
bres, tipos, valores y otras
propiedades) correspondientes
a ese objeto. Ninguna de estas
propiedades está codificada en
hardware, se generan a partir
de la información semántica
procedente del modelo formal
de datos expresado con el
modelo UML y que se encuen-
tran disponibles en la aplica-
ción.
Comparador ‘plug and play’
de configuraciones IED
Otra aplicación inmediata, inte-
grada en el motor, es un com-
Revista ABB 4/2006
 Más allá de la primera impresión

Lo más brillante de la energía

parador de configuraciones IED ‘plug
and play’. Esta aplicación compara el
contenido real de un dispositivo IED
con su configuración descrita en el co-
rrespondiente archivo SCL. La utilidad
de esta herramienta se observa especial-
mente durante la puesta en servicio o el
mantenimiento, cuando el ingeniero ne-
cesita verificar que la configuración IED
real coincide con la proporcionada por
el correspondiente archivo SCL.
Generador ‘plug and play’
de configuraciones IED
Normalmente, los archivos SCL son ge-
nerados por la herramienta de ingenie-
ría, pero también es posible generar
automáticamente un archivo SCL. Esto
es especialmente útil durante la actuali-
zación del sistema, ya que la mayoría de
los sistemas usuales de automatización
de subestaciones no tienen un archivo
SCL que las describa (y si lo tienen,
puede estar anticuado). El archivo SCL
generado se puede importar más tarde
desde la herramienta de ingeniería para
los procesos posteriores, evitando así un
trabajo pesado y susceptible de errores.
Las aplicaciones descritas a modo de
ejemplos ilustran la posibilidad de crear
aplicaciones ‘plug and play’ basadas en
la capacidad de autodescripción de dis-
positivos IED en tiempo de ejecución,
utilizando como entrada únicamente la
dirección IP (o un rango de ellas). Des-
de una perspectiva sistémica, sin embar-
go, está limitada la posibilidad de utili-
zar únicamente el modelo de datos y
servicios ACSI (definidos en la Parte 7
del estándar), que se refieren a disposi-
tivos IED individuales. En consecuencia,
es imposible vincular las funciones des-
cubiertas automáticamente (es decir,
nodos lógicos) al equipo primario, ni
se puede deducir la distribución de la
subestación, ni siquiera analizar la red
de comunicaciones entre dispositivos.
En otras palabras, si sólo se dispone de
la dirección IP (de su rango), sólo es
posible crear un sistema de supervisión
muy elemental centrado en dispositivos
IED individuales.
Gracias a la norma CEI
61850 de comunicación
para la automatización de
susbestaciones, los cos-
tes SAS de ingeniería y
configuración se han
reducido notablemente.
Para ampliar las capacidades del sistema
de supervisión se requiere un archivo
adicional SCL, completo y actualizado,
para hacer comprensible en conjunto el
sistema de automatización de la subesta-
ción. Una aplicación que exija que el
usuario le proporcione este fichero ya
no puede considerarse por ‘plug and
play’. Una solución posible consiste en
alojar el archivo SCL adicional en una
dirección predefinida en una pasarela.
En este caso será posible la aplicación
que describimos a continuación.
Sistema (básico) ‘plug and play’
de supervisión de subestaciones
El navegador CEI 61850 descrito puede
descubrir una configuración de automa-
tización de uno o más dispositivos IED
en una subestación. Gracias al modelo
de datos definido en el estándar es fácil
identificar los puntos de datos de esta-
dos y mediciones y, por consiguiente,
crear automáticamente una interfaz de
usuario para visualizar todos los datos
de proceso (de estado y medición).
Por otro lado, se puede realizar automá-
ticamente la suscripción a un servicio
de registro de eventos que proporcione
valores actualizados. Además, si se
proporciona un archivo SCL con la
descripción del patio de maniobras
(es decir, una sección de la subesta-
ción), se podrá crear y visualizar un
sencillo diagrama monofilar con los da-
tos del proceso.
Conclusión
A pesar de su nombre, CEI 61850 es
mucho más que un mero estándar de
comunicaciones, ya que también define
un modelo de datos y los servicios para
operar con estos datos. ABB‘s Corporate
Research ha aprovechado estas caracte-
rísticas para desarrollar la tecnología
subyacente que permite utilizar aplica-
ciones ‘plug and play’ (por ejemplo,
deducir automáticamente la configura-
ción de un IED). Evidentemente, siste-
mas tan complejos como SCADA nunca
llegarán a tener pleno carácter ‘plug and
play’ y requerirán cierto trabajo de inge-
niería. Sin embargo, este trabajo será
más simple gracias a los planteamientos
propuestos y reducirá el número de
pruebas de aceptación en fábrica, el
tiempo de puesta en funcionamiento y
el mantenimiento.
Los componentes esenciales de la
arquitectura ‘plug and play’ se están
convirtiendo en parte integrante de los
productos SAS de ABB. Este hecho,
unido a la complejidad y a la creciente
importancia de la norma CEI 61850, ha
dado un nuevo impulso al desarrollo
conjunto de herramientas en ABB.
Christian Frei
Tatjana Kostic
ABB Corporate Research
Baden-Dättwil, Suiza
christian.frei@ch.abb.com
tatjana.kostic@ch.abb.com
Publicaciones de ABB sobre la norma CEI 61850:
http://www.abb.com/cawp/seitp202/C1256A8C0049
9292C1256D4100388F27.aspx

Notas
7)
El lenguaje SCL define la interrelación del equipo de la subestación entre sí y con la propia subestación.
8)
Manufacturing Message Specification: ISO 9506-1 e ISO 9506-2: Sistemas de automatización industrial, especificación de mensajes para la fabricación; primera edición,
15-08-2000
9)
Algunas de estas aplicaciones están actualmente en proceso de transferencia a unidades de negocio de ABB para la integración de productos.

Bibliografía
[1] IEC 61850: Communications Networks and Systems in Substations, International Standard, 2003.
[2] O. Preiss and A. Wegmann, ‘Towards a Composition Model Problem Based on IEC 61850’, The Journal of Systems and Software, Vol. 65/3, Elsevier Science, 2003,
pp. 227–236.
[3] OMG, Unified Modelling Language Specification, Version 2.0, July 2005. http://www.omg.org/uml
[4] T. Kostic and O. Preiss, ‘UML model of the IEC 61850 (v6, May 2004) and the data mappings between CIM 10 and IEC 61850’. Not yet published (contact authors).
[5] T. Kostic, O. Preiss, C. Frei, ‘Understanding and Using the IEC 61850: A Case for Meta-Modelling,’ Elsevier Journal of Computer Standards & Interfaces, vol. 27/6,
pp. 679–695, 2005.

Revista ABB 4/2006 33

View publication stats