Post on 25-Oct-2021
DESARROLLO DE UNA INTERFAZ SOFTWARE BASADA EN LA NORMA IEC
62439-3 ORIENTADA A REDES REDUNDANTES DE COMUNICACIONES PARA
AUTOMATIZACIÓN DE SUBESTACIONES ELÉCTRICAS
NICOLÁS RICARDO HERNÁNDEZ PÁEZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FALCULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
BOGOTÁ
2017
DESARROLLO DE UNA INTERFAZ SOFTWARE BASADA EN LA NORMA IEC
62439-3 ORIENTADA A REDES REDUNDANTES DE COMUNICACIONES PARA
AUTOMATIZACIÓN DE SUBESTACIONES ELÉCTRICAS
TRABAJO DE GRADO
MODALIDAD PASANTÍA
NICOLÁS RICARDO HERNÁNDEZ PÁEZ
COD. 20121005030
IVÁN DARÍO CLAROS GÓMEZ
GERENTE DE DESARROLLO TECNOLÓGICO
AXON GROUP LTDA
GUSTAVO ADOLFO PUERTO LEGUIZAMÓN PhD
DOCENTE DE PLANTA FACULTAD DE INGENIERÍA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FALCULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
BOGOTÁ
2017
CONTENIDO
1. Introducción ………………………………………………………………………. 4
2. Marco teórico…………………………………………………………………….. 7
2.1 Link Redundancy Entity………………………………………….. 7
2.1.1 Algoritmo de descarte…………………………………………………..
2.2 Tabla de nodos………………………………………………………………..7
3. Desarrollo cronograma de actividades ………………………..…………………...19
4. Desarrollo de objetivos ……………………………………… 22
4.1 Envío de tramas de supervisión PRP ……………………………………22
4.2 Recepción de tramas de supervisión PRP y Tabla de nodos
4.3 Envío y recepción de tramas de información PRP
5. Desarrollos adicionales …….……………………………………………… 22
5.1 Puerto virtual…………………………………………………………..XX
5.2 Servicios de Windows……………………………………………………XX
5.3 Interfaz Gráfica de Usuario………………………………………………XX
6. Pruebas Realizadas ………………………………………………………….. 24
6.1 DANP a DANP …………………………………………………………XX
6.2 DANP a SAN……………………………………………………………..XX
6.3 DANP a SAN con RedBox……………………………………………….XX
6.4 DANP a Relé Siprotec 5………………………………………………..XX
7. Mejoras futuras...………………………………………………………………. 24
8. Bibliografía ………………………………………………………………………. 25
1. INTRODUCCIÓN
Las redes eléctricas y los sistemas de comunicaciones son en la actualidad el pilar
fundamental de los procesos industriales de producción, la alta demanda energética obliga a
una evolución permanente de los sistemas de distribución, generación y transporte. Un
mercado tan amplio y con un crecimiento tan acelerado requiere sistemas con muy alta
calidad, con modernos sistemas de control, seguimiento y mantenimiento que garanticen la
confiabilidad del servicio, el cumplimiento de los estándares de calidad de la energía y una
rápida respuesta ante fallos con sistemas inteligentes de detección de problemas,
aislamiento y rápida recuperación del servicio. El uso de dispositivos de control inteligentes
(IED’s) van de la mano de Gateways de comunicaciones y sistemas SCADA (Supervisión,
Control y Adquisición de Datos), sobre redes de comunicaciones de alta confiabilidad. Esta
combinación surge como una excelente alternativa para la automatización de subestaciones
eléctricas permitiendo controlar tanto a nivel local como remoto, el proceso de generación
transporte y distribución de energía eléctrica.
La necesidad de interoperabilidad entre dispositivos de diferentes fabricantes y de generar
estándares de comunicaciones enfocados en sistemas de comunicaciones de alta velocidad
que garanticen una transferencia eficiente y fiable de datos, comandos y procesos entre los
dispositivos de automatización de redes eléctricas permitió el surgimiento de protocolos de
comunicaciones enfocados a la automatización de subestaciones eléctricas, como GOOSE y
MMS referenciados en el estándar IEC-61850 [10]. Estos protocolos fueron enfocados a la
integración de equipos de diferentes fabricantes y dar soporte a los distintos niveles del
sistema (proceso, bahía y subestación), minimizando la necesidad de utilizar conversores de
protocolos, reduciendo la complejidad y los tiempos de los procesos de ingeniería.
Las redes de comunicaciones en subestaciones eléctricas requieren de sistemas de alta
disponibilidad, con porcentajes mínimos de error que garanticen la integridad y la
velocidad de la información con mecanismos de rápida respuesta ante fallos. Las redes de
comunicaciones redundantes y los protocolos de redundancia como PRP [1] surgen de la
necesidad de dichos sistemas, garantizando la integridad de la información y ofreciendo
una respuesta ante fallos casi instantánea, con tiempos de reconfiguración cero.
El presente documento expone las etapas de desarrollo y validación realizadas para el
diseño e implementación de una interfaz software orientada a redes redundantes de
comunicaciones para automatización de subestaciones eléctricas enfocado hacia el
protocolo de redundancia paralela PRP expuesto en la norma IEC 62439-3.
2. MARCO TEÓRICO
Las redes industriales de comunicaciones requieren de una alta disponibilidad además de
tener la capacidad de garantizar la integridad de la información y poseer una alta capacidad
de respuesta ante fallos. Pequeñas perdidas en la conectividad pueden resultar en pérdidas
de funcionalidad de los sistemas, más aún si se trata de sistemas de generación y
distribución de energía. Como solución a los requerimientos de las redes Ethernet
industriales han sido propuestos e implementados diferentes esquemas de redundancia,
tratando de garantizar la recuperación y la integridad de la información ante fallos de la red.
El protocolo de redundancia paralela PRP surge como una excelente solución a esta
necesidad, debido a que la redundancia es implementada en los nodos y no en la red,
además de tener tiempo de reconfiguración nulo por lo que no presenta un periodo de no
disponibilidad de la red.
El protocolo PRP es un protocolo transparente a la topología de la red, esta no requiere
cambios para su implementación. PRP opera en dos redes LAN independientes que pueden
o no tener distintas topologías. Ambas LAN son idénticas en protocolo a nivel de control de
enlace lógico (LLC) y control de acceso al medio (MAC), pero pueden ser diferentes en
topología y desempeño. Cada trama enviada por un nodo PRP es duplicada en el envío y
transmitida por ambas redes, el nodo receptor procesa la trama que llegue primero y
descarta la copia. La estructura encargada del funcionamiento a nivel de protocolo en un
modelo de capas se denomina Entidad de Redundancia de Enlace (LRE por sus siglas en
inglés).
2.1 Link Redundancy Entity (LRE)
La entidad de redundancia de enlace (Link Redundancy Entity) es el corazón del PRP, su
correcto funcionamiento es crucial tanto para el funcionamiento a nivel de protocolo de los
nodos como para el óptimo desempeño de la red de comunicaciones. Esta entidad, trabaja
en ambos sentidos de la comunicación, en el envío de información es la encargada de
duplicar las tramas que provienen de las capas superiores, además de añadir los
encabezados PRP (RCT); del otro lado, para la recepción de información, esta se encarga
del descarte de tramas duplicadas, además de eliminar el RCT previo al envío de las tramas
aceptadas a las capas superiores.
Un parámetro fundamental para el funcionamiento de la LRE es la tabla de nodos, en ella
se lleva el control y seguimiento de todos los nodos conectados a la red, tanto SAN (Single
Atached Node) como DANP (Double Atached Node), con diferentes parámetros como la
LAN por la que están conectados, total de tramas recibidas de este nodo, entre otros
parámetros que más adelante se explicarán. La LRE basada en el contenido de esta tabla
está en la capacidad de tomar decisiones en el envío de información, permitiendo un mejor
manejo de la red y evitando congestiones ya que si una trama que proviene de las capas
superiores requiere ser enviada a un nodo SAN, no debe ser duplicada pues solo se tiene
conexión con ese nodo por una de las dos LAN, en este caso la LRE debe tomar la decisión
de enviar solo una trama por una de las dos redes sin añadir el encabezado PRP, así la
comunicación con nodos SAN es transparente, y se efectúa de forma similar a una
comunicación sin PRP. Igualmente esta entidad desempeña el trabajo de esconder las dos
redes de las capas superiores, para ellas solo estarán conectadas a una sola LAN, esto
gracias al algoritmo de descarte y a la eliminación del RCT en la trama aceptada del lado de
la recepción.
Figura 1. Link Redundancy Entity [1]
La Entidad de Redundancia de Enlace se implementa como una interface entre la capa de
red y la capa de transporte, en el caso de una comunicación entre dos DANP como se
muestra en la figura X del lado del envío el DANP 1 recibe una trama de la capa de red,
como el destino de esta trama es un nodo DANP en su tabla de nodos, esta duplica la trama
y añade los encabezados PRP (RCT) y envía una trama por cada puerto de red.
Del lado de la recepción el nodo DANP2 recibe dos tramas similares, una por cada puerto
de red, la Entidad de Redundancia de Enlace se encarga de aceptar una de las dos tramas y
descartar la otra, haciendo uso de su algoritmo de descarte, para finalmente enviar una a las
capas superiores luego de eliminar el RCT.
2.1.1. Algoritmo de descarte
Del lado de la recepción, un nodo DANP, en una comunicación de DANP a DANP recibirá
dos tramas duplicadas, una por cada LAN, provenientes del nodo DANP remitente. El
nodo receptor debe estar en la capacidad de aceptar solo una de ellas, esto con el fin de no
saturar con duplicados las capas superiores haciendo transparente el protocolo y su
implementación, tanto para la red como para las capas superiores. La LRE es la subcapa
encargada de este algoritmo, apoyada en su tabla de nodos, debe tener un registro y control
del número de secuencia de las tramas recibidas provenientes de este nodo, para así tener la
capacidad de decidir entre aceptar o descartar cada trama.
La norma IEC 62439-3 deja a elección del diseñador el diseño de la lógica y la
implementación del algoritmo de descarte.
2.2 Tabla de nodos
Un nodo que implemente el protocolo PRP debe establecer un monitoreo de algunos
elementos, tanto de la red como de los diferentes nodos conectados a ella. Este monitoreo
permite una supervisión constante de la red, así como la comunicación con nodos que
soporten o no el protocolo PRP. Según la norma IEC 62439-3 cada entrada de la tabla de
nodos se le debe contener los siguientes parámetros:
Argumento Definición Tipo
MacAddress Dirección MAC nodo fuente OctetString6
CntReceivedA Número de tramas recibidas de este nodo sobre la Lan A Unsigned32
CntReceivedB Número de tramas recibidas de este nodo sobre la Lan B Unsigned32
CntErrWrongLanA Numero de tramas recibidas de ese nodo con el LanId erróneo en la Lan A Unsigned32
CntErrWrongLanB Numero de tramas recibidas de ese nodo con el LanId erróneo en la Lan B Unsigned32
TimeLastSeenA Tiempo en el que la última trama de ese nodo fue recibida en la Lan A TimeTricks
TimeLastSeenB Tiempo en el que la última trama de ese nodo fue recibida en la Lan B TimeTricks
SanA True si el nodo remoto es probablemente SAN accesible desde el puerto A Boolean
SanB True si el nodo remoto es probablemente SAN accesible desde el puerto B Boolean
Tabla 1. Tabla de nodos [1]
Guardar una entrada en la tabla de nodos
Un nodo SAN o DANP debe ser guardado en la tabla de nodos al momento de recibir la
primera trama de él. Inicialmente, todos los nodos deben ser guardados como SAN, el tipo
de nodo solamente debe ser actualizado a DANP al momento de recibir una trama de
supervisión de dicho nodo. Las tramas de supervisión PRP indican que el nodo soporta PRP
y está conectado a ambas redes, por lo que la comunicación con él debe ser redundante. Un
nodo que no envíe tramas de supervisión debe ser guardado como un SAN conectado por la
red A o B dependiendo de la red de la que se reciban tramas de él. La comunicación con un
nodo SAN se debe realizar solamente por la LAN a la que está conectado.
Borrar una entrada de la tabla de nodos
Un nodo SAN o DANP según la norma IEC 62439-3 debe ser borrado de la tabla de nodos
si durante dos minutos se deja de recibir tramas de cualquier tipo de este, así los
dispositivos que sean desconectados de la red serán eliminados, permitiendo tener
seguimiento de los nodos actualmente conectados a la red. Si pasados los dos minutos sin
recibir información de un nodo y este ya ha sido borrado de la tabla, se vuelve a recibir
información de este, se debe crear una nueva entrada en la tabla, esto permite tener
actualizado el estado, el tipo y el número de dispositivos conectados a la red.
La norma IEC 62439-3 deja a elección del diseñador el uso de otros parámetros para las
entradas de la tabla de nodos, para la implementación realizada en este proyecto se tuvieron
en cuenta varios parámetros adicionales, los cuales serán explicados a detalle
posteriormente.
3. DESARROLLO CORONOGRAMA DE ACTIVIDADES
En la planificación del cronograma de actividades, expuesto en el anteproyecto presentado,
se tenía presupuestado culminar los objetivos planteados en 12 semanas, iniciando el día 13
de Marzo de 2017 y culminando el 1 de Junio de 2017. Para esto se plantearon las 9 etapas
de desarrollo del proyecto que se muestran a continuación.
Etapa 1: Estudio de los sistemas de control y adquisición de datos y las redes de
comunicaciones en subestaciones eléctricas
Etapa 2: Estudio de redes industriales redundantes y protocolos implementados.
Etapa 3: Estudio a del protocolo de redundancia paralela PRP, su normatividad, sus
conceptos teóricos y su implementación.
Etapa 4: Análisis de los sistemas y dispositivos en el mercado actual que soporten
protocolos redundantes.
Etapa 5: Estudio de la normatividad, funcionamiento, características e implementaciones
de los estándares de redes Ethernet industriales.
Etapa 6: Estudio de la teoría, forma de implementación y desarrollos previos de drivers de
red personalizados para Windows.
Etapa 7: Codificación y desarrollo de software para la formación y envío de tramas PRP
tanto de información como de supervisión que se ajuste a la normatividad de IEC-62439-3.
Etapa 8: Codificación y desarrollo de software para la recepción de tramas PRP tanto de
información como de supervisión, con capacidad de descarte de duplicados y manejo de la
tabla de nodos.
Etapa 9: Evaluación de desempeño y cumplimiento de los requerimientos de diseño del
sistema implementado.
Adicionalmente a estas 9 etapas, para la codificación, implementación y ensamble de las
funcionalidades adicionales de configuración, rendimiento y mantenimiento logradas en el
proyecto de las que se hablará en el capítulo de Objetivos Adicionales Alcanzados,
mencionadas anteriormente fueron requeridas las 4 etapas adicionales:
Etapa adicional A: Codificación y configuración de puerto virtual de enlace entre capas
superiores y tarjetas de red.
Etapa adicional B: Creación, ensamble, y modificación desde la ejecución de la aplicación
del archivo de configuración para el enlace de los dos puertos reales de red y el puerto
virtual.
Etapa adicional C: Implementación de la aplicación como servicio de Windows, y
servicio de supervisión y seguimiento.
Etapa adicional D: Diseño de la interfaz gráfica de usuario.
La Tabla 2 muestra el desarrollo cronológico del proyecto, con los tiempos requeridos para
la realización de cada una de sus etapas, incluyendo las etapas adicionales de desarrollo.
Esta tabla al ser evaluada en paralelo con la presentada en el cronograma de actividades del
anteproyecto muestra no solo el cumplimiento de las fechas establecidas para la
culminación de cada etapa, sino el desarrollo de aspectos y funcionalidades adicionales a
las planteadas como objetivos del proyecto, siendo culminadas satisfactoriamente todas las
etapas incluyendo las adicionales, en el mismo tiempo total de desarrollo establecido en el
anteproyecto.
Tabla 2. Cumplimiento cronograma de actividades
4. DESARROLLO DE OBJETIVOS
El objetivo general de este proyecto es desarrollar un prototipo de software que implemente
una interfaz de comunicaciones capaz de enviar y recibir tramas PRP haciendo uso de una
red Ethernet, orientando a un nodo DANP para sistemas de control y automatización de
subestaciones eléctricas. Para el cumplimiento de este, luego de la culminación de la
estructuración teórica planteada en primer objetivo específico se realizó el diseño e
implementación software en lenguaje C haciendo uso del entorno de desarrollo Visual
Studio 2015, de una interfaz software que permita el envío y la recepción de tramas PRP
de supervisión e información, así como el manejo y gestión de la tabla de nodos y
algoritmo de descarte.
Para la creación y manejo, tanto en envío como en recepción de los sockets Ethernet, se
hizo uso de la librería WinPcap, esta librería de código abierto, es la herramienta estándar
de la industria para acceder a la conexión entre capas de red en entornos Windows. Permite
a las aplicaciones capturar y trasmitir los paquetes de red puenteando la pila de protocolos;
WinPcap consiste en un controlador, que extiende el sistema operativo para proveer acceso
de red a bajo nivel, y una biblioteca que se usa para acceder fácilmente a las capas de red de
bajo nivel, siendo el motor de captura de paquetes y filtrado de muchas de las herramientas
SEMANA ETAPAS
1 2 3 4 5 6 7 8 9 10 A B C D
1 X X
2 X X
3 X X
4 X
5 X
6 X X
7 X
8 X
9 X
10 X
11 X
12 X X
13 X
de red comerciales, incluyendo analizadores de protocolos, monitores de red, sistemas de
detección de intrusos de red, sniffers, generadores de tráfico y network testers.
4.1 Envío de tramas de supervisión PRP
La implementación del diseño realizado fue desarrollado como una aplicación de consola
de Windows, las pruebas iniciales de desarrollo y funcionamiento se realizaron haciendo
uso del analizador de protocolos Wireshark en una conexión Ethernet punto a punto
realizando dos conexiones, por interfaces de red diferentes. La Figura 2 muestra la
estructura de las tramas de supervisión construidas y enviadas por cada una de las dos
LAN, el desarrollo de estas cumple con la norma IEC 62439-3.
La dirección MAC fuente de la trama, como la dirección MAC del nodo dentro de la trama
de supervisión provienen de la dirección MAC del puerto virtual creado
(02:00:4C:4F:4F:51), esto debido a que el único contacto que tienen las capas superiores
con el resto de capas de la pila de protocolos es este puerto virtual, así que de cara a las
capas de transporte y aplicación, el puerto virtual hace transparente el protocolo PRP, para
ellas la comunicación se realiza de forma natural, sin duplicados y con una única conexión,
otorgada precisamente por este puerto virtual.
Debido a que la implementación del puerto virtual y el driver de red no estaban dentro de
los objetivos del proyecto, la estructura, topología y funcionamiento de estos se tratará en el
capítulo de Objetivos Adicionales Alcanzados.
Figura 2. Tramas de supervisión Lan A y Lan B
4.2 Recepción de tramas de supervisión PRP y tabla de nodos
La parte más importante en la administración de la tabla de nodos es la identificación de los
dispositivos conectados como SAN (single atached nodes) y DANP (double atached nodos
with PRP), este es el corazón del protocolo, ya que permite una comunicación transparente
con dispositivos que no soporten PRP y hace la redundancia independiente de la topología
de red y del tipo de dispositivos conectados a ella. Con esto se logra una de las bondades
principales de este protocolo, la interoperabilidad entre dispositivos con y sin PRP.
Según la norma IEC 62439-3 el parámetro de control y filtrado para cada entrada de la tabla
de nodos, debe ser la dirección MAC. Un nodo debe ser guardado como DANP solamente
al recibir una trama de supervisión con su dirección MAC en la información dentro de ella.
Un nodo debe ser guardado como SAN si no se reciben tramas de supervisión de este. En la
aplicación realizada se tuvieron en cuenta varios parámetros adicionales a los que sugiere la
norma para cada entrada en la tabla de nodos, a continuación se muestran una tabla con
todos los parámetros utilizados, su descripción y tipo de datos para la gestión de cada
entrada de la tabla.
Parámetro Definición Tipo
MacAddress Dirección MAC nodo fuente char*
CntReceivedA Número de tramas recibidas de este nodo sobre la Lan A int
CntReceivedB Número de tramas recibidas de este nodo sobre la Lan B int
CntErrWrongLanA Numero de tramas recibidas de ese nodo con el LanId erróneo en la Lan A int
CntErrWrongLanB Numero de tramas recibidas de ese nodo con el LanId erróneo en la Lan B int
SanA True si el nodo remoto es probablemente SAN accesible desde el puerto A bool
SanB True si el nodo remoto es probablemente SAN accesible desde el puerto B bool
Danp True si el nodo remoto es un DANP bool
RedBox True si el DANP está conectado mediante un redBox bool
RedBoxMac Dirección MAC RedBox char*
totalFramesReceived Tramas totales recibidas de este nodo int
lastSeqNrReceived Ultimo número de secuencia PRP recibido uint16_t
lastSupSeqNrReceived Ultimo número de supervisión recibido uint16_t
tvlType Tipo de nodo y tipo de modo de operación int
RedFramesReceived Tramas con PRP recibidas de este nodo Int
TimeLastSup Tiempo en el que la última trama de supervisión TimeTricks
TimeLastSeenA Tiempo en el que la última trama de ese nodo fue recibida en la Lan A TimeTricks
TimeLastSeenB Tiempo en el que la última trama de ese nodo fue recibida en la Lan B TimeTricks
Tabla 3. Tabla de nodos implementada
La Figura 3 muestra la impresión en consola de la tabla de nodos para red con los
siguientes dispositivos:
- MAC 18:DB :F2:17:77:0B SAN A
- MAC 02:00:4C:4F:F4:50 DANP
-84:B1:5A:00:DA:BA DANP
Figura 3. Tabla de nodos en consola
Para la recepción de tramas de información PRP la aplicación utiliza el algoritmo de
descarte planteado en el anteproyecto, para esto la recepción de tramas se divide en tres
tipos.
Si la trama recibida no tiene PRP, la LRE debe actualizar la tabla de nodos y subir
la trama a capas superiores.
Si la trama es PRP de supervisión, la LRE solamente debe actualizar la tabla de
nodos.
Si la trama PRP es de información, la LRE debe evaluar si la trama es un duplicado,
y dependiendo del resultado actualizar la tabla de nodos, quitar el encabezado RCT
y enviarla o no a capas superiores.
4.3 Envío y recepción de tramas de información PRP
La LRE en el momento previo a enviar una trama a cualquier nodo de la red debe realizar
una evaluación de su tabla de nodos, verificando si el nodo destino es un SAN conectado
por una de las dos LAN o es un DANP conectado por ambas LAN. Dependiendo del tipo
de nodo en la tabla y la dirección MAC destino de la trama, la LRE debe tomar una
decisión antes de enviar la trama a las tarjetas de red reales. Las posibles situaciones que se
pueden presentar en el momento del envío y las decisiones que debe tomar la LRE son las
siguientes:
Si la dirección de destino no se encuentra en la tabla de nodos, la LRE no debe
enviar la trama a ningún puerto de red.
Si la dirección de destino es broadcast, la LRE no debe colocar encabezado RCT y
debe enviar la trama por ambas LAN.
Si la dirección de destino está guardada en la tabla de nodos como un SANA (San
conectado por la LAN A), la LRE deberá no añadir el encabezado RCT y enviar la
trama solamente por la LAN A.
Si la dirección de destino está guardada en la tabla de nodos como un SANB (San
conectado por la LAN B), la LRE deberá no añadir el encabezado RCT y enviar la
trama solamente por la LAN B.
Si la dirección de destino está guardada en la tabla de nodos como un DANP, la
LRE deberá colocar el encabezado RCT y enviar la trama por las dos LAN.
La Figura 4 muestra un ejemplo de recepción de trama PRP de información, como
cualquier protocolo puede trabajar sobre PRP, ya que este es transparente a la
comunicación, no debería importar el protocolo utilizado. En este caso se hizo uso del
protocolo ICMP haciendo un ping desde un nodo DANP a otro nodo DANP. En la figura
podemos observar como en los dos puertos reales se reciben tramas similares con
encabezados PRP pero la LRE se encarga de subir a el puerto virtual solamente una de ellas
previa eliminación del RCT.
Figura 4. Protocolo ICMP en los dos puertos reales y puerto virtual
5. DESARROLLOS ADICIONALES
El alcance inicial del proyecto estaba limitado por el desarrollo de la interfaz software
capaz de manejar la recepción y envío de información haciendo uso del protocolo de
redundancia paralela PRP. Sin embargo para su implementación funcional, instalación y
trabajo dentro del modelo de comunicaciones fue requerido el diseño y desarrollo de varias
herramientas adicionales.
Varios de los requerimientos de los desarrollos adicionales necesarios, son establecidos por
el contexto de trabajo. Ya que el producto final está enfocado a su implementación en
varios de los productos de la empresa, y estos productos trabajan protocolos definidos en
capas de transporte y aplicación, como los son los establecidos por IEC 61850, se debe
garantizar un desarrollo de alta calidad, con un servicio confiable, que no afecte el
desempeño de la comunicación y que sea de fácil uso para el usuario.
5.1 Puerto Virtual
El protocolo PRP debe ser transparente para las capas superiores, ellas no se deben
encargar del manejo de duplicados en la recepción, ni de añadir encabezados PRP en el
envío. Es por esto que las capas superiores deben tener acceso a un solo puerto de red, se
debe garantizar que la comunicación sea similar a una en la que no use el protocolo PRP,
las capas superiores no deben ni enviar ni recibir duplicados.
El puerto virtual, se comporta como el enlace entre las capas superiores y la LRE, la Figura
5 muestra la estructura de capas utilizada en la implementación del puerto virtual y la LRE
entre las capas superiores y las dos tarjetas de red.
Figura 5. Estructura implementada
5.2 Servicios de Windows
Los servicios de Microsoft Windows, antes conocidos como servicios NT, permiten crear
aplicaciones ejecutables de larga duración, que se ejecutan en sus propias sesiones de
Windows. Estos servicios pueden iniciarse automáticamente cuando el equipo arranca, se
pueden pausar y reiniciar, y no muestran ninguna interfaz de usuario. Estas características
hacen que los servicios resulten perfectos para ejecutarse en un servidor o donde se necesite
una funcionalidad de ejecución larga que no interfiera con los demás usuarios que trabajen
en el mismo equipo.
Debido a que el protocolo debe trabajar de forma adecuada para cualquier tipo de
comunicación Ethernet sin importar si el nodo a comunicar soporta o no PRP además de
estar en ejecución sin interrupciones, se realizó su implementación como un servicio de
Windows. Adicionalmente, se desarrolló un servicio de Windows de administración
adicional que se encargará de la supervisión y mantenimiento de servicio principal, este
servició es capaz de tomar decisiones frente a fallos en el servicio principal y su aplicación,
como lo son cierres y bloqueos inesperados. El servicio de supervisión está en la capacidad
de tomar decisiones de ejecución, detención y reinicio del servicio principal y la aplicación
en ejecución.
5.3 Interfaz Gráfica de Usuario
Para permitir al usuario el control sobre la aplicación, mediante la selección de adaptadores
de red utilizados para el protocolo, visualización de la tabla de nodos y del estado de
funcionamiento de la aplicación, se diseñó la siguiente interfaz gráfica de usuario. Esta
funciona de manera independiente a la aplicación y los servicios de Windows
desarrollados, ya que su enlace con el proceso es un archivo de configuración que
sobrescribe cada vez que el usuario realiza cambios.
Figura 6. Interfaz gráfica de usuario
6. PUEBAS REALIZADAS
Para verificar el funcionamiento del desarrollo realizado, y acercarlo a sus condiciones de
trabajo reales, se realizaron pruebas de desempeño simulando condiciones de alto flujo de
información, en dos redes LAN, estas pruebas permitieron la detección y corrección de
pequeños errores de implementación de código.
Para el desarrollo una de las pruebas de funcionalidad y rendimiento realizadas, se hizo uso
de los siguientes equipos:
4 PC Dell Inspiron 15 Series 5000
- Intel Core i5
- RAM de 8 GBytes
- Disco Duro de 1 TByte con 5400 rpm
- Sistema operativo Windows 8
Figura 7. PC Del Inspiron 15
Relé Siemens Siprotec 5 7SJ82
- Protección y automatización
- Phasor Measurement Unit (PMU)
- Sincronización de tiempo IEEE 1588
- 4 modulos de comunicación para protocolos de (IEC 61850, IEC 60870-5-
103, IEC 60870-5-104, Modbus TCP, DNP3 (serial and TCP)
- Sistema modular para ajuste de cantidad de I/O
-
Figura 8. Relé Siprotec5
Redbox Ruggedcom RS950G
- Manejo de HSR/ PRP
- 3 puertos configurables de fibra
- 2 puertos Ethernet para IEC62439
Figura 9. RedBoxRuggedcom Rs950G
Dos switch Ethernet TPLINK
- Usados como las dos redes LAN
Figura 10. Switch Ethernet
La topología de las dos redes LAN utilizadas para esta prueba se muestra en la Figura 11
Figura 11. Topología de red utilizada
Para tener un flujo alto de información y acercar la aplicación a las condiciones de trabajo
que enfrentará en la práctica, se realizaron tres tipos de conexiones a nivel de aplicación
usando cada uno de los nodos conectados a la red. A continuación se describe cada una de
las conexiones y los resultados obtenidos en la prueba para para cada tipo de conexión.
6.1 DANP a DANP
Para esta conexión se hizo uso de los equipos PC_PRP1 y PC_PRP2 mostrados en la
Figura12, en estos equipos está corriendo la aplicación desarrollada, por lo que tienen la
capacidad de comunicarse haciendo uso del protocolo PRP.
Para esta prueba se hizo uso del software IPERF, el cual permite establecer una conexión
TCP o UDP y mantener un flujo constante de información. En sus configuraciones, IPERF
permite modificar la velocidad de transmisión, el tiempo de duración de la prueba, la
longitud del datagrama, el tipo de protocolo a utilizar (TCP o UDP), además de entregar un
informe de los resultados de la prueba, con parámetros como latencia, cantidad de paquetes
perdidos, velocidad de transmisión, entre otros.
Los siguiente, son los resultados obtenidos de IPERF para una prueba de 13 HORAS a una
velocidad de 1.5 Mb/s
Figura 12. Resultados iperf DANP a DANP
6.2 DANP A SAN
Para esta conexión se hizo uso de los equipos PC_PRP1 y PC2, el equipo PC_PRP1 tiene la
aplicación en ejecución, por lo que puede comunicarse haciendo uso de PRP, pero el equipo
PC1 se comporta como un nodo SAN conectado a través de la LAN A.
Para esta prueba se hizo uso del software 61850 Relay Demo ejecutándose desde el lado del
PC1. Este software permite simular un Relé de protecciones capaz de comunicarse
haciendo uso del protocolo Goose. Demo Reley permite modificar periódicamente sus
valores de corriente de línea, generando y enviando reportes periódicos del estado de esta.
Del lado del PC_PRP1 se hizo uso del software AT61, este software de Axon Group es un
simulador de protocolo IEC61850, Este software permite cargar el CID, SCD, ICD u
obtener la configuración directamente del servidor IEC 61850, además permite el envío de
comandos, activación de reportes, interrogación general, reportes dinámicos, activación de
grupos de protección entre otras funciones.
Esta conexión DANP-SAN haciendo uso del Demo Relay y el AT61, estuvo corriendo
durante 72 horas haciendo uso de un protocolo orientado a la conexión y enviando reportes
periódicos. La prueba tuvo un resultado satisfactorio, ya que la conexión nunca se perdió y
los datos se transmitieron con éxito a lo largo de ella. La Figura 13 muestra la prueba
realizada.
Figura 13. Conexión DANP a SAN
6.3 DANP A SAN con RedBox
Para esta conexión se hizo uso de los equipos PC_PRP2 y PC1 mostrados en la Figura14,
en el equipo PC_PRP2 está en ejecución la aplicación desarrollada, mientras que el equipo
PC1 está conectado a ambas LAN a través del RedBox, por lo que ambos equipos tienen la
capacidad de comunicarse haciendo uso del protocolo PRP.
Para esta conexión se realizó una prueba similar a la efectuada en la conexión DANP a
DANP, haciendo uso de la herramienta IPERF. Los siguiente, son los resultados obtenidos
de IPERF para una prueba de 13 HORAS a una velocidad de 1.5 Mb/s.
Figura 14. Resultados iperf DANP a SAN
6.4 DANP a relé Siprotec 5
Para esta conexión se hizo uso de los equipos PC_PRP1 y relé Siprotec 5 mostrados en la
Figura 15, en el equipoPC_PRP1 está en ejecución la aplicación desarrollada, mientras que
el relé Siprotec 5 tiene en sus configuraciones habilitado el protocolo de redundancia
paralela, por lo que ambos equipos tienen la capacidad de comunicarse haciendo uso del
protocolo PRP.
Para esta última conexión se hizo una prueba similar a la realizada en la conexión DANP a
SAN, haciendo uso de la herramienta de simulación de protocolos AT61. El resultado de
esta prueba fue satisfactorio, debido a que la conexión siempre se mantuvo a lo largo de los
72 horas de duración, mientras el relé enviaba reportes periódicos del estado de sus
variables.
Figura 15. Conexión DANP a Relé
7. MEJORAS FUTURAS
Algoritmo de descarte
El algoritmo de descarte implementado en la aplicación desarrollada consistía en
aceptar tramas cuyo número de secuencia fuera superior al último número de
secuencia recibido por el nodo fuente, y descartar tramas cuyo número de secuencia
fuera inferior o igual a este. Aunque este algoritmo funciona de forma correcta, en
casos en los que las tramas llegan en desorden producen tramas perdidas, lo que lo
hace menos eficiente. Una solución planteada a futuro para este problema es la
implementación de un buffer que sea llenado con los últimos números de secuencia
recibidos, así se podría dar un mejor manejo a tramas que llegan en desorden,
comparando su número de secuencia con los últimos recibidos previo a tomar la
decisión de aceptar o descartar la trama.
Equipos Siemens
En las pruebas realizadas con equipos Siemens que dan soporte al protocolo de
redundancia paralela PRP como el relé Siprotec 5 y el RedBox Ruggedcom
RS950G, se encontró que implementan la norma IEC 62439-3 se realizó de forma
inadecuada, ya que en el envío de información sin importar el tipo de nodo del
destinatario, ya sea SAN o DANP añaden el encabezado RCT y envían por las dos
redes LAN. Debido a que el encabezado RCT se encuentra en la parte final de la
trama, los la mayoría de las aplicaciones en equipos que no soportan PRP pueden
recibir y entender la información que incluye encabezados PRP, por lo cual su
implementación sigue siendo funcional. Como hipótesis a esta implementación, se
plantea la reducción de tiempos de procesamiento sin afectar la funcionalidad de la
comunicación.
Norma
En la etapa de pruebas de desarrollo se encontró una debilidad del protocolo PRP no
tratada en la norma IEC 62439-3. Al momento de desconectar o reiniciar un nodo
DANP en una red, se debe esperar 2 minutos mientras todos los nodos DANP de la
red lo eliminan de su tabla de nodos, de lo contrario los nodos DANP tendrán en su
tabla de nodos guardado un último número de secuencia recibido mayor al que
tendrá al momento del reinicio el nodo, lo que producirá el descarte de todas las
tramas recibidas hasta que el número de secuencia enviado por el nodo reiniciado
sea mayor al último recibido.
8. BIBLIOGRAFÍA
[1] International Electrotecnical Comision: IEC-62439-3, 2011.
[2] Hubert Kirrmann ABB Switzerland Ltd, Corporate Research: Highly Available
Automation Networks Standard Redundancy Methods, 2012.
[3] Siemens: Round and round: the Media Redundancy Protocol, 2010.
[4] Cisco: Media Redundancy Protocol Configuration Guide for IE 2000, IE 4000, and IE
5000 Switches, 2016.
[5] Christoph Paassh IP Networking Lab Université Catholique de Louvain, FOSDEM
conference: MultiPath TCP Linux Kernel implementation, 2012.
[6] Eng. Shahar Fisher Siemens Israel: SICAM Substation Automation, 2012.
[7] Gunnar Prytz, Rahil Hussain ABB Corporate Research: Multipath Redundancy for
Industrial Networks using IEEE 802.1aq Shortest Path Bridging, 2014
[8] Claudia Carmona Rodríguez Universidad Pontificia Bolivariana: Software Defined
Networking for Electrical Substation based on IEC-61850, 2016.
[9] Siemens: Redundant networks for industry, Noviembre 2012.
[10] International Electrotecnical Comision: IEC-61850, 2007.