Implementaci n del protocolo TCP/IP sobre o un microcontrolador de 8 bits

Pablo Garca Fern ndez a 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 comunicao ci n de los datos. Esta se puede realizar aprovechando soluciones hardware externas, o lo que conlleva un coste mayor, o bien se puede adoptar la soluci n de integrar los o 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 ultimo tipo, o basada en una arquitectura tipo microcontrolador, e incorporando un sistema de comunicaciones v lido tanto para transmisi n sobre un enlace de radio como sobre Ethernet. a o Para ello se ha desarrollado una pila TCP/IP simplicada sobre una arquitectura de 8 bits.

 Indice general
1. Introducci n o 2. Descripci n de la Arquitectura o 2.1. RTUs de comunicaci n va trunking . . . . . . . . . . . . . . . . o 2.2. RTUs de comunicaci n por red Ethernet . . . . . . . . . . . . . . o 2.3. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Microcontrolador en RTUs de tipo trunking (PIC16F876) . 2.3.2. Microcontrolador en RTUs de tipo Ethernet (PIC16F877) . . . . . . . . . . . 2 4 5 5 6 6 7 8 8 10 13 13 15 16 18 18 19 21 22 23 24 25 26 26 27 27 28 31

3. Descripci n de la aplicaci n particular o o 3.1. Memoria de almacenamiento de datos . . . . . . . . . . . . . . . . . 3.1.1. Estructura interna de la memoria de almacenamiento de datos 4. Canales de Comunicaci n o 4.1. Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Sistema MPT 1327 . . . . . . . . . . . . . . . . . . . . . . . 4.2. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Protocolo de Comunicaciones 5.1. Protocolo TCP/IP . . . . . . . . . . . . . 5.1.1. Simplicaciones Protocolo IP . . 5.1.2. Simplicaciones Protocolo TCP . 5.2. Esquemas de comunicaciones tipo . . . . 5.2.1. Comunicaciones de datos . . . . . 5.2.2. Comunicaciones de alarmas . . . 5.2.3. Comunicaciones de conguraci n o 6. Estructura de los paquetes 6.1. Mensajes de datos . . . . . . 6.2. Mensajes de alarma . . . . . 6.3. Mensaje de sincronizaci n . o 6.4. Mensajes de Parametrizaci n o 7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Captulo 1

Introducci n o
Las aplicaciones industriales que requieren el envo de informaci n del estado de o cualquier fase de su proceso productivo hacia las instalaciones de control requieren la aplicaci n de m todos de telemedida ables y economicamente viables. o e Las empresas el ctricas no son una excepci n a esta regla. Las peculiaridades de e o este negocio hacen que las diversas fases de la cadena productiva est n alejadas mucho e entre si y del centro de control. En particular, el proceso de distribuci n de la energa o el ctrica, conlleva la necesidad de la medida de diferentes par metros que muestren el e a 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 o u e medida en la red de baja. Tradicionalmente, el m todo de medida empleado para la e carga de los transformadores situados entre la media y la baja tensi n ( 20KV /380V o ), vena siendo la comprobaci n de la corriente que circulaba por cada fase del trans o formador en una fecha en la que se cree que el consumo es el mayor de todo el a o, n normalmente la noche de nochebuena. Este m todo tiene diversos inconvenientes, entre e 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, ene n e tre los que se incluyen varios accidentes que supusieron la destrucci n del Centro de o Transformaci n (C.T.) y el asumir fuertes indemnizaciones a los afectados por el accio dente. Con el objetivo de subsanar esta laguna en el proceso de monitorizaci n se procede o a desarrollar un sistema que cumpla las siguientes especicaciones: Medida de par metros el ctricos relativos al estado del C.T. a e Gesti n de diversas alarmas que se puedan dar en el C.T. o Envo de la informaci n almacenada al centro de control, utilizando para ello o diversos canales de comunicaci n disponibles por la compa a. o n Coste mnimo posible debido a lo numeroso de los centros en los que se ten ga que implementar esta tecnologa ( unos 1500 centros en el area central de Asturias ). 2

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

Captulo 2

Descripci n de la Arquitectura o
El equipo remoto est compuesto de dos chips fundamentales: el microcontrolador, a que es el componente maestro de la placa electr nica donde se ejecuta el programa que o se encarga de registrar las corrientes de carga e inspeccionar el estado de las lneas 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 circuitera electr nica que ser difea o a rente dependiendo del tipo de comunicaci n que se vaya a utilizar: trunking ( enlace o radio ) o Ethernet.

Figura 2.1: Esquema general del prototipo dise ado n 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 n entradas anal gicas (entradas de las corrientes de fase a medir 2.2(a)), conector puerto o serie para la trasmisi n de los datos va trunking o conector RJ45 para la transmisi n o o Ethernet (dependiendo del tipo de comunicaci n), entrada de alimentaci n del equipo o o y batera de refuerzo. La diferencia entre ambas versiones de RTUs est en la etapa de interface con el a medio por el cual se produce la transmisi n de los datos. A grandes rasgos, el equipo o remoto de comunicaci n va trunking dispone de un conector DB9 para puerto serie, o mientras que la RTU de comunicaci n con la red Ethernet dispone del correspondiente o conector RJ45. Asmismo, 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. u o 4

(a) Esquema de las entradas anal gicas o

(b) Esquema de las entradas digitales

Figura 2.2: Entradas al microcontrolador

2.1.

RTUs de comunicaci n va trunking o

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 o o toda la circuitera necesaria para realizar la etapa de adaptaci n de niveles requerida o por la norma RS-232 de transmisi n por el puerto serie, incluyendo un MAX238CNG o del fabricante Maxim que realiza esta adaptaci n). o El n mero de entradas anal gicas disponibles es de 4 (para las corrientes por las u o fases R, S, T y N), mientras que tendr n 5 entradas digitales para cablear los sensores a de alarma, de las cuales, en principio, s lo se utilizar n 4. o a Las primeras versiones de los equipos remotos disponan de una entrada de alimen taci n de 220 Vac. Posteriores implementaciones de estas RTUs eliminan esta ultima y o la sustituyen por una entrada de alimentaci n de 12 Vcc. o

2.2.

RTUs de comunicaci n por red Ethernet o

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 capacio dad de conexi n de perif ricos, por su mayor n mero de pines. La etapa de interconeo e u xi n de estas RTUs con la red Ethernet se compone de un chip Crystal CS8900A de o la compa a Cirrus, que realiza las funciones de interface Ethernet entre el microconn trolador y la red externa, junto con la adaptaci n de niveles para la conexi n mediante o o conector RJ45 al exterior (realizada por medio de un transformador aislador). El funcionamiento del controlador CS8900A y su interacci n con el mircrocontrolador es, o descrito de forma breve, el siguiente: 5

Cuando el controlador Ethernet CS8900A reciba una trama de la red, calcular su a CRC, y si este es v lido, desencapsular el contenido de la trama, ltrando la cabecea a ra Ethernet, e indicando al microcontrolador por medio de una lnea de interrupci n o que se ha recibido un paquete. De este modo, el microcontrolador podr leer de la a memoria del controlador el paquete ya desencapsulado y operar con el. A la inversa, cuando el microcontrolador quiera enviar un paquete a trav s de la red Ethernet, lo e escribir en el buffer del controlador y le dar una orden de envo, con lo que este ultia a mo lo encapsular en tramas Ethernet y se encargar de enviarlo de modo transparente a a al microcontrolador. La adaptaci n hacia el exterior del controlador se compone de un o 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 podran cablear u dos transformadores al mismo equipo remoto), mientras que incorporan 6 entradas digitales. La alimentaci n de estos equipos se realizar siempre a 12 Vcc. o a

2.3.

Microcontrolador

El microcontrolador es el circuito electr nico m s importante de la RTU. Se eno a 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 el se comportan o e como esclavos, siendo el microcontrolador quien gobierna todas las acciones, se ales n y/o eventos que se pudieran producir en el equipo remoto en su instalaci n denitiva o en campo. Dependiendo del tipo de RTU considerada (trunking o Ethernet), el microcontrolador incorporado a ella es distinto, b sicamente en cuanto al n mero de pines totales a u 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 n PIC16F877 del mismo fabricante. La elecci n de estos microcontroladores para su integraci n en las RTUs se ha o o basado en su f cil programaci n y bajo coste, que los hacen ideales para implementar a o 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 va truno king es un PIC16F876 del fabricante Microchip, el cual posee las siguientes caractersticas b sicas: a Microcontrolador RISC (s lo posee 35 instrucciones). o Frecuencia de operaci n de hasta 20 MHz. o Arquitectura FLASH (programable y reprogramable el ctricamente, una nueva e programaci n borra la antigua). o 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. e

3 puertos de entrada/salida de prop sito general. o 3 temporizadores. 2 puertos serie. Conversor anal gico/digital de 10 bits con capacidad para 5 entradas anal gicas. o o 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 caractersti cas que el usado para las comunicaciones trunking. No obstante es el chip de m s alto a nivel de la gama de microcontroladores FLASH del fabricante Microchip, en el cual tambi n se incluye el PIC16F876. Unicamente diere de este en las siguientes carace tersticas b sicas: a Posibilidad de ejecutar 14 interrupciones de perif ricos. e 5 puertos de entrada/salida de prop sito general. o 2 puertos serie y un puerto paralelo. Conversor anal gico/digital de 10 bits con capacidad para 8 entradas anal gicas. o o Se distribuye en diversos encapsulados de 40 pines. El mayor n mero de puertos de prop sito general que posee este microcontrolau o dor le hacen tener m s pines, que se utilizan para aumentar el n mero de entradas a u anal gicas y digitales con respecto al microcontrolador utilizado para las RTUs truno king. Asmismo, tambi n se usan patillas extras del PIC16F877 para realizar la comuni e caci n con el controlador Ethernet CS8900A, encargado de encapsular y desencapsular o las tramas que circular n por la red Ethernet, y que har de interface entre esta red y el a a propio microcontrolador.

Captulo 3

Descripci n de la aplicaci n o o particular

El equipo remoto (RTU) es la tarjeta electr nica que se encarga de recoger los o datos de las corrientes de carga de los transformadores, y de registrar y comunicar las posibles alarmas generadas en cada centro de transformaci n. o Como su propio nombre indica, la placa electr nica se instalar in situen cada o a 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 a 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 encueno tre situado el equipo remoto, este estar capacitado para establecer una comunicaci n a o como maestro con el puesto de control con el n de transmitir esta alarma, de tal modo que sea convenientemente registrada y se act e en consecuencia. u De otro lado, ha de se alarse que esta interacci n o comunicaci n entre E.R.A.C.C. n o o y los equipos remotos puede realizarse de dos modos distintos: va trunking o Ether net. Debido a estas dos posibilidades de comunicaci n, la arquitectura de las RTUs o ser diferente dependiendo del medio de transmisi n. En lo sucesivo, todas las refea o rencias dadas servir n para ambas versiones, a no ser que se indique explcitamente lo a contrario. En los siguientes apartados se explicar con m s detalle aspectos de las RTUs tales a a 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 convea nientemente (almacenamiento en una base de datos) de tal modo que queden registrados 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 permao nentemente hasta que se reciba la petici n de volcado. Por este motivo, se almacenar n o a 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 capacia dad es de 8 Kbytes. Se trata de una memoria EEPROM de comunicaci n por bus serie o 8

(a) Sensor de intrusismo colocado en la portilla de acceso al recinto.

(b) Aspecto del Transformador con los sensores de corriente.

(c) Aspecto del Armario de control con el dise o hardware implementado. n

Figura 3.1: Armario de control y sensores instalados. I2C de bajo coste y peque o tama o que se conecta directamente al microcontrolador n n a trav s de dos pines y se comportar como un esclavo para este. El chip utilizado es el e a mismo en ambas versiones de RTUs (trunking o Ethernet). La comunicaci n que se establece entre esta memoria y el microcontrolador se o hace a trav s del protocolo de comunicaciones I2C. La va de interconexi n entre los e o dos equipos es un bus serie I2C que, b sicamente, consta de dos hilos, uno para la se al a n de reloj y el otro para la transmisi n/recepci n serie de los datos. o o En esta memoria se almacenan dos tipos de datos: se guardar n las muestras de a 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 a o 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 a a cuando este solicite el envo de los datos requeridos, o cuando se produzca una alarma que por iniciativa propia la RTU habr de comunicar. a El n mero de paquetes o tramas a guardar en esta memoria ser el siguiente: u a 21 paquetes de datos de 296 bytes cada uno, conteniendo las muestras de corrien9

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. o o 1 paquete de alarmas (44 bytes), conteniendo el c digo de la alarma generada. o 1 paquete de sincronismo (44 bytes), paquete especial para el inicio de una comunicaci n. o 1 paquete de ags (40 bytes), para enviar como paquete de reconocimiento o de nal de una comunicaci n. o Ha de tenerse en cuenta que como la capacidad de la memoria es limitada, se recoger n cclicamente datos de corrientes correspondientes a una semana (5376 bytes), a tras la cual, se almacenar n los nuevos datos sobrescribiendo los antiguos desde el a 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 o a carga a realizar por dicho programa, el solicitar una nueva petici n de volcado de datos o antes de transcurrida una semana a partir de la ultima petici n que se realiz , con el n o o de no perder datos para el registro que ya hayan sido sobrescritos por el microcontrolador en la memoria EEPROM del equipo remoto.

3.1.1. Estructura interna de la memoria de almacenamiento de datos

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 arquitectura, la estructura interna de los paquetes que se ir n almacenando en la memoria a EEPROM 24LC64 es la indicada en la tabla 3.1. Una representaci n gr ca del mapa de la memoria EEPROM 24LC64 se puede o a ver en la gura 3.2 Esta distribuci n de memoria es muy importante, debido a la capacidad que tiene la o memoria EEPROM para ser escrita de dos modos distintos: byte a byte, o por p ginas a de hasta un m ximo de 32 bytes cada una. En el diagrama anterior no se muestra una a relaci n a escala del tama o de cada paquete; enti ndase la la central de cada paquete o n e de datos (donde se encuentra escrito el nombre del paquete) como una comprensi n de o bytes (en realidad, en dicha la se est n representando 7 u 8 bloques de 32 bytes por a paquete, dependiendo del paquete de que se trate). Lo que se pretende representar en dicho gr co, que es lo m s importante, es la formade un paquete cualquiera dentro a a del mapa de memoria, dividido en las de 32 bytes, que es la longitud m xima que a 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 lmite m ximo de 32 bytes a que se pueden escribir (la explicaci n m s detallada de este efecto se encuentra en o a la documentaci n de la memoria EEPROM 24LC64). Por este motivo, este mapa de o memoria visualiza el byte de comienzo y el de n de cada paquete con respecto a la la de 32 bytes donde se encuentra dicho byte. La direcci n escrita dentro de cada paquete o corresponde a la direcci n de comienzo de dicho paquete dentro de la memoria. o Puede comprobarse que tras los primeros 4 paquetes de datos, la distribuci n de los o paquetes comprendidos entre el n mero 5 y el 20 se repite cclicamente, en 4 bloques u

10

Tabla 3.1: Direcciones de los paquetes PAQUETE Direcci n de comienzo Direcci n de nal o o 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 ags 19C8h 19EF h de igual n mero de paquetes. Los restantes se distribuyen a continuaci n de aquellos. u o Las cabeceras de todos los paquetes ser n escritas en la memoria por el programa que a se ejecuta en el microcontrolador en la inicializaci n de este. o Los distintos bytes correspondientes a cada paquete se repartir n como siguen: a 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 cabecera y 4 para datos). Paquete de sincronismo: 44 bytes (los 44 corresponder n a la a cabecera TCP/IP, ser n los 40 usuales m s 4 bytes de opciones). Paquete de ags: 40 a a 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 a de las corrientes de carga de los transformadores que se pretenden medir.

11

Tabla 3.2: Distribuci n en memoria de los paquetes. o Direcci n o 0x0000 8 bytes 8 bytes 0x0000 Paquete de Datos 1 0x128 Paquete de Datos 2 0x250 Paquete de Datos 3 Paquete de Datos 4 0x04A0 Paquetes de Datos 5 . . . 20 8 bytes 8 bytes

0x378

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 Paquete de Alarmas

0x1A00

12

Captulo 4

Canales de Comunicaci n o
4.1. Trunking
El canal de comunicaci n Trunking es un medio de transmisi n mediante enlace o o de radio, cuyo mecanismo de control hace referencia al reparto autom tico de canales a en un sistema de m ltiples repetidores. Las ventajas de este sistema son un menor u 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 o conmutados de los canales telef nicos tradicionales. o 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. u La gura 4.3 muestra el tr co existente en un sistema de 5 canales y la probabilia dad de que los cinco canales est n ocupados simult neamente. e a Como se puede ver, si un canal es reservado para un unico usuario, la probabilidad de ques est ocupado es mucho mayor que si se emplea de modo truncado e 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 co. Canales usados para establecer las comunicaciones entre los a diferentes usuarios del sistema. El esquema de inicio de una conexi n es el siguiente o 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 o ). El equipo enva un mensaje a trav s del canal de control, solicitando un canal e para llevar a cabo la continuaci n. o El ordenador de control asigna un canal para realizar la comunicaci n mediante o el envo de un mensaje por el canal de control.

13

(a) Sistema trunking de 5 canales y probabilidad de ocupaci n de todos ellos de manera simult nea. o a

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

Figura 4.1: Sistema trunking de 5 canales. Cuando el equipo de radio recibe la informaci n del canal asignado, sintoniza o sus frecuencias de transmisi n y recepci n a la del nuevo canal. o o Se desarrolla un peque o protocolo de inicio de comunicaci n. n o Una se al audible indica que la transmisi n puede comenzar. n o

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 e a es el sistema est ndar p blico MPT 1327[1], desarrollado por el Departamento de a u Comercio e Industria del Reino Unido. Las principales caractersticas del canal de control, son las descritas en la tabla 4.1 Tabla 4.1: Caractersticas del canal de control. Velocidad de transmisi n o Modulaci n o Frecuencia de valor 1 Frecuencia de valor 0 1200bps FFSK 1200 Hz 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. o o Las instrucciones que se envan en cada uno de los paquetes incluyen las siguientes: ALOHA. La estaci n base se encuentra preparada para recibir una petici n de o o llamada. ALOHY. La estaci n base est llamando a un dispositivo de la red. o a 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 o o 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 diferentes 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 enva el mensaje. La secuencia tpica de inicio de transmisi n es la siguiente: o 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 identicaci n del otro dispositivo o del grupo de ellos. o La estaci n base retransmite un mensaje de AHOY con la identidad de el/los o dispositivo/s requeridos. El dispositivo que realiza la llamada sabe que su petici n ha sido atendida meo diante la escucha del mensaje AHOY. El dispositivo receptor escucha el mensaje AHOY y transmite un mensaje ACKNOWLEDGE hacia la estaci n base. o 15

La estaci n base transmite un mensaje GO TO CHANNEL a todos los dispositio vos involucrados en la transferencia. El canal de control en este tipo de sistemas puede estar congurado de dos maneras Canal dedicado. El canal de control solo transmite informaci n relativa al estado o del sistema Canal no dedicado. El canal se puede usar tambi n para tr co, ya sea de voz o e a de datos. En el caso de la aplicaci n desarrollada, todas las comunicaciones se realizaron a o trav s del canal de control, al estar congurado como un canal no dedicado. La soluci n e o comercial usada fue el equipo Actionet [2] de Nokia , y en concreto se utiliz el o modelo R40 de la misma compa a para acceder a la red Trunking ( ver foto 4.2 ), n usando un modem est ndar de modulaci n FFSK como interface entre el puerto serie a o y el equipo de radio. Las caractersticas b sicas del conjunto modem - radio empleados a son las siguientes Comunicaci n half duplex. o Contro de ujo hardware. Para conseguir activar el contacto PTT del equipo de radio, el modem debe de mantener activada la lnea RTS hasta que reciba un CLS por parte de la radio. El tiempo muerto necesario entre la recepci n del CLS y el o envo 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 o n realizar la comunicaci n entre los diferentes C.T. y el ordenador de control, se puso o 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 e 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 el todo la pila TCP/IP y el el encapsulado a en tramas Ethernet. Empleo de circuitera que realizara unicamente el encapsulado en tramas Ether net, quedando la implementaci n del protocolo TCP/IP a cargo del microcontroo lador De las dos alternativas se escogi la segunda, bas ndose principalmente en criterios o a econ micos. o Con objeto de aislar la red local constituida para la conexi n de todas las RTUs de o la red local general, el departamento de inform tica de la compa a estableci una red a n o virtual, garantizando de esta manera la seguridad de la red interna.

16

(a) Se solicita el inicio de una transferencia de datos, mediante el pulsado del PTT

(b) Se asigna un canal libre para la comunicaci n a todos los integrantes del o grupo.

(c) Desarrollo de la transferencia.

(d) Fin de la transferencia.

(e) Liberaci n del canal. o

Figura 4.3: Esquema de comunicaci n trunking. o

17

Captulo 5

Protocolo de Comunicaciones
La implementaci n del protocolo de comunicaciones se valor en un primer moo o mento desde dos alternativas: 1. 2. Implementaci n de un protocolo propietario o Utilizaci n de un protocolo est ndar o a

Las ventajas de la primera de las alternativas estaban basadas en la exibilidad que se podra obtener, pudiendo realizar un protocolo que se adaptara completamente a las especicaciones requeridas. Como principal desventaja se encontraba su posterior adaptaci n para la comunicaci n a trav s de Internet. o o e Para solucionar el problema de la primera de las opciones, se busc la existencia de o alguna soluci n hardware que permitiera realizar un interface entre una comunicaci n o o serie y una red ethernet. En el mercado existen varias opciones, siendo una de las mas interesantes la propuesta por la empresa Lantronix . Esta marca dispone de un interface serie/Ethernet que dispone en su interior de una implementaci n completa del o protocolo TCP/IP, as como del encapsulado posterior en tramas Ethernet. El aspecto de este dispositivo se puede ver en las guras 5.1. El problema de este dispositivo es el precio por unidad ( 200e). La segunda de las alternativas tena, en contraposici n con la anterior, una menor o exibilidad en cuanto a las caractersticas del protocolo. Sin embargo su utilizaci n era o mucho mas atractiva desde el punto de vista econ mico, solucion ndose el interface o a con la red Ethernet mediante el empleo de un chip dedicado y una circuiteria adicional de bajo coste ( 80e)[3] ( ver gura 5.2 ). Bas ndose en que este era uno de los a requerimientos sobre lo que mas se haba insistido, debido al alto n mero de unidades u a desarrollar, se adopt la segunda de las opciones. o Una vez decidido el realizar la comunicaci n bas ndose en el uso de un protocolo o a est ndar, se procede a denir las necesidades a

5.1.

Protocolo TCP/IP

El protocolo implementado ha sido una versi n simplicada del conjunto de proo 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 acuo di a los RFCs correspondientes a cada protocolo ( RFC IP: 760, RFC TCP: 761 ), o

18

(a) Aspecto de interface puerto serie Ethernet de la casa Lantronix.Soluci n o de alto coste

(b) Esquema de la soluci n de Lantroo nix

Figura 5.1: Interface puerto serie - Ethernet de la casa Lantronix y se realizaron una serie de simplicaciones, con objeto de hacer posible el desarrollo sobre una arquitectura tan simple.

5.1.1.

Simplicaciones Protocolo IP

Las especicaciones del protocolo IP se encuentran en el RFC 760. Para desarrollar la implementaci n sobre el microcontrolador se realizaron algunas simplicaciones soo bre el mismo, con objeto de disminuir la complejidad del c digo. La mas importante de o las modicaciones realizadas es la referente en cuanto al mecanismo de fragmentaci n o implementado en el protocolo. Dado que la longitud de los mayores paquetes de datos a transmitir, es lo sucientemente peque a ( 296 bytes ) como para asegurar que no iban a sufrir ning n tipo de n u fragmentaci n, no se realiz la implementaci n de ning n mecanismo de fragmentao o o u ci n. 1 Para asegurar que los paquetes no se fragmentaran se introdujo la opci n de no o o fragmentar en el campo Flags de la cabecera. Otras simplicaciones menores realizadas se detallan sobre los campos del datagrama IP de la gura 5.1 VER. Versi n del protocolo. La versi n actual del mismo es la V 4. o o LON. Longitud en unidades de 4 octetos de la cabecera. TIPO SERVICIO. El valor de este campo se reere a la calidad del servicio proporcionada. El valor de este campo se ignora en la implementaci n realizada. o LONGITUD TOTAL. Longitud total del datagrama, medida en octetos, incluidos datos y cabecera. IDENTIFICACION: 0 Campos relativos a la fragmentaci n de paquetes, en o nuestro caso este campo no es interpretado, al no estar implementada la fragmentaci n en el protocolo. o
1 El tama o m ximo de paquete est muy alejado del m ximo permitido en una red Ethernet, que es de n a a a 1526 bytes, por lo que el suprimir el mecanismo de fragmentaci n es una simplicaci n aceptable. o o

19

(a) Tarjeta para la interconexi n del o Chip de Crystal al Microcontrolador.

(b) Tarjeta para la interconexi n del o Chip de Crystal al Microcontrolador.

Figura 5.2: Soluci n Ethernet embebida. o Tabla 5.1: Cabecera IP. Byte 1 Ver Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Lon Tipo de Servicio Longitud Total Identicaci n o Flags Desplazamiento TTL Protocolo Checksum Direcci n IP Fuente o Direcci n IP Destino o Opciones Relleno Datos ...

FLAGS. Campo con tres bits relativos a la fragmentaci n del datagrama. Con o 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 referido 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 o o de control se iba a realizar a trav s de una red virtual dedicada, el valor de este e 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. DIRECCION IP FUENTE. Identicaci n del emisor del mensaje. Este campo es o comprobado por el microcontrolador para asegurarse de que la trasmisi n tiene o como origen el ordenador de control.

20

 DIRECCION 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 o el canal trunking, y al estar congurados 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. o OPCIONES. El valor de este campo no se ha usado en la implementaci n del o protocolo.

5.1.2. Simplicaciones Protocolo TCP

Sobre la capa IP, cuya implementaci n se ha explicado en el apartado anterior, se o construye la capa de transporte TCP. Mediante el empleo del protocolo TCP se consigue que sea el propio protocolo el encargado de asegurar la abilidad en las comunicaciones, mediante el empleo de n meros de secuencia y acuses de recibo numerados, u asegurando que todos los paquetes son recibidos y retransmiti ndolos en caso contrae 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 simplicaciones de mayor importancia introducidas en el protocolo son las relativas a la no implementaci n del algoritmo de ventana deslizante, al empleo en todos los o paquetes de datos de la opci n EOL ( End of letter ) con objeto de asegurar la respuesta o individual a cada paquete y el no uso del campo de opciones. Otra de las modicaciones realizadas se reere al mecanismo de reintentos en caso de fallo en la transmisi n. En las especicaciones del protocolo, se especica que el o responsable del envo 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 o u reintento a no ser que el receptor se lo solicite mediante el envo de un mensaje que contenga como n mero de ACK el que corresponde al n mero de secuencia del reenvo. u u Las simplicaciones menores se comentan sobre los comentarios de los campos del datagrama TCP. El formato del datagrama es el indicado en la gura 5.2 Tabla 5.2: Cabecera TCP. Byte 1 Byte 2 Byte 3 Puerto Fuente Byte 4 Byte 5 Byte 6 Byte 7 Puerto Destino Byte 8

Desp

Res Checksum Opciones

N mero de Secuencia u N mero de ACK u C digo o

Ventana Puntero Urgente Relleno

Datos ... Los valores de los diferentes campos de la cabecera son los enumerados a continuaci n o PUERTO FUENTE. N mero de puerto del origen de datos. Su uso es debido a u la posibilidad de multiplexar varias comunicaciones de datos. En nuestra aplicaci n, se asignaron n meros de puerto congurables para la comunicaci n de o u o 21

datos y para los diferentes tipos de alarma, siendo estos puertos congurables por el usuario. PUERTO DESTINO. N mero de puerto del destino de datos. u NUMERO DE SECUENCIA. N mero de secuencia del primer octeto del datau grama. Existen indicaciones de como elegir el valor inicial del n mero de seu cuencia, de manera que no se puedan repetir a lo largo de una comunicaci n. En o 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. u o NUMERO DE ACK. N mero de secuencia del siguiente paquete que se espera u 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. CODIGO. Bits de control. El unico uso especial en nuestra implementaci n es el o bit de EOL (End of Letter ), el cual indica que se ha llegado al nal 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 o por el microcontrolador sea respondido de manera individual. Con este ag, se simplica la implementaci n del protocolo en el micro, evitando el tener que o mantener una cola con los paquetes enviados hasta la recepci n de un ACK o WINDOW. N mero de octetos de datos, a partir del n mero indicado en el ACK, u u que el cliente puede aceptar. Este n mero se utiliza para la implementaci n del u o algoritmo de ventana deslizante del protocolo, que en nuestro caso no ha sido implementado, ya que el n mero de paquetes aceptado es uno ( tama o del buffer u n de entrada del microcontrolador ). Para evitar que la implementaci n del protoo colo realizada por el ordenador inunde la del micro, se ha utilizado el ag 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 funo 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 a e operaciones, como pueden ser la conguraci n de la unidad remota y la consulta del o estado de las alarmas. El segundo tipo de intercambio de informaci n es el producido o cuando el C.T. tiene que comunicar alguna incidencia. Este tipo de comunicaci n es de o mucha mayor importancia que la de datos, por lo que el mecanismo de reintentos es di ferente. Por ultimo se encuentran las comunicaciones relacionadas con la conguraci n o de par metros, las cuales son iniciadas por el ordenador de control. a 22

5.2.1.

Comunicaciones de datos

El esquema tipo de una comunicaci n de datos es el mostrado en las siguientes o guras. Una conversaci n para el intercambio de datos comienza cuando el ordenador o 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 o de control, y que se vera nalizada cuando se reciba el ultimo paquete de datos, si no se produce ningun error en la misma. El inicio tpico, en ausencia de errores, es el mostrado en la gura 5.3. A continuaci n el ordenador enva un mensaje de saludo, o que en caso de ser reconocido como un patr n correcto por la unidad remota, permite o el inicio de la transacci n. Finalmente, y como ultimo de los procesos de inicio de la o comunicaci n, se procede a realizar las conguraciones que sean necesarias. En caso de o que no se desee realizar ninguna, se enva el paquete que contiene como datos la cadena FINCONF, pudiendo comenzar el intercambio de informaci n; segun el esquema de o la gura 5.6. Como se ve en el esquema anterior, el nal de la comunicaci n se produce o cuando la unidad remota enva un ultimo paquete de datos, el cual contiene el bit de FIN activado.

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

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

23

Figura 5.5: Esquema de una comunicaci n de conguraci n. o o

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

5.2.2. Comunicaciones de alarmas

El esquema tipo de una comunicaci n de alarmas es el mostrado en las guras 5.7, o 5.8. 2 Una de las principales caractersticas del funcionamiento de este tipo de comuni caci n, es el mecanismo de reintentos. Debido a la urgencia que puede suponer el coo 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 a la conexi n durante 10 veces a intervalos regulares de 10 segundos. En caso de que o no lo consiga, espera tres minutos y repite el ciclo anterior. Este ultimo 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 este una petici n de datos. o
los diagramas representados se ha supuesto que no haba ninguna comunicaci n activa en ese mo o mento. En caso de que asi fuera, la unidad remota enviara un paquete con el bit RST activo, a n de obligar a terminar la comunicaci n actual y poder realizar el envo de la alarma. o
2 En

24

Figura 5.7: Inicio de la conexi n de alarmas. o

Figura 5.8: Envo del mensaje de alarma al ordenador de control.

5.2.3.

Comunicaciones de conguraci n o

El esquema tipo de una comunicaci n de conguracion es el mismo que el moso trado en la gura 5.5. Las comunicaciones de conguracion 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 suponde de conguracion, no comenzando la unidad remota a trasnmitir datos hasta que haya recibido este paquete.

25

Captulo 6

Estructura de los paquetes

Como ultimo 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 a a 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 parametrizaci n, se incluyen tambi n en este apartado con el n de estudiar con un poco o e m s de detalle su estructura. a Estos mensajes ser n los enviados por la RTU cuando el control solicite informaa ci n sobre las curvas de carga. Los mensajes tendr n una longitud total de 296 bytes, o a 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 a 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
h Ir i Ir h Is i Is h It i It h In i In

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

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 a datos. Los datos enviados ser n el c digo de alarma (en el primer byte), m s la fecha y a o a hora en que se ha generado la alarma (7 bytes restantes). Los c digos de las diferentes o alarmas se muestran en la siguiente tabla: Tabla 6.2: CODIGOS DE ALARMA Alarma Reset Incendio Sobretemperatura Fusin del fusible de MT o Inundacin o Intrusismo Cdigo o 0x110 0x111 0x112 0x113 0x114 0x115

La estructura del campo datos de cada paquete ser la siguiente: Los bytes corresa 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 signicado: AN OH : Byte alto del n mero de a o u n AN OL : Byte bajo del n mero de a o u n M ES: N mero de mes u DIA: N mero de da u HORA: N mero de hora u M IN U T O: N mero de minuto u SEGU N DO: N mero de segundo u

6.3.

Mensaje de sincronizaci n o

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 a de cabecera y 8 de datos. La estructura de este mensaje es la siguiente:

27

 Tabla 6.4: ESTRUCTURA MENSAJES DE SINCRONIZACION 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). a a o Indicar que el mensaje enviado es de sincronizaci n de fecha y hora. El resto de bytes a o corresponde a la nueva fecha que se enviar . Esta fecha ser la que tenga el PC de a a 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 o sincronismo de E.R.A.C.C., contendr la fecha recibida desde este (si es el primer a mensaje de sincronizaci n) o la fecha que tenga en ese momento el reloj interno del o equipo remoto (para los posteriores mensajes de sincronizaci n). o

6.4.

Mensajes de Parametrizaci n o

Mensaje de conguraci n IP o Para cambiar la direcci n IP del equipo remoto, o que este conozca una nueva o direcci n IP del puesto de control donde se ejecutar E.R.A.C.C., se enviar un mensaje o a a de 48 bytes de longitud total, de los cuales 8 bytes ser de datos. La estructura de cada a byte de datos ser la siguiente: a Tabla 6.5: ESTRUCTURA MENSAJES DE CONFIGURACION IP DireccionEEP ROM N umerodebytes IP1 IP2 IP3 IP4 ND ND

Los distintos bytes del campo datos de cada paquete tienen el siguiente signicado: DireccionEEP ROM : Direcci n de comienzo de la EEPROM interna del mio crocontrolador, donde se encuentra almacenada la direcci n IP a congurar. La o direcci n a enviar ser la direcci n 00h, direcci n a partir de la cual residen los o a o o cuatro bytes de direcci n de la RTU, o la direcci n 04h, con lo que se reconguo o rar para el equipo remoto un posible cambio en la direcci n IP del PC de control. a o Puede obtenerse m s informaci n acerca de la distribuci n de estas direcciones a o o en el apartado Mapa de memoria EEPROM interna del microcontrolador. N umerodebytes : N mero de bytes a escribir en la EEPROM interna del miu crocontrolador. Este campo se usa como par metro en la funci n de escritura a o en dicha EEPROM. Su valor habr de ser 4, que es el n mero de bytes que se a u congurar n (ser n los 4 bytes que vendr n a continuaci n en el mensaje, que a a a o compondr n la direcci n IP a congurar). a o IP1 : Octeto m s signicativo de la direcci n IP a congurar. a o IP2 : Siguiente octeto de la direcci n IP. o 28

IP3 : Tercer octeto de la direcci n IP. o IP4 : Octeto menos signicativo de la direcci n IP a congurar. o N D : Byte sin ning n signicado dentro del mensaje. Puede ser cualquier valor. u Mensaje de conguraci n de puertos o La posibilidad de poder congurar los puertos de comunicaci n depender de la o a capacidad de almacenamiento en memoria de programa disponible para el microcontrolador. En principio, para las RTUs de comunicaci n va trunking no se contempla o la posibilidad de congurar estos par metros. Para los equipos Ethernet tampoco se a contempla esta posibilidad, si es factible mantener los n meros de puerto jos. En u cualquiera de los casos, ha de informarse mejor en el c digo fuente sobre la implemeno taci n o no de esta caracterstica. o La estructura de estos mensajes ser similar a la de los mensajes de conguraci n a o de las direcciones IP, s lo que en este caso el n mero de puerto ocupar unicamente o u a dos bytes. La estructura es la siguiente: Tabla 6.6: ESTRUCTURA MENSAJES DE CONFIGURACION DE PUERTOS DireccionEEP ROM N umerodebytes P uertoH P uertoL ND ND ND ND

Los distintos bytes del campo datos de cada paquete de conguraci n de puertos o tienen el siguiente signicado: DireccionEEP ROM : Direcci n de comienzo de la EEPROM interna del mio crocontrolador, donde se encuentran almacenados los n meros de puertos temu porales (v ase el mapa de memoria EEPROM interna del microcontrolador). La e direcci n a enviar en este byte ser la siguiente: Estas direcciones correspono a Tabla 6.7: DIRECCIONES EEPROM DE LOS PUERTOS Puerto Puerto de datos Puerto de alarma 1 (incendio) Puerto de alarma 2 (sobretemperatura) Puerto de alarma 3 (fusin del fusible MT) o Puerto de alarma 4 (inundacin) o Puerto de alarma 5 (intrusismo) Direccin EEPROM o 0x14 0x16 0x18 0x1A 0x1C 0x1E

den a las direcciones de comienzo reservadas en la memoria EEPROM interna donde almacenar los nuevos datos de conguraci n para los puertos. Durante o una comunicaci n entre E.R.A.C.C. y una RTU se pueden congurar los puero tos de comunicaci n, pero no pueden ser cambiados durante el transcurso de la o propia comunicaci n de conguraci n, si no que esto tendr que realizarse una o o a 29

vez nalice dicha comunicaci n. Por lo tanto, si el equipo remoto detecta que o est recibiendo un mensaje de este tipo, almacenar estos par metros en las dia a a recciones temporales de su EEPROM interna, y continuar la comunicaci n por a o el mismo n mero de puerto que lo estaba haciendo. Una vez que vuelva al estado u CLOSED, entonces copiar los par metros escritos en las direcciones temporaa a les en las direcciones correspondientes (jas) de la misma memoria EEPROM. La pr xima comunicaci n que se establezca ya ser realizada a trav s de los o o a e n meros de puerto que se le hayan pasado previamente. u N umerodebytes : N mero de bytes a escribir en la EEPROM interna del miu crocontrolador. Este campo se usa como par metro en la funci n de escritura en a o dicha EEPROM. Su valor habr de ser en este caso 2, que es el n mero de bytes a u que se congurar n (ser n los 2 bytes que vendr n a continuaci n en el mensaje, a a a o que compondr n el n mero de puerto a congurar). a u P uertoH : Octeto m s signicativo del n mero de puerto a congurar. a u P uertoL : Byte menos signicativo del n mero de puerto. u N D : Byte sin ning n signicado dentro del mensaje. Puede ser cualquier valor. u Mensaje de n de conguraci n (petici n de volcado de datos) o o Este mensaje se enviar despu s de todos los mensajes de conguraci n que hayan a e o podido ser enviados. Su recepci n por parte de la RTU indicar a esta que la orden de o a petici n de volcado de datos procedente de E.R.A.C.C. se ha generado, por lo que el o equipo remoto ha de enviar, en primer lugar y si las hubiese, las alarmas no comunicadas almacenadas en el buffer de alarmas, y luego todos los paquetes de datos. Ser un a mensaje de 47 bytes, con 7 bytes de datos. Los datos contendr n la cadena de caracteres a 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 a bienvenida que habr de ser reconocido por la RTU antes de proseguir en la comunia caci n. El mensaje de bienvenida contendr 47 bytes, de los cuales 7 son datos. Estos o a ser n la cadena de caracteres HELLOHC, que se interpretar como dicho mensaje de a a bienvenida. Si este no es enviado por el PC, o la recepci n no es correcta, la RTU no o contestar a petici n del puesto de mando. La raz n de ser de este mensaje es que sirve a o o para establecer un peque o ltro de acceso a cada equipo remoto, con el n de que las n RTUs Ethernet no puedan ser accedidas f cilmente a trav s de la red por equipos no a e autorizados. Aunque para los equipos remotos trunking esta especicaci n no es imo portante, se sigue manteniendo por compatibilidad en el c digo fuente empleado para o ambas versiones.

30

Captulo 7

Conclusiones
En el presente trabajo se ha expuesto una soluci n v lida y exible para comunicar o a un ( o varios ) dispositivos remotos con un centro de control. Aunque la aplicaci n o realizada est particularizada para el caso estudiado, es factible realizar peque as moa n dicaciones para adaptarla a otros requerimientos. La soluci n elegida presenta las o siguientes ventajas e inconvenientes Soluci n exible. El hecho de haber realizado una implementaci n que permite o o tanto la comunicaci n mediante enlace de radio o red Ethernet, medios muy o diferentes entre si, muestra la exibilidad del prototipo. Bajo costo. El alto n mero de unidades a desarrollar haca que el precio fuera un u factor determinante en la soluci n elegida. Como se ha expuesto en anteriores o apartados, la implementaci n escogida tiene un importante ahorro frente a otras o 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 comunicaciones sean mas lentas que con otra implementaci n mas sencilla ( una comunio caci n con los datos de una semana dura en torno a los dos minutos ). Posibles o soluciones a esto pasan por el uso de un protocolo no orientado a conexi n, como o UDP. Alto uso de memoria de programa por parte del protocolo de comunicaciones. Esta limitaci n hace que futuras ampliaciones del software del microcontrolador o sean complejas de llevar a cabo.

31

Bibliografa
[1] http://www.radio.gov.uk/publication/mpt/mpt3.htm, est ndar MPT1327. a Especicaciones del

[2] http://www.roboteks.com/actionet.htm, Introducci n al sistema Actionet. o [3] http://www.embeddedethernet.com/, Conexi n de un microcontrolador a una o LAN. [4] http://www.winradio.com/home/trunking theory.htm, Introducci n al Truno king. [5] http://www.genesisworld.com/trunking.htm, Enlaces Trunking. [6] http://www.signalharbor.com/ttt/00jan/index.html, Introducci n al Trunking. o [7] http://www.roboteks.com/pmr.htm, Ejemplo de un sistema basado en el producto Actionet. [8] http://www.signalharbor.com/ttt/00feb/index.html, Funcionamiento de un sistema 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