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
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO INDUSTRIAL
PROYECTO FIN DE CARRERA
DISPOSITIVO DE CONTROL PARA
REDES DE DISTRIBUCIÓN
ELÉCTRICA
A mis padres y mi hermana por el apoyo incondicional que siempre me han mostrado. Gracias por todo.
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 61850 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 61850 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.
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).
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 61850. Los servicios MMS definen el formato, contenido y procedimiento de intercambio de mensajes entre dispositivos de control industrial heterogéneos.
6- ACSI de IEC 61850. 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 61850 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.
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 61850 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 61850 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.
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 isthrough 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).
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 61850. 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 61850 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.
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.
ESTE PROYECTO CONTIENE LOS SIGUIENTES
DOCUMENTOS:
DOCUMENTO Nº 1, MEMORIA (167 páginas.):
1.1 Memoria Pág. 6 a 104. 99 páginas. 1.2 Estudio de viabilidad. Pág. 105 a 128. 24 páginas. 1.3 Manual de utilización de
la librería desarrollada. Pág. 129 a 145. 16 páginas. 1.4 Código Fuente. Pág. 146 a 167. 22 páginas.
Índice general
Parte I Memoria... 5
Capítulo 1 Introducción... 6
1 Estudio del arte...8
2 Motivación del proyecto...9
3 Objetivos ...10
4 Metodología...11
5 Recursos...11
Capítulo 2 Introducción a IEC 61850... 13
1 Definiciones y abreviaciones ...13
2 Objetivo...14
3 Partes de la normativa...14
4 Conceptos básicos...16
5 Modelo de información ...18
6 Modelo de servicios abstractos ...24
7 Relación entre las IEC 61850-7-2, IEC 61850-7-3 y IEC 61850-7-4 ...28
8 Mapping a un sistema de comunicaciones determinado ...30
Capítulo 3 Modelo de comunicaciones ... 32
1 Pila de comunicaciones...32 2 MMS sobre TCP/IP...36 3 Capa física ...39 4 Ethernet...39 5 IP ...40 6 TCP ...40
7 Capa de transporte OSI / RFC 1006 ...43
7.1 Descripción... 43
8 Capa de sesión...47 8.1 Descripción... 47 8.2 Implantación. ... 47 9 Capa de presentación ...48 9.1 Descripción... 48 9.2 Implantación ... 48 9.3 Lenguaje ASN1. ... 49
9.4 Reglas de codificación BER. ... 50
9.5 Ejemplo de uso del compilador ASN1C... 50
10 Capa de aplicación...57
10.1 ACSE ... 57
10.2 MMS ... 58
Capítulo 4 Protocolo MMS ... 61
1 Historia de MMS ...62
2 Modelo orientado a objetos ...62
3 Servicios ...66
4 Implantación...68
Capítulo 5 Implementación del ACSI de IEC 61850 ... 73
1 Modelo de datos IEC 61850...75
2 Servicios abstractos del ACSI...80
Capítulo 6 IEC 61850 sobre MMS... 83
Capítulo 7 Resultados ... 91
1 Establecimiento de la conexión...91
2 Establecimiento de la asociación. ...94
3 Transferencia de datos...96
4 Cierre normal de la conexión...99
Parte II Estudio económico... 104
Capítulo 1 El software libre en las empresas ... 106
1 Introducción...106
2 El software libre y las fuerzas competitivas ...108
3 Análisis de costes...113
4 La pequeña empresa y el software libre...115
5 Las grandes empresas y el software libre...118
6 El caso de Hewlett-Packard...121
7 Linux vs Windows ...122
8 Grupos de presión sobre el software libre...126
9 Conclusiones...126
Parte III Manual de utilización de la librería desarrollada ... 128
Capítulo 1 Introducción... 129
Capítulo 2 Interfaz de comunicaciones ... 130
Capítulo 3 Funciones de ayuda ... 133
1 Strings: ...133
2 To_bit_string:...134
3 From_Octet_string: ...136
Capítulo 4 VariableAccessSpecification ... 138
Capítulo 5 Cliente... 141
Parte IV Código fuente ... 145
Capítulo 1 Introducción... 146
Capítulo 2 Interfaz de comunicaciones ... 147
Capítulo 3 Funciones de ayuda ... 148
Capítulo 4 VariableAccessSpecification ... 153
Capítulo 1 I
NTRODUCCIÓ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 61850 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 61850 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.
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 61850-8 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 61850 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 61850.
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.
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 1006.
La parte IEC 61850-8-1 define la arquitectura de comunicaciones determinada.
En cuanto a las estructura de este documento, primero se hará una introducción sobre la norma IEC 61850 (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 61850 (Capítulo 5). En el Capítulo 6, se explica la manera de mapear IEC 61850 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 61850 [1].
El estándar IEC 61850 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 2003.
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 61850 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.
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 61850 y mapping de estos servicios en un sistema de comunicación determinado.
-Validar en dispositivos genéricos 61850 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).
-Objetivos adicionales:
-Desarrollo de una herramienta para la configuración de dispositivos bajo norma IEC 61850.
4 Metodología
Trabajo realizado:-Lectura de las normativas IEC 61850 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 RFC1006.
-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 61850.
-Validar la librería en dispositivos genéricos 61850.
5 Recursos
El proyecto se realizará bajo sistema operativo Linux, de manera que se obtengan las ventajas del software libre.
(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.
Capítulo 2
I
NTRODUCCIÓN A
IEC
61850
1 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
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 61850-1: Introduction and overview.
Se da una visión general de la norma y establece los conceptos básicos.
IEC 61850-2: Glossary.
Conjunto de términos utilizados a lo largo de la norma.
IEC 61850-3: General requeriments.
Requisitos de calidad, condiciones ambientales, servicios auxiliares y otras especificaciones.
Gestión de sistemas y proyectos. Requisitos de ingeniería, ciclo de vida de los sistemas y garantía de calidad.
IEC 61850-5: Communication requirements for functions and device models.
Requisitos del sistema de comunicaciones y de los equipos.
IEC 61850-6: Substation automation system configuration language (SCL).
Lenguaje basado en XML empleado para la configuración de IEDs.
IEC 61850-7: Basic communication structure.
7-1: Principles and models. Visión general de la parte 7. 7-2: 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 61850-8: 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 61850-9: Specific communication service mapping.
Mapping del modelo de información y servicios de comunicación abstractos a un sistema de comunicaciones concreto.
IEC 61850-10: Conformance testing.
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 61850 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.
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 61850-7-2).
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 61850 establecerá:
• Funciones e información que son visibles dentro de la red. Cómo es nombrada y cómo es descrita (IEC 61850-7-2, IEC 61850-7-3 y IEC 61850-7-4).
• Cómo puede accederse a esta información y cómo puede ser intercambiada (IEC 61850-7-2).
• Cómo se conectan los dispositivos a la red de comunicaciones (IEC 61850-7-8-x y IEC 61850-7-9-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 61850-6 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.
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 61850-7-4. En ella se hace una clasificación según se muestra en la Tabla 1.
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.
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 61850-7-4, 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 61850-7-4. Estos
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 61850-7-4 e IEC 61850-7-3.
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.
Figura 6 Ejemplo del modelo de datos abstractos [1]
6 Modelo de servicios abstractos
En la parte IEC 61850-7-2, 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 61850-8-x e IEC 61850-9-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
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:
Figura 8 Cliente/Servidor [1]
La norma IEC 61850 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 61850 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.
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):
7 Relación entre las IEC 7-2, IEC 7-3 y IEC
61850-7-4
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 61850-7-2, IEC 61850-7-3, IEC 61850-7-4, 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 61850-7-2 se describe la definición general del modelo de clases.
En la parte IEC 61850-7-4 se describen unas especializaciones de la clase LOGICAL-NODE.
En la parte IEC 61850-7-3 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).
Figura 10 Relación entre las diferentes partes [1]
Como ejemplo, en la Figura 11 se muestran dos LN definidos en la parte IEC 61850-7-4, XCBR y XDIS, cada LN contiene una serie de datos, uno de ellos (pos) del tipo DPC definido en IEC 61850-7-3. 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 61850-7-2.
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 61850-8-x e IEC 61850-9-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.
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.
Capítulo 3
M
ODELO 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 61850-8-1. 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.
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 61850-7-2.
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
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.
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.
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.
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.
Por otra parte, el método más usado y el que establece el estándar IEC 61850 para que las aplicaciones OSI operen en un medio TCP/IP es descrito en RCF 1006.
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.
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
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
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).
• 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
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 1006
7.1 Descripción.
Esta capa del modelo OSI es descrita en el estándar ISO 8073. 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
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.
• TP1: Recuperación básica de errores. • TP2: Similar a TP0, pero con multiplexado. • TP3: Recuperación de errores y multiplexado.
• TP4: Detección y recuperación de errores. Similar a TCP.
7.2 Implantación
Se asume que TCP ofrece los siguientes servicios: (Connected, connect fails, data ready, errored, closed, listen on port, open port, read data, send data, close)
RFC 1006 describe cómo usar estos servicios para emular los siguientes servicios OSI: (N-Connect.indication, N-Connect.confirmation, Data.indication, Disconect.indication, Connect.Request, N-Connect.response, N-Data.request, N-Disconnect.request).
El protocolo especificado en esta memoria, es igual a TP0 con las excepciones:
• Datos de inicio deben ser intercambiados durante el establecimiento de la conexión.
• Se soporta una mayor longitud de PDU.
• El servicio de red usado, es suministrado por TCP.
Este protocolo establece un mapping entre las primitivas TCP y las esperadas por TP0 (Transport protocol class 0) de la siguiente manera: Network service TCP
--- --- CONNECTION ESTABLISHMENT
N-CONNECT.RESPONSE listen completes N-CONNECT.CONFIRMATION open (ACTIVE open) finishes
DATA TRANSFER
N-DATA.REQUEST send data
N-DATA.INDICATION data ready followed by read data
CONNECTION RELEASE
N-DISCONNECT.REQUEST close
N-DISCONNECT.INDICATION connection closes errors
Los elementos usados durante la transferencia de datos son idénticos a los presentados en ISO 8073 (Transport protocol specification) de manera que se deben encapsular los TPDUs en unidades discretas llamadas TPKTs
Un TPKT consta de dos partes, un packet-header y un TPDU. Packet-header:
El formato es constante, independientemente del tipo de paquete: | Vrsn | reserved | packet lenght | TPDU |
Vrsn: Versión. Es siempre 3 para esta versión de la memo. (8 bits) Reserved: (8 bits) será 0.
Packet-lenght: Contiene la longitud del paquete entero en bytes, incluyendo el packet-header. (16 bits), (min=7, max=65535).
TPDU:
El formato del TPDU es el soportado para TP0. En el RFC 905 viene la especificación de su estructura y los tipos de TPDUs soportados.
8 Capa de sesión
8.1 Descripción.
La capa de sesión es esencialmente una versión mejorada de la capa de transporte. En la práctica muy pocas aplicaciones soportan la capa de sesión. Su tarea principal es la de sincronizar las relaciones de comunicación, es decir proporcionan los mecanismos necesarios para controlar el diálogo entre la aplicaciones de los sistemas finales. En muchos casos son prescindibles. La capa de sesión proporciona los siguientes servicios:
-Control del diálogo: Puede ser simultáneo en los dos sentidos (full-duplex) o alternado en ambos sentidos (half-duplex).
-Agrupamiento: El flujo de datos se puede marcar para definir grupos de datos.
-Recuperación: Puede proporcionar un mecanismo de puntos de comprobación, de forma que si ocurre algún tipo de fallo entre puntos de comprobación, la entidad de sesión pueda retransmitir todos los datos desde el último punto de comprobación.
8.2 Implantación.
En cuanto al formato de los SPDU (session protocol data units), este viene definido en ISO 8327-1. La relación entre las primitivas que ofrece y sus diferentes SPDUs se muestran a continuación:
S_CONNECT.request CN connect SPDU S_CONNECT.indication CN connect SPDU S_CONNECT.response(+) AC accept SPDU
S_CONNECT.confirm(+) AC accept SPDU S_CONNECT.confirm(-) RF refuse SPDU
S_DATA.request DT data transfer SPDU S_DATA.indication DT data transfer SPDU S_RELEASE.request FN finish SPDU
S_RELEASE.indication FN finish SPDU S_RELEASE.response(+) DN disconnect SPDU S_RELEASE.confirm(+) DN disconnect SPDU S_U_ABORT.request AB abort SPDU S_U_ABORT.indication AB abort SPDU
9 Capa de presentación
9.1 Descripción.
Define el formato de los datos que se van a intercambiar entre las aplicaciones. (En el caso de MMS utilizará ASN.1).
Esta capa se encarga de asegurar que la información contenida en los PDUs se conserve durante la transferencia. Tiene dos funciones:
-Negociar la sintaxis de transferencia.
-Transformar los mensajes mediante la sintaxis determinada.
9.2 Implantación
En el estándar ISO 8823 se especifica este protocolo y en ISO 8822 se especifican sus servicios.
En general, maneja las estructuras de datos abstractas y realiza las conversiones de representación de datos necesarios para la correcta interpretación de los mismos.
Esta capa está definida a través del lenguaje ASN.1 (Abstract syntax notation nº1), que es una notación normalizada por ISO para la descripción de estructuras de datos.
Para transformar los mensajes, se ha utilizado el compilador ASN.1 compiler de Lev Walkin. Un compilador Open Source, que se encarga de convertir una especificación ASN.1 en estructuras de datos C.
Así, los mensajes de presentación, son especificados en ASN.1, y el compilador crea a partir de esta especificación una serie de estructuras y uniones, describiendo el correspondiente tipo de ASN.1. También crea el código que permite la serialización y deserialización automática de estas estructuras. (Para este proyecto, reglas de codificación BER -Basic encoding rules-).
Cuando el nivel de aplicación le pasa los datos, los codifica con la sintaxis definida, rellena los mensajes de presentación donde se negocia la sintaxis y codifica el mensaje mediante las reglas de codificación de ASN.1.
9.3 Lenguaje ASN1.
ASN.1 (Abstract syntax notation number 1) se utiliza para definir el formato de los PDUs (Protocol data units), la representación de la información y las operaciones realizadas con los datos transmitidos.
Los protocolos de aplicación describen sus PDUs en términos de sintaxis abstracta. Esta sintaxis se utiliza para el intercambio de información entre componentes de aplicaciones diferentes. Dentro de un sistema, la información representada utilizando sintaxis abstracta se debe traducir en alguna forma de representación para el usuario. También se debe traducir entre la sintaxis abstracta de la aplicación y una sintaxis de transferencia que describa los valores de los datos en una forma binaria.
La traducción entre la sintaxis abstracta y la sintaxis de transferencia se realiza por medio de reglas que especifican la representación de cada dato.
De esta manera, se consigue que exista una representación común para el intercambio de datos entre sistemas diferentes, y cada aplicación utiliza una representación particular de datos.
9.4 Reglas de codificación BER.
El formato BER especifica un formato descriptivo y auto-delimitativo para codificar las estructuras de datos ASN.1. Cada elemento de datos está codificado por un identificador de tipos, una descripción longitud, los elementos de datos actuales, y donde sea necesario, un marcador de fin-de-contenido. Estos tipos de codificaciones son llamados comúnmente tipo-longitud-valor (TLV). Este formato permite a un receptor decodificar la información ASN.1 desde una corriente incompleta, sin necesitar conocimiento previo del tamaño, contenido, o significado semántico de los datos.
9.5 Ejemplo de uso del compilador ASN1C.
A continuación se explicará el mecanismo para la creación de una estructura ASN.1 y la utilización de las herramientas de codificación que genera el compilador.
Primero se realizará la especificación de la estructura asn1. Para ello se crea un archivo con el nombre estructura.asn1 donde se especifica la estructura ASN.1 determinada. En la Figura 21 se muestra un ejemplo de una estructura concreta ASN.1.
Figura 21 Ejemplo estructura ASN.1
Se especifican dos elementos, Estructura y MyInt (tipo simple BOOLEAN). La estructura (sequence) contiene tres elementos (dato1, dato2, struct), el primero es del tipo BOOLEAN, el segundo es una lista de longitud variable de elementos MyInt, y el tercero es una lista de longitud variable de elementos Estructura (recursivo). Este archivo se compila mediante el compilador asn1c, con la instrucción:
asn1c –fcompound-names –fnative-types estructura.asn1
La opción –fcompound-names, se utiliza para usar nombres complejos de las estructuras, de manera que se previenen errores debidos a que distintos módulos usen los mismos nombres en diferentes contextos.
La opción –fnative-types, hace que se usen los tipos de datos propios de la máquina (int, double…).
Se generan los archivos: MyInt.h, MyInt.c, Estructura.h, Estructura.c junto con diferentes archivos necesarios para la compilación y codificación de las estructuras y un archivo Makefile.
A continuación se nuestra el contenido del archivo MyInt.h donde se define el tipo de dato MyInt_t.
Ahora se mostrará parte del archivo generado Estructura.h donde se observa la estructura generada Estructura_t con los tipos de datos antes explicados.
Por último se construirá el archivo en el que se rellenan las estructuras de datos, y se codifican.
A continuación se expone un ejemplo.
/*
Javier Juárez Montojo 2008/2009 */ #include <iostream.h> #include "Estructura.h" int main() { Estructura_t *mnsj; MyInt_t *dato; Estructura_t *str; asn_enc_rval_t er; char buf[256]; int ret;
mnsj[0].dato1=10; //dato2 dato[0]=20; dato[1]=21; ret = ASN_SEQUENCE_ADD(&mnsj[0].dato2.list,&dato[0]); if(ret != 0) {
cout<<"Error en codificación dato2"<<endl; }
ret = ASN_SEQUENCE_ADD(&mnsj[0].dato2.list,&dato[1]); if(ret != 0)
{
cout<<"Error en codificación dato2"<<endl; } //struct str[0].dato1=30; ret = ASN_SEQUENCE_ADD(&mnsj[0].Struct.list,str); if(ret != 0) {
cout<<"Error en codificación Struct"<<endl; } //Leer variables cout<<"Dato1: "<<mnsj[0].dato1<<endl; cout<<"Dato2.2: "<<mnsj[0].dato2.list.array[0][0]<<endl; cout<<"Dato2.2: "<<mnsj[0].dato2.list.array[1][0]<<endl; cout<<"Dato1: "<<mnsj[0].Struct.list.array[0][0].dato1<<endl; //Codificar er = der_encode_to_buffer(&asn_DEF_Estructura, mnsj, buf, 256); if (er.encoded == -1) {
cout<<"Cannot encode: "<< er.failed_type->name<<endl; }
else {
printf("Structure successfully encoded\n"); } free(dato); free(mnsj); free(str); return 0; }
Este programa se encarga de rellenar la estructura mnsj y codificar el mensaje mediante las reglas de codificación BER, almacenando la trama de bits en la variable buf.
La compilación se realiza mediante la ayuda del siguiente Makefile: ASN_MODULE_SOURCES= \ Estructura.c \ MyInt.c ASN_MODULE_HEADERS= \ Estructura.h \ MyInt.h ASN_MODULE_HEADERS+=BOOLEAN.h ASN_MODULE_SOURCES+=BOOLEAN.c ASN_MODULE_HEADERS+=asn_SEQUENCE_OF.h ASN_MODULE_SOURCES+=asn_SEQUENCE_OF.c ASN_MODULE_HEADERS+=asn_SET_OF.h ASN_MODULE_SOURCES+=asn_SET_OF.c ASN_MODULE_HEADERS+=constr_SEQUENCE.h ASN_MODULE_SOURCES+=constr_SEQUENCE.c ASN_MODULE_HEADERS+=constr_SEQUENCE_OF.h ASN_MODULE_SOURCES+=constr_SEQUENCE_OF.c ASN_MODULE_HEADERS+=constr_SET_OF.h ASN_MODULE_SOURCES+=constr_SET_OF.c ASN_MODULE_HEADERS+=asn_application.h ASN_MODULE_HEADERS+=asn_system.h ASN_MODULE_HEADERS+=asn_codecs.h ASN_MODULE_HEADERS+=asn_internal.h ASN_MODULE_HEADERS+=OCTET_STRING.h ASN_MODULE_SOURCES+=OCTET_STRING.c ASN_MODULE_HEADERS+=BIT_STRING.h ASN_MODULE_SOURCES+=BIT_STRING.c ASN_MODULE_SOURCES+=asn_codecs_prim.c ASN_MODULE_HEADERS+=asn_codecs_prim.h ASN_MODULE_HEADERS+=ber_tlv_length.h ASN_MODULE_SOURCES+=ber_tlv_length.c ASN_MODULE_HEADERS+=ber_tlv_tag.h ASN_MODULE_SOURCES+=ber_tlv_tag.c ASN_MODULE_HEADERS+=ber_decoder.h ASN_MODULE_SOURCES+=ber_decoder.c ASN_MODULE_HEADERS+=der_encoder.h ASN_MODULE_SOURCES+=der_encoder.c ASN_MODULE_HEADERS+=constr_TYPE.h ASN_MODULE_SOURCES+=constr_TYPE.c ASN_MODULE_HEADERS+=constraints.h ASN_MODULE_SOURCES+=constraints.c ASN_MODULE_HEADERS+=xer_support.h ASN_MODULE_SOURCES+=xer_support.c ASN_MODULE_HEADERS+=xer_decoder.h ASN_MODULE_SOURCES+=xer_decoder.c ASN_MODULE_HEADERS+=xer_encoder.h ASN_MODULE_SOURCES+=xer_encoder.c ASN_MODULE_HEADERS+=per_support.h
ASN_MODULE_SOURCES+=per_encoder.c
CFLAGS = -w -I.
OBJS=${ASN_MODULE_SOURCES:.c=.o} ${ASN_CONVERTER_SOURCES:.c=.o} all: ${OBJS} programa
programa: Programa.cpp
g++ $(CFLAGS) -c Programa.cpp g++ $(CFLAGS) *.o -o ejecutable clean:
rm *.o ejecutable
regen: regenerate-from-asn1-source regenerate-from-asn1-source:
asn1c -fcompound-names -fnative-types ASN.asn1
Para la realización de este proyecto han surgido algunos problemas debidos a que el compilador asn1c no soporta el tipo de dato VisibleString (subconjunto de caracteres, los visibles y el espacio), entre otros, necesarios para la correcta configuración de los mensajes MMS. Este tipo de datos el compilador los crea vía Octet_String, lo que hace que el identificador del tipo de dato a la hora de su codificación mediante las reglas BER, sea erróneo, o por lo menos no el esperado. Esto provoca que se tengan que realizar algunas modificaciones para poder codificarlo de manera correcta.
Primero se explicará brevemente, el método de codificación mediante reglas BER.
Cada campo consta de tres partes:
• Tipo (Tag): Etiqueta que identifica el valor. • Longitud: La del valor, en bytes.
• Valor.
Los “Tags” involucrados en el problema, serían los siguientes: • Octet_String: 0x04.
• Visible_String: 0x1A (26). • UTF8_String: 0x0C (12).
Uno de los tipos de datos que define y utiliza MMS es un Identifier_t, que debe ser del tipo Visible_String, por lo que su Tag debería ser 0x1A, mientras que el compilador lo codifica de manera que le pone la etiqueta 0x0C, lo que rompe el estándar MMS.
Este error, se ha solucionado de manera local en los mensajes MMS: • Read_Request.
• Write_Request.
• GetNameList_Request.
Se deja para futuros desarrollos, su mejora y total solución.
10 Capa de aplicación
Comprende los servicios específicos de la aplicación para la comunicación. Los protocolos que se utilizarán en esta capa, son MMS (Manufacturing message specification) cuyo estándar es el ISO 9506, y el protocolo ACSE (ISO 8649 e ISO 8650).
10.1 ACSE
Es el servicio de control de la aplicación. Proporciona facilidades para el control de la asociación de la aplicación entre entidades conectadas a través del nivel de presentación.
Este protocolo se usa para establecer y liberar la asociación de la aplicación y determina la identidad y el contexto de la asociación. ACSE soporta dos modos de servicios de comunicación, uno orientada a conexión y otra no orientada a conexión. A continuación se muestran los
ACSE service APDU Communication mode Service type
A-ASSOCIATE AARQ, AARE Connection oriented confirmed
A-RELEASE RLRQ, RLRE Connection oriented confirmed
A-ABORT ABRT Connection oriented non-confirmed
A-P-ABORT ABRT Connection oriented Provider initiated
A-UNIT-DATA ADAT Connectionless non-confirmed
Cada APDU contiene una serie de variables a través de las cuales se intercambia la información.
10.2 MMS
El protocolo MMS se explicará con mayor detalle en los capítulos siguientes.
Este protocolo sigue una arquitectura Cliente/Servidor. En ella el envió y recepción de mensajes sigue la siguiente estructura:
En la Figura 22 se muestra el mecanismo de establecimiento de conexión.
Figura 22 Establecimiento de la conexión
En la mayoría de las implementaciones, un servidor está escuchando continuamente en un puerto (102 en este proyecto), hasta que la conexión sea hecha.
En la Figura 23 se muestra el mecanismo de transferencia de datos:
Figura 23 Transferencia de datos
Esto se repite indefinidamente hasta que se proceda a la Data.Request Data.Indication Data.Confirmation Data.Response Connect.Request Connect.Indication Connect.Confirmation Connect.Response Servidor Cliente Cliente Servidor
