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
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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

UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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)
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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
- l ogi cal _name: octet_stri ng
- val ue: unsi gned l ong
- scal ar_uni t: unsi gned l ong ([1])
- status: unsi gned l ong
- capture_ti me: octet_stri ng
+ reset(i nt) : voi d
class Disconnect control
Disconnect Control
- l ogi cal _name: octect-stri ng
- output_state: bool ean
- control _state: i nt
- control _mode: i nt
+ remote_di sconnect(i nt) : voi d
+ remote_reconnect(i nt) : voi d
class Domain Obj ects
Profile Generic
- l ogi cal _name: octet-stri ng
- buffer: array
- capture_obj ects: array
- capture_peri od: doubl e-l ong-unsi gned
- sort_method: enum
- sort_obj ect: capture_obj ect_ defi ni ti on
- entri es_i n_use: doubl e-l ong-unsi gned
- profi l e_entri es: doubl e-l ong-unsi gned
+ reset(i nt) : voi d
+ capture(i nt) : voi d
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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 script
3
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.
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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 capas
5
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.
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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)
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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)





UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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.

UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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.
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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-53
6
. 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.
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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-3
7
. 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)
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 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
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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.


UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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<Header> ()
.AddConstructor<ControlMessageHeader> ()
;
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 << "Command " << m_command
<< "Customer Id - Meter Address " <<
m_customerId;
}

void
ControlMessageHeader::SetCommand (uint32_t command)
{
m_command = command;
}

uint32_t
ControlMessageHeader::GetCommand (void) const
{
return m_command;
}

Ejemplo 2: Construccin nodo Medidor I nteligente utilizando los helpers
El nodo medidor inteligente (Fig. 19) se compone de tres partes: tecnologa e interface de comunicaciones, pila de protocolos
DLMS/COSEM y el modelo de interfaz COSEM.
Una vez creado el nodo ns-3 y configurado su interfaz de comunicaciones (para este ejemplo Wi-Fi sobre IPv4), se procede a
instalar el protocolo de aplicacin DLMS/COSEM invocado en el script de simulacin las siguientes lneas:

// Cosem Applications Servers
UdpCosemServerHelper cosemServer (serverInterfaces);
ApplicationContainer serverApps = cosemServer.Install (wifiStaNodes);

En la primera lnea se instancia un objeto UdpCosemServerHelper, el cual usa la interfaz IP anexada al nodo SM para su
creacin. En la segunda lnea, se instala al nodo estacin Wi-Fi (i.e. al nodo SM) toda la pila de protocolo DLMS/COSEM. El
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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> node = *i;
// Add the CosemServerStack to the Node (i.e. UdpCosemWrapperServer & CosemAlServer)
AddCosemServerStack (node);

// Create a CosemApServerObject
Ptr<CosemApServer> cosemApServer = CreateObject<CosemApServer> ();
// Retrieve the pointer of the CosemAlServer that has previously aggregated to the node
Ptr<CosemAlServer> cosemAlServer = node->GetObject<CosemAlServer> ();
// Retrieve the pointer of the UdpCosemWrapperServer that has previously aggregated to the node
Ptr<UdpCosemWrapperServer> udpCosemWrapperServer = node->GetObject<UdpCosemWrapperServer> ();
// 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> node)
{
// Create a UdpCosemWrapperServer
Ptr<UdpCosemWrapperServer> udpCosemWrapperServer = CreateObject<UdpCosemWrapperServer> ();
// Create a CosemAlServer Object
Ptr<CosemAlServer> cosemAlServer = CreateObject<CosemAlServer> ();
// 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:
UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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> node = *i;

/**
* Extended Register Class Object
*/
// Create CosemExtendedRegisterClass Object
Ptr<CosemExtendedRegisterClass> cosemExtendedRegisterClass = CreateObject<CosemExtendedRegisterClass>
();
// Set the CosemApServer object pointer attached at the node
Ptr<Application> app = m_serverApps.Get (j);
Ptr<CosemApServer> cosemApServer = app->GetObject<CosemApServer> ();
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> cosemProfileGenericClass = CreateObject<CosemProfileGenericClass> ();
// Set the CosemApServer object pointer attached at the node
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> cosemDisconnectControlClass =
CreateObject<CosemDisconnectControlClass> ();
// Set the CosemApServer object pointer attached at the node
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.

UNIVERSIDAD DE LOS ANDES GRUPO TELECOMUNICACIONES UNIANDES JULIO 2013

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-cosem- server.h && .cc
udp-cosem-server-helper.h && .cc
Ubicacin /src/cosem/model, /src/cosem/helper
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
Ubicacin /src/cosem/model, /src/cosem/helper
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
Ubicacin /src/cosem/model, /src/cosem/helper
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.