(Spanish) Modelado e Implementación Del Protocolo DLMSCOSEM Para Aplicaciones AMI en Ns-3

UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

1

Resumen Centros de investigacin, gobiernos e industrias de los sectores de las telecomunicaciones, control, potencia y energa en general, estn poniendo su atencin en el desarrollo e implementacin de nuevos servicios y aplicaciones, con el fin de acelerar la

migracin de las redes elctricas tradicionales a las redes elctricas de prxima generacin, tambin conocidas como Smart Grids.

Dentro de los Smart Grids se encuentran las Infraestructuras de Medicin Avanzada (AMI, por sus siglas en ingls), las cuales

desempean un papel importante en la modernizacin de las redes elctricas, porque aumentan la confiabilidad y la eficiencia en el uso

de los recursos y hacen posible correr aplicaciones como: programas de respuesta de la demanda, medicin bidireccional remota,

desconexin-reconexin remota gestionada a travs de sistemas AMI. En este documento, se presentan los resultados de modelado e

implementacin del Protocolo DLMS/COSEM para aplicaciones AMI (medicin bidireccional y desconexin-reconexin remota de

medidores elctricos inteligentes) en el simulador de redes ns-3.

Palabras claves DLMS/COSEM, IEC 62056-47/53, AMI, Concentrador de Datos, MDMS, ns-3.

I. INTRODUCCIN

La Infraestructura de Medicin Avanzada (AMI, por sus siglas en ingls) constituye el primer paso de la evolucin de las redes

elctricas convencionales a las redes elctricas de prxima generacin, tambin conocidas como Redes Inteligentes. AMI se considera el escenario a travs del cual corrern varias de las aplicaciones prometedoras para la gestin eficiente de las redes

elctricas. Entre ellas se encuentran: programas de Respuesta de la demanda, Medicin bidireccional remota, Control de carga,

Conexin y Desconexin de la energa de forma remota, Vehculos Elctricos, entre otras.

Este trabajo busca presentar los resultados de diseo (modelado) e implementacin en ns-3 del protocolo europeo

DLMS/COSEM, estandarizado en la norma IEC 62056, empleado para aplicaciones AMI, tales como: medicin bidireccional y

desconexin-reconexin remota de medidores elctricos inteligentes. Adicionalmente, se propone modelos de un medidor

elctrico inteligente, segn la IEC 62056-6-2 (Draft); de las aplicaciones AMI mencionadas y los componentes ms relevantes

dentro de una red AMI: Concentrados de Datos y Sistema de Gestin de Datos de Medicin (MDMS, por sus siglas en ingls).

Este documento se encuentra organizado como sigue: en la seccin 2, se presenta la metodologa de diseo empleada para el

modelado e implementacin del protocolo DLMS/COSEM, las aplicaciones y los componentes esenciales AMI en ns-3, seguido

de una breve descripcin del esquema de telecomunicaciones propuesto para la red AMI (seccin 3).

Posteriormente, en la seccin 4 se detallan los resultados de la etapa de modelado, continuando con los resultados de la

implementacin en ns-3 (seccin 5), y finalizando con algunas conclusiones y trabajo futuro en la seccin 6.

II. METODOLOGA

Para el desarrollo, incorporacin, pruebas y ajustes del mdulo DLMS/COSEM en el simulador de redes ns-3, se sigui la

metodologa propuesta en la Fig. 1. Esta metodologa se compone de varias etapas, como se describen brevemente a

continuacin: (1) Revisin de las normas y especificaciones tcnicas de los protocolos y tecnologas de comunicaciones a

emplear, con el fin de obtener los fundamentos para el desarrollo del modelo a implementar; (2) Investigacin de las libreras

disponibles en ns-3 para el desarrollo del modelo; (3) Una vez estudiadas las normas y las especificaciones tcnicas e

identificadas las libreras disponibles en ns-3 relevantes para el desarrollo del mdulo, se realiza la abstraccin del modelo,

utilizando herramientas de modelado UML y los paradigmas de la Programacin Orientada a Objetos (POO); (4) Finalizada la

etapa de modelado, se pasa a la etapa de codificacin del modelo resultante, empleando el lenguaje de programacin C++;

seguido de su incorporacin en ns-3 (5); y posteriormente, se realizan las pruebas (i.e. simulaciones) y los ajustes pertinentes al

modelo, lo cual requerir repetir el ciclo completo o partes de la metodologa hasta obtener el 100% funcionamiento del mdulo

de acuerdo con las directrices establecidas.

Modelado e Implementacin del Protocolo DLMS/COSEM para aplicaciones AMI en ns-3

Juan M. Aranda L. K., Roberto Bustamante M.

Julio de 2013, {jm.aranda121, rbustama}@uniandes.edu.co


2

Fig. 1. Metodologa empleada para el modelado e implementacin del protocolo DLMS/COSEM y aplicaciones AMI en ns-3

III. ESQUEMA DE TELECOMUNICACIONES PARA AMI

En la Fig. 2 se ilustra un esquema general de telecomunicaciones para una red AMI implementada sobre las tecnologas de

acceso LTE y Wi-Fi, utilizando concentradores de datos (DC, por sus siglas en ingls) y un Sistema de Gestin de Datos de

Medicin (MDMS, por sus siglas en ingls) para la gestin de los medidores elctricos inteligentes (MIs). Como se puede

observar en la figura, el esquema se compone esencialmente de tres partes: (1) Recoleccin de datos a nivel local, (2) Red de

Comunicaciones AMI y (3) Centro de Control. La red de rea local (parte (1)) se implementa sobre la tecnologa Wi-Fi y el

estndar de comunicaciones IEC 62056 (i.e. protocolo DLMS/COSEM). Comprende tanto los medidores inteligentes,

incorporados en cada una de las instalaciones de los consumidores (residenciales, comerciales e industriales), como los

concentradores de datos, cuyo objetivo es agrupar el trfico producido por un conjunto de medidores dentro del alcance de su red

y de enviarlo hacia el Sistema de Gestin de Datos de Medicin cuando ste los solicite. Adicionalmente, el DC tiene la tarea de

retransmitir a los medidores elctricos inteligentes las seales de precios/control (comandos) generados por el servidor de

Respuesta de la Demanda y del MDMS. Entre el concentrador de datos y el Centro de Control se implementa una red de acceso

LTE y una red de transporte con cobertura metropolitana sobre fibra ptica (parte (2)). Por ltimo, la arquitectura de

telecomunicaciones, empleada para transferir los paquetes a los diferentes servidores dentro de las instalaciones del Centro de

Control, consiste en una red de rea local implementada sobre la tecnologa Ethernet (parte (3)).

Fig. 2. Ejemplo ilustrativo del esquema de telecomunicaciones para una red AMI implementada sobre las tecnologas LTE y Wi-Fi


3

IV. MODELADO

A. Modelo de Interfaz COSEM bsico Medidor Elctrico Inteligente

De acuerdo con la norma IEC 62056-62 [1], el modelo de interfaz COSEM para un medidor elctrico presenta una estructura

jerrquica de tres niveles: (1) el dispositivo fsico como tal, (2) el dispositivo lgico, y (3) los objetos COSEM accesibles.

Teniendo en cuenta esta jerarqua y las caractersticas de modelos reales de medidores inteligentes [2], se propuso un modelo

COSEM bsico para un medidor elctrico inteligente con funcionalidades de registro de energa activa total consumida (kWh) y

de desconexin-reconexin remota de la unidad de desconexin del dispositivo (Fig. 3).

Fig. 3. Modelo interfaz COSEM bsico para el medidor inteligente con funcionalidades de registrar la energa activa total consumida en el abonado y

desconexin-reconexin remota del suministro de energa. LDN: Logical Device Name object. A: Association object.

El dispositivo lgico est compuesto por cinco objetos COSEM (Fig. 3): (1) LDN (Logical Device Name), instancia que contiene el identificador nico del dispositivo lgico (identificador establecido por el fabricante); (2) A (Association)

1, instancia

que contiene informacin sobre la asociacin de aplicacin establecida; (3) total energy, instancia que almacena el valor de la energa activa total consumida en el abonado (kWh) y el tiempo en que se realiza el registro; y (4) disconnect unit, instancia que permite manipular la unidad de desconexin del medidor para ejecutar acciones de desconexin y reconexin del suministro

de energa de forma remota [3]; y (5) Capture, instancia que proporciona mecanismos para almacenar, clasificar y acceder a grupos de datos (arreglos de datos que contienen: medicin, unidades y tiempo de registro). Los objetos (1) y (2) son

establecidos por la norma IEC 62056-62 como partes que deben de estar presentes en un dispositivo lgico COSEM. Estos dos

objetos no sern descritos en este documento. Para mayor informacin remitirse a la referencia [1]. Por ltimo, dado a que el

dispositivo fsico contiene un nico dispositivo lgico, ste constituye el Management logical device, elemento obligatorio en cualquier dispositivo fsico (IEC 62056-62).

El objeto total energy es una instancia de la IC (Interface Class) Extended Register (class_id: 4). Esta clase contiene las caractersticas necesarias para modelar el comportamiento de un registro genrico (i.e. medidor elctrico convencional), las

cuales son identificadas por medio de sus atributos. Como se muestra en la Fig. 4, la IC Extended Register posee los siguientes

atributos [3]:

(1) logical_name: atributo tipo octet-string, el cual contiene el cdigo OBIS que identifica a la instancia total energy y

cuyo valor es 1.0.1.7.0 (i.e. la instancia es un objeto Potencia Activa ( ) tipo elctrico ( ), utilizado para capturar el valor instantneo ( ) de la energa activa total ( ) a travs canal especificado por el fabricante ( ) del dispositivo fsico. El campo F del cdigo OBIS no es utilizado en este caso (IEC 62056-61, 2006, Table 16)).

(2) value: atributo tipo unsigned long (tipo de dato escogido de acuerdo con IEC 62056-62), el cual almacena el contenido actual del registro, es decir, el valor de la energa activa total consumida.

(3) scalar_unit: atributo tipo integer, el cual consiste en un arreglo de dos elementos: en la posicin [0], se almacena el exponente del factor multiplicador (en base 10) y en [1], la unidad fsica (i.e. Wh, posicin (30) del enum definido en

IEC 62056-62). Ej. Para value = 750, [0]= 3 y [1] = Wh, el dato recibido por el Centro de Control sera 750 kWh.

(4) status: atributo tipo unsigned long, el cual almacena informacin sobre el estado del Extended Register (informacin establecido por el fabricante).

(5) capture_time: atributo tipo octet-string, el cual contiene el momento en que fue capturado el atributo value (para efectos de simulacin, se considera el tiempo de simulacin en que ocurre el evento de captura del atributo value).

La IC Extended Register contiene el mtodo reset(), el cual se utiliza para restablecer el valor del atributo value a su valor por defecto. Para el modelo propuesto, este valor por defecto se asume igual a cero.

1 Representa la asociacin de aplicacin utilizando la referencia tipo Logical Name (LN)


4

Fig. 4. Diagramas de clases de las ICs Extended Register, Disconnect control y Profile Generic (Adaptado de [3])

El objeto capture es una instancia de la IC Profile generic (class_id: 7) (Fig. 4), cuyos atributos y mtodos se detallan brevemente a continuacin [3]:

(1) logical_name: atributo tipo octet-string, el cual contiene el cdigo OBIS que identifica a la instancia capture y cuyo valor se asume igual a 1.0.1.7.0.255.

(2) buffer: atributo tipo arreglo de estructuras, el cual contiene una secuencia de estructuras, cuyos campos son: value, scalar_unit, capture_time). El mtodo de clasificacin de la secuencia de entradas al buffer se consider tipo FIFO.

(3) capture_objects: atributo tipo arreglo, el cual contiene la lista de objetos a capturar que son asignados a la instancia capture. Para el modelo se consider un arreglo unidimensional, cuyo componente es un objeto tipo total energy.

(4) capture_period: atributo tipo unsigned long double, que especifica el periodo de tiempo en que se realiza la captura de objetos tipototal energy. Se asumi un intervalo de 60 segundos [2].

(5) sort_method: atributo tipo enum (fifo, lifi, largest, smallest, nearest_to_zero, farest_from_zero), que especifica el tipo de mtodo de clasificacin empleado por la instancia capture. Se emplea el mtodo de clasificacin por defecto (i.e. FIFO).

(6) sort_object: atributo tipo capture_objects, que especifica el registro en el mtodo de clasificacin est basado. (7) entries_in_use: atributo tipo unsigned long double, que realiza la funcin de contador del nmero de entradas

almacenadas en el buffer.

(8) profile_entries: atributo tipo unsigned long double, que especifica el nmero de entradas que retiene el buffer. Se asumi un buffer con capacidad de almacenar 8192 entradas (equivalente a 8 KBytes de memoria RAM aprox.).

La IC Profile Generic contiene los mtodos reset() y capture(), los cuales se utilizan para vaciar el buffer y capturar e

introducir los objetos tipo total energy en el periodo de tiempo establecido al buffer, respectivamente. Por ltimo, el objeto disconnect unit es una instancia de la IC Disconnect control (class_id: 70) (Fig. 4), que presenta los

atributos y mtodos, que se describen a continuacin [3]:

(1) logical_name: atributo tipo octet-string, el cual contiene el cdigo OBIS que identifica a la instancia disconnect unit y cuyo valor se asume igual a 0.1.96.3.10.255.

(2) output_state: atributo tipo boolean, que contiene el estado fsico actual de la unidad de desconexin del medidor: TRUE (connected) y FALSE (disconnected).

(3) control_state: atributo tipo entero, que representa el estado actual del objeto Disconnect. Los estados se definen en un enum: (0) Disconnected, (1) Connected, (2) Ready_for_reconnection

(4) control_mode: atributo tipo entero, que permite configurar el comportamiento del objeto Disconnect para todos los posibles estados de transicin de la mquina de estados (Fig. 5). En este modelo se considera el modo 2

2.

Los mtodos remote_disconnect (data) y remote_reconnect (data) permiten forzar al objeto Disconnect a pasar al estado

disconnected si el control mode es mayor que cero y al estado connected si el control mode es 2 o 4, respectivamente [3]. El

2 Disconnection: Remote (b, c), manual (f), local (g); Reconnection: Remote (a), manual (e).

class Register

Extended Register

- logical_name: octet_string

- value: unsigned long

- scalar_unit: unsigned long ([1])

- status: unsigned long

- capture_time: octet_string

+ reset(int) : void

class Disconnect control

Disconnect Control

- logical_name: octect-string

- output_state: boolean

- control_state: int

- control_mode: int

+ remote_disconnect(int) : void

+ remote_reconnect(int) : void class Domain Objects

Profile Generic

- logical_name: octet-string

- buffer: array

- capture_objects: array

- capture_period: double-long-unsigned

- sort_method: enum

- sort_object: capture_object_ definition

- entries_in_use: double-long-unsigned

- profile_entries: double-long-unsigned

+ reset(int) : void

+ capture(int) : void


5

argumento de entrada, data, es un nmero entero. Para el modelo no se considera el data (i.e. no-data). En la prctica estos

mtodos son invocados desde un script3 dentro del software DLMS/COSEM instalado en el medidor.

Fig. 5. Diagrama de estado para los objetos tipo Disconnect control (Tomado de [3])

El modelo de medidor elctrico inteligente Cosem captura la energa activa total consumida por el abonado siguiendo el

procedimiento mostrado en la Fig. 6 (basado en [2]). Bsicamente, el objeto total energy incrementa el contador en la unidad consumida (kWh) por el abonado (se asumi un consumo de 1kWh cada 30 segundos)

4. Esta informacin es capturada por el

objeto Capture cada 60 segundos, el cual es almacenada en memoria (i.e. buffer, con la estructura mencionada anteriormente).

Ante la llegada de un mensaje GET.ind (generado por el cliente Cosem) al medidor, el objeto CosemServerAP recupera los datos

de medicin accediendo al modelo de interface Cosem, el cual en respuesta le devuelve un conjunto de datos (informacin que corresponde a los datos almacenado en el buffer hasta el instante en que se realiza la solicitud) con la estructura mostrada en la

figura. Obtenida la informacin requerida, el objeto CosemServerAP la enva al cliente, generando un mensaje Get.res

(NORMAL, Data), siguiendo las instrucciones del protocolo de aplicacin DLMS/COSEM.

Fig. 6. Procedimiento ejecutado para la captura de la energa total registrada en un medidor elctrico inteligente, usando el modelo y protocolo DLMS/COSEM

3 Instancia de la IC Script table (class_id=9) 4 Siempre y cuando el valor del atributo output_state del objeto disconnect unit sea verdadero.


6

B. Protocolo de aplicacin DLMS/COSEM

El protocolo de aplicacin DLMS/COSEM especifica el procedimiento de la transferencia de informacin para los procesos

de asociacin de aplicacin e intercambio de mensajes entre los servidores y clientes COSEM [1]. Se implement teniendo en

cuenta las indicaciones dadas en la norma IEC 62056-53, para la capa de aplicacin e IEC 62056-47, para la sub-capa de

transporte COSEM para redes IPv4. La Fig. 7 muestra la pila de protocolos Cliente/Servidor localizados en diferentes

dispositivos fsicos. En la capa superior, se encuentra el protocolo de aplicacin cliente/servidor DLMS/COSEM (i.e. el proceso

y la capa de aplicacin cliente/servidor) utilizado para el intercambio de mensajes entre el servidor y el cliente. La capa de

transporte y la capa de red estn compuestas por la pila UDP/IP, donde la capa de transporte corresponde a la capa COSEM-

UDP, la cual utiliza los servicios del protocolo IPv4. Finalmente, la capa de enlace y la capa fsica corresponden a la tecnologa

de acceso que se emplee para la comunicacin, por ejemplo la tecnologa celular LTE (Long Term Evolution), especificada en el

Release 8 de la 3GPP (3rd Generation Partnership Project).

Fig. 7. Pila de protocolos Cliente/Servidor localizados dispositivos diferentes fsicos

En la Fig. 8, se resume la estructura en capas5 y los servicios DLMS/COSEM empleados en la comunicacin y soportados por

las capas de aplicacin y transporte COSEM UDP. Se escogi UDP/IP dado a que presenta un comportamiento superior a

TCP/IP para funciones AMI ejecutadas en tiempo real [2] y facilita la implementacin del protocolo en ns-3.

Fig. 8. Estructura y servicios DLMS/COSEM (Adaptada de [4])

Para que el cliente pueda ejecutar una accin de forma remota es necesario que, en primer lugar, establezca una sesin de

comunicaciones con el servidor. Para ello, se deben pasar por tres fases de comunicaciones, las cuales se muestran en la Fig. 9.

5 Estructura que presenta todo dispositivo que emplea el protocolo de aplicacin DLMS/COSEM. Las capas y servicios corresponden a instancias de clases modeladas e implementadas de acuerdo con las especificaciones tcnicas y el API de ns-3.


7

Se emplean los servicios de la capa de aplicacin COSEM para establecer una asociacin de aplicacin entre las partes

involucradas, continuando con la comunicacin de datos y finalizando con la liberacin de la AA (slo cuando sea solicitada por

el cliente).

Fig. 9. Fases de la sesin de comunicacin Cliente/Servidor (Adaptada de [4])

La interaccin y la ordenacin temporal de los mensajes intercambiados entre las diferentes entidades durante el

establecimiento de asociacin de aplicacin, comunicacin de datos y liberacin de asociacin, se pueden describir a travs de

diagramas de secuencia UML. Este trabajo se centra nicamente en la fase IInivel de aplicacin, ya que los diagramas de secuencia de las fases I, II (nivel de transporte) y III y el formato de los mensajes se pueden construir con facilidad a partir de los

resultados de modelado obtenidos en [4].

C. Aplicaciones AMI

A continuacin, se detallan el funcionamiento a alto nivel y el modelado de las aplicaciones AMI, implementadas en ns-3, en

trminos de la interaccin (diagramas de secuencias) y el formato de los APDUs (Application Protocol Data Units)

intercambiados por las entidades AMI a nivel de aplicacin.

1) Medicin bidireccional remota: La aplicacin de medicin remota bidireccional comprende tanto la medicin peridica de la energa consumida (kWh) como las mediciones de potencia (activa y reactiva) y la calidad de la potencia (i.e. voltaje y

frecuencia) [5]. La red AMI se vale de medidores inteligentes (MIs), instalados en consumidores individuales, o de

concentradores de datos (DC, permiten la agregacin de datos recolados por los medidores atendidos por ste) para realizar las

mediciones a una frecuencia pre-establecida, que puede ser diariamente, hora a hora o incluso en intervalos de tiempo ms

pequeos (una vez cada 15min). Todo el volumen de datos generado del lado del consumidor es gestionado y analizado por el

Sistema de Gestin de Datos de Medicin (MDMS, por sus siglas en ingls), instalado por lo general en el Centro de Control de

la empresa, a travs de una red de comunicaciones bidireccional (sobre IP), como se muestra en la Fig. 10.

Fig. 10. Diagrama ilustrativo Aplicacin Smart Grids Medicin Remota Bidireccional. DC: Data Concentrator. SM: Smart Meter. MDMS: Meter Data Management System.

Asumiendo que el MI se comunica con el MDMS a travs de un DC, el MI desempea el rol de servidor (responde a las

solicitudes emitidas por el MDMS, a travs del DC) y el DC, el rol de cliente (emite solicitudes con la informacin solicitada por

el MDMS). Por tanto, la comunicacin entre el DC y el MI se puede realizar a travs del protocolo de aplicacin DLMS/COSEM

FASE I: Establecimiento

Asociacin

Establecimiento Asociacin de Aplicacin (AA) (servicios COSEM-OPEN)

FASE II: Comunicacin

de datos

Intercambio de datos - Nivel Aplicacin (servicios COSEM-GET, COSEM-ACTION)

Intercambio de datos - Nivel Transporte (servicios COSEM UDP-DATA)

FASE III: Liberacin Asociacin

Liberacin AA (servicios COSEM-RELEASE)


8

descrito en la seccin anterior. Por otro lado, la comunicacin entre el DC y el MDMS se realiza empleando un protocolo

COSEM virtual. Todos los mensajes generados durante la interaccin entre los componentes principales de la red AMI son empaquetados

dentro de unidades de datos del protocolo de aplicacin (APDU, por sus siglas en ingls) y enviados por el perfil de

comunicaciones (UDP/IP). Un APDU define el formato, es decir, la estructura y el tamao en bytes de los mensajes transferidos

[4]. En este trabajo se consider la estructura mnima requerida para el intercambio de mensajes entre las diferentes entidades

AMI. La codificacin A-XDR de estos APDUs queda fuera del alcance de este trabajo. La Fig. 11 presenta la estructura y el

tamao en bytes (sin codificar) de los mensajes intercambiados entre las aplicaciones COSEM (i.e. entre el DC y el MI) durante

la obtencin de datos de medicin.

GET-Request/GET-Response (NORMAL) APDUs

Fig. 11. Formato y tamao en bytes (B, sin codificar): (a) GET-Request-Normal APDU (12B). (b) GET-Response-Normal APDU (8B) (Adaptado de [1])

Fig. 12, Fig. 13 y Fig. 14 presentan la estructura y el tamao en bytes de los mensajes generados por el MDMS y enviados al DC.

El DC genera un mensaje METER-EVENT para informarle al MDMS que la instruccin (contenida en un mensaje CONTROL)

ha sido ejecutada satisfactoriamente por el MI. Los mensajes METER-POLL son utilizados para la solicitud y transferencia de

datos de medicin (un bloque o varios bloques) entre el DC y el MDMS.

CONTROL Y METER-EVENT APDUs

Fig. 12. Formato y tamao en bytes (B, sin codificar): (a) CONTROL APDU (7B). (b) METER-EVENT APDU (4B)


9

METER-POLL-Request/METER-POLL-Response (NORMAL) APDUs

Fig. 13. Formato y tamao en bytes (B, sin codificar): (a) METER-POLL-Request-Normal APDU (9B). (b) METER-POLL-Response-Normal APDU (8B)

METER-POLL-Request-Next/METER-POLL-Response-Block APDUs

Fig. 14. Formato y tamao en bytes (B, sin codificar): (a) METER-POLL-Request-Next APDU (6B). (b) METER-POLL-Response-Block ADPU (11B)

En la Fig. 15 se presenta, de forma resumida, la interaccin y la ordenacin temporal de los mensajes intercambiados entre las

aplicaciones instaladas en los nodos principales de la red AMI (i.e. MI, DC y MDMS). Para ms detalle, remitirse al cdigo del

mdulo COSEM en ns-3 (src/cosem/model). En la interaccin de las aplicaciones COSEM cliente-servidor, nicamente se

muestran los mensajes intercambiados durante la fase de comunicacin de datos, con el fin de simplificar el diagrama. Cada una

de las transiciones en el diagrama de la Fig. 15 corresponde a un evento ns-3, creado a partir del API Simulator::Schedule de ns-

3. La interaccin entre las entidades AMI (SM y DC) a la hora de ejecutar una accin de control solicitada por el MDMS, que

corresponde a una desconexin/reconexin del suministro de energa elctrica, se detalla en la siguiente aplicacin.


10

Fig. 15. Interaccin entre las aplicaciones instaladas en los nodos principales de la red AMI: Transmisin de las mediciones almacenadas en el DC en varios

bloques.

2) Desconexin-Reconexin remota: Esta aplicacin permite al operador de red realizar la suspensin de la alimentacin de

energa elctrica de los consumidores, cuando stos incumplen en el pago de su factura (Fig. 16). Una vez que los consumidores

son dados de alta, el operador activa el servicio de energa a travs de una reconexin remota (Fig. 16). Esta aplicacin reduce la

necesidad de enviar una flota para realizar la desconexin y reconexin fsica de la alimentacin, lo que se traduce en un ahorro

en mano de obra y combustible. Por otro lado, la accin de desconexin se puede realizar tambin de forma local (i.e. en el

Medidor Inteligente (MI)) y automtica (durante un intervalo de tiempo pre-establecido (30segs, 5min, 15min o 30 min), cuando

se presenten casos de manipulacin del dispositivo o fallo en el circuito. La Fig. 16 muestra los eventos generados en una

desconexin-reconexin remota/automtica de suministro de energa, gestionados por el MI y el Sistema de Gestin de Datos de

Medicin (MDMS). En ns-3 se implement la aplicacin de desconexin-reconexin remota nicamente.


11

Fig. 16. Diagrama ilustrativo Aplicacin Smart Grids Desconexin-Reconexin Remota (Automtica). MI: Medidor Inteligente. MDMS: Meter Data Management System.

En esta aplicacin se emplean los servicios COSEM GET y ACTION NORMAL para la obtencin del estado de conexin del

MI (i.e. atributo output_state) y para invocar uno de los mtodos descritos en la Fig. 4 (dependiendo de la accin que se desee

realizar en el medidor (desconexin/reconexin)), respectivamente.

La Fig. 17 presenta el formato y el tamao en bytes de los mensajes COSEM-ACTION-Request-Normal y COSEM-ACTION-

Response-Normal utilizados en la fase de comunicacin de datos DLMS/COSEM, los cuales fueron construidos de acuerdo con

la norma IEC 62056-536. La codificacin A-XDR de estos APDUs queda fuera del alcance de este trabajo. Para la obtencin del

estado de salida de la unidad desconexin del MI (i.e. output_state) se emplea el mensaje descrito en Fig. 11.

Fig. 17. Formato y tamao en bytes (B, sin codificar): (a) ACTION-Request-Normal APDU (13B). (c) ACTION-Response-Normal APDU (5B) (Adaptado de

[1])

La Fig. 18 presenta la interaccin y la ordenacin temporal de los mensajes intercambiados nicamente entre los procesos de

aplicacin Cliente (DC) y servidor (MI) a la hora de ejecutar la accin de reconexin-desconexin remota del MI, solicitada por

el MDMS.

6 La frecuencia con que el operador de red pueda emitir estos mensajes depender de la situacin del consumidor y del estado del Sistema Elctrico.


12

Fig. 18. Diagrama de secuencia para la fase II (nivel de aplicacin) Aplicacin Desconexin/Reconexin (Adaptado de [1]). CAP: Client Application Processs. SAP: Server Application Process. CAL: Client Application Layer. SAL: Server Application Layer. CSPL: Client Supporting Protocol Layer (COSEM UDP TL).

SSPL: Server Supporting Protocol Layer (COSEM UDP TL).

D. Componentes AMI

A continuacin, se presenta el modelo de simulacin para los componentes esenciales de una red AMI. En trminos generales,

los modelos presentan una estructura basada en capas, empezado por la capa de aplicacin y terminando por la capa fsica

(NetDevice), donde cada una de ellas representa una clase implementada en C++ de acuerdo con el API de ns-37. Estos modelos fueron obtenidos a partir de informacin disponible en la literatura, normas tcnicas y especificaciones de equipos

comerciales.

1) Medidor Inteligente (SM, por sus siglas en ingls): Este nodo presenta el modelo de interfaz COSEM y la pila de protocolos DLMS/COSEM (i.e. Proceso de aplicacin, Capa de aplicacin y Sub-Capa UDP-Wrapper) (Fig. 19). Por una parte, el modelo

de interfaz COSEM constituye un modelo de objetos COSEM (conjunto de instancias de clases implementadas en C++) con

funcionalidades de registro de la energa total consumida y manejo de la unidad de desconexin del medidor. Por otra parte, la

pila de protocolos DLMS/COSEM ofrece los servicios requeridos para la comunicacin e intercambio de mensajes con el nodo

cliente, a travs del perfil de comunicaciones.

2) Concentrador de Datos (DC por sus siglas en ingls): Al igual que el nodo SM, posee la pila de protocolos DLMS/COSEM, la cual le permite interactuar con un conjunto de medidor inteligentes (servidores), a travs de una interfaz Wi-Fi.

Adicionalmente, posee una aplicacin Data Concentrator que le permite interactuar con el Centro de Control (CC) a travs de UDP/IP y va LTE (Fig. 19). Por cada solicitud realizada por el CC (a travs del sistema MDM), por lo general cada 30 minutos,

el DC le transfiere las mediciones capturadas por la aplicacin COSEM (empleando una solicitud de datos de medicin

7 Documentado en http://www.nsnam.org/docs/release/3.17/doxygen/index.html (Consultado el 11 de junio de 2013)


13

siguiendo el estilo del planificador Round Robin y transferidas a la aplicacin DC va el enlace bidireccional establecida a nivel

de aplicacin) y almacenadas en memoria (DC Memory) por la aplicacin DC.

Fig. 19. Modelo de simulacin de los nodos Medidor Inteligente y Concentrador de Datos en ns-3

Fig. 20. Modelo de simulacin del nodo Sistema de Gestin de Datos de Medicin (MDMS) en ns-3


14

3) Sistema de Gestin de Datos de Medicin (MDMS, por sus siglas en ingls): A nivel de aplicacin posee la funcionalidad de realizar la desconexin-reconexin remota de MIs, adems de las destinadas a la gestin y representacin de los datos de

medicin (Meter Reading, Meter Events). Cada una de estas funcionalidades es una funcin miembros de la clase MDM-APP

implementada en C++. Adicionalmente, el nodo MDMS posee una base de datos en donde registra todas las mediciones enviadas

por el DC y que posteriormente, puede ser accedidas y utilizadas por un mdulo de programa de Respuesta de la Demanda. En la

Fig. 20 no se muestra la pila de protocolos de la aplicacin DLMS/COSEM, dado que se asume que en la red AMI existen nodos

intermedios (i.e. Concentradores de Datos), encargados de ejecutar la accin de desconexin o reconexin emitida por el

MDMS. En caso que se busque una comunicacin directa entre el MDMS y el MI, se debe anexar las capas DLMS/COSEM

correspondientes a la parte cliente al modelo del nodo MDMS.

Para todos los modelos de simulacin (Fig. 19 y Fig. 20), las capas resaltadas en color verde, junto con todos los objetos que

las contienen, son mdulos incorporados en ns-3; las dems son mdulos propios del simulador.

V. IMPLEMENTACIN EN NS-3

A. Simulador y lenguaje de programacin empleados

Para el presenta trabajo se ha escogido el simulador de eventos discretos (open-source) ns-3, desarrollado principalmente para

fines de investigacin y educacin (inici en 2006). Comparado a ns-2, es un simulador desarrollado desde cero y totalmente en

el lenguaje de programacin C++. Presenta una estructura modular y documentacin ms robusta, grandes ventajas ofrecidas a

los desarrolladores a la hora de integrar nuevos mdulos al simulador, a diferencia de ns-2, que se hace engorroso a la hora de

entender un mdulo ya existente o a la hora de ingresar uno nuevo.

Toda la implementacin del protocolo DLMS/COSEM, las aplicaciones AMI y ejemplos se encuentran documentados y

disponibles en el repositorio: https://code.google.com/p/dlms-cosem-ns-3/ .

En la carpeta model se encuentran los cdigos de cada una de las partes o sub-mdulos de los modelos de simulacin

propuestos. Por otra parte, la carpeta helper contiene los cdigos que facilitan la construccin y enlace de los diferentes sub-

mdulos de los nodos y aplicaciones AMI ofrecidas para una red AMI. Por ltimo, en la carpeta examples se disponen de

algunos script de simulacin para redes AMI implementadas sobre diferentes tecnologas de comunicaciones y el protocolo

DLMS/COSEM.

B. Procedimiento para incorporar el mdulo DLMS/COSEM en ns-3

Una vez descargado e instalado el simulador de redes ns-3 en una plataforma Linux (se recomienda la distribucin Ubuntu), se

debe seguir el procedimiento propuesto a continuacin, para la correcta incorporacin del mdulo DLMS/COSEM a ns-3:

1. Descargar el mdulo del repositorio https://code.google.com/p/dlms-cosem-ns-3/source/browse/#svn%2Ftrunk 2. Crear dentro del directorio src/ una carpeta con el nombre cosem e introducir las carpetas model, helper y examples con

todos los archivos .h y .cc que contienen.

3. Verificar en el archivo wscript (de la carpeta cosem) que se encuentren listadas todos las direcciones a los archivos .h y .cc que contiene las carpetas model y helper (los archivos .h o .cc que no se encuentren especificados en este wscript, no

sern tenidos en cuenta en el momento de la compilacin del mdulo, por tanto, se generar errores a la hora de ejecutar

el script de simulacin).

4. Copiar un ejemplo de la carpeta examples en la carpeta scratch. 5. Volver a compilar todo el paquete de ns-3 utilizando build.py u otro mtodo para la construccin y compilacin de ns-3

(remitirse al tutorial de ns-3).

6. Ejecutar el script de simulacin ejemplo, utilizando waf, para validar la correcta incorporacin del mdulo (no debera arrojar error alguno en el terminal. En caso contrario, repetir este procedimiento).

C. Ejemplos ilustrativos de implementacin en ns-3

Se tomarn como ejemplos la implementacin del mensaje de control (Fig. 11) y la construccin del nodo medidor inteligente

(Fig. 19) utilizar los helpers.

Ejemplo 1: Implementacin del Mensaje de Control

La Fig. 11 muestra la estructura establecida para los mensajes de control enviados por el nodo MDMS al nodo DC. Esta

estructura es codificada utilizando el API de ns-3 establecido para la definicin y construccin de encabezados (headers) del

mensaje o protocolo definidos por el desarrollador: Serialize, Deserialize y GetSerializeSize (ver cdigo). Serialize almacena los

campos del header en el buffer del packet creado, en el momento que se invoca el mtodo Packet::AddHeader, utilizando el

comando write; Deserialize hace el proceso inverso a Serialize al invocar el Packet::RemoveHeader; finalmente,

GetSerializeSize arroja el tamao en bytes establecido para el header definido. Por ltimo, los mtodos Get y Set permiten

acceder a los campos del header definidos en los atributos de la clase ControlMessageHeader.


15

Archivo cosem/model/dr-hearder.h

/*

* Control Message Header: CONTROL

*/

class ControlMessageHeader : public Header

{

public:

ControlMessageHeader ();

virtual ~ControlMessageHeader ();

static TypeId GetTypeId (void);

virtual TypeId GetInstanceTypeId (void) const;

virtual uint32_t GetSerializedSize (void) const;

virtual void Serialize (Buffer::Iterator start)

const;

virtual uint32_t Deserialize (Buffer::Iterator

start);

virtual void Print (std::ostream &os) const;

// Allow protocol-specific access to the header

void SetCommand (uint32_t command);

uint32_t GetCommand (void) const;

void SetCustomerId (uint16_t customerId);

uint16_t GetCustomerId ();

private:

uint32_t m_command; // Command: (4B)

uint16_t m_customerId; // Customer Id (2B)

};

Archivo cosem/model/dr-hearder.cc

/*--------------------------------------------------

* CONTROL MESSAGE

*--------------------------------------------------

*/

NS_OBJECT_ENSURE_REGISTERED (ControlMessageHeader);

TypeId

ControlMessageHeader::GetTypeId (void)

{

static TypeId tid = TypeId

("ns3::ControlMessageHeader")

.SetParent ()

.AddConstructor ()

;

return tid;

}

ControlMessageHeader::ControlMessageHeader ()

{

m_command = 0; // Disconnect Meter

m_customerId = 0;

}

ControlMessageHeader::~ControlMessageHeader ()

{

}

TypeId

ControlMessageHeader::GetInstanceTypeId (void) const

{

return GetTypeId ();

}

uint32_t

ControlMessageHeader::GetSerializedSize (void) const

{

return 6; // without the message id

}

void

ControlMessageHeader::Serialize (Buffer::Iterator

start) const

{

start.WriteHtonU32 (m_command);

start.WriteHtonU16 (m_customerId);

}

uint32_t

ControlMessageHeader::Deserialize (Buffer::Iterator

start)

{

Buffer::Iterator i = start;

m_command = i.ReadNtohU32 ();

m_customerId = i.ReadNtohU16 ();

return GetSerializedSize ();

}

void

ControlMessageHeader::Print (std::ostream &os) const

{

os


16

cosemServer.Install invoca los mtodos, que se describen brevemente en el archivo cosem/helper/udp-cosem-

server-helper.cc y se muestran a continuacin:

ApplicationContainer

UdpCosemServerHelper::Install (NodeContainer c)

{

ApplicationContainer apps;

for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)

{

// Retreive the pointer of the i-node storaged in the NodeContainer

Ptr node = *i;

// Add the CosemServerStack to the Node (i.e. UdpCosemWrapperServer & CosemAlServer)

AddCosemServerStack (node);

// Create a CosemApServerObject

Ptr cosemApServer = CreateObject ();

// Retrieve the pointer of the CosemAlServer that has previously aggregated to the node

Ptr cosemAlServer = node->GetObject ();

// Retrieve the pointer of the UdpCosemWrapperServer that has previously aggregated to the node

Ptr udpCosemWrapperServer = node->GetObject ();

// Add the CosemApServer created to the Node

node->AddApplication (cosemApServer);

// Set the pointer to the CosemAlServer object attached at the node

cosemApServer->SetCosemAlServer (cosemAlServer);

// Set the wPort

udpCosemWrapperServer->SetwPortServer (cosemApServer);

// Set the Udp Port listening by the CAL

cosemApServer->SetUdpport (4056);

// Set the Ip address assigned to the node

cosemApServer->SetLocalAddress (m_interface.GetAddress (m_index));

// Add the CosemApServer created to the ApplicationContainer

apps.Add (cosemApServer);

// Connect CosemAlServer and cosemApServer to each other

cosemAlServer->SetCosemApServer (cosemApServer);

cosemApServer->SetCosemAlServer (cosemAlServer);

m_index++;

}

return apps;

}

void

UdpCosemServerHelper::AddCosemServerStack (Ptr node)

{

// Create a UdpCosemWrapperServer

Ptr udpCosemWrapperServer = CreateObject ();

// Create a CosemAlServer Object

Ptr cosemAlServer = CreateObject ();

// Connect UdpCosemWrapperServer and CosemAlServer to each other

udpCosemWrapperServer->SetCosemAlServer (cosemAlServer);

cosemAlServer->SetCosemWrapperServer (udpCosemWrapperServer);

// Aggregate the UdpCosemWrapperServer to the node and set Ip Address and Udp Port number

node->AggregateObject (udpCosemWrapperServer);

udpCosemWrapperServer->SetUdpport (4056);

udpCosemWrapperServer->SetLocalAddress (m_interface.GetAddress(m_index));

// Aggregate the CosemAlServer to the node and set its state to CF_IDLE and Udp Port number

node->AggregateObject (cosemAlServer);

cosemAlServer->SetStateCf (1);

cosemAlServer->SetUdpport (4056);

}

Por ltimo, se anexa el modelo de interfaz COSEM al nodo SM creado, invocando en el script de simulacin las siguientes

lneas:

// COSEM Interface Model

SmartMeterCosemModelHelper cosemModel (serverApps);

cosemModel.Install (wifiStaNodes);

En la primera lnea se instancia un objeto SmartMeterCosemModelHelper, el cual usa el objeto de aplicacin COSEM Server

agregado al nodo SM. Al igual que la anterior configuracin, el cosemModel.Install instala el modelo de interfaz COSEM

al nodo SM, invocando los mtodos, que se describen brevemente en el archivo cosem/helper/sm-cosem-model-

helper.cc y que se muestran a continuacin:


17

void

SmartMeterCosemModelHelper::Install (NodeContainer c)

{

ApplicationContainer apps;

uint16_t j = 0; // counter of CosemServerApp created

for (NodeContainer::Iterator i = c.Begin (); i != c.End (); ++i)

{

// Retreive the pointer of the i-node storaged in the NodeContainer

Ptr node = *i;

/**

* Extended Register Class Object

*/

// Create CosemExtendedRegisterClass Object

Ptr cosemExtendedRegisterClass = CreateObject

();

// Set the CosemApServer object pointer attached at the node

Ptr app = m_serverApps.Get (j);

Ptr cosemApServer = app->GetObject ();

cosemExtendedRegisterClass->SetCosemApServer (cosemApServer);

cosemExtendedRegisterClass->SetNode (node);

// Initialize CosemExtendedRegisterClass parameters

cosemExtendedRegisterClass->Init ();

// Aggregate the CosemExtendedRegisterClass to the node

node->AggregateObject (cosemExtendedRegisterClass);

/**

* Profile Generic Class Object

*/

// Create CosemProfileGenericClass Object

Ptr cosemProfileGenericClass = CreateObject ();


cosemProfileGenericClass->SetCosemApServer (cosemApServer);

cosemProfileGenericClass->SetCaptureObjects (cosemExtendedRegisterClass);

// Initialize CosemProfileGenericClass parameters

cosemProfileGenericClass->Init ();

// Aggregate the CosemProfileGenericClass to the node

node->AggregateObject (cosemProfileGenericClass);

/**

* Disconnect Control Class

*/

// Create CosemDisconnectControlClass Object

Ptr cosemDisconnectControlClass =

CreateObject ();


cosemDisconnectControlClass->SetCosemApServer (cosemApServer);

// Set the disconnected unit state to CONNECTED state

cosemDisconnectControlClass->SetControlState (CONNECTED);

// Aggregate the CosemDisconnectControlClass to the node

node->AggregateObject (cosemDisconnectControlClass);

j ++;

}

}

VI. CONCLUSIONES Y TRABAJO FUTURO

En este documento se present los resultados de modelado e implementacin en ns-3 del protocolo de aplicacin

DLMS/COSEM para aplicaciones AMI, junto el modelo de interfaz COSEM para un medidor inteligente (Fig. 3), con

funcionalidades de medicin y desconexin-reconexin remota (soportada por un perfil de comunicaciones UDP/IP sobre Wi-Fi

y/o LTE). Adicionalmente, se present los modelos de simulacin para los componentes esenciales de una red AMI, teniendo en

cuenta el API de ns-3 (Fig. 19 y Fig. 20): Medidor Inteligente, Concentrador de Datos y Sistema de Gestin de Datos de

Medicin y todo lo referente al formato de los mensajes intercambiados y la interaccin entre ellos.

Para trabajo futuro se propone: (1) Modelar e implementar en ns-3 una aplicacin de respuesta de la demanda tipo precio,

utilizando el estndar DLMS/COSEM (modelo objetos y servicios), y (2) Extender el mdulo DLMS/COSEM para dar soporte

al manejo de eventos de alarmas a nivel de medicin y la lectura simultnea de medidores inteligentes. Por ltimo, proponer e

implementar un proceso de validacin del protocolo DLMS/COSEM y aplicaciones AMI, a travs de simulaciones de escenarios

realistas e interesantes para las empresas de energa.


18

ANEXO

A. Libreras introducidas a ns-3

a) Modelo de Interfaz COSEM

Nombre

Archivo

cosem-extended-register-class.h && .cc

cosem-profile-generic-class.h && .cc

cosem-disconnect-control-class.h && .cc

sm-cosem-model-helper.h && .cc

Ubicacin /src/cosem/model, /src/cosem/helper

Descripcin

Estas libreras, codificadas en C++ e incorporadas en ns-3, corresponden a las clases de interfaz (IC,

por sus siglas en ingls) (Extended Register, Profile Generic, Disconnect Control) que representan el

comportamiento de un medidor inteligente con funcionalidades de medicin y desconexin-

reconexin remota. Finalmente, las libreras del helper que conectan todos los objetos de las ICs para construir el modelo de interfaz COSEM.

b) Protocolo de aplicacin DLMS/COSEM

Nombre

Archivo

cosem-ap-client.h && .cc

cosem-al-client.h && .cc

udp-cosem-client.h && .cc

udp-cosem-client-helper.h && .cc

cosem-ap-server.h && .cc

cosem-al- server.h && .cc

udp-cosemserver.h && .cc

udp-cosem-server-helper.h && .cc


Descripcin

Estas libreras, codificadas en C++ e incorporadas en ns-3, corresponden a la pila de protocolo

DLMS/COSEM cliente/servidor (i.e. proceso de aplicacin, capa de aplicacin y sub-capa de

transporte UDP-Wrapper) bajo el perfil de comunicaciones UDP/IP. Finalmente, las libreras del

helper que conectan todos los objetos DLMS/COSEM y lo anexa a los nodos cliente/servidor.

c) Aplicaciones Concentrador de Datos (DC) y Sistema de Gestin de Datos de Medicin (MDMS)

Nombre

Archivo

dc-app.h && .cc

data-concentrator-helper.h && .cc

mdm-app.h && .cc

mdm-application-helper.h && .cc


Descripcin

Estas libreras, codificadas en C++ e incorporadas en ns-3, implementan los modelos de simulacin

de las aplicaciones DC y MDMS, los cuales son anexados a los nodos DC y MDMS a travs de las

libreras helper correspondientes.

d) Mensajes DLMS/COSEM, MDM

Nombre

Archivo

cosem-header.h && .cc

dr-header.h && .cc


Descripcin

Estas libreras, codificadas en C++ e incorporadas en ns-3, corresponden a la implementacin de los

mensajes DLMS/COSEM intercambiados entre los nodos medidor y concentrador de Datos o MDMS

y los mensajes transferidos entre los nodos DC y MDMS, en la gestin remota de los medidores

inteligentes dentro la red AMI.

REFERENCIAS

[1] Electricity metering-data exchange for meter reading, tariff and load control: IEC-62056 Parts 47, 53 and 62, IEC, 2006. [2] T. Otani, A Primary Evaluation for Applicability of IEC 62056 to A Next-Generation Power Grid, in 2010 First IEEE International Conference on Smart

Grid Communications (SmartGridComm), pp. 67-72.

[3] Electricity Metering Data Exchange The DLMS/COSEM Suite: IEC-62056 Part 6-2: COSEM Interface classes, IEC, Draft, 2010 [4] J. M. Aranda, Evaluacin del desempeo de una Red AMI implementada sobre las tecnologas PLC y HSDPA, Bogot: Tesis Magster, Universidad de

los Andes, 2012, pp. 1-148.

[5] K. Budka, et al. (2010). Communication Network Architecture and Design Principles for Smart Grids. Bell Labs Technical Journal 15 (2), 205-228. Acatel-Lucent. Wiley Periodicals, Inc.

(Spanish) Modelado e Implementación Del Protocolo DLMSCOSEM Para Aplicaciones AMI en Ns-3

Documents

Transcript of (Spanish) Modelado e Implementación Del Protocolo DLMSCOSEM Para Aplicaciones AMI en Ns-3