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.