Implementación del protocolo TCP/IP sobre

un microcontrolador de 8 bits

Pablo Garcı́a Fernández

28 de mayo de 2002
 Resumen

La necesidad por parte de la industria de monitorizar las variables determinantes de su

proceso productivo, en lugares alejados de sus centros de control, realza la importancia
de sistemas de monitorización que dispongan de elementos para realizar la comunica-
ción de los datos. Esta se puede realizar aprovechando soluciones hardware externas,
lo que conlleva un coste mayor, o bien se puede adoptar la solución de integrar los
dispositivos para realizarla, reduciendo de esta manera tanto el coste como el espacio
necesario para su uso. En este trabajo se propone una solución de este último tipo,
basada en una arquitectura tipo microcontrolador, e incorporando un sistema de comu-
nicaciones válido tanto para transmisión sobre un enlace de radio como sobre Ethernet.
Para ello se ha desarrollado una pila TCP/IP simplificada sobre una arquitectura de 8
bits.
Índice general

1. Introducción 2

2. Descripción de la Arquitectura 4
2.1. RTUs de comunicación vı́a trunking . . . . . . . . . . . . . . . . . . 5
2.2. RTUs de comunicación por red Ethernet . . . . . . . . . . . . . . . . 5
2.3. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Microcontrolador en RTUs de tipo trunking (PIC16F876) . . . 6
2.3.2. Microcontrolador en RTUs de tipo Ethernet (PIC16F877) . . . 7

3. Descripción de la aplicación particular 8

3.1. Memoria de almacenamiento de datos . . . . . . . . . . . . . . . . . 8
3.1.1. Estructura interna de la memoria de almacenamiento de datos 10

4. Canales de Comunicación 13
4.1. Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Sistema MPT 1327 . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5. Protocolo de Comunicaciones 18
5.1. Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.1. Simplificaciones Protocolo IP . . . . . . . . . . . . . . . . . 19
5.1.2. Simplificaciones Protocolo TCP . . . . . . . . . . . . . . . . 21
5.2. Esquemas de comunicaciones tipo . . . . . . . . . . . . . . . . . . . 22
5.2.1. Comunicaciones de datos . . . . . . . . . . . . . . . . . . . . 23
5.2.2. Comunicaciones de alarmas . . . . . . . . . . . . . . . . . . 24
5.2.3. Comunicaciones de configuración . . . . . . . . . . . . . . . 25

6. Estructura de los paquetes 26

6.1. Mensajes de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Mensajes de alarma . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Mensaje de sincronización . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Mensajes de Parametrización . . . . . . . . . . . . . . . . . . . . . . 28

7. Conclusiones 31

1
Capı́tulo 1

Introducción

Las aplicaciones industriales que requieren el envı́o de información del estado de

cualquier fase de su proceso productivo hacia las instalaciones de control requieren la
aplicación de métodos de telemedida fiables y economicamente viables.
Las empresas eléctricas no son una excepción a esta regla. Las peculiaridades de
este negocio hacen que las diversas fases de la cadena productiva estén alejadas mucho
entre si y del centro de control. En particular, el proceso de distribución de la energı́a
eléctrica, conlleva la necesidad de la medida de diferentes parámetros que muestren el
estado de funcionamiento de la red. Actualmente se encuentran monitorizadas diversas
variables en la red de alta y media tensión, no existiendo ningún método continuo de
medida en la red de baja. Tradicionalmente, el método de medida empleado para la
carga de los transformadores situados entre la media y la baja tensión ( 20KV /380V
), venı́a siendo la comprobación de la corriente que circulaba por cada fase del trans-
formador en una fecha en la que se cree que el consumo es el mayor de todo el año,
normalmente la noche de nochebuena. Este método tiene diversos inconvenientes, entre
los que cabe destacar:

Proceso de medida manual.

Proceso de medida discontinuo

El método descrito ha acarreado diversos problemas a la compañı́a eléctrica, en-

tre los que se incluyen varios accidentes que supusieron la destrucción del Centro de
Transformación (C.T.) y el asumir fuertes indemnizaciones a los afectados por el acci-
dente.
Con el objetivo de subsanar esta laguna en el proceso de monitorización se procede
a desarrollar un sistema que cumpla las siguientes especificaciones:

Medida de parámetros eléctricos relativos al estado del C.T.

Gestión de diversas alarmas que se puedan dar en el C.T.
Envı́o de la información almacenada al centro de control, utilizando para ello
diversos canales de comunicación disponibles por la compañı́a.

Coste mı́nimo posible debido a lo numeroso de los centros en los que se ten-
ga que implementar esta tecnologı́a ( unos 1500 centros en el área central de
Asturias ).

2
La solución propuesta se basa en una arquitectura tipo microcontrolador a la cual llegan
las diversas señales del sistema y el cual es capaz de enviar la información al centro de
control.
Los canales de comunicación sobre los que se debe implementar la transmisión de
datos son muy diferentes entre si, y el sistema debe de ser capaz de utilizar los dos con
los mı́nimos cambios posibles en su diseño. Los medios utilizados son la comunicación
a través de la red de radio de la compañı́a y la utilización de la red de cable disponible
para su transmisión a través de Internet.

3
Capı́tulo 2

Descripción de la Arquitectura

El equipo remoto está compuesto de dos chips fundamentales: el microcontrolador,

que es el componente maestro de la placa electrónica donde se ejecuta el programa que
se encarga de registrar las corrientes de carga e inspeccionar el estado de las lı́neas de
alarma; y la memoria EEPROM en la cual se almacenan los datos de corrientes en las
fases recogidos por el microcontrolador.
Además, el equipo remoto dispone de diversa circuiterı́a electrónica que será dife-
rente dependiendo del tipo de comunicación que se vaya a utilizar: trunking ( enlace
radio ) o Ethernet.

Figura 2.1: Esquema general del prototipo diseñado

La Unidad Remota ( RTU ) dispone, entre otros elementos, de diversas bornas

para las entradas digitales (entradas de las señales de alarma 2.2(b)), bornas para las
entradas analógicas (entradas de las corrientes de fase a medir 2.2(a)), conector puerto
serie para la trasmisión de los datos vı́a trunking o conector RJ45 para la transmisión
Ethernet (dependiendo del tipo de comunicación), entrada de alimentación del equipo
y baterı́a de refuerzo.
La diferencia entre ambas versiones de RTUs está en la etapa de interface con el
medio por el cual se produce la transmisión de los datos. A grandes rasgos, el equipo
remoto de comunicación vı́a trunking dispone de un conector DB9 para puerto serie,
mientras que la RTU de comunicación con la red Ethernet dispone del correspondiente
conector RJ45. Ası́mismo, el microcontrolador utilizado en cada una de estas versiones
es distinto, ası́ como el número de bornas analógicas y digitales en cada equipo.

4
 (a) Esquema de las entradas analógicas (b) Esquema de las entradas digitales

Figura 2.2: Entradas al microcontrolador

2.1. RTUs de comunicación vı́a trunking

El microcontrolador que tienen incorporado es un PIC16F876 de Microchip, el cual
dispone de un conector puerto serie para la transmisión y recepción de los datos (con
toda la circuiterı́a necesaria para realizar la etapa de adaptación de niveles requerida
por la norma RS-232 de transmisión por el puerto serie, incluyendo un MAX238CNG
del fabricante Maxim que realiza esta adaptación).
El número de entradas analógicas disponibles es de 4 (para las corrientes por las
fases R, S, T y N), mientras que tendrán 5 entradas digitales para cablear los sensores
de alarma, de las cuales, en principio, sólo se utilizarán 4.
Las primeras versiones de los equipos remotos disponı́an de una entrada de alimen-
tación de 220 Vac. Posteriores implementaciones de estas RTUs eliminan esta última y
la sustituyen por una entrada de alimentación de 12 Vcc.

2.2. RTUs de comunicación por red Ethernet

En este caso, el microcontrolador utilizado es un PIC16F877 de Microchip, con las
mismas prestaciones que el utilizado para la versión trunking, pero con mayor capaci-
dad de conexión de periféricos, por su mayor número de pines. La etapa de intercone-
xión de estas RTUs con la red Ethernet se compone de un chip Crystal CS8900A de
la compañı́a Cirrus, que realiza las funciones de interface Ethernet entre el microcon-
trolador y la red externa, junto con la adaptación de niveles para la conexión mediante
conector RJ45 al exterior (realizada por medio de un transformador aislador). El fun-
cionamiento del controlador CS8900A y su interacción con el mircrocontrolador es,
descrito de forma breve, el siguiente:

5
 Cuando el controlador Ethernet CS8900A reciba una trama de la red, calculará su
CRC, y si este es válido, desencapsulará el contenido de la trama, filtrando la cabece-
ra Ethernet, e indicando al microcontrolador por medio de una lı́nea de interrupción
que se ha recibido un paquete. De este modo, el microcontrolador podrá leer de la
memoria del controlador el paquete ya desencapsulado y operar con él. A la inversa,
cuando el microcontrolador quiera enviar un paquete a través de la red Ethernet, lo
escribirá en el buffer del controlador y le dará una orden de envı́o, con lo que este últi-
mo lo encapsulará en tramas Ethernet y se encargará de enviarlo de modo transparente
al microcontrolador. La adaptación hacia el exterior del controlador se compone de un
transformador aislador 10BASET conexionado al conector RJ45 de interface con la red
Ethernet.
El número de entradas disponibles en las versiones Ethernet es 8 (se podrı́an cablear
dos transformadores al mismo equipo remoto), mientras que incorporan 6 entradas
digitales.
La alimentación de estos equipos se realizará siempre a 12 Vcc.

2.3. Microcontrolador
El microcontrolador es el circuito electrónico más importante de la RTU. Se en-
carga de ejecutar el programa que gestiona la recogida de las muestras de corrientes y
la detección de alarmas urgentes. Todos los periféricos conectados a él se comportan
como esclavos, siendo el microcontrolador quien gobierna todas las acciones, señales
y/o eventos que se pudieran producir en el equipo remoto en su instalación definitiva
en campo.
Dependiendo del tipo de RTU considerada (trunking o Ethernet), el microcontro-
lador incorporado a ella es distinto, básicamente en cuanto al número de pines totales
que presenta. De este modo, el microcontrolador usado en las RTUs trunking es un
PIC16F876 de la compañı́a Microchip, mientras que en las RTUs Ethernet se utiliza un
PIC16F877 del mismo fabricante.
La elección de estos microcontroladores para su integración en las RTUs se ha
basado en su fácil programación y bajo coste, que los hacen ideales para implementar
todo tipo de trabajos en aplicaciones industriales.

2.3.1. Microcontrolador en RTUs de tipo trunking (PIC16F876)

El microcontrolador incorporado en los equipos remotos de comunicación vı́a trun-
king es un PIC16F876 del fabricante Microchip, el cual posee las siguientes carac-
terı́sticas básicas:

Microcontrolador RISC (sólo posee 35 instrucciones).

Frecuencia de operación de hasta 20 MHz.

Arquitectura FLASH (programable y reprogramable eléctricamente, una nueva

programación borra la antigua).
8 K palabras de 14 bits de memoria de programa. 368 bytes de memoria de datos
RAM. 256 bytes de memoria de datos EEPROM.
Posibilidad de ejecutar 13 interrupciones de periféricos.

6
 3 puertos de entrada/salida de propósito general.
3 temporizadores. 2 puertos serie.
Conversor analógico/digital de 10 bits con capacidad para 5 entradas analógicas.
Se distribuye en diversos encapsulados de 28 pines.

2.3.2. Microcontrolador en RTUs de tipo Ethernet (PIC16F877)

El microcontrolador utilizado en las RTUs Ethernet posee las mismas caracterı́sti-
cas que el usado para las comunicaciones trunking. No obstante es el chip de más alto
nivel de la gama de microcontroladores FLASH del fabricante Microchip, en el cual
también se incluye el PIC16F876. Únicamente difiere de este en las siguientes carac-
terı́sticas básicas:

Posibilidad de ejecutar 14 interrupciones de periféricos.

5 puertos de entrada/salida de propósito general.
2 puertos serie y un puerto paralelo.
Conversor analógico/digital de 10 bits con capacidad para 8 entradas analógicas.
Se distribuye en diversos encapsulados de 40 pines.

El mayor número de puertos de propósito general que posee este microcontrola-

dor le hacen tener más pines, que se utilizan para aumentar el número de entradas
analógicas y digitales con respecto al microcontrolador utilizado para las RTUs trun-
king. Ası́mismo, también se usan patillas extras del PIC16F877 para realizar la comuni-
cación con el controlador Ethernet CS8900A, encargado de encapsular y desencapsular
las tramas que circularán por la red Ethernet, y que hará de interface entre esta red y el
propio microcontrolador.

7
Capı́tulo 3

Descripción de la aplicación
particular

El equipo remoto (RTU) es la tarjeta electrónica que se encarga de recoger los

datos de las corrientes de carga de los transformadores, y de registrar y comunicar las
posibles alarmas generadas en cada centro de transformación.
Como su propio nombre indica, la placa electrónica se instalará ”in situ”en cada
CT, de tal modo que exista un equipo remoto por cada transformador que quiera ser
analizado. Básicamente se comporta como un esclavo que atenderá exclusivamente a
las peticiones que le realice el programa principal (E.R.A.C.C.) instalado en un puesto
de control. Sólamente cuando se produzca alguna alarma en el CT en el cual se encuen-
tre situado el equipo remoto, este estará capacitado para establecer una comunicación
como maestro con el puesto de control con el fin de transmitir esta alarma, de tal modo
que sea convenientemente registrada y se actúe en consecuencia.
De otro lado, ha de señalarse que esta interacción o comunicación entre E.R.A.C.C.
y los equipos remotos puede realizarse de dos modos distintos: vı́a trunking o Ether-
net. Debido a estas dos posibilidades de comunicación, la arquitectura de las RTUs
será diferente dependiendo del medio de transmisión. En lo sucesivo, todas las refe-
rencias dadas servirán para ambas versiones, a no ser que se indique explı́citamente lo
contrario.
En los siguientes apartados se explicará con más detalle aspectos de las RTUs tales
como su arquitectura interna y su funcionamiento general.

3.1. Memoria de almacenamiento de datos

Las muestras recogidas de las corrientes de fase han de ser almacenadas para que
posteriormente puedan volcarse al puesto de control, desde el que se tratarán conve-
nientemente (almacenamiento en una base de datos) de tal modo que queden registra-
dos los consumos que se producen en los transformadores de los CTs de media/baja
tensión. Dichas muestras de corrientes recogidas por la RTU han de guardarse perma-
nentemente hasta que se reciba la petición de volcado. Por este motivo, se almacenarán
en una memoria EEPROM.
La memoria utilizada en el equipo remoto para depositar los datos de corrientes
muestreados por el microcontrolador será el chip 24LC64 de Microchip, cuya capaci-
dad es de 8 Kbytes. Se trata de una memoria EEPROM de comunicación por bus serie

8
 (a) Sensor de intrusismo colocado en la (b) Aspecto del Transformador con los
portilla de acceso al recinto. sensores de corriente.

(c) Aspecto del Armario de control con

el diseño hardware implementado.

Figura 3.1: Armario de control y sensores instalados.

I2C de bajo coste y pequeño tamaño que se conecta directamente al microcontrolador

a través de dos pines y se comportará como un esclavo para este. El chip utilizado es el
mismo en ambas versiones de RTUs (trunking o Ethernet).
La comunicación que se establece entre esta memoria y el microcontrolador se
hace a través del protocolo de comunicaciones I2C. La vı́a de interconexión entre los
dos equipos es un bus serie I2C que, básicamente, consta de dos hilos, uno para la señal
de reloj y el otro para la transmisión/recepción serie de los datos.
En esta memoria se almacenan dos tipos de datos: se guardarán las muestras de
corrientes de fase recogidas durante una semana (5376 bytes) ası́ como la estructura
completa de los paquetes que serán transaccionados durante una comunicación entre el
equipo remoto y el puesto de control. En esta memoria EEPROM, el microcontrolador
irá construyendo las tramas y paquetes TCP/IP que serán enviados al PC de control
cuando este solicite el envı́o de los datos requeridos, o cuando se produzca una alarma
que por iniciativa propia la RTU habrá de comunicar.
El número de paquetes o tramas a guardar en esta memoria será el siguiente:

21 paquetes de datos de 296 bytes cada uno, conteniendo las muestras de corrien-

9
 tes de fase recogidas durante una semana.
1 paquete extra o auxiliar de datos (296 bytes), para enviar cualquier otro tipo de
información que no sean datos de corrientes o códigos de alarmas generadas.
1 paquete de alarmas (44 bytes), conteniendo el código de la alarma generada.
1 paquete de sincronismo (44 bytes), paquete especial para el inicio de una co-
municación.
1 paquete de flags (40 bytes), para enviar como paquete de reconocimiento o de
final de una comunicación.

Ha de tenerse en cuenta que como la capacidad de la memoria es limitada, se re-

cogerán cı́clicamente datos de corrientes correspondientes a una semana (5376 bytes),
tras la cual, se almacenarán los nuevos datos sobrescribiendo los antiguos desde el
principio, siendo responsabilidad del usuario del programa que se ejecuta en el PC de
control (E.R.A.C.C.), ası́ como de la programación de las tareas automáticas de des-
carga a realizar por dicho programa, el solicitar una nueva petición de volcado de datos
antes de transcurrida una semana a partir de la última petición que se realizó, con el fin
de no perder datos para el registro que ya hayan sido sobrescritos por el microcontro-
lador en la memoria EEPROM del equipo remoto.

3.1.1. Estructura interna de la memoria de almacenamiento de da-

tos
La memoria EEPROM 24LC64 puede direccionar hasta 8 Kbytes de datos, por lo
que su rango de direcciones se establece entre 0000h y 1FFFh. En virtud de esta arqui-
tectura, la estructura interna de los paquetes que se irán almacenando en la memoria
EEPROM 24LC64 es la indicada en la tabla 3.1.
Una representación gráfica del mapa de la memoria EEPROM 24LC64 se puede
ver en la figura 3.2
Esta distribución de memoria es muy importante, debido a la capacidad que tiene la
memoria EEPROM para ser escrita de dos modos distintos: byte a byte, o por páginas
de hasta un máximo de 32 bytes cada una. En el diagrama anterior no se muestra una
relación a escala del tamaño de cada paquete; entiéndase la fila central de cada paquete
de datos (donde se encuentra escrito el nombre del paquete) como una comprensión de
bytes (en realidad, en dicha fila se están representando 7 u 8 bloques de 32 bytes por
paquete, dependiendo del paquete de que se trate). Lo que se pretende representar en
dicho gráfico, que es lo más importante, es la ”forma”de un paquete cualquiera dentro
del mapa de memoria, dividido en filas de 32 bytes, que es la longitud máxima que
puede ser escrita en un solo ciclo de escritura en la memoria EEPROM.
A la hora de escribir estos paquetes en la memoria, es preciso ajustarse a este mapa
de memoria, de tal modo que no se sobrepase nunca el lı́mite máximo de 32 bytes
que se pueden escribir (la explicación más detallada de este efecto se encuentra en
la documentación de la memoria EEPROM 24LC64). Por este motivo, este mapa de
memoria visualiza el byte de comienzo y el de fin de cada paquete con respecto a la fila
de 32 bytes donde se encuentra dicho byte. La dirección escrita dentro de cada paquete
corresponde a la dirección de comienzo de dicho paquete dentro de la memoria.
Puede comprobarse que tras los primeros 4 paquetes de datos, la distribución de los
paquetes comprendidos entre el número 5 y el 20 se repite cı́clicamente, en 4 bloques

10
 Tabla 3.1: Direcciones de los paquetes
PAQUETE Dirección de comienzo Dirección de final
o
Paquete n 1 de datos 0000h 0127h
Paquete no 2 de datos 0128h 024F h
Paquete no 3 de datos 0250h 0377h
Paquete no 4 de datos 0378h 049F h
Paquete no 5 de datos 04A0h 05C7h
Paquete no 6 de datos 05C8h 06EF h
Paquete no 7 de datos 06F 0h 0817h
Paquete no 8 de datos 0818h 093F h
Paquete no 9 de datos 0940h 0A67h
Paquete no 10 de datos 0A68hS 0B8F h
Paquete no 11 de datos 0B90h 0CB7h
Paquete no 12 de datos 0CB8h 0DDF h
Paquete no 13 de datos 0DE0h 0F 07h
Paquete no 14 de datos 0F 08h 102F h
Paquete no 15 de datos 1030h 1157h
Paquete no 16 de datos 1158h 127F h
Paquete no 17 de datos 1280h 13A7h
Paquete no 18 de datos 13A8h 14CF h
Paquete no 19 de datos 14D0h 15F 7h
Paquete no 20 de datos 15F 8h 171F h
Paquete no 21 de datos 1720h 1847h
Paquete extra (auxiliar de datos) 1848h 196F h
Paquete de alarmas 1970h 199Bh
Paquete de sincronismo 199Ch 19C7h
Paquete de flags 19C8h 19EF h

de igual número de paquetes. Los restantes se distribuyen a continuación de aquellos.

Las cabeceras de todos los paquetes serán escritas en la memoria por el programa que
se ejecuta en el microcontrolador en la inicialización de este.
Los distintos bytes correspondientes a cada paquete se repartirán como siguen:
Todos los paquetes de datos y el paquete auxiliar de datos: 296 bytes, de los cuales
40 son de cabecera TCP/IP y 256 de datos. Paquete de alarmas: 44 bytes (40 de ca-
becera y 4 para datos). Paquete de sincronismo: 44 bytes (los 44 corresponderán a la
cabecera TCP/IP, serán los 40 usuales más 4 bytes de opciones). Paquete de flags: 40
bytes, todos ellos de cabecera.
En resumen, y sobre un total de 8 Kb (8192 bytes) de capacidad de la memoria
EEPROM, se están ocupando 6640 bytes, de los cuales 5376 corresponden a los datos
de las corrientes de carga de los transformadores que se pretenden medir.

11
 Tabla 3.2: Distribución en memoria de los paquetes.

Dirección 8 bytes 8 bytes 8 bytes 8 bytes

0x0000 0x0000
Paquete de Datos 1
0x128
Paquete de Datos 2
0x250
Paquete de Datos 3
0x378
Paquete de Datos 4

0x04A0

Paquetes de Datos 5 . . . 20

0x1720 0x1720
Paquete de Datos 21
0x1848
Paquete Extra ( Auxiliar de Datos )
0x1970
Paquete Extra ( Auxiliar de Alarmas ) 0x199C
Paquete de Sincronismo
0x19C8 Paquete de Flags
0x19F 0
0x1A00 Paquete de Alarmas

12
Capı́tulo 4

Canales de Comunicación

4.1. Trunking
El canal de comunicación Trunking es un medio de transmisión mediante enlace
de radio, cuyo mecanismo de control hace referencia al reparto automático de canales
en un sistema de múltiples repetidores. Las ventajas de este sistema son un menor
tiempo de acceso al medio y una capacidad por canal mas alta para una determinada
calidad de servicio. Se trata de un canal de comunicación basado en la idea de circuitos
conmutados de los canales telefónicos tradicionales.
Las presunciones realizadas por el sistema para realizar este tipo de control son las
siguientes:
Cada usuario usa el sistema un tiempo reducido.
No existen un gran número de usuarios usando el sistema al mismo tiempo.
La figura 4.3 muestra el tráfico existente en un sistema de 5 canales y la probabili-
dad de que los cinco canales estén ocupados simultáneamente.
Como se puede ver, si un canal es reservado para un único usuario, la probabilidad
de ques esté ocupado es mucho mayor que si se emplea de modo truncado
Los sistemas de radio trunking cuentan con dos tipos de canales

Canal de control. Es el encargado de comunicar las diferentes unidades de radio

y el ordenador de control.
Canales de tráfico. Canales usados para establecer las comunicaciones entre los
diferentes usuarios del sistema.

El esquema de inicio de una conexión es el siguiente

Cada unidad de radio escucha de manera continua el canal de control

Cuando se desea iniciar una transmisión, se activa el contacto PTT ( push to talk
). El equipo envı́a un mensaje a través del canal de control, solicitando un canal
para llevar a cabo la continuación.

El ordenador de control asigna un canal para realizar la comunicación mediante

el envı́o de un mensaje por el canal de control.

13
 (a) Sistema trunking de 5 canales y probabilidad de ocu-
pación de todos ellos de manera simultánea.

(b) Retraso en % frente a % de ocupación.

Figura 4.1: Sistema trunking de 5 canales.

Cuando el equipo de radio recibe la información del canal asignado, sintoniza

sus frecuencias de transmisión y recepción a la del nuevo canal.

Se desarrolla un pequeño protocolo de inicio de comunicación.

Una señal audible indica que la transmisión puede comenzar.

Figura 4.2: Modelo Nokia R40 utilizado en el desarrollo del proyecto

14
4.1.1. Sistema MPT 1327
En el caso de la red trunking de Hidroeléctrica del Cantábrico, el sistema utilizado
es el sistema estándar público MPT 1327[1], desarrollado por el Departamento de
Comercio e Industria del Reino Unido. Las principales caracterı́sticas del canal de
control, son las descritas en la tabla 4.1

Tabla 4.1: Caracterı́sticas del canal de control.

Velocidad de transmisión 1200bps
Modulación FFSK
Frecuencia de valor ’1’ 1200 Hz
Frecuencia de valor ’0’ 1800 Hz

El canal de control se encuentra dividido en ranuras de 128 bits cada uno, dado que
la velocidad de transmisión es de 1200bps, la duración de cada ranura es de 107ms.
Las instrucciones que se envı́an en cada uno de los paquetes incluyen las siguientes:
ALOHA. La estación base se encuentra preparada para recibir una petición de
llamada.
ALOHY. La estación base está llamando a un dispositivo de la red.
ACKNOWLEDGE. El mensaje ha sido recibido.
CLEAR. Fin de la llamada.
GO TO CHANNEL. Indica a un dispositivo que cambie su canal
REQUEST. Petición de un dispositivo a la estación base para comenzar una
llamada.
El mecanismo de acceso al medio, para el canal de control, es un pseudo Aloha
ranurado. Mediante este mecanismo se remite a los dispositivos del sistema las dife-
rentes ranuras de tiempo disponibles para acceder al canal de control. En el caso en que
exista mas de una disponible, es el propio dispositivo el que elige, de manera aleatoria,
la ranura en la que envı́a el mensaje.
La secuencia tı́pica de inicio de transmisión es la siguiente:
Un dispositivo desea contactar con otro o un grupo de ellos.
El dispositivo que desea realizar la llamada escucha por el canal de control el
mensaje de ALOHA, seleccionando la ranura para transmitir.
En el momento apropiado, se transmite un mensaje de REQUEST con la identi-
ficación del otro dispositivo o del grupo de ellos.
La estación base retransmite un mensaje de AHOY con la identidad de el/los
dispositivo/s requeridos.
El dispositivo que realiza la llamada sabe que su petición ha sido atendida me-
diante la escucha del mensaje AHOY.
El dispositivo receptor escucha el mensaje AHOY y transmite un mensaje ACK-
NOWLEDGE hacia la estación base.

15
 La estación base transmite un mensaje GO TO CHANNEL a todos los dispositi-
vos involucrados en la transferencia.
El canal de control en este tipo de sistemas puede estar configurado de dos maneras
Canal dedicado. El canal de control solo transmite información relativa al estado
del sistema
Canal no dedicado. El canal se puede usar también para tráfico, ya sea de voz o
de datos.
En el caso de la aplicación desarrollada, todas las comunicaciones se realizaron a
través del canal de control, al estar configurado como un canal no dedicado. La solución
comercial usada fue el equipo Actionetr[2] de Nokiar, y en concreto se utilizó el
modelo R40 de la misma compañı́a para acceder a la red Trunking ( ver foto 4.2 ),
usando un modem estándar de modulación FFSK como interface entre el puerto serie
y el equipo de radio. Las caracterı́sticas básicas del conjunto modem - radio empleados
son las siguientes
Comunicación half duplex.
Contro de flujo hardware. Para conseguir activar el contacto PTT del equipo de
radio, el modem debe de mantener activada la lı́nea RTS hasta que reciba un CLS
por parte de la radio. El tiempo muerto necesario entre la recepción del CLS y el
envı́o del primer caracter fue ajustado experimentalmente a un valor de 100ms.

4.2. Ethernet
Con la intención de aprovechar la red de cable de la compañı́a como medio para
realizar la comunicación entre los diferentes C.T. y el ordenador de control, se puso
como requerimiento al prototipo desarrollado el que fuera capaz de intercambiar datos
a través de una red Ethernet. Como alternativas al interface entre el microcontrolador
y la red, se barajaron dos opciones:
Empleo de dispositivo comercial que hiciera el interface entre el puerto serie y la
red Ethernet, encontrándose dentro de él todo la pila TCP/IP y el el encapsulado
en tramas Ethernet.

Empleo de circuiterı́a que realizara únicamente el encapsulado en tramas Ether-

net, quedando la implementación del protocolo TCP/IP a cargo del microcontro-
lador
De las dos alternativas se escogió la segunda, basándose principalmente en criterios
económicos.
Con objeto de aislar la red local constituida para la conexión de todas las RTUs de
la red local general, el departamento de informática de la compañı́a estableció una red
virtual, garantizando de esta manera la seguridad de la red interna.

16
(a) Se solicita el inicio de una trans- (b) Se asigna un canal libre para la co-
ferencia de datos, mediante el pulsado municación a todos los integrantes del
del PTT grupo.

(c) Desarrollo de la transferencia. (d) Fin de la transferencia.

(e) Liberación del canal.

Figura 4.3: Esquema de comunicación trunking.

17
Capı́tulo 5

Protocolo de Comunicaciones

La implementación del protocolo de comunicaciones se valoró en un primer mo-

mento desde dos alternativas:
1. Implementación de un protocolo propietario
2. Utilización de un protocolo estándar
Las ventajas de la primera de las alternativas estaban basadas en la flexibilidad que
se podrı́a obtener, pudiendo realizar un protocolo que se adaptara completamente a
las especificaciones requeridas. Como principal desventaja se encontraba su posterior
adaptación para la comunicación a través de Internet.
Para solucionar el problema de la primera de las opciones, se buscó la existencia de
alguna solución hardware que permitiera realizar un interface entre una comunicación
serie y una red ethernet. En el mercado existen varias opciones, siendo una de las
mas interesantes la propuesta por la empresa Lantronixr. Esta marca dispone de un
interface serie/Ethernet que dispone en su interior de una implementación completa del
protocolo TCP/IP, ası́ como del encapsulado posterior en tramas Ethernet. El aspecto
de este dispositivo se puede ver en las figuras 5.1. El problema de este dispositivo es el
precio por unidad ( ' 200e).
La segunda de las alternativas tenı́a, en contraposición con la anterior, una menor
flexibilidad en cuanto a las caracterı́sticas del protocolo. Sin embargo su utilización era
mucho mas atractiva desde el punto de vista económico, solucionándose el interface
con la red Ethernet mediante el empleo de un chip dedicado y una circuiteria adicional
de bajo coste ( ' 80e)[3] ( ver figura 5.2 ). Basándose en que éste era uno de los
requerimientos sobre lo que mas se habı́a insistido, debido al alto número de unidades
a desarrollar, se adoptó la segunda de las opciones.
Una vez decidido el realizar la comunicación basándose en el uso de un protocolo
estándar, se procede a definir las necesidades

5.1. Protocolo TCP/IP

El protocolo implementado ha sido una versión simplificada del conjunto de pro-
tocolos TCP/IP, usados como soporte para conocidas aplicaciones de Internet, como
pueden ser el ftp y el correo electrónico. Para realizar las implementaciones se acu-
dió a los RFC’s correspondientes a cada protocolo ( RFC IP: 760, RFC TCP: 761 ),

18
 (a) Aspecto de interface puerto serie - (b) Esquema de la solución de Lantro-
Ethernet de la casa Lantronix.Solución nix
de alto coste

Figura 5.1: Interface puerto serie - Ethernet de la casa Lantronix

y se realizaron una serie de simplificaciones, con objeto de hacer posible el desarrollo

sobre una arquitectura tan simple.

5.1.1. Simplificaciones Protocolo IP

Las especificaciones del protocolo IP se encuentran en el RFC 760. Para desarrollar
la implementación sobre el microcontrolador se realizaron algunas simplificaciones so-
bre el mismo, con objeto de disminuir la complejidad del código. La mas importante de
las modificaciones realizadas es la referente en cuanto al mecanismo de fragmentación
implementado en el protocolo.
Dado que la longitud de los mayores paquetes de datos a transmitir, es lo suficien-
temente pequeña ( 296 bytes ) como para asegurar que no iban a sufrir ningún tipo de
fragmentación, no se realizó la implementación de ningún mecanismo de fragmenta-
ción. 1 Para asegurar que los paquetes no se fragmentaran se introdujo la opción de no
fragmentar en el campo Flags de la cabecera.
Otras simplificaciones menores realizadas se detallan sobre los campos del data-
grama IP de la figura 5.1

VER. Versión del protocolo. La versión actual del mismo es la V 4.

LON. Longitud en unidades de 4 octetos de la cabecera.
TIPO SERVICIO. El valor de este campo se refiere a la calidad del servicio
proporcionada. El valor de este campo se ignora en la implementación realizada.
LONGITUD TOTAL. Longitud total del datagrama, medida en octetos, incluidos
datos y cabecera.
IDENTIFICACIÓN: 0 Campos relativos a la fragmentación de paquetes, en
nuestro caso este campo no es interpretado, al no estar implementada la frag-
mentación en el protocolo.
1 El tamaño máximo de paquete está muy alejado del máximo permitido en una red Ethernet, que es de

1526 bytes, por lo que el suprimir el mecanismo de fragmentación es una simplificación aceptable.

19
 (a) Tarjeta para la interconexión del (b) Tarjeta para la interconexión del
Chip de Crystal al Microcontrolador. Chip de Crystal al Microcontrolador.

Figura 5.2: Solución Ethernet embebida.

Tabla 5.1: Cabecera IP.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
Ver Lon Tipo de Servicio Longitud Total
Identificación Flags Desplazamiento
TTL Protocolo Checksum
Dirección IP Fuente
Dirección IP Destino
Opciones Relleno
Datos
...

FLAGS. Campo con tres bits relativos a la fragmentación del datagrama. Con
el valor uno en el segundo de los bits se indica que el paquete no debe de ser
fragmentado.

DESPLAZAMIENTO. Campo relativo al desplzamiento del paquete actual re-

ferido al total, en una trama framentada. No implementado.
TTL. El valor de este campo indica el tiempo de vida del paquete en la red. Dado
que la comunicación entre los diferentes nodos de la aplicación y el ordenador
de control se iba a realizar a través de una red virtual dedicada, el valor de este
campo carece de importancia.
PROTOCOLO. Indicador del protocolo, en nuestro caso protocolo TCP.
CHECKSUM. Algoritmo para comprobar que no existen errores en los valores
de los campos de la cabecera. No comprueba los datos del paquete.

DIRECCIÓN IP FUENTE. Identificación del emisor del mensaje. Este campo es

comprobado por el microcontrolador para asegurarse de que la trasmisión tiene
como origen el ordenador de control.

20
 DIRECCIÓN IP DESTINO. Destinatario del datagrama. El valor de este campo
es comprobado por los nodos situados en los CT como medio para reconocer a
quien se dirige la trama. En el caso de emplear como medio de comunicación
el canal trunking, y al estar configurados todos los nodos dentro de un mismo
grupo, el microcontrolador solo debe de responder en el caso en el que la trama
tenga su dirección IP.
OPCIONES. El valor de este campo no se ha usado en la implementación del
protocolo.

5.1.2. Simplificaciones Protocolo TCP

Sobre la capa IP, cuya implementación se ha explicado en el apartado anterior, se
construye la capa de transporte TCP. Mediante el empleo del protocolo TCP se consi-
gue que sea el propio protocolo el encargado de asegurar la fiabilidad en las comuni-
caciones, mediante el empleo de números de secuencia y acuses de recibo numerados,
asegurando que todos los paquetes son recibidos y retransmitiéndolos en caso contra-
rio. Por otro lado, gracias al mecanismo de multiplexado basado en puertos, se obtiene
una manera de diferenciar los diferentes tipos de comunicaciones ( datos y alarmas ).
Las simplificaciones de mayor importancia introducidas en el protocolo son las relati-
vas a la no implementación del algoritmo de ventana deslizante, al empleo en todos los
paquetes de datos de la opción EOL ( End of letter ) con objeto de asegurar la respuesta
individual a cada paquete y el no uso del campo de opciones.
Otra de las modificaciones realizadas se refiere al mecanismo de reintentos en caso
de fallo en la transmisión. En las especificaciones del protocolo, se especifica que el
responsable del envı́o de un mensaje debe de reenviarlo en caso de no recibir un acuse
de recibo del mismo. En la implementación realizada, el emisor no debe realizar ningún
reintento a no ser que el receptor se lo solicite mediante el envı́o de un mensaje que
contenga como número de ACK el que corresponde al número de secuencia del reenvı́o.
Las simplificaciones menores se comentan sobre los comentarios de los campos del
datagrama TCP. El formato del datagrama es el indicado en la figura 5.2

Tabla 5.2: Cabecera TCP.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
Puerto Fuente Puerto Destino
Número de Secuencia
Número de ACK
Desp Res Código Ventana
Checksum Puntero Urgente
Opciones Relleno
Datos
...

Los valores de los diferentes campos de la cabecera son los enumerados a conti-
nuación
PUERTO FUENTE. Número de puerto del origen de datos. Su uso es debido a
la posibilidad de multiplexar varias comunicaciones de datos. En nuestra apli-
cación, se asignaron números de puerto configurables para la comunicación de

21
 datos y para los diferentes tipos de alarma, siendo estos puertos configurables
por el usuario.
PUERTO DESTINO. Número de puerto del destino de datos.
NÚMERO DE SECUENCIA. Número de secuencia del primer octeto del data-
grama. Existen indicaciones de como elegir el valor inicial del número de se-
cuencia, de manera que no se puedan repetir a lo largo de una comunicación. En
nuestro caso, y dado que las comunicaciones de datos son cortas, simplemente se
hace corresponder el número inicial con el de puerto de la comunicación actual.
NÚMERO DE ACK. Número de secuencia del siguiente paquete que se espera
recibir.
DESP. Desplazamiento en unidades de 4 bytes hasta el comienzo de los datos.
RES. Espacio reservado para usos futuros, debe de tener el valor cero.
CÓDIGO. Bits de control. El único uso especial en nuestra implementación es el
bit de EOL (End of Letter ), el cual indica que se ha llegado al final del segmento
actual, obligando al protocolo TCP a pasar los datos a la capa superior. De esta
manera se evita que el protocolo acumule varios paquetes antes de enviarlos a
la capa de aplicación, obligando de esta manera a que cada paquete enviado
por el microcontrolador sea respondido de manera individual. Con este flag, se
simplifica la implementación del protocolo en el micro, evitando el tener que
mantener una cola con los paquetes enviados hasta la recepción de un ACK
WINDOW. Número de octetos de datos, a partir del número indicado en el ACK,
que el cliente puede aceptar. Este número se utiliza para la implementación del
algoritmo de ventana deslizante del protocolo, que en nuestro caso no ha sido im-
plementado, ya que el número de paquetes aceptado es uno ( tamaño del buffer
de entrada del microcontrolador ). Para evitar que la implementación del proto-
colo realizada por el ordenador inunde la del micro, se ha utilizado el flag EOL
en todos los paquetes de datos.
CHECKSUM. Checksum de cabecera y datos.
PUNTERO URGENTE. No implementado.
OPCIONES. No implementadas.

5.2. Esquemas de comunicaciones tipo

En el sistema de comunicaciones desarrollado, se pueden producir tres tipos de
comunicaciones. La primera de ellas es la comunicación de datos. Esta modo de fun-
cionamiento se produce cuando el ordenador de control requiere a la unidad remota los
datos de las corrientes recogidas. Durante la misma se podrán realizar también otras
operaciones, como pueden ser la configuración de la unidad remota y la consulta del
estado de las alarmas. El segundo tipo de intercambio de información es el producido
cuando el C.T. tiene que comunicar alguna incidencia. Este tipo de comunicación es de
mucha mayor importancia que la de datos, por lo que el mecanismo de reintentos es di-
ferente. Por último se encuentran las comunicaciones relacionadas con la configuración
de parámetros, las cuales son iniciadas por el ordenador de control.

22
5.2.1. Comunicaciones de datos
El esquema tipo de una comunicación de datos es el mostrado en las siguientes
figuras. Una conversación para el intercambio de datos comienza cuando el ordenador
de control requiere a cualquiera de las unidades remotas los valores de la curva de carga
del transformador. Es por tanto, una comunicación que se inicia por parte del ordenador
de control, y que se vera finalizada cuando se reciba el ultimo paquete de datos, si no
se produce ningun error en la misma. El inicio tı́pico, en ausencia de errores, es el
mostrado en la figura 5.3. A continuación el ordenador envı́a un mensaje de saludo,
que en caso de ser reconocido como un patrón correcto por la unidad remota, permite
el inicio de la transacción. Finalmente, y como ultimo de los procesos de inicio de la
comunicación, se procede a realizar las configuraciones que sean necesarias. En caso de
que no se desee realizar ninguna, se envı́a el paquete que contiene como datos la cadena
”FINCONF”, pudiendo comenzar el intercambio de información; segun el esquema de
la figura 5.6. Como se ve en el esquema anterior, el final de la comunicación se produce
cuando la unidad remota envı́a un último paquete de datos, el cual contiene el bit de
FIN activado.

Figura 5.3: Inicio de la comunicación de datos.

Figura 5.4: Mensaje de saludo enviado por el ordenador de control.

23
 Figura 5.5: Esquema de una comunicación de configuración.

Figura 5.6: Recepción de los datos almacenados en la unidad remota.

5.2.2. Comunicaciones de alarmas

El esquema tipo de una comunicación de alarmas es el mostrado en las figuras 5.7,
5.8. 2
Una de las principales caracterı́sticas del funcionamiento de este tipo de comuni-
cación, es el mecanismo de reintentos. Debido a la urgencia que puede suponer el co-
nocimiento, por parte del sitema de control, de una alarma, se introduce un mecanismo
de reintentos formado por dos bucles. El primero de ellos está reintentando establecer
la conexión durante 10 veces a intervalos regulares de 10 segundos. En caso de que
no lo consiga, espera tres minutos y repite el ciclo anterior. Este último ciclo se repite
5 veces, y en el caso de que no se consiga enviar la alarma se almacena en un buffer
interno. Las alarmas almacenadas en el buffer ( hasta un total de cinco ) son enviadas
al ordenador de control cuando se produzca por parte de éste una petición de datos.
2 En los diagramas representados se ha supuesto que no habı́a ninguna comunicación activa en ese mo-
mento. En caso de que asi fuera, la unidad remota enviarı́a un paquete con el bit RST activo, a fin de obligar
a terminar la comunicación actual y poder realizar el envı́o de la alarma.

24
 Figura 5.7: Inicio de la conexión de alarmas.

Figura 5.8: Envı́o del mensaje de alarma al ordenador de control.

5.2.3. Comunicaciones de configuración

El esquema tipo de una comunicación de configuracion es el mismo que el mos-
trado en la figura 5.5. Las comunicaciones de configuracion se pueden realizar en el
transcurso de una de datos. Para ello se ha creado el mensaje que contiene como datos
la cadena ”FINCONF”, de este modo todo mensaje que preceda a esta cadena se su-
ponde de configuracion, no comenzando la unidad remota a trasnmitir datos hasta que
haya recibido este paquete.

25
Capı́tulo 6

Estructura de los paquetes

Como último punto del estudio del protocolo desarrollado, se muestra la estructura
de los paquetes intercambiados entre el equipo remoto y el PC de control. Todos los
paquetes que enviará la RTU estarán almacenados en la memoria EEPROM externa
24LC64 en la forma que se ha citado en el apartado Memoria de almacenamiento de
datos.

6.1. Mensajes de datos

Aunque los mensajes de datos no pueden ser considerados como mensajes de pa-
rametrización, se incluyen también en este apartado con el fin de estudiar con un poco
más de detalle su estructura.
Estos mensajes serán los enviados por la RTU cuando el control solicite informa-
ción sobre las curvas de carga. Los mensajes tendrán una longitud total de 296 bytes,
siendo 40 de ellos correspondientes a las cabeceras y 256 correspondientes a los datos.
Los datos de las curvas de carga corresponderán a las medias de las corrientes
de las tres fases y neutro recogidas cada minuto y almacenadas cada cuarto de hora.
La estructura de almacenamiento de una muestra (recogida cada 15 minutos) es la
siguiente:

Tabla 6.1: ESTRUCTURA MENSAJE DE DATOS

Irh Iri Ish Isi Ith Iti Inh Ini

Se han representado los datos las corrientes por las fases R, S, T y neutro respecti-
vamente. Los ı́ndices h y l hacen referencia al byte alto y bajo del valor de la corriente
correspondiente. Como la capacidad de un paquete de datos es de 256 bytes, en él irán
contenidos, manteniendo siempre la secuencia antes representada, los valores corres-
pondientes a 32 muestras recogidas a intervalos de 15 minutos, es decir, a las muestras
de corrientes almacenadas en un intervalo de 8 dı́as. En los 3 primeros paquetes de da-
tos irán contenidos los valores relativos a un dı́a completo, mientras que en la totalidad
de los 21 paquetes se almacenarán los datos recogidos durante una semana.

26
6.2. Mensajes de alarma
Son los mensajes enviados por el equipo remoto cuando se produce una alarma. Los
mensajes tendrán una longitud de 48 bytes, correspondiendo 40 de ellos a cabecera y 8
a datos.
Los datos enviados serán el código de alarma (en el primer byte), más la fecha y
hora en que se ha generado la alarma (7 bytes restantes). Los códigos de las diferentes
alarmas se muestran en la siguiente tabla:

Tabla 6.2: CÓDIGOS DE ALARMA

Alarma Código
Reset 0x110
Incendio 0x111
Sobretemperatura 0x112
Fusión del fusible de MT 0x113
Inundación 0x114
Intrusismo 0x115

La estructura del campo datos de cada paquete será la siguiente: Los bytes corres-

Tabla 6.3: ESTRUCTURA MENSAJES DE ALARMA

CodigoAlarma AN OH AN OL M ES DIA HORA M IN U T O SEGU N DO

pondientes al campo fecha y hora tienen el siguiente significado:

AN OH : Byte alto del número de año
AN OL : Byte bajo del número de año
M ES: Número de mes

DIA: Número de dı́a

HORA: Número de hora
M IN U T O: Número de minuto
SEGU N DO: Número de segundo

6.3. Mensaje de sincronización

Es un mensaje enviado por E.R.A.C.C. para ordenar el sincronismo de los relojes
del computador y el equipo remoto. Tendrá una longitud de 48 bytes, siendo 40 de ellos
de cabecera y 8 de datos.
La estructura de este mensaje es la siguiente:

27
 Tabla 6.4: ESTRUCTURA MENSAJES DE SINCRONIZACIÓN

Bytedecontrol : 0X54 AN OH AN OL M ES DIA HORA M IN U T O SEGU N DO

El campo byte de control contendrá el carácter T de Time (código ASCII 54h).

Indicará que el mensaje enviado es de sincronización de fecha y hora. El resto de bytes
corresponde a la nueva fecha que se enviará. Esta fecha será la que tenga el PC de
control si el mensaje es enviado por este, de tal modo que sirva de fecha de sincronismo
para la RTU. Si el mensaje es enviado por esta como contestación a un mensaje de
sincronismo de E.R.A.C.C., contendrá la fecha recibida desde este (si es el primer
mensaje de sincronización) o la fecha que tenga en ese momento el reloj interno del
equipo remoto (para los posteriores mensajes de sincronización).

6.4. Mensajes de Parametrización

Mensaje de configuración IP
Para cambiar la dirección IP del equipo remoto, o que este conozca una nueva
dirección IP del puesto de control donde se ejecutará E.R.A.C.C., se enviará un mensaje
de 48 bytes de longitud total, de los cuales 8 bytes será de datos. La estructura de cada
byte de datos será la siguiente:

Tabla 6.5: ESTRUCTURA MENSAJES DE CONFIGURACIÓN IP

DireccionEEP ROM N umerodebytes IP1 IP2 IP3 IP4 ND ND

Los distintos bytes del campo datos de cada paquete tienen el siguiente significado:

DireccionEEP ROM : Dirección de comienzo de la EEPROM interna del mi-

crocontrolador, donde se encuentra almacenada la dirección IP a configurar. La
dirección a enviar será la dirección 00h, dirección a partir de la cual residen los
cuatro bytes de dirección de la RTU, o la dirección 04h, con lo que se reconfigu-
rará para el equipo remoto un posible cambio en la dirección IP del PC de control.
Puede obtenerse más información acerca de la distribución de estas direcciones
en el apartado Mapa de memoria EEPROM interna del microcontrolador.

N umerodebytes : Número de bytes a escribir en la EEPROM interna del mi-

crocontrolador. Este campo se usa como parámetro en la función de escritura
en dicha EEPROM. Su valor habrá de ser 4, que es el número de bytes que se
configurarán (serán los 4 bytes que vendrán a continuación en el mensaje, que
compondrán la dirección IP a configurar).

IP1 : Octeto más significativo de la dirección IP a configurar.

IP2 : Siguiente octeto de la dirección IP.

28
 IP3 : Tercer octeto de la dirección IP.
IP4 : Octeto menos significativo de la dirección IP a configurar.
N D : Byte sin ningún significado dentro del mensaje. Puede ser cualquier valor.

Mensaje de configuración de puertos

La posibilidad de poder configurar los puertos de comunicación dependerá de la
capacidad de almacenamiento en memoria de programa disponible para el microcon-
trolador. En principio, para las RTUs de comunicación vı́a trunking no se contempla
la posibilidad de configurar estos parámetros. Para los equipos Ethernet tampoco se
contempla esta posibilidad, si es factible mantener los números de puerto fijos. En
cualquiera de los casos, ha de informarse mejor en el código fuente sobre la implemen-
tación o no de esta caracterı́stica.
La estructura de estos mensajes será similar a la de los mensajes de configuración
de las direcciones IP, sólo que en este caso el número de puerto ocupará únicamente
dos bytes. La estructura es la siguiente:

Tabla 6.6: ESTRUCTURA MENSAJES DE CONFIGURACIÓN DE PUERTOS

DireccionEEP ROM N umerodebytes P uertoH P uertoL ND ND ND ND

Los distintos bytes del campo datos de cada paquete de configuración de puertos
tienen el siguiente significado:

DireccionEEP ROM : Dirección de comienzo de la EEPROM interna del mi-

crocontrolador, donde se encuentran almacenados los números de puertos tem-
porales (véase el mapa de memoria EEPROM interna del microcontrolador). La
dirección a enviar en este byte será la siguiente: Estas direcciones correspon-

Tabla 6.7: DIRECCIONES EEPROM DE LOS PUERTOS

Puerto Dirección EEPROM

Puerto de datos 0x14
Puerto de alarma 1 (incendio) 0x16
Puerto de alarma 2 (sobretemperatura) 0x18
Puerto de alarma 3 (fusión del fusible MT) 0x1A
Puerto de alarma 4 (inundación) 0x1C
Puerto de alarma 5 (intrusismo) 0x1E

den a las direcciones de comienzo reservadas en la memoria EEPROM interna

donde almacenar los nuevos datos de configuración para los puertos. Durante
una comunicación entre E.R.A.C.C. y una RTU se pueden configurar los puer-
tos de comunicación, pero no pueden ser cambiados durante el transcurso de la
propia comunicación de configuración, si no que esto tendrá que realizarse una

29
 vez finalice dicha comunicación. Por lo tanto, si el equipo remoto detecta que
está recibiendo un mensaje de este tipo, almacenará estos parámetros en las di-
recciones temporales de su EEPROM interna, y continuará la comunicación por
el mismo número de puerto que lo estaba haciendo. Una vez que vuelva al estado
CLOSED, entonces copiará los parámetros escritos en las direcciones tempora-
les en las direcciones correspondientes (fijas) de la misma memoria EEPROM.
La próxima comunicación que se establezca ya será realizada a través de los
números de puerto que se le hayan pasado previamente.
N umerodebytes : Número de bytes a escribir en la EEPROM interna del mi-
crocontrolador. Este campo se usa como parámetro en la función de escritura en
dicha EEPROM. Su valor habrá de ser en este caso 2, que es el número de bytes
que se configurarán (serán los 2 bytes que vendrán a continuación en el mensaje,
que compondrán el número de puerto a configurar).
P uertoH : Octeto más significativo del número de puerto a configurar.
P uertoL : Byte menos significativo del número de puerto.
N D : Byte sin ningún significado dentro del mensaje. Puede ser cualquier valor.

Mensaje de fin de configuración (petición de volcado de datos)

Este mensaje se enviará después de todos los mensajes de configuración que hayan
podido ser enviados. Su recepción por parte de la RTU indicará a esta que la orden de
petición de volcado de datos procedente de E.R.A.C.C. se ha generado, por lo que el
equipo remoto ha de enviar, en primer lugar y si las hubiese, las alarmas no comunica-
das almacenadas en el buffer de alarmas, y luego todos los paquetes de datos. Será un
mensaje de 47 bytes, con 7 bytes de datos. Los datos contendrán la cadena de caracteres
FINCONF.

Mensaje de bienvenida
En todas las comunicaciones establecidas entre E.R.A.C.C. y cualquier RTU, y en
el sentido descrito (PC de control -¿Equipo remoto), se enviará un mensaje especial de
bienvenida que habrá de ser reconocido por la RTU antes de proseguir en la comuni-
cación. El mensaje de bienvenida contendrá 47 bytes, de los cuales 7 son datos. Estos
serán la cadena de caracteres HELLOHC, que se interpretará como dicho mensaje de
bienvenida. Si este no es enviado por el PC, o la recepción no es correcta, la RTU no
contestará a petición del puesto de mando. La razón de ser de este mensaje es que sirve
para establecer un pequeño filtro de acceso a cada equipo remoto, con el fin de que las
RTUs Ethernet no puedan ser accedidas fácilmente a través de la red por equipos no
autorizados. Aunque para los equipos remotos trunking esta especificación no es im-
portante, se sigue manteniendo por compatibilidad en el código fuente empleado para
ambas versiones.

30
Capı́tulo 7

Conclusiones

En el presente trabajo se ha expuesto una solución válida y flexible para comunicar

un ( o varios ) dispositivos remotos con un centro de control. Aunque la aplicación
realizada está particularizada para el caso estudiado, es factible realizar pequeñas mo-
dificaciones para adaptarla a otros requerimientos. La solución elegida presenta las
siguientes ventajas e inconvenientes
Solución flexible. El hecho de haber realizado una implementación que permite
tanto la comunicación mediante enlace de radio o red Ethernet, medios muy
diferentes entre si, muestra la flexibilidad del prototipo.
Bajo costo. El alto número de unidades a desarrollar hacı́a que el precio fuera un
factor determinante en la solución elegida. Como se ha expuesto en anteriores
apartados, la implementación escogida tiene un importante ahorro frente a otras
alternativas
Protocolo complejo. El hecho de haber realizado un protocolo complejo, como
es el TCP/IP, para un medio como es el enlace de radio, hace que las comunica-
ciones sean mas lentas que con otra implementación mas sencilla ( una comuni-
cación con los datos de una semana dura en torno a los dos minutos ). Posibles
soluciones a esto pasan por el uso de un protocolo no orientado a conexión, como
UDP.
Alto uso de memoria de programa por parte del protocolo de comunicaciones.
Esta limitación hace que futuras ampliaciones del software del microcontrolador
sean complejas de llevar a cabo.

31
Bibliografı́a

[1] “http://www.radio.gov.uk/publication/mpt/mpt3.htm,” Especificaciones del

estándar MPT1327.
[2] “http://www.roboteks.com/actionet.htm,” Introducción al sistema Actionet.
[3] “http://www.embeddedethernet.com/,” Conexión de un microcontrolador a una
LAN.
[4] “http://www.winradio.com/home/trunking theory.htm,” Introducción al Trun-
king.

[5] “http://www.genesisworld.com/trunking.htm,” Enlaces Trunking.

[6] “http://www.signalharbor.com/ttt/00jan/index.html,” Introducción al Trunking.
[7] “http://www.roboteks.com/pmr.htm,” Ejemplo de un sistema basado en el pro-
ducto Actionet.

[8] “http://www.signalharbor.com/ttt/00feb/index.html,” Funcionamiento de un siste-

ma Trunking.
[9] “Dod standard internet protocol,” Request for comment del protocolo IP.
[10] “Dod standard transmission control protocol,” Request for comment del protocolo
TCP.

32