Autorizada la entrega del proyecto del alumno. Javier Juárez Montojo EL DIRECTOR DEL PROYECTO. José Antonio Rodríguez Mondéjar

Transcripción

1 Autorizada la entrega del proyecto del alumno Javier Juárez Montojo. EL DIRECTOR DEL PROYECTO José Antonio Rodríguez Mondéjar Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos Álvaro Sánchez Miralles Fdo.: Fecha: / /

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL PROYECTO FIN DE CARRERA DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA AUTOR: JAVIER JUÁREZ MONTOJO MADRID, Junio de 2009

3 A mis padres y mi hermana por el apoyo incondicional que siempre me han mostrado. Gracias por todo.

4 I DISPOSITIVO DE CONTROL PARA REDES DE DISTRIBUCIÓN ELÉCTRICA Autor: Juárez Montojo, Javier. Director: Rodríguez Mondéjar, José Antonio. Entidad Colaboradora: ICAI-Universidad Pontificia Comillas RESUMEN DEL PROYECTO El objetivo del proyecto es desarrollar una librería para construir dispositivos de control y supervisión de elementos eléctricos mediante la aplicación de la norma IEC sobre un sistema de comunicaciones determinado mediante el uso exclusivo de recursos Open Source. Las subestaciones eléctricas, son sistemas complejos con gran variedad de dispositivos heterogéneos. La norma IEC busca conseguir la interoperabilidad entre los distintos equipos electrónicos inteligentes (IED, Intelligent Electronic Device) que forman parte del sistema de automatización de una subestación eléctrica (SAS, Substation Automation System). Se entiende por IED a todo dispositivo electrónico inteligente con uno o más microprocesadores con capacidad para intercambiar datos con una fuente externa. En general, la norma busca que IEDs de distintos fabricantes sean capaces de intercambiar procesos y datos entre ellos mediante la abstracción de la información necesaria, de manera que los niveles inferiores del sistema de comunicaciones sean transparentes. La norma posee una extensión de aproximadamente 1400 páginas, lo que hace que la implantación sea laboriosa. Ante esto, surge la necesidad de crear una serie de librerías y herramientas que faciliten su desarrollo. La norma define el modelo de datos y los servicios de manera abstracta, lo que hace necesario realizar un mapping a un sistema de comunicaciones concreto. Uno de los objetivos principales de este proyecto ha sido independizar el sistema de comunicaciones y la parte de protocolos, de las funciones propias del dispositivo. Con ello se consigue abaratar el desarrollo de dispositivos y aumentar la fiabilidad, al trabajar con un módulo independiente. En general utiliza distintos tipos de sistemas de comunicaciones según el tipo de mensajes que sea necesario intercambiar. En este proyecto, se ha realizado el desarrollo de la arquitectura de comunicaciones basada en el protocolo de comunicaciones MMS (Manufacturing

5 II Message Specification). Esta arquitectura está basada en el mecanismo Cliente/Servidor. El protocolo MMS se apoya sobre el modelo de comunicaciones OSI, cuya estructura está basada en siete niveles o capas. En la actualidad se utiliza TCP/IP como arquitectura de uso, de manera que es necesario que las capas superiores del modelo OSI, operen sobre TCP/IP. En la Figura 1 se muestra la pila de comunicaciones utilizada. Figura 1 Pila de comunicaciones empleada El conjunto de protocolos TCP/IP son parte del núcleo del sistema operativo, y se accede a él mediante una serie de funciones (BSD socket API). El resto de capas han tenido que ser implantadas en este proyecto, siguiendo los correspondientes estándares: 1- La capa RFC1006, que es una capa intermedia para la simulación de la capa de transporte OSI sobre TCP/IP. 2- La capa de transporte de OSI (ISO 8073). 3- La capa de sesión de OSI (ISO 8326, ISO 8327). 4- La capa de presentación de OSI (ISO 8823). Lenguaje ASN.1 (ISO 8825).

6 III 5- La capa de aplicación MMS (ISO 9506) y ACSE (ISO 8650) (para el control de la asociación). MMS propone unos objetos y servicios, que se adaptan perfectamente a la base del modelo IEC Los servicios MMS definen el formato, contenido y procedimiento de intercambio de mensajes entre dispositivos de control industrial heterogéneos. 6- ACSI de IEC El ACSI (Abstract Communication Service Interface) es la interfaz de comunicaciones donde la norma especifica los servicios abstractos de comunicación necesarios para el intercambio de datos en el modelo de información. Se han realizado múltiples pruebas de interoperatividad. Entre ellas, una con una protección de ABB basada en el estándar IEC con resultados de total interoperatividad. Como prueba de ello, en la Figura 2 se presenta uno de los mensajes intercambiados, concretamente la respuesta de la protección ante la petición del servicio Identify, en el que indica el nombre del fabricante, modelo y versión. Los mensajes han sido analizados mediante el programa Wireshark, que es un analizador de protocolos en redes de comunicaciones. Figura 2 Mensaje identify En esta figura pueden observarse los diferentes protocolos de comunicaciones implementados en el proyecto.

7 I CONTROL DEVICE FOR ELECTRICAL DISTRIBUTION NETWORKS Author: Juárez Montojo, Javier. Manager: Rodríguez Mondéjar, José Antonio. Collaborating entity: ICAI-Universidad Pontificia Comillas ABSTRACT The objective of this project is to develop a library to construct devices of control and supervision of electric devices by means of the application of the norm IEC on a communication system by means of the exclusive use of resources Open Source. The electrical substations are complex systems with a huge variety of different devices. The standard IEC search to obtain the interoperability between the different intelligent electronic devices (IED) that are part of the substation automation system (SAS). An IED is any device incorporating one or more processors with the capability to receive or send data from or to an external source. In general, the standard tries to assure that IEDs of different manufacturers are capable of exchanging processes and information through the abstraction of the necessary information, so that the low levels of the communication systems are transparent. The standard has an extension of approximately 1400 pages, which does that the implantation is laborious. Because of this, is necessary creating a series of tools that facilitate the development. The standard defines the model of information and services in an abstract way, which it makes necessary to create a mapping for a concrete system of communications. The first objective was to separate the communication systems and the protocols of the functions device. With it one manages to cheapen the development of devices and to increase the reliability on having worked with an independent module. In general, it uses different types of systems of communications according to the type of messages that it is necessary to exchange. In this project, it has been developed an architecture of communications based on the protocol of communications MMS (Manufacturing Message Specification). This architecture uses the client/server mechanism.

8 II The MMS protocol is based on the communication model OSI, whose structure is based on seven levels or layers. Currently, TCP/IP is the stack used, so that it is necessary that the high layers of OSI run on TCP/IP. The Figure 1 shows the protocol stack used in this project. Figura 1 Protocol stack The set of protocols TCP/IP are part of the core of the operating system, the access to it is through a series of functions (BSD socket API). The other layers have been implemented in this project, according the next standards: 1- RFC 1006 layer. It is an intermediate layer for the simulation of the transport layer OSI over TCP/IP. 2- Transport layer OSI (ISO 8073). 3- Session layer OSI (ISO 8326, ISO 8327). 4- Presentation layer OSI (ISO 8823). ASN.1 language (ISO 8825). 5- Application layer. MMS protocol (ISO 9506) and ACSE (ISO 8650) (Association Control Service Element). MMS propose a few objects and services which adapt perfectly to the base of the model IEC The MMS services

9 III define the format, content and procedure of exchange of messages between heterogeneous devices of industrial control. 6- ACSI (Abstract Communication Service Interface) layer of IEC The ACSI is where the standard defines the abstract services and the generic class. Multiple tests of interoperability have been realized. Between them, one with a protection of ABB based on the standard IEC with results of total interoperability. The Figure 2 shows an example of one of the interchanged messages, concretely the response before the request of the service Identify, in which it indicates the name of the vendor, model and revision. The messages have been analyzed with Wireshark, which is an analyzer of protocols in networks of communications. Figura 2 Identify message. In this figure can be observed the different protocols of communications implemented in the project.

10 Agradecimientos especiales Gracias a mi director de proyecto José Antonio Rodríguez Mondéjar por la confianza depositada en mí. A Iñigo Ramiro (IIT) por el apoyo dado. A Carolina Bachenheimer (ABB) por la ayuda prestada.

11 ESTE PROYECTO CONTIENE LOS SIGUIENTES DOCUMENTOS: DOCUMENTO Nº 1, MEMORIA (167 páginas.): 1.1 Pág. 6 a páginas. 1.2 Estudio de viabilidad. Pág. 105 a páginas. 1.3 Manual de utilización de la librería desarrollada. Pág. 129 a páginas. 1.4 Código Fuente. Pág. 146 a páginas. DOCUMENTO Nº 2, PRESUPUESTO (3 páginas.).

12 Documento I

13 Índice general Parte I... 5 Capítulo 1 Introducción Estudio del arte Motivación del proyecto Objetivos Metodología Recursos...11 Capítulo 2 Introducción a IEC Definiciones y abreviaciones Objetivo Partes de la normativa Conceptos básicos Modelo de información Modelo de servicios abstractos Relación entre las IEC , IEC y IEC Mapping a un sistema de comunicaciones determinado...30 Capítulo 3 Modelo de comunicaciones Pila de comunicaciones MMS sobre TCP/IP Capa física Ethernet IP TCP Capa de transporte OSI / RFC Descripción Implantación

14 8 Capa de sesión Descripción Implantación Capa de presentación Descripción Implantación Lenguaje ASN Reglas de codificación BER Ejemplo de uso del compilador ASN1C Capa de aplicación ACSE MMS Capítulo 4 Protocolo MMS Historia de MMS Modelo orientado a objetos Servicios Implantación...68 Capítulo 5 Implementación del ACSI de IEC Modelo de datos IEC Servicios abstractos del ACSI...80 Capítulo 6 IEC sobre MMS Capítulo 7 Resultados Establecimiento de la conexión Establecimiento de la asociación Transferencia de datos Cierre normal de la conexión...99 Capítulo 8 Conclusiones Capítulo 9 Futuros desarrollos Bibliografía

15 Parte II Estudio económico Capítulo 1 El software libre en las empresas Introducción El software libre y las fuerzas competitivas Análisis de costes La pequeña empresa y el software libre Las grandes empresas y el software libre El caso de Hewlett-Packard Linux vs Windows Grupos de presión sobre el software libre Conclusiones Parte III Manual de utilización de la librería desarrollada Capítulo 1 Introducción Capítulo 2 Interfaz de comunicaciones Capítulo 3 Funciones de ayuda Strings: To_bit_string: From_Octet_string: Capítulo 4 VariableAccessSpecification Capítulo 5 Cliente Parte IV Código fuente Capítulo 1 Introducción Capítulo 2 Interfaz de comunicaciones Capítulo 3 Funciones de ayuda Capítulo 4 VariableAccessSpecification Capítulo 5 Cliente

16 Parte I MEMORIA 5

17 Capítulo 1 INTRODUCCIÓN El objetivo del proyecto es desarrollar una librería para construir dispositivos de control y supervisión de elementos eléctricos mediante la aplicación de la norma IEC sobre un sistema de comunicaciones determinado mediante el uso exclusivo de recursos Open Source. Las subestaciones eléctricas, son sistemas complejos con gran variedad de dispositivos. La norma IEC busca conseguir la interoperabilidad entre los distintos equipos electrónicos inteligentes (IED, Intelligent Electronic Device) que forman parte del sistema de automatización de una subestación eléctrica (SAS, Substation Automation System). Se entiende por IED a todo dispositivo electrónico inteligente con uno o más microprocesadores con capacidad para intercambiar datos con una fuente externa. En general, la norma busca que IEDs de distintos fabricantes sean capaces de intercambiar procesos y datos entre ellos mediante la abstracción de la información necesaria de manera que los niveles inferiores del sistema de comunicaciones sean transparentes. Concretamente se encarga del modelado de los elementos dentro del sistema de automatización, para ello realiza una separación de la misma en distintos bloques eléctricos (bays) que se controlarán de manera conjunta según motivos de fabricación o de funcionalidad. La norma crea una virtualización de todos los elementos de la subestación, de manera que cada punto de acceso a la red se modelará como un equipo físico (Server), cada IED como un dispositivo lógico (LD) y cada elemento de la subestación como un nodo lógico (LN). Además, la norma especifica una interfaz de comunicaciones ACSI (Abstract Communication Service Interface) que define los servicios abstractos de comunicación necesarios para el intercambio de datos en el modelo de información. 6

18 Por otra parte, la naturaleza de este proyecto hace que sea necesaria la utilización de un completo lenguaje de programación orientado a objetos. El lenguaje elegido para este proyecto ha sido el lenguaje C++. En la parte IEC de la norma se especifican los sistemas de comunicaciones empleados. Este trabajo se centrará en el modelo Cliente/Servidor. En el que el mapping de la IEC a un sistema de comunicaciones determinado se realizará a nivel de aplicación mediante MMS (Manufacturing message specification). El mecanismo cliente/servidor, es aquel por el que un cliente accede a los datos de un servidor mediante petición de un servicio concreto. Este paso del modelo MMS a tramas de bits se hace en el nivel de presentación mediante el lenguaje ASN.1. Los servicios MMS definen el formato, contenido y procedimiento de intercambio de mensajes entre dispositivos de control industrial heterogéneos. Dado que el propio modelo de MMS se basa en objetos, resulta adecuado para ser utilizado en el diseño de sistemas de control de procesos orientados a objetos. Para MMS, cada dispositivo conectado a la red es visto como un dispositivo virtual, VMD (Virtual Manufacturing Device), ocultando sus particularidades y homogeneizando el acceso a los distintos recursos de cada dispositivo. MMS propone unos objetos y servicios, que se adaptan perfectamente a la base del modelo IEC El protocolo de comunicaciones MMS está basado en el modelo OSI (Open System Interconnection, estándar internacional ISO 7498). Su estructura está basada en siete niveles o capas. MMS es en definitiva un protocolo a nivel de aplicación dentro del modelo OSI que permite crear un modelo de información abstracto de 7

19 usuario de manera que se pueda convertir los mensajes en valores binarios, es decir, en tramas que se puedan transmitir a través de las capas inferiores de comunicaciones. El modelo OSI ha ido quedando relegado a un segundo plano de manera que únicamente suele usarse como modelo de referencia. En la actualidad el estándar de comunicaciones de uso es TCP/IP. Existen distintas técnicas para que aplicaciones OSI puedan operar sobre el medio TCP/IP. El método más ampliamente utilizado es descrito en RFC La parte IEC define la arquitectura de comunicaciones determinada. En cuanto a las estructura de este documento, primero se hará una introducción sobre la norma IEC (Capítulo 2), después se pasará a hablar sobre el modelo de comunicaciones y los distintos protocolos implementados en este proyecto (Capítulo 3); se tratará con mayor profundidad el protocolo de aplicación MMS (Manufacturing Message Specification) (Capítulo 4) y se hablará sobre el modelo de datos y servicios de la IEC (Capítulo 5). En el Capítulo 6, se explica la manera de mapear IEC sobre MMS, y por último se exponen los resultados (Capítulo 7), las conclusiones (Capítulo 8) y los futuros desarrollos (Capítulo 9). 1 Estudio del arte Existen multitud de protocolos para la automatización de subestaciones, que incluyen diversos protocolos propietarios, esto hace que conseguir la interoperabilidad entre dispositivos de distintos fabricantes sea complejo y laborioso. Ante este problema se creó el estándar IEC [1]. 8

20 El estándar IEC está considerado como una importante norma internacional para sistemas de automatización en subestaciones, mediante la cual, se pretende reducir notablemente los costes de ingeniería y configuración en la automatización de subestaciones eléctricas. Este estándar usa un modelo de comunicaciones basado en el protocolo Manufacturing Message Specification [2] [3]. Dicho protocolo fue creado en la década de los 80, siendo su última versión del año Existe una implementación de la arquitectura MAP y de un servidor MMS [23] desarrollado por la universidad EPFL de Laussane en lenguaje Ada de dominio público. 2 Motivación del proyecto La norma IEC consta de una serie de documentos con una extensión de alrededor de 1400 páginas. Este estándar es complejo y difícil de entender, por lo que frente a las ventajas que genera, su alta dificultad hace que el tiempo empleado en su implantación sea poco abordable. Por otra parte, aunque este estándar no especifica los servicios ACSI como una API (Application Programming Interface), se podría especificar así con el objetivo de que los diseñadores de las aplicaciones Cliente no necesiten preocuparse de qué pila de comunicaciones MMS que se usa. Ante esto, surge la necesidad de construir una librería para poder desarrollar dispositivos de control de forma eficiente. En la Figura 1 se muestra un ejemplo de la arquitectura empleada. 9

21 Figura 1 Ejemplo de mapping de comunicaciones [1] Hay que destacar por tanto, que el objetivo principal de este proyecto ha sido independizar el sistema de comunicaciones y la parte de protocolos, de las funciones propias del dispositivo. Con ello se consigue abaratar el desarrollo de dispositivos y aumentar la fiabilidad, al trabajar con un módulo independiente. 3 Objetivos -Implementación del ACSI (Abstract Communication Service Interface) de la norma IEC y mapping de estos servicios en un sistema de comunicación determinado. -Validar en dispositivos genéricos dicha funcionalidad. -Determinación de la capacidad de la red en velocidad y caudal de datos (Este objetivo se ha sustituido por el del análisis de los mensajes intercambiados con dispositivos bajo norma IEC 61850). -Guía útil para que la librería pueda ser aplicada por terceros. -Realizar el proyecto únicamente mediante el uso de recursos Open Source (software distribuido y desarrollado libremente). 10

22 -Objetivos adicionales: -Desarrollo de una herramienta para la configuración de dispositivos bajo norma IEC Metodología Trabajo realizado: -Lectura de las normativas IEC y de ISO 9506 (Manufacturing Message Specification). -Familiarización con los lenguajes de programación C, C++, y con el lenguaje ASN.1 (Abstract syntax notation n.1). -Familiarización con el sistema operativo Linux y sus herramientas de desarrollo. -Implementación del protocolo de aplicación MMS (basado en modelo OSI) sobre TCP/IP mediante norma RFC Implementación de la capa de sesión y presentación del modelo OSI. -Implementación de los servicios MMS. -Implementación del ACSI de la IEC Validar la librería en dispositivos genéricos Recursos El proyecto se realizará bajo sistema operativo Linux, de manera que se obtengan las ventajas del software libre. Los lenguajes de programación utilizados serán C y C++. La estructura de los mensajes de MMS se realizarán mediante lenguaje ASN.1 según viene especificados en el estándar ISO

23 (Industrial automation systems -- Manufacturing Message Specification -- Part 2: Protocol specification). Se usarán las reglas de codificación BER (Basic encode rules), definidas en el estándar ASN.1 para codificar la información abstracta en un flujo de bits único. Compiladores: Familia de compiladores GNU: Gcc (Compilador C) G++ (Compilador C++) Herramienta Make. Asn1c: Compilador de asn.1 (Abstract syntax notation n.1). Se encarga de convertir una especificación ASN.1 en estructuras de datos C/C++. También crea el código que permite la serialización y deserialización automática de estas estructuras usando las reglas BER. Wireshark: Analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones para desarrollo de software y protocolos. 12

24 Capítulo 2 INTRODUCCIÓN A IEC Definiciones y abreviaciones SAS: Sistema de automatización de una subestación eléctrica. ACSI: Abstract Communication Service Interface. Modelo de servicios abstractos de comunicación Bay: Bloques eléctricos en que puede separarse una subestación. IED: Equipos electrónicos inteligentes. Cualquier dispositivo con uno o más microprocesadores con capacidad para recibir o enviar datos. Logical Node: Unidades lógicas básicas que realizan una función que debe ejecutar el sistema. Data object (DO): Parte de un Logical Node que representa una información específica. Intercambiabilidad: Capacidad para cambiar un dispositivo de un fabricante por otro de un fabricante distinto. Interoperabilidad: Capacidad de dos o más IEDs de intercambiar información, sean o no del mismo fabricante. Protocolo: Conjunto de reglas que determinan el comportamiento y características de la comunicación. SCSM: Specific Communication Service Mapping. Proceso estándar que suministra un mapping concreto de los servicios y objetos del ACSI a una pila de comunicaciones concreta. 13

25 2 Objetivo La experiencia adquirida dentro de la industria ha demostrado la necesidad de utilizar potentes protocolos de comunicaciones que sean capaces de proveer interoperabilidad entre IEDs de distintos fabricantes. Se entiende por IED a todo dispositivo electrónico inteligente que forma parte del sistema de automatización de las subestaciones eléctricas. En este contexto, interoperabilidad se refiere a la capacidad para operar en la misma red, mediante el intercambio de datos y procesos por parte de dispositivos heterogéneos. Para ello, la norma trata, a lo largo de sus 10 partes, cuatro aspectos fundamentales: 1. Explica los requisitos de los sistemas de comunicaciones y de los equipos. 2. Establece un modelo de datos sólido. 3. Establece una serie de servicios de comunicación 4. Especifica un lenguaje descriptivo para la configuración de subestaciones basado en XML. 3 Partes de la normativa IEC : Introduction and overview. Se da una visión general de la norma y establece los conceptos básicos. IEC : Glossary. Conjunto de términos utilizados a lo largo de la norma. IEC : General requeriments. Requisitos de calidad, condiciones ambientales, servicios auxiliares y otras especificaciones. IEC : System and Project management. 14

26 Gestión de sistemas y proyectos. Requisitos de ingeniería, ciclo de vida de los sistemas y garantía de calidad. IEC : Communication requirements for functions and device models. Requisitos del sistema de comunicaciones y de los equipos. IEC : Substation automation system configuration language (SCL). Lenguaje basado en XML empleado para la configuración de IEDs. IEC : Basic communication structure. 7-1: Principles and models. Visión general de la parte : Abstract communication service interface (ACSI). Describe el ACSI. Especifica los servicios de comunicación abstractos. 7-3: Common data classes. Parte del modelo de información. 7-4: Compatible logical node classes and data classes. Parte del modelo de información. IEC : Specific communication service mapping (SCSM). Mapping del modelo de información y servicios de comunicación abstractos a un sistema de comunicaciones concreto. Mapping a MMS. IEC : Specific communication service mapping. Mapping del modelo de información y servicios de comunicación abstractos a un sistema de comunicaciones concreto. IEC : Conformance testing. Pruebas de validez. 15

27 4 Conceptos básicos Una subestación eléctrica puede ser definida como un nodo dentro de la red eléctrica usada para la transformación de la tensión. Suelen colocarse en las inmediaciones de las centrales eléctricas para elevar el voltaje en la salida de los generadores y en las cercanías de de los consumidores para bajarlo de nuevo. El elemento principal de la subestación es el transformador, aunque además contiene elementos de corte y protección. Para que un sistema de automatización de subestaciones eléctricas (SAS) sea eficiente es necesario definir un modelo de datos sólido y un sistema de comunicaciones concreto, de manera que se logre alcanzar la interoperabilidad entre los distintos elementos dentro de la subestación. El estándar IEC define la información necesaria para esto. Para ello utiliza el concepto de virtualización, de manera que todo elemento dentro de la subestación eléctrica va a ser modelado como un Logical Node (LN). Por ejemplo, la representación virtual de un interruptor con capacidad de corte en carga será un LN de la clase estandarizada XCBR. Varios LN constituyen un Logical Device (LD). Cada LD siempre es implementado dentro de un IED. 16

28 Figura 2: Modelo conceptual [1] En la Figura 2 puede observarse como los dispositivos reales son modelados como diferentes LN que forman un LD. Este LD puede ser una representación de una bahía dentro de la subestación. El concepto de bahía viene a ser una separación que se hace de los elementos de la subestación en distintos bloques eléctricos, principalmente por motivos de funcionalidad o relacionados con su fabricación, pero que se controlan de manera conjunta. En el ejemplo, el LN XCBR contiene a su vez una serie de datos (Position, Mode ), que a su vez contendrán una serie de atributos. Los datos contienen una estructura y semántica completamente conocida dentro del contexto del SAS. La información representada por estos datos y sus atributos serán intercambiados por una serie de servicios definidos en el ACSI (IEC ). Este modelo de datos y servicios, son definidos de manera abstracta lo que independiza los objetos del sistema de comunicaciones 17

29 determinado. Esto hace que sea necesario el mapping de estos datos y servicios a un sistema de comunicaciones concreto. No obstante esta naturaleza abstracta permite el mapping a cualquier protocolo de comunicaciones. Actualmente la norma sólo especifica este mapping sobre una pila de comunicaciones que incluye el protocolo Manufacturing Message Specification (MMS) sobre TCP/IP y ethernet. Resumiendo, el estándar IEC establecerá: Funciones e información que son visibles dentro de la red. Cómo es nombrada y cómo es descrita (IEC , IEC y IEC ). Cómo puede accederse a esta información y cómo puede ser intercambiada (IEC ). Cómo se conectan los dispositivos a la red de comunicaciones (IEC x y IEC x). Todos estos elementos dentro de la subestación deben ser configurados. Esta configuración contiene la descripción de los distintos objetos y la relación entre ellos. La parte IEC especifica la descripción de un lenguaje para la configuración de los IEDs en subestaciones eléctricas. Este lenguaje es denominado Substation configuration description language (SCL). 5 Modelo de información En la Figura 3 se muestra un ejemplo de cómo diferentes LNs forman distintos IEDs. 18

30 Figura 3 Ejemplo de composición de diferentes IEDs [1] Los LNs que aquí se muestran son PTOC (Protección de sobreintensidad), PDIS (Protección de distancia), PTRC (Trip Conditioning) y XCBR (Interruptor). En el caso de la izquierda, todos los LNs se encuentran en un mismo IED que se conecta directamente al interruptor. No hay bus de campo en el proceso. En el caso del centro, los nodos lógicos PTOC, PDIS y PTRC se alojan en un mismo IED que se conecta al bus de campo. El LN XCBR se encuentra en otro dispositivo que se conecta al interruptor. Por último, en el caso de la derecha, existe un dispositivo que contiene la funcionalidad de sobreintensidad, otro que contiene la de distancia y otro donde se alojó el XCBR. El conjunto de LNs (unos 91) vienen definidos en la parte IEC En ella se hace una clasificación según se muestra en la Tabla 1. 19

31 Tabla 1 Grupos de LNs [1] Cada LN está a su vez formado por distintos datos que a su vez contienen diferentes atributos. En la Figura 4 se muestra un ejemplo de la estructura del LN XCBR. 20

32 Figura 4 Información contenida en un LN XCBR [1] El objeto XCBR1 del tipo LN XCBR contiene una serie de datos (Pos, Mode ). El significado de estos datos viene definido en la parte IEC , así por ejemplo, el dato Pos indica el estado o posición del interruptor. El contenido de estos datos, esta formado por una serie de atributos que están contenidos y definidos en lo que se conoce como Common Data Class (CDC). Un CDC es una agrupación de distintos atributos de manera que se crean clases genéricas de datos (datos referidos como atributos) que se repetirán en los distintos datos definidos en la IEC Estos CDC vienen establecidos en la parte IEC Así, el dato Pos es del tipo DPC (double point control) que contiene una serie de atributos como 21

33 ctlval, opertim Cada CDC contiene atributos de uso obligatorio y otros de uso opcional, lo que hace que para cada tipo de dato existan atributos del CDC que no sean necesarios. Es importante fijarse en que los atributos definidos están agrupados según su Functional Constraint (FC), así habrá atributos de Control (CO), Status (ST), Substitution (SV) Extendiendo este modelo a lo representado en la Figura 3 se obtendría un modelo de información como se representa en la Figura 5. Figura 5 Ejemplo de modelado [1] Este ejemplo muestra claramente el concepto de virtualización que utiliza la norma. De esta manera se consigue definir qué elementos serán visibles dentro de la red, cómo son nombrados y cómo son descritos. El primer paso dentro de esta virtualización sería modelar cada LN según el modelo establecido en IEC e IEC

34 El siguiente paso sería el modelado del Logical Device (LD). Un LD representa una serie de funciones, cada una de ellas representadas por un LN. Es decir cada LD representa a cada IED. Todo LD debe contener al menos dos LNs. LLN0: Nodo lógico que contiene toda la información común al LD. LPHD: Nodo lógico que contiene la información acerca del equipo físico original del LD. Por último se va a introducir el concepto de equipo físico (Server). Un Server representa un punto de acceso a la red. Es decir, si un único IED se conecta directamente a la red, al Server le corresponderá un único LD que represente al IED, pero por el contrario, si varios IEDs comparten el mismo punto de acceso a la red, el Server contendrá a los diferentes LDs. En resumen, la norma establece un modelo orientado a objetos para la virtualización de la realidad. Usando el tipo de notación UML (Unified Modeling Language), se muestra, en la Figura 6, un ejemplo de este modelo. Así, la clase Server contendrá de 1 a n LDs, cada LD contendrá varios LNs, que a su vez contendrán diferentes datos con sus correspondientes atributos. 23

35 Figura 6 Ejemplo del modelo de datos abstractos [1] 6 Modelo de servicios abstractos En la parte IEC , se definen una serie de servicios cuyo objetivo es acceder e intercambiar la información dentro del modelo anteriormente explicado. Los servicios son definidos usando una técnica orientada a objetos. Estos servicios son abstractos, es decir, su definición está centrada en la descripción de la función de los servicios. Esto hace necesario realizar un mapping a un sistema de comunicación determinado para crear mensajes concretos. Estos mensajes están especificados en la parte IEC x e IEC x. Estos servicios están definidos en lo que se conoce como ACSI (Abstract communication Service Interface). Existen dos grandes grupos de servicios de comunicaciones, un grupo usa el mecanismo Cliente/Servidor mediante servicios como control o lectura de datos, mientras que el otro, utiliza un modelo punto a punto con los GSE 24

36 servicios (usado para tareas con tiempo crítico) y con los Sampled Values Services para transmisiones periódicas. En la Figura 7 se muestran los distintos mecanismos anteriormente expuestos. Figura 7 Métodos de comunicación ACSI [1] Como ya se ha comentado, los datos y dispositivos reales son modelados mediante una representación virtual. Esta imagen virtual será accesible a través de los servicios ACSI. Un ordenador debe pedir un servicio y debe recibir la respuesta del dispositivo. El modelo Cliente/Servidor: En una arquitectura Cliente/Servidor, los clientes realizan peticiones de servicio y reciben confirmaciones de estos servicios procesados en el servidor. En la Figura 8 se muestra este mecanismo. 25

37 Figura 8 Cliente/Servidor [1] La norma IEC define únicamente el comportamiento del servidor, es decir, los objetos que contiene (LNs, data ) y las peticiones de servicios intercambiados. El rol del cliente es complementario, aunque su estructura interna y funciones no están definidas en el estándar. El servidor, por tanto, es la clave del modelo establecido. En la Figura 9 se muestra la jerarquía de componentes dentro de la estructura definida por la norma. Los dispositivos que cumplen con la normativa IEC deben ser visibles a cualquier otro dispositivo conectado a la red cumpliendo la interoperabilidad entre ellos. Todo lo que no sea modelado como servicio, logical device, logical node, data, data attribute no debe ser visible dentro de la red. 26

38 Figura 9 Jerarquía de los componentes. [1] Generic Substation Event (GSE): Es el servicio que permite la comunicación de eventos genéricos de la subestación a varios dispositivos IEDs dentro del sistema, de manera simultánea, rápida y segura. Está relacionado con acciones automáticas que requieran el intercambio de información con una importante restricción temporal. Para poder proporcionar este servicio la norma establece dos bloques de control. El GoCB, que permite el envío de mensajes tipo GOOSE, basado en un mecanismo Publicador/abonado, y el GsCB, que permite el envío de mensajes GSSE, de características similares al GoCB pero con tratamiento de distinto tipo de información. Transmission of sampled values (TSV): Es el servicio que permite la transmisión de valores instantáneos de medidas analógicas, minimizando el tiempo que transcurre desde el muestreo hasta la recepción del mensaje. 27

39 7 Relación entre las IEC , IEC y IEC Ya se ha explicado de manera conceptual las diferentes partes que contienen la norma, ahora se procederá a la relación entre las partes IEC , IEC , IEC , desde un punto de vista de los conceptos de programación orientada a objetos que utiliza la norma. Recapitulando un poco, todo lo que hay dentro de una subestación eléctrica va a ser modelada mediante Nodos lógicos. Cada LN puede ser visto como un objeto con atributos y operaciones. Cada objeto es un elemento de una determinada clase que describe las propiedades y el comportamiento del objeto. Por lo tanto, para cada tipo de objeto es necesario definir un modelo de clase. En la parte IEC se describe la definición general del modelo de clases. En la parte IEC se describen unas especializaciones de la clase LOGICAL-NODE. En la parte IEC se especifican una serie de clases genéricas de datos que van a tener una serie de atributos perfectamente definidos. En la Figura 10 se representa este concepto, por el cual, el modelo de información que se obtiene y a la que se tiene acceso mediante una serie de servicios determinados (7-2), es un modelo jerarquizado en el que cada LN (7-4) tiene unos datos formados por una serie de atributos (7-3). 28

40 Figura 10 Relación entre las diferentes partes [1] Como ejemplo, en la Figura 11 se muestran dos LN definidos en la parte IEC , XCBR y XDIS, cada LN contiene una serie de datos, uno de ellos (pos) del tipo DPC definido en IEC En la parte de abajo de la Figura 11 se muestra un objeto (XCBR1) de la clase XCBR al que se puede acceder mediante una serie de servicios definidos en IEC

41 Figura 11 Ejemplo de la relación entre las distintas partes de la norma [1] 8 Mapping a un sistema de comunicaciones determinado Como ya se ha comentado, el modelo anterior es definido de manera abstracta, por lo que será necesario realizar un mapping a un sistema de comunicaciones determinado. Dicho mapping viene especificado en las partes IEC x e IEC x. El ACSI no especifica mensajes concretos, es decir no contiene los mensajes codificados que contienen los parámetros de los servicios. En la Figura 12 se muestra los diferentes mapping definidos en la norma. 30

42 Figura 12 ACSI mappings [1] Todos los servicios, menos los GOOSE y TSV son mapeados sobre MMS (Manufacturing Message Specification), TCP/IP y ethernet. Este SCSM (Specific communication service mapping) define como se implementan los distintos servicios y objetos sobre una pila de comunicaciones determinada. La interoperabilidad que busca la norma hace necesario que todos los dispositivos usen la misma pila; aún así, la naturaleza abstracta del modelo propuesto, hace que este se pueda adaptar según vayan evolucionando las tecnologías de comunicación. En la Figura 13 se muestra un ejemplo del mapping de los servicios ACSI sobre MMS. Figura 13 Mapping a MMS [1] 31

43 Capítulo 3 MODELO DE COMUNICACIONES 1 Pila de comunicaciones En este apartado se va a tratar sobre la pila de comunicaciones que estable la norma en la parte IEC Para ello, primero establece el tipo de mensajes que van a ser intercambiados: Tipo 1: Fast Messages. Tipo 1A: Trip. Tipo 2: Médium speed messages. Tipo 3: Low speed messages. Tipo 4: Raw data messages. Tipo 5: File transfer functions. Tipo 6: Time synchronisation messages Los mensajes tipo 1 y 1A son mapeados sobre distintos Ethertype para optimizar la decodificación de los mensajes recibidos. Los mensajes del tipo 2, 3 y 5 requieren servicios orientados a la conexión. El estándar MMS (Manufacturing Message Specification) suministra el modelo de información y los servicios requeridos por el ACSI. 32

44 Estos mensajes son mapeados como se muestra en la Figura 14. Figura 14 Perfil de las comunicaciones [1] En este proyecto se va a desarrollar únicamente la arquitectura necesaria para el intercambio de los mensajes 2, 3 y 5. Estos mensajes son los definidos dentro del ACSI especificado en la parte IEC Por lo tanto, a partir de aquí, únicamente se tratará la pila de comunicaciones de la arquitectura Cliente/Servidor, es decir la pila basada en el protocolo de aplicación MMS (Manufacturing Message Specification). El protocolo de comunicaciones MMS está apoyado sobre el modelo OSI (Open System Interconnection, estándar internacional ISO 7498). Su estructura está basada en siete niveles o capas. Este modelo se definió antes de implementar los protocolos, por lo que su utilización ha quedado determinada por su uso como modelo. En la actualidad se utiliza el modelo TCP/IP como arquitectura de uso. En la Figura 15 se muestran las diferentes capas del modelo OSI. 33

45 Figura 15 Modelo OSI [1] Por lo mencionado anteriormente, en la práctica, el protocolo MMS operará sobre TCP/IP. Los requerimientos básicos de MMS, canal de comunicación fiable y full duplex entre otros, son cubiertos por TCP/IP. Existen distintas técnicas para que aplicaciones OSI puedan operar sobre el medio TCP/IP. El método utilizado más ampliamente es descrito en RFC 1006, que se describirá en los siguientes apartados. Concretando la pila de comunicaciones a la arquitectura Cliente/Servidor seguida en este proyecto, el A-Profile (Especificación de las tres capas superiores del modelo OSI) se muestra en la Figura 16. Figura 16 A-Profile [1] 34

46 En cuanto al T-Profile (Especificación de las cuatro capas inferiores del modelo OSI), existen varias combinaciones posibles como se mostró en la Figura 14. En la arquitectura Cliente/Servidor en concreto, existen dos T-Profiles que pueden ser usados por el A-Profile descrito en la Figura 16, estos son: TCP/IP u OSI. El uso de TCP/IP como estándar de hecho, hace que en este proyecto se utilice el TCP/IP T-Profile que se muestra en la Figura 17. Figura 17 TCP/IP T-Profile [1] En los siguientes apartados se hablará sobre las distintas capas de la arquitectura empleada. 35

47 2 MMS sobre TCP/IP MMS forma parte de la arquitectura MAP, basada en el modelo de referencia OSI. En la Figura 18 se muestra esta arquitectura. Figura 18 Arquitectura MAP [15] La mayoría de las aplicaciones implementadas en el modelo OSI, pueden operar en el medio TCP/IP. Por encima de la capa de transporte, las funcionalidades de la pila TCP/IP son equivalentes a las de la pila MAP. La única diferencia es que para implementar MMS sobre TCP/IP, una capa intermedia de comunicación, debe ser especificada. 36

48 En general, las posibles implementaciones de MMS son las mostradas en la Figura 19: Figura 19 Diferentes pilas para MMS [16] a) Arquitectura MAP. b) Solución usando RFC 1006 (ISO transport services on top of the TCP. Versión 3) para emular los servicios OSI sobre TCP/IP. c) Solución poco realista de implementar todos los servicios sobre sockets TCP/IP d) Solución usando RPC. e) Solución trasladando las especificaciones de MMS PDUs de ASN1 a CORBA IDL. En diversos estudios ha quedado demostrada la funcionalidad de MMS sobre RPC, no obstante, la dificultad de trasladar las MMS ASN1 PDUs a estructuras de datos de RPC hace que se desestime esta opción, aunque a priori aseguraría una transferencia de datos fiable. 37

49 Por otra parte, el método más usado y el que establece el estándar IEC para que las aplicaciones OSI operen en un medio TCP/IP es descrito en RCF Este método propone una implementación completa de las capas de sesión, presentación y ACSE sobre TCP/IP. En la Figura 20 se muestra la pila completa utilizada. Figura 20 Pila de comunicaciones 38

50 En general, cada capa proporciona servicios a la capa que está encima de ella. Un servicio es un conjunto de operaciones que ofrece cada capa, viene a ser lo que se hace en cada capa. 3 Capa física Se encarga de la transmisión de cadenas de bits sobre el medio físico. Especifica las características del medio de transmisión, la naturaleza de las señales, la velocidad de datos y cuestiones afines. 4 Ethernet Cualquier sistema Ethernet consta de tres elementos básicos: El medio físico: o Tipo eléctrico (Cable coaxial o par trenzado). o Tipo óptico (fibra óptica). Reglas de control de acceso al medio (MAC). Trama Ethernet El control de acceso al medio empleado en Ethernet es el CSMA/CD: 1. La estación transmite si el medio está libre. 2. Si el medio está ocupado, la estación continua escuchando hasta que encuentra libre el canal, en cuyo caso transmite inmediatamente. 3. Si dos estaciones intentan transmitir a la vez sus señales, colisionan. Se les notifica (mediante una señal corta de alerta) a las estaciones y estas vuelven a planificar sus transiciones. 4. Eligen un intervalo de tiempo aleatorio y vuelven a intentarlo (Repetidas colisiones, indican red ocupada). Ethernet es actualmente el principal protocolo a nivel de enlace. 39

51 5 IP El protocolo de Internet (IP) es parte del conjunto de protocolos TCP/IP. Se especifica, como cualquier protocolo estándar, en dos partes. La interfaz con la capa superior El formato real del protocolo y los mecanismos asociados. Se utiliza para ofrecer el servicio de encaminamiento a través de varias redes. Se implementa tanto en sistemas finales, como en routers intermedios. Un router es un dispositivo con capacidad de procesamiento, que conecta dos redes y cuya función principal es retransmitir datos desde una red a otra siguiendo la ruta adecuada para alcanzar el destino. Se añade una cabecera de información de control a cada segmento, para formar un datagrama IP. En la cabecera IP, además de otros campos, se incluirá la dirección del computador destino. (La capa de enlace de datos tiene la dirección de la red de destino). Funcionamiento de la capa de acceso al medio y de IP: En la capa IP se añade la cabecera con la dirección del computador destino entre otros. En la capa MAC se añade la cabecera con la dirección de la red destino entre otros. (Dirección del router). El paquete llega al router, que elimina la cabecera del paquete, y examina la cabecera IP. Añade al datagrama una cabecera de acceso a la red direccionando el paquete. 6 TCP Es el protocolo de control de la transmisión orientado a conexión. Está diseñado para proporcionar una conexión segura entre procesos. Independientemente de la naturaleza de las aplicaciones que intercambian datos, es usual requerir que los datos se intercambien de 40

52 forma segura. Es decir, que todos los datos lleguen a la aplicación destino, en el mismo orden en que fueron enviados. La capa de aplicación genera un bloque de datos y los envía a la capa TCP. Esta capa puede que lo divida en fragmentos más pequeños para hacerlos más manejables. A cada fragmento se le añade una cabecera formando un segmento TCP. La cabecera incluye, entre otros, el puerto destino. Normalmente, el protocolo IP y el resto de protocolos dependientes de la red, forman parte del núcleo del sistema operativo (Aquella parte del sistema operativo que interactúa de forma directa con el hardware de una máquina), mientras que los protocolos de aplicación se implementan como procesos separados. TCP está implementado para ejecutarse, bien dentro del núcleo, como un programa separado o bien como un paquete de librería (Trozos de código que contienen alguna funcionalidad preconstruida que puede ser utilizada por un ejecutable) enlazado con el programa de aplicación. En la cabecera de cada PDU se debe incluir un campo, que permita identificar al protocolo de aplicación al que pertenecen los contenidos de dicha PDU. Esta función se realiza mediante los números de puerto fuente y destino. En general la cabecera TCP se compone de los siguientes campos: Un número de puerto de origen (2 bytes). Un número de puerto destino (2 bytes). Un número de secuencia (4 bytes). Un número de acuse de recibo (4 bytes). Tamaño de la cabecera (4 bits). Campo reservado (6 bits). Indicador (6 bits). 41

53 Tamaño de ventana (2 bytes). Suma de comprobación (2 bytes). Puntero de datos urgentes (2 bytes). Opciones. Normalmente la cabecera es de 20 bytes, usando las opciones al principio de la conexión TCP. En cuanto al campo de los indicadores (6 bits), se tienen los indicadores de 1 bit siguientes: URG: Contiene datos urgentes. ACK: Acuse de recibo válido. PUSH: Se solicita una manipulación más rápida del paquete. RST: Se solicita una finalización porque el proceso local se está cerrando. SYN: Establece el número de secuencia inicial del host. Se establece sólo durante el comienzo de la asociación. FIN: Se solicita el cierre de la conexión de manera normal. Los PDUs asociados a cada protocolo de aplicación, tienen una estructura definida, esta es transparente al protocolo TCP, que las tratan como un flujo de bytes. Las primitivas del protocolo TCP, son un conjunto de llamadas al sistema operativo que constituyen una API. La forma en que una aplicación se identifica con el protocolo de transporte y viceversa es a través de un número denominado puerto. Con 42

54 un puerto se identifica una aplicación dentro de un conmutador de forma precisa. Con un socket es posible identificar una aplicación dentro de toda la red. Esto es posible, identificando además del puerto, la dirección IP del ordenador. Se tiene así una terna denominada socket, de la forma: (Dirección IP, Protocolo de transporte, Puerto) En Unix, un archivo está identificado en cada proceso a través de un número que se denomina descriptor de archivo. La API del sistema de archivo define funciones que utilizan a ese descriptor para acceder al archivo y realizar las operaciones correspondientes. Este concepto se puede extrapolar a un socket. De forma que se asocia un descriptor con una aplicación especifica en la red. Los sockets se crean y se utilizan mediante una serie de funciones que forman un API (application program interface). 7 Capa de transporte OSI / RFC Descripción. Esta capa del modelo OSI es descrita en el estándar ISO Se encarga de asegurar la completa y correcta transferencia de datos. Hay cinco protocolos de transporte definidos en OSI (TP0, TP1, TP2, TP3, TP4). En comparación con TCP el protocolo que es similar en cuanto a sus características, es el TP4 (También puede ser referido como COTP). Una diferencia fundamental entre TP4 y TCP es que TP4 usa diez TPDUs (transport protocol data units) diferentes, mientras que TCP sólo usa uno. Esto hace que TCP sea mucho más sencillo, aunque su cabecera sea mucho más compleja (la cabecera TCP tiene al menos 20 bytes, 43

55 mientras que TP4, 5 bytes). Dentro de TP4 se usa la TSAP, que es similar al concepto de puerto en TCP. El método descrito en RFC 1006 suministra una completa implementación de las capas superiores del modelo OSI sobre TCP/IP. A continuación se explicará brevemente este método en el que se simula el protocolo TP4, mediante el establecimiento de un mapping entre las primitivas TCP y las esperadas por TP0 (Transport protocol class 0). RFC 1006: El puerto 102 de TCP se reserva para usuarios que implementen este método. Esta norma, permite una convergencia y estrategia de transición entre las redes basadas en TCP/IP y las redes basadas en OSI. Existen dos aproximaciones para llevar esto a cabo. Una es transportar cada aplicación por separado y otra es realizar la implementación basándose en que TCP/IP y OSI están ambos diseñados por capas. Se usará la independencia de capas para definir un TSAP (Transport service access point) que aparente ser idéntico a los servicios e interfaces ofrecidas por el ISO TSAP, pero en realidad se implementará el protocolo ISO TP0 en lo alto de TCP/IP. Esto hace que se logre la misma funcionalidad que TP4. De esta manera, las capas superiores de OSI, pueden operar completamente sin saber que están en una red TCP/IP. En cuanto a los protocolos de transporte del modelo OSI, a continuación se muestran algunas de sus características: TP0: Contempla un número de funciones mínimas. No hace otra cosa que segmentación y reensamblado. 44