Universidad de la República Facultad de Ingeniería ...iie.fing.edu.uy/publicaciones/2009/GBT09/GBT09.pdf · Universidad de la República ... Santiago Morrison por su colaboración

Universidad de la Repblica

Facultad de Ingeniera

Documentacin Final grupo HAOPL(Home

Automation Over PowerLines)

Juan Martin Gonzalez Dibarboure

Pablo Biagioni Walpert

Matias Tassano Ferres

Tutor: Michel Hakas Sochaczewski

16 de febrero de 2009

HAOPL

Agradecimientos

Debemos sin duda agradecer a las siguientes personas:

Familias Gonzlez, Dibarboure, Biagioni, Cortizo, Tassano Ferrs por aguan-tarnos durante el desarrollo.

Alejandro Cirino por su asesora y por el prstamo del hub utilizado para eldesarrollo.

Ricardo Arvisa por la fabricacin del circuito impreso y por su apoyo a losestudiantes.

Leonardo Steinfeld por su darnos las primeras armas en el mbito de los micro-procesadores y por cedrnoslo en prstamo.

Fernando Manacorda por el prstamo del dominio web y protoboard, y porsus sugerencias y enseanzas.

Michel Hakas por su colaboracin en el momento justo.

Santiago Morrison por su colaboracin en el suministro de microcontroladoresvarios.

Santiago Gondelman por la bsqueda del chip Ethernet en Brasil.

Sin su apoyo, las cosas hubieran sido bastante ms complicadas.

1

ndice general

I GESTIN 1

1. Introduccin general 2

2. Objetivo general del proyecto 3

3. Autoevaluacin del grupo 4

4. Conclusin 6

5. Proyeccin a futuro 8

II MDULO 11

6. Hardware 126.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.2. Descripcin por bloques . . . . . . . . . . . . . . . . . . . . . . . 136.3. El microcontrolador y sus interfaces . . . . . . . . . . . . . . . . 146.4. Controlador Ethernet . . . . . . . . . . . . . . . . . . . . . . . . 156.5. PLCBus 1141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.6. Desarrollo cronolgico . . . . . . . . . . . . . . . . . . . . . . . . 16

7. Archivos de Tablas 207.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.2. Memoria Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.3. Estructura de tablas . . . . . . . . . . . . . . . . . . . . . . . . . 21

8. Stack TCP/IP 248.0.1. Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.1. Estructura del main . . . . . . . . . . . . . . . . . . . . . . . . . 248.2. Ejemplo de ujo normal del programa . . . . . . . . . . . . . . . 258.3. Recepcin de paquetes . . . . . . . . . . . . . . . . . . . . . . . . 25

9. Comunicacin entre webserver y mdulo 289.1. Envo de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299.2. Actualizacin de IP . . . . . . . . . . . . . . . . . . . . . . . . . . 309.3. Ejecucin de un comando . . . . . . . . . . . . . . . . . . . . . . 309.4. Actualizacin del status . . . . . . . . . . . . . . . . . . . . . . . 339.5. Envo de log de eventos agendados . . . . . . . . . . . . . . . . . 34

2

NDICE GENERAL HAOPL

10.Ejecucin y manejo de eventos y comandos 3710.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

10.1.1. Deniciones previas . . . . . . . . . . . . . . . . . . . . . 3710.2. Corroboracin del protocolo PLCbus . . . . . . . . . . . . . . . . 38

10.2.1. Conguracin del dispositivo PLCbus 1141 . . . . . . . . 3810.2.2. Pruebas de funcionamiento . . . . . . . . . . . . . . . . . 3910.2.3. Ensayos sobre tiempos de respuesta . . . . . . . . . . . . 40

10.3. Descomposicin modular . . . . . . . . . . . . . . . . . . . . . . . 4110.4. Mdulo UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

10.4.1. Envo y recepcin . . . . . . . . . . . . . . . . . . . . . . 4110.4.2. Deteccin de errores . . . . . . . . . . . . . . . . . . . . . 42

10.5. Reloj (time.c y time.h) . . . . . . . . . . . . . . . . . . . . . . . . 4310.6. Scheduler (scheduler.c y scheduler.h) . . . . . . . . . . . . . . . . 4410.7. Motor de PLCbus . . . . . . . . . . . . . . . . . . . . . . . . . . 45

10.7.1. Tipos de eventos . . . . . . . . . . . . . . . . . . . . . . . 4610.7.2. Manejos de prioridades para eventos . . . . . . . . . . . . 4710.7.3. Envo de comandos . . . . . . . . . . . . . . . . . . . . . . 4710.7.4. Transmisiones exitosas y reintentos . . . . . . . . . . . . . 4710.7.5. Post proceso . . . . . . . . . . . . . . . . . . . . . . . . . 4910.7.6. Virtualizacin de la memoria . . . . . . . . . . . . . . . . 50

11.Seguridad 5111.1. Autenticacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

11.1.1. Eleccin del algoritmo de hash . . . . . . . . . . . . . . . 5211.1.2. Contraseas temporales . . . . . . . . . . . . . . . . . . . 54

11.2. Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5511.3. Procedimiento completo . . . . . . . . . . . . . . . . . . . . . . . 56

12.Pruebas de funcionamiento 5812.1. Pruebas de la interfaz Ethernet . . . . . . . . . . . . . . . . . . . 60

12.1.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

III SERVIDOR 63

13.Introduccin a las herramientas utilizadas 6413.1. Asuntos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6413.2. Seleccin de los lenguajes . . . . . . . . . . . . . . . . . . . . . . 6513.3. Introduccin a los lenguajes utilizados . . . . . . . . . . . . . . . 66

13.3.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6613.3.2. Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . 6813.3.3. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7013.3.4. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

13.4. Introduccin a MySql . . . . . . . . . . . . . . . . . . . . . . . . 7213.5. Apache Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3

NDICE GENERAL HAOPL

14.Interfaz Grca y procesos 7514.1. Estructura general de la pgina . . . . . . . . . . . . . . . . . . . 7514.2. Descripcin de las funcionalidades . . . . . . . . . . . . . . . . . 77

14.2.1. Login, usuario normal y administrador del sistema . . . . 7814.2.2. Actualizacin del mdulo y estado de la conexin . . . . . 7814.2.3. Seleccin de la hora local, hora amanecer y hora anochecer 7914.2.4. Consulta de los actuadores existentes, agregar y quitar

actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.2.5. Ejecucin de un comando . . . . . . . . . . . . . . . . . . 8014.2.6. Consulta y actualizacin del registro de sucesos . . . . . . 8114.2.7. Consulta y actualizacin del estado del sistema . . . . . . 8214.2.8. Agendar o quitar comandos . . . . . . . . . . . . . . . . . 8314.2.9. Crear editar, borrar y agendar escenas . . . . . . . . . . . 84

14.3. Solucin tcnica de cada funcionalidad. . . . . . . . . . . . . . . . 8714.3.1. Grcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8714.3.2. Procesamiento de datos . . . . . . . . . . . . . . . . . . . 95

15.Almacenamiento de datos en el servidor 10715.1. Tablas de la base de datos . . . . . . . . . . . . . . . . . . . . . . 10715.2. PHP y MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

16.Seguridad 12016.1. Autenticacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12016.2. Encriptacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A. Evolucin del proyecto durante su ejecucin 123A.1. Objetivo inicial y desviaciones del mismo . . . . . . . . . . . . . 123A.2. Supuestos y realidades . . . . . . . . . . . . . . . . . . . . . . . . 123A.3. Evaluacin del anlisis inicial de riesgos . . . . . . . . . . . . . . 124

B. Reestructura del proyecto 125B.1. Asignacin nal de tareas . . . . . . . . . . . . . . . . . . . . . . 126B.2. Evaluacin de las tareas realizadas . . . . . . . . . . . . . . . . . 128

B.2.1. Negociacin de colaboracin con XTEND . . . . . . . . . 128B.2.2. Adquisicin de chip Ethernet, estudio de su funcionamien-

to y adaptacin del stack TCP/IP . . . . . . . . . . . . . 128B.2.3. Diseo de funcionamiento interno . . . . . . . . . . . . . . 128B.2.4. Anlisis de comunicacin con exterior . . . . . . . . . . . 129B.2.5. Construccin del hardware de desarrollo . . . . . . . . . . 129B.2.6. Estudio de lenguajes necesarios, diseo e implementacin

de la interfz grca de usuario . . . . . . . . . . . . . . . 129B.2.7. Instalacin de red PLCBus y corroboracin del protocolo 130B.2.8. Diseo de formatos de datos e implementacin del inter-

cambio con el servidor . . . . . . . . . . . . . . . . . . . . 130B.2.9. Implementacin de driver bsico para PLCBus . . . . . . 131B.2.10. Implementacin de escritura y lectura de tablas en memo-

ria Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131B.2.11. Implementacin del mdulo de ejecucin de eventos y co-

mandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132B.2.12. Pruebas del sistema completo . . . . . . . . . . . . . . . . 132

4

NDICE GENERAL HAOPL

B.2.13.Versin nal del esquemtico y diagramado de PCB . . . 132B.2.14. Estudio de algoritmos de autenticacin y cifrado y diseo

de uno propio . . . . . . . . . . . . . . . . . . . . . . . . . 133

C. Pgina multiusuario 134

D. Horas planicadas vs. horas reales 136

E. Contenido del CD 137

5

ndice de guras

6.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . 136.2. Diagrama de bloques del hardware. . . . . . . . . . . . . . . . . . 146.3. Esquemtico del circuito completo. . . . . . . . . . . . . . . . . . 156.4. Hardware utilizado para el desarrollo. . . . . . . . . . . . . . . . 176.5. Pasarela PLCBus-1141 por dentro. . . . . . . . . . . . . . . . . . 186.6. Circuito del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 196.7. Hardware completo del sistema. . . . . . . . . . . . . . . . . . . . 19

7.1. Organizacin de las tablas en memoria. Las direcciones estn ex-presadas en words. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.2. Direccionamiento en las tablas. . . . . . . . . . . . . . . . . . . . 227.3. Diagrama con el formato con el que se almacenan los eventos

diarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.1. Convenciones del diagrama de estados del programa. . . . . . . . 268.2. Diagrama de estados del programa para el caso de las pruebas de

comunicacin Ethernet realizadas. . . . . . . . . . . . . . . . . . 268.3. Diagrama del chequeo de protocolo . . . . . . . . . . . . . . . . . 27

9.1. Extracto de una captura en el Wireshark mostrando envos detablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

9.2. Extracto de una captura en el Wireshark mostrando proceso deactualizacin de IP . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9.3. Extracto de una captura en el Wireshark mostrando proceso deenvo de comando . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9.4. Extracto de una captura en el Wireshark mostrando proceso deenvo de status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.5. Extracto de una captura en el Wireshark mostrando proceso deenvo de comando . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

10.1. Interaccin entre los mdulos que componen el software . . . . . 42

11.1. Algoritmo de autenticacin . . . . . . . . . . . . . . . . . . . . . 5311.2. Algoritmo de encriptacin . . . . . . . . . . . . . . . . . . . . . . 56

12.1. Diagrama completo de elementos utilizados para las pruebas defuncionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

12.2. Secuencia desarrollada en la prueba de la interfaz Ethernet. . . . 62

6

NDICE DE FIGURAS HAOPL

13.1. Ejemplo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6813.2. Al cargar la pgina . . . . . . . . . . . . . . . . . . . . . . . . . . 6913.3. Luego de hacer clic en Aceptar en el mensaje de bienvenida . . . 6913.4. Pgina HTML sin el archivo CSS cargado . . . . . . . . . . . . . 7113.5. Pgina HTML con el archivo CSS cargado . . . . . . . . . . . . . 71

14.1. Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7614.2. Pgina de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7614.3. Pgina para consultar, agregar o quitar actuadores . . . . . . . . 8014.4. Pgina de ejecucin de comando . . . . . . . . . . . . . . . . . . 8114.5. Pgina de registro de sucesos . . . . . . . . . . . . . . . . . . . . 8114.6. Pgina de estado del sistema . . . . . . . . . . . . . . . . . . . . 8214.7. Pgina de agendado de comandos . . . . . . . . . . . . . . . . . . 8414.8. Pgina de agendado de escenas . . . . . . . . . . . . . . . . . . . 8514.9. Pgina de consulta de escenas existentes . . . . . . . . . . . . . . 8514.10.Pgina para crear una escena . . . . . . . . . . . . . . . . . . . . 8614.11.Pgina para editar escenas . . . . . . . . . . . . . . . . . . . . . . 8614.12.Frames utilizadas para la pgina web. . . . . . . . . . . . . . . . 8814.13.Ejemplo de contenedor . . . . . . . . . . . . . . . . . . . . . . . . 8814.14.Jerarqua Javascript . . . . . . . . . . . . . . . . . . . . . . . . . 9014.15.Efecto logrado con Javascript . . . . . . . . . . . . . . . . . . . . 9114.16.Imagen a partir de la cual se genera el botn para agregar actuador 9414.17.Botn de submit generado con un archivo de estilo . . . . . . . . 9414.18.Botn de submit sin el archivo de estilo . . . . . . . . . . . . . . 9414.19.Comunicacin entre del servidor y el mdulo y el servidor y el

cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10114.20.Almacenamiento de un comando . . . . . . . . . . . . . . . . . . 10414.21.Diagrama de ujo del armado del paquete correspondiente a un

da . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

15.1. Acceso al servidor MySql desde la consola. . . . . . . . . . . . . . 115

7

Resumen

El siguiente documento corresponde a la documentacin nal del proyectode n de carrera del grupo HAOPL.El producto desarrollado en este proyecto busca satisfacer la necesidad de con-trolar remtamente un hogar, sin tener una PC dedicada a esto instalada endicho hogar. Por controlar debe entenderse comandar artefactos elctricos sen-cillos. Este proyecto se vincula con el rea de la domtica y emplea la tecnologaPLCbus. El producto nal se compone de dos partes: un mdulo, que conllevun desarrollo tanto de hardware como del rmware de su microcontrolador, yuna pgina web, que conllev el desarrollo de varios scripts escritos en lenguajesde pginas web dinmicas. El mdulo se instala en el hogar y se comunica conel usuario del sistema a travs de la pgina web, y adems es quien se encargade comandar los dispositivos elctricos.El documento se divide en tres partes: gestin, mdulo, y servidor y en generalno se ahondar en extremo en cuanto al desarrollo tcnico del rmware, ya quese adjunta documentacin especca del mismo.

Parte I

GESTIN

1

Captulo 1

Introduccin general

Existen en plaza diferentes dispositivos para diversos protocolos, que per-miten el manejo de redes domticas[1]1 a travs de Internet. Dado que existenproductos que sirven de puente entre una PC y una red domtica, se decidiusar uno de estos para lograr un producto que diera la posibilidad de precindirde una PC y tuviese a grandes rasgos las mismas funcionalidades que ofrecenlos productos PC-dependientes, pero a un costo signcativamente menor.Inicialmente se pens en emplear el protocolo de domtica X-10[2] dado su usoestandarizado en el sector. Quien luego sera nuestro tutor nos hizo observar queexisten un sinnmero de productos desarrollados para este dada su trayectoriaen el mercado y que la idea no sera muy viable. Por ese motivo y dado queexisten hoy en da protocolos que mejoran sustancialmente la performance yaumentan las funcionalidades, se pens en cambiar de protocolo. Se considerentonces utilizar PLCbus[3], ya que no existe ningn mdulo que permita laconexin remota a la red domtica. Adems, se eligi este pues en comparacincon X-10, presenta algunas mejoras importantes como las siguientes: mayor ro-bustz frente a los ruidos elctricos, ms comandos y direcciones (se permiteagregar ms artefactos a controlar) y quiz lo ms importante: bidirecionalidad.Es por tanto que PLCbus se presenta como el sucesor de X-10, el protocolo decomunicacin por lneas elctricas ms usado en la actualidad.Si bien la alternativa era tentadora, signicaba tambin investigar y disear enun rea para la cual no hay prcticamente informacin disponible. En diferentesoportunidades se pag el precio de incursionar en aguas desconocidas.

1Por domtica se entiende el conjunto de sistemas capaces de automatizar una vivienda uocina.

2

Captulo 2

Objetivo general del proyecto

El proyecto tiene como objetivo disear y construir un sistema de controlremoto que permita a un usuario nal sin conocimientos tcnicos, el comando atravs de Internet de una red domtica.Permite al usuario conectarse de forma rpida y segura a travs de un PC osimilar (cualquiera que maneje TCP/IP) a un dispositivo central situado en elhogar, ocina, etc. que se encargar de comandar, utilizando como canal de co-municacin la lnea elctrica, actuadores conectados a los electrodomsticos.Para esto, el mdulo realiza el comando de dispositivos del tipo PC-powerline1

(existentes en mercado), mdulos que permiten el control de la red domticapor intermedio de una PC. De esta forma, se aprovecharn los benecios de losproductos existentes en el mercado, eliminando la necesidad de tener un PCdedicado a brindar dicho servicio.El sistema debe tener la capacidad de ejecutar comandos de forma instantneaas como la posibilidad de agendar los mismos y permitirle al usuario la creaciny modicacin de eventos agendados as como la posibilidad de crear, agendar yejecutar escenas2. Este debe funcionar de forma autnoma en el sentido de quesolo se necesita acceder a l para su conguracin y programacin de eventos.Con esto se busca brindarles a los consumidores una manera sencilla, eciente,rpida y cmoda de comandar remotamente aparatos elctricos de uso domsti-co. Tambin es de fundamental importancia disear un producto que sea robustoy acorde a los precios del mercado de modo de satisfacer las expectativas delcliente, por lo que se debi optimizar el diseo para reducir el costo lo mximoposible.Se busca cubrir la necesidad de una forma efectiva y eciente de controlar deforma remota las redes domticas sobre powerlines existentes y brindar unasolucin de bajo costo a un segmento del mercado actualmente desatendido,principalmente a usuarios del protocolo PLCBus quienes no cuentan actual-mente con un dispositivo similar.En la Figura 6.1 se observa un diagrama de la conguracin del sistema com-pleto. Se aprecian tres divisiones, el servidor web, el domicilio del usuario y lacasa u ocina del usuario. En amarillo se muestra precisamente en que consisteel producto que se desarroll en este proyecto.

1Lnea elctrica, instalacin elctrica en el hogar. Estos dispositivos se comunican medianteel cableado previamente existente.

2Entendido como un conjunto de comandos que se ejecutan en forma simultnea.

3

Captulo 3

Autoevaluacin del grupo

Los motivos del retraso al cual nos enfrentamos ya han sido expuestos enpartes anteriores, pero fundamentalmente se deben a una planicacin en exce-so optimista. En la mayora de las tareas los tiempos previstos fueron correctospero no as en otras.Result que la demora en estas pocas (algunas pertenecientes al camino crtico)llev a un atraso importante. Adems, se debieron realizar algunas tareas queno haban sido consideradas, y existieron algunos inconvenientes que no habansido correctamente evaluados, o que no haban sido siquiera previstos.Si bien podamos haber estimado ms tiempo para las importaciones previendoparos, etc., de forma de contemplar posibles problemas; bajo ningn conceptohubiramos imaginado que bamos a tener que invertir tiempo y recursos paraconseguir drivers apropiados para el mdulo 1141.Por otra parte, inicialmente se contaba nicamente con una plataforma de de-sarrollo por lo cual no podan trabajar todos los integrantes del proyecto deforma simultnea lo que implicaba que mientras algunos se encontraban en unaintensa actividad, otros solo podan dedicarse a tareas de preparacin de las eta-pas siguientes. Afortunadamente esto fue solucionado al agregarse una segundaplataforma la cual, si bien era ms limitada que la primera, permiti que sepudiera trabajar en paralelo lo cual contribuy signicativamente a reducir lostiempos.En cuanto a las horas de dedicacin al proyecto, la distribucin no fue uniformecomo se haba planeado. Inicialmente se evalu esto como algo normal debido alas actividades curriculares realizadas por el grupo durante el primer semestre,sin embargo no se revirti luego de terminado el semestre. Adems, el hechode no contar con fechas lmites estrictas dentro del periodo de ejecucin delproyecto contribuy a que algunas actividades se dilataran ms de lo debido porno dedicar un esfuerzo extra para llegar en fecha. De hecho, hasta el momentoquedan actividades inconclusas, que deberan haberse terminado a principio deEnero, previo al comienzo de la etapa de documentacin.En cuanto al funcionamiento como equipo, nunca se logr el nivel de comuni-cacin requerido para el correcto entendimiento entre los integrantes. Si biense haba decidido elaborar informes semanales sobre la evolucin de las tareas,esta prctica se abandon sobre el nal del proyecto. A pesar de esto, hubieronmomentos de mucha colaboracin entre las partes, pero fueron los menos y engeneral sin involucrar a la totalidad del equipo. Afortunadamente, dado el cam-

4

HAOPL

bio de enfoque del proyecto hacia tareas autnomas por medio de la divisindel mismo en tres mdulos auto contenidos permiti reducir el impacto de lafalta de comunicacin, y mejorar considerablemente la ecacia y eciencia delequipo.

5

Captulo 4

Conclusin

A pesar de la culminacin formal de las actividades en el marco del proyectode n de carrera, queda abierta la posibilidad de continuarlo con expectativasde una futura comercializacin del mismo. En particular, quedan tareas pendi-entes relacionadas a la seguridad del intercambio de la informacin, as comola estandarizacin del protocolo de intercambio de datos y del procesamientode los mismos. Por otra parte, se tienen en mente diversas funcionalidades nocontempladas en el proyecto que lo haran un producto comercialmente msatractivo.Desde el comienzo, el proyecto tuvo como objetivo principal ganar experienciaen el diseo de sistemas embebidos en tiempo real, y su aplicacin en el trcode informacin sobre redes TCP/IP, siendo su aplicacin especca en el rea dela domtica una forma de establecer una restriccin al diseo, y permitir de estaforma tener objetivos claros. Por otra parte, se opt desde un principio por lautilizacin de un microcontrolador de gama baja, de forma de lograr desarrollarhabilidades en la programacin con recursos escasos, tanto por un desafo per-sonal, como por el convencimiento de que no es necesaria una gran capacidadde procesamiento para implementar un producto atractivo.El mayor desafo que debimos enfrentar fue esta escasez de recursos de proce-samiento, lo que nos oblig a utilizar nuestra inventiva con el n de podersuperarlo. Por otra parte, una complejidad no menor es el hecho de que el sis-tema diseado debe ser absolutamente autnomo, y capaz de sobrellevar por simismo problemas como el corte de energa, desconexin de la red, etc.Todo esto nos oblig a hacer un diseo por dems acabado del sistema, exigiendorever constantemente las decisiones tomadas, buscando darle mayor estabilidadal sistema, y optimizando el consumo de recursos como una tarea constante ysistemtica.Por otra parte estamos satisfechos con los logros obtenidos en el rea de progra-macin web, ya que la solucin que requera el sistema era bastante singular, yaque el servidor debe actuar de intermediario entre el mdulo y el usuario, y laexperiencia en programacin web era nula.Llegada esta instancia y en empresas rumbeadas de la forma que fue rumbeadala nuestra, es decir, anteponer bajo costo de fabricacin contra horas de disey desarrollo que se plantee la incgnita de si esta losofa valo la pena. Hayque decir que sin duda lo fue desde el punto de vista acadmico y como mediode adquisicin de conocimientos para los integrantes. Por otro lado, aunque el

6

HAOPL

sistema desarrollado fue desde un inicio de recursos acotados de procesamientoy memoria del lado del mdulo, no lo es del lado del servidor web de aplica-ciones lo que hace posible que se puedan integrar al sistema nuevas y variadasfuncionalidades sin tener que migrar a otro microcontrolador y sin grandes cam-bios signicativos. Esta losofa hizo posible lograr un producto con un costo defabricacin de alrededor de USD130 (sin olvidar que este es el costo de la fab-ricacin de una sola unidad y que el mismo disminuye sensiblemente conformela fabricacin sea de ms unidades). A lo largo del proyecto se logr adquiriruna gran experiencia en estos temas, lo cual creemos que es ms destacable queel producto obtenido ya que abre las puertas a una gran variedad de posiblesaplicaciones, sobre todo teniendo en cuenta el relativo bajo costo del hardwaredesarrollado.En cuanto al producto obtenido, nos sentimos satisfechos con el mismo, aunquereconocemos que an puede desarrollarse ms. Debemos destacar en este punto,que a pesar de las dudas iniciales que tuvimos acerca del objetivo del proyecto,el mismo nos satisface gratamente por ser un producto funcional y completo.Por otra parte, consideramos que la eleccin del protocolo a utilizar, y la apues-ta a cubrir este segmento del mercado fue acertada ya que al da de hoy todavano se dispone de un producto similar en el mercado, siendo este un productonecesario.Finalmente, en cuanto al proyecto y la gestin del mismo, queda un sentimientode insatisfaccin, a pesar de que debemos reconocer que si se tiene en cuentaque la gestin del mismo fue realizada enteramente por los estudiantes, y lainexperiencia en proyectos de esta magnitud, la gestin debe ser consideradabuena.Se debe sealar que, la falta de responsabilidades claras y de algn tipo deliderazgo o mecanismo de toma rpida de decisiones, sumado al afn de evitardiscusiones y de no mandar al resto de los integrantes, llev a que en mu-chos casos se dilataran excesivamente tareas y decisiones que no lo ameritaban,restndole tiempo a otras que deban llevarse a cabo con mayor conciencia.Por otra parte, el compromiso de los diferentes integrantes no fue parejo, derivan-do en una distribucin de tareas desigual que si bien en el balance general norepresenta una diferencia excesiva, si lo represento en la etapa inicial del proyec-to, desgastando la relacin entre los integrantes y desgastando al grupo, dicul-tando la gestin del proyecto.El balance general del proyecto es bueno por haber obtenido un producto fun-cional, de gran potencial y con recursos smamente escazos, si bien reconocemosque hubieron falencias en cuanto a la comunicacin intragrupo.

7

Captulo 5

Proyeccin a futuro

A continuacin se describen algunas funcionalidades que en algn momentodel transcurso del proyecto se sugirieron, pero que luego por falta de tiempo nose implementaron.

1. Cmaras IP

La idea es integrar cmaras IP al producto de manera que funcionen deforma completamente independiente del mdulo. Es decir, que generen unstream de video que sea enviado al servidor de manera segura y mostradoen la pgina web. Una ventaja de esto es que no se requiere realizar ningncambio al mdulo y una desventaja es el costo de las cmaras IP.

2. Calendario

Actualmente los comandos se agendan en forma semanal en la pginaweb. Si por ejemplo el usuario desea agendar un comando en este momen-to para dentro de un mes exacto, no puede hacerlo. Esta funcionalidadprevee que los comandos se agenden en un calendario anual o mensual.Se implementara directamente en el servidor sin agregar nada extra almdulo.

3. Video Integrado

Tratando de satisfacer la misma necesidad que con las cmaras IP, otraopcin es usar el propio mdulo conectado a una cmara web para generarel stream de video. Los cambios del lado del servidor seran similares a losde utilizar cmaras IP, pero habra que hacer un trabajo adicional en elrmware del mdulo para lograr el streaming de video. Esto muy proba-blemente llevara a un cambio del microcontrolador, ya que sus recursosseran desbordados por esta nueva funcionalidad.

4. Ampliacin del log de eventos

Actualmente el log de eventos solo almacena datos referidos a la ejecucinde comandos agendados. Esta funcionalidad podra ampliarse de manerade poder almacenar ms comandos o incluso otro tipo de datos como:

8

HAOPL

reinicios del microcontrolador, usuarios que se han logeado a la pginaweb, de quienes ha recibido paquetes, etc..

5. Idiomas

Para obtener un producto comercialmente ms atractivo sin duda habraque considerar la opcin de tener un acceso web al menos en espaol eingls. Tambin sera bueno en otra etapa inclur portugus.

6. Skins

Skins o apariencias. Tomando como ejemplo nada ms y nada menos quea gmail, quien recientemente ha includo skins, es una opcin que sin lugara dudas torna mucho ms atractivo, customizable y menos montono elacceso web. Ms an si es uno pensado para que el acceso al mismo seaprcticamente diario.No se tiene claro en el momento el esfuerzo de programacin que deman-dara.

7. Captura de escenas

Existen dispositivos PLCbus que son capaces de generar escenas automti-camente. Es decir, si el usuario lo solicita, ingresan a la red domtica todoslos comandos que se corresponden con alguna de las escenas que tienenalmacenadas. Sera bueno dotar al mdulo de inteligencia de manera quepueda capturar las escenas que son enviadas por dispositivos externos, yalmacenarlas de manera que puedan ser ejecutadas desde la pgina web.Esto demandara un esfuerzo de programacin relativamente grande tantoen el servidor como en el mdulo.

8. Conguracin de dispositivos externos

Resulta que la conguracin de algunos dispositivos PLCbus o X-10 esbastante tediosa. Algunas veces requiere mantener botones apretados porvarios segundos y otros mecanismos un tanto rudimentarios. Sera deseabledotar al sistema de un modo conguracin, al que se ingrese desde lapgina web y permita congurar otros dispositivos de la red domtica.Esto sin duda requiere un esfuerzo de programacin importante.

9. Pgina de conguracin

Este punto fue quiz el ms hablado durante el transcurso del proyec-to. Resulta que el mdulo tiene almacenados una direccin IP del grupode las privadas, una direccin MAC y un identicador. La nica forma demodicar estos parametros del mdulo hoy en da es a travs de la interfazJTAG. Lo que se quera era poder congurar el mdulo o incluso hacer unupgrade del rmware por ejemplo a travs de una pgina web almacenadaen el mismo, y la interfaz RJ-45. Esto en principio no sera tan complejode llevar a cabo.

10. Seguridad

9

HAOPL

Quiz la tarea de mayor prioridad que qued sin completar es hacer todoslos intercambios de informacin de forma segura. Actualmente la comuni-cacin entre el mdulo y el servidor se realiza de dos maneras distintas1,y solo una de ellas puede ser considerada relativamente segura.

1Ver captulo 9 Comunicacin entre webserver y mdulo

10

Parte II

MDULO

11

Captulo 6

Hardware

6.1. Introduccin

A la hora del planteo de qu requerimientos debera cumplir el mdulo adesarrollar, se concluy que un punto de inters era lograr un sistema que fueseeconmico, sobretodo poniendo en la balanza la potencialidad de insertar com-ercialmente el producto nal.Por otro lado, haba que tener en cuenta las dems necesidades: el mdulo sepens para el control remoto por medio de Internet de los actuadores PLCBusque existen en un hogar, por lo que son necesarias tanto la conectividad TCP/IPcomo la posibilidad de que el mdulo enve comandos PLCBus hacia el hogar.Antes de continuar, y para evitar posteriores confusiones, creemos convenientehacer algunas aclaraciones sobre licencias tomadas en el uso de algunos trminosa lo largo de este documento.Protocolo de comunicacin con PLCBus-1141:Haremos referencia al mismo como protocolo PLCBus o el protocolo pero debe-mos tener en cuenta que una cosa es el protocolo PLCBus de trasmisiones sobrelneas elctricas, y otra muy diferente es el protocolo utilizado para la comuni-cacin serie entre una PC y el mdulo PLCBus-1141.RS232:Es conveniente aclarar que haremos referencia a RS232 en el sentido de la co-municacin serie asncrona y del conector DB9 (con su pinout correspondiente)pero dejando de lado los pines de sealizacin y utilizando nicamente los deRX, TX y GND.Mdulo:Se mencionar mdulo haciendo referencia tanto a unidades fsicas bien delimi-tadas (ej:PLCBus-1141) como a unidades de software bien delimitadas, determi-nadas por la funcin que cumplen dentro del sistema y que pueden ser pensadascomo un objeto independiente de los dems.Ej: Mdulo TCP/IP hace referencia tanto al hardware como al software cuyanica funcin es establecer comunicaciones va TCP/IP y que puede funcionarde forma independiente al resto del sistema.

En la Figura 6.1 se observa la arquitectura de todo el sistema

12

6.2. DESCRIPCIN POR BLOQUES HAOPL

Figura 6.1: Arquitectura del sistema

6.2. Descripcin por bloques

En primera instancia, una decisin importante a tomar era la del microcon-trolador. Por varias razones el seleccionado fue el ATmega32, un AVR RISC de8 bits del fabricante ATMEL[5]. Este microcontrolador posee integrados en elmismo chip numerosos mdulos que proveen soluciones a las necesidades quedeban solventarse. Al proveerse tantas soluciones en un mismo chip, y con loque adems hablamos de un microcontrolador de bajo costo, el costo de desar-rollo de el producto se reduce sensiblemente, tanto en tiempo como en dinero.Un punto a tener en cuenta y que viene de la mano con la eleccin del microcon-trolador a utilizar es el hardware adicional necesario para la programacin y de-bugging del rmware. Para este propsito existe una plataforma muy econmicadel mismo fabricante del ATmega32 llamada AVR Dragon, y que se encontrabadisponible dentro del mismo Instituto de Ingeniera Elctrica, lo cual fue otropunto a favor de la eleccin del ATmega32 para el proyecto.

Para superar el hecho de que se necesitaba conectar el mdulo en una redEthernet se busc un controlador stand-alone capaz de lograr esto y que ademstuviese una interfaz soportada por el ATmega32. El elegido fue el ENC28J60de Microchip[6], el cual posee interfaz serial SPI. Se trata de un controladorcompatible con el estndar IEEE 802.3 y que integra funcionalidades de MACy 10BASE-T PHY.

Con respecto al envo de comandos PLCBus dentro del hogar, se lleg auna implementacin que no siempre fue la apuntada. Inicialmente se estudifuertemente la posibilidad de que el propio mdulo generase y transmitiese loscomandos hacia la lnea elctrica. La falta de informacin provista del protocolollev a que se descartara esta opcin. La solucin que le sigui consiste en utilizarun mdulo comercial que implementa una pasarela entre una interfaz PLCBusy RS232, el PLCBus-1141[7].

13

6.3. EL MICROCONTROLADOR Y SUS INTERFACES HAOPL

Figura 6.2: Diagrama de bloques del hardware.

En la Figura 6.2 puede observarse un diagrama de bloques del hardwareutilizado para el desarrollo del sistema. Se aprecia la plataforma AVR Dragonen conexin con el ATmega32 a travs de la interfaz JTAG. Esta plataformatambin se utiliz para alimentar al microcontrolador en las etapas de trabajocon el hardware de prototipado.

6.3. El microcontrolador y sus interfaces

Entre otros, el ATmega32 posee (y son utilizados en el sistema) 32KB dememoria ash programable, 1KB de memoria EEPROM, 2KB de memoriaSRAM, 32 lneas de I/O de propsito general, tres contadores/timers, USART,puerto serial SPI, interfaz JTAG y soporte para on-chip debugging y progra-macin.Para la comunicacin con el controlador Ethernet se utiliza la interfaz serialSPI (Serial Peripheral Interface). Al ser un medio de transmisin sincrnico,la frecuencia de reloj debe ser la misma en ambos lados, y en este caso el querestringe la frecuencia a el valor jo de 8MHz es el ENC28J60. El ATmega32posee la caracterstica de que su interfaz SPI funciona a una frecuencia igual ala mitad de su frecuencia de reloj y por esto debi suplirse a este con un cristalde 16MHz, ya que aunque el ATmega32 ofrece varias posibilidades de reloj au-togenerado, no se logra esta frecuencia por estos medios.El medio para la comunicacin entre la plataforma de programacin y el mi-crocontrolador es la interfaz JTAG, la cual permite utilizarse tambin para eldebugging y emulacin. Esta fue la elegida ya que otros medios de comunicacinofrecidos por el AVR Dragon no proveen simultneamente estas dos posibilidades(High Voltage Serial Programming, Parallel Programming, debugWire). Por ellado de la comunicacin entre la PC y la plataforma se provee interfaz USB. Yaen el lado de la PC, el software utilizado para controlar el AVR Dragon se tratade el AVR Studio 4[8], provisto gratuitamente por ATMEL y que permite inte-grar tanto el compilador gratuito de ATMEL como el AVR-GCC, el compilador

14

6.4. CONTROLADOR ETHERNET HAOPL

Figura 6.3: Esquemtico del circuito completo.

de cdigo libre ms utilizado por la comunidad AVR.Con respecto a la UART, esta es utilizada para la comunicacin con la pasarelaPLCBus-1141 la cual convierte comandos generados por el procesador a coman-dos del protocolo PLCBus sobre la instalacin elctrica y que se comunica conlos distintos actuadores distribuidos a lo largo del hogar para que estos ejecutenlas acciones deseadas por el usuario (por ej: apagar/prender lmparas, subir per-sianas, abrir portn, etc.). La UART del ATmega32 genera niveles de tensinque no son los especicados por el (pseudo)estndar RS232, el cual estableceseales vlidas en el rango [-15V, -3V] para los unos lgicos y en [+3V, +15V]para los ceros lgicos. Por este hecho es que se utiliza el conversor de nivelesMAX232 de Maxim[9].

6.4. Controlador Ethernet

El controlador ofrece una implementacin efectiva de capa fsica y capaMAC, sin embargo para lograr la integracin en redes LAN fue necesario desar-rollar y programar en el microcontrolador un stack TCP/IP que implementasela capas superiores. Ofrece un buer de 8KB para transmisin y recepcin depaquetes, implementa automticamente funciones como padding programable yclculo del CRC e incluso pueden programrsele ltros de paquetes entrantessegn diferentes criterios, como por ejemplo, que los paquetes entrantes poseancomo direccin de capa MAC de destin la direccin que utiliza el ENC28J60.

Para lograr el correcto funcionamiento de este es necesario agregar un cristalde 25MHz entre sus pines OSC2:1 para que este pueda generar su seal dereloj. Otro requerimiento de este controlador es suministrarle una tensin de+3.3V. Para esto fue necesario armar una fuente de tensin a partir del inte-grado LM317[10], de donde se convierte la tensin de salida de un regulador detensin de 220VAC/7.5VDC a 3.3VDC. Es necesario que la salida del integradosea lo ms estable posible puesto que el ENC28J60 es sensible a variaciones de

15

6.5. PLCBUS 1141 HAOPL

la tensin de alimentacin. Se agregaron varios capacitores de desacople parasuperar este hecho.

Para la conexin fsica entre el chip ENC28J60 y el cable de Ethernet seutiliz un conector RJ45 modelo j00-0014NL de Pulse con ltros magnticosanti EMI (Electromagnetic Interference) incorporados. El ENC28J60 recibe co-mo entrada y salida hacia el conector 2 pares de pines, uno para transmisin yel otro para recepcin.

6.5. PLCBus 1141

Esta pasarela posee dos canales de comunicacin. Por un lado se conectaa la UART del procesador mediante un conector DB9, instalado por el grupoy que cortocircuita el conector USB, y por el otro se conecta a la instalacinelctrica del hogar. Sin embargo, en un principio el mdulo no se alimentabadesde ninguna de estas dos posibilidades, sino que la alimentacin la obtena dela interfaz USB. Este mdulo est concebido para que se le enven instruccionesmediante su interfaz USB, que no consiste ms que en una UART interna conec-tada a un chip conversor RS232-USB. Inicialmente se evalu la implementacinde USB dentro del mdulo en desarrollo, pero por diversas razones se terminoptando por puentear la entrada al chip conversor (conexin serie de la UARTdel PLCBus-1141) con la conexin de la UART del microcontrolador y utilizarla interfaz USB existente para lograr la alimentacin +5V. Actualmente, luegode haber superado la etapa de hardware armado sobre protoboard y habiendologrado un circuito impreso del sistema, la pasarela se alimenta del regulador detensin +5V existente y se comunica con el ATmega32 por medio de RS-232.

6.6. Desarrollo cronolgico

Este proyecto est basado en muchos de sus aspectos iniciales en el proyectoya existente y accesible en la web AVRnet[11] y lo relacionado al hardware no esla excepcin. Pueden observarse varios aspectos en comn con el proyecto antesmencionado, pero tambin puede observarse que aparecieron diferencias entre elhardware diseado en cada proyecto conforme avanzaba el desarrollo del nuestro.

Inicialmente se pas a armar una versin de prototipo sobre un protoboard.Para lograr esto, primero fue necesario realizar una importacin de varios el-ementos al no encontrarse estos en plaza. Los artculos importados fueron elcontrolador ENC28J60 as como el respectivo cristal de 25MHz, el cristal de16MHz para el microcontrolador y el conector RJ45. Luego de algunas semanasse pudo reunir todos los elementos y se procedi al armado del prototipo.

No todos los elementos utilizados actualmente lo fueron desde un principio.Para la fuente de alimentacin del controlador Ethernet se empez utilizando elintegrado LP2950 el cual requiere menos componentes externos que el LM317,pero se encontr que el primero recalentaba demasiado y que su salida no era

16

6.6. DESARROLLO CRONOLGICO HAOPL

Figura 6.4: Hardware utilizado para el desarrollo.

lo estable que se requiere para que el ENC28J60 funcione correctamente. Otropunto modicado fue la utilizacin de un conversor de niveles entre los puer-tos del microcontrolador y el controlador Ethernet. El ENC28J60 funciona enel rango de [0V, +3.3V] mientras que el ATmega32 funciona entre [0V, +5V].De esta manera se lleg a utilizar el buer triestado 74ACT125 entre sealescomunes a ambos. Una lectura en ms detalle de las respectivas hojas de datosconcluy que el conversor de niveles no era necesario y se quit[12].

Como parte del proyecto se deba controlar el envo/recepcin de comandos ynoticaciones por intermedio de un dispositivo PLCBus-1141. Dicho dispositivoexiste en mercado en 2 versiones, una con interfaz USB y otra con RS232. Parael proyecto se pretenda utilizar la versin con RS232 ya que esto simplicabanotablemente la comunicacin entre nuestro Hardware y el PLCBus-1141 sinembargo, se tena en cuenta que esto podra ser un problema ya que el mercadotiende a dejar de lado los dispositivos con conexin RS232 y cambiar por ver-siones con USB. De hecho, el PLCBus-1141 que fue suministrado por nuestrosocio (XTEND) trae como interfaz de fbrica un puerto USB por lo que se debiadaptar el proyecto para asegurarse que el mismo pudiera implementarse inclusoen el caso hipottico de que solo existieran dispositivos con USB en el mercado.

Se consideraron diferentes opciones para solventar este tema, tales como mi-grar a un microcontrolador que implementase la interfaz USB o incluso utilizaruna implementacin de un host USB mediante una librera rmware escrita enC, pero estas opciones no resultaron atractivas ya que encareca el producto yrequera adaptar todo el proyecto a un nuevo microcontrolador para la primeropcin, adems de agregar el problema de que la comunicacin va USB es mu-cho ms complejo que por medio de RS232.[13][14][15]

17


Figura 6.5: Pasarela PLCBus-1141 por dentro.

Por otra parte, se intuy con certeza que la nica diferencia entre el dis-eo del modelo con RS232 y el USB era un adaptador RS232-USB por lo cualpodramos tener (a menos de pequeas modicaciones) una interfaz serie. Aldesarmar el PLCBus-1141 vimos que efectivamente esto era as. De hecho sepuede ver en la gura Figura 6.5 la huella en la placa para un conector DB9utilizado en el caso del modelo con interfaz RS232. Esto reforz la idea de tra-bajar con un puerto serie a pesar de todo ya que a nuestro entender carece desentido hacer mltiples conversiones USB-RS232.

Ya llegadas las instancias nales del proyecto se empez con la construccinde un circuito impreso de todo el sistema, exceptuando el circuito del PLCBus-1144 el cual permanece en la placa original. El diseo se llev a cabo utilizandola versin freeware del famoso software de diseo Eagle[16]. El resultado puedeverse en la gura Figura 6.6 y en la gura Figura 6.7 se aprecia todo el sistemaarmado dentro de una caja.

18


Figura 6.6: Circuito del sistema.

Figura 6.7: Hardware completo del sistema.

19

Captulo 7

Archivos de Tablas

7.1. Introduccin

El mdulo en desarrollo ofrece la posibilidad al usuario de programar yagendar eventos que deben llevarse a cabo a la hora y da que este estipule.Un ejemplo de estos eventos podra ser que el usuario, quien previamente poseeactuadores PLCBus para lmparas instalados, desea apagar ciertas lmparastodas las noches a las 11:30 PM. Para poder lograr agendar los eventos condiferentes comandos PLCBus que el usuario decida y que luego estos se ejecutende la manera y en el tiempo correcto fue necesario establecer una estructura detablas de agendas de eventos. Las mencionadas tablas se archivarn dentro delos 32kB de memoria ash que posee el microcontrolador ATmega32.

7.2. Memoria Flash

El microcontrolador utilizado, el AVR de 8bits ATmega32 de ATMEL, poseetres tipos de memoria til para utilizar:

Memoria RAM. 2kB. Utilizada para datos y variables en tiempo de ejecu-cin.

Memoria EEPROM. 1kB. Utilizada a criterio del programador.

Memoria ash. 32kB. Utilizada principalmente para guardar cdigo pro-grama.

Los procesadores AVR fueron creados en una arquitectura Harvard, en dondela RAM se usa para guardar variables y la ash para guardar programa, ylas dos estn en espacios separados de memoria. La complicacin a la hora dequerer utilizar la memoria ash para guardar informacin aparte del cdigo delprograma se agrava ms an por el hecho de que el lenguaje C fue escrito paraarquitecturas Von Neumann, en donde datos y programa coexisten en el mismoespacio de memoria.[18]Para poder indicarle al compilador AVR-GCC de que queremos trabajar condatos en el espacio de programa, se utiliza la librera de avr-libc, en donde se denen macros para la utilizacin de la ash[18].

20

7.3. ESTRUCTURA DE TABLAS HAOPL

Figura 7.1: Organizacin de las tablas en memoria. Las direcciones estn expre-sadas en words.

7.3. Estructura de tablas

Para que se fuese posible agendar eventos para ejecutar por parte del usuario,debe ser posible guardar la informacin generada a partir de esos eventos. Paraello se dise una estructura de tablas por da las cuales estarn ubicadas dentrode la memoria de programa.La estructura consta de una tabla semanal, repartida en 7 tablas equivalentes,una para cada da de la semana. A cada tabla diaria se le asign un tamao de10 pginas, o 1280 bytes (1,25kB).

Como se aprecia en la gura Figura 7.1, en los 2kB ms altos de la memoriade programa se encuentra alojado el Boot Loader e inmediatamente por debajose encuentra el tope superior del conjunto de las tablas. El direccionamiento aesta regin de programa se logra mediante la denicin y posterior utilizacin delas constantes WEEK_TABLE_TOP,WEEK_TABLE_BOTTOM, DAY_TABLE_LEN,entre otras.WEEK_TABLE_TOP y WEEK_TABLE_BOTTOM marcan el nal y el ini-cio de la tabla semanal y determinan un intervalo de 8960 bytes (8.75kB) elcual se reparte uniformemente en las tablas de cada da, empezando desde ladireccin ms baja como el da cero el domingo y terminando en la tabla delda seis, el sbado.A partir de esto, las funciones que acceden a la tabla del correspondiente dareciben como argumento un nmero del 0 al 6 que indica a la tabla de cul dase pretende acceder (0 indica domingo, 6 sbado); este multiplicado al largo detabla de cada da (indicado por DAY_TABLE_LEN) es sumado a la direccinde comienzo de todas las tablas. Esto resulta la direccin de comienzo de latabla del respectivo da.

21


Figura 7.2: Direccionamiento en las tablas.

A lo largo de las tablas diarias estn guardados los eventos que deben eje-cutarse en su respectivo horario a lo largo del da. Cada evento contiene in-formacin acerca del horario a ejecutarse, la cantidad de comandos PLCBusa ejecutarse y la codicacin de estos comandos. Estos eventos se encuentranordenados por orden cronolgico: el primero en ejecutarse en el da se encuentraen las direcciones ms bajas de la tabla del da correspondiente.La informacin de horario a ejecutarse se compone de dos campos dentro delevento: el campo OFFSET DE TIEMPO, de 16 bits, y el campo AM_PM (P enla Figura 7.3), de 1 bit. Este ltimo indica con un 0 si la hora de ejecucin delevento es en horario AM, y con un 1 si la hora es en horario PM. El campo deOFFSET DE TIEMPO indica la hora de ejecucin en segundos relativa a las 12AM/PM (dependiendo del estado del campo AM_PM). Para que efectivamentese lleven a cabo las acciones requeridas en cada evento a la hora estipulada, ex-isten ciertas variables en el programa principal que se actualizan en tiempo realy que hacen las veces de reloj, pero no con el formato habitual, hh:mm:ss, sinocon el formato utilizado en estas tablas, AM_PM:OFFSET (ver Figura 7.2).Bsicamente, estas variables se comparan con los campos correspondientes delprximo evento a ejecutarse a cada segundo para vericar si la hora de ejecucines la corriente.

Para poder agendar los comandos PLBUS se requieren 4 bytes por comando.Esto lleva a que cada evento ocupe como mnimo 7 bytes,es decir, se puede lograragendar un mximo de 182 eventos diarios.

22


Figura 7.3: Diagrama con el formato con el que se almacenan los eventos diarios.

23

Captulo 8

Stack TCP/IP

8.0.1. Diseo

Dado que el sistema es en su mayora reactivo (en el sentido de que losprocesos se bloquean a la espera de eventos) y que el ujo de los mismos espredenido e invariante (visto desde la perspectiva de comunicaciones exitosas),se decidi utilizar para el ujo del programa el mecanismo de round-robin coninterrupciones1, y disear los procesos como mquinas de estado.Para implementar este modelo, se crearon funciones wrappers de los distintosprotocolos, con la nalidad de dividir el ujo en la ejecucin de diferentes tareaso procesos.Se implementaron para estas, conjuntos de funciones estandarizadas de controlde ujo (XXX_start(), XXX_init(), XXX_error(), etc.)2y una estructura debanderas y campos de ujo para la intercomunicacin entre procesos. Dichaestructura es global al proyecto, y es utilizada por el loop principal para deter-minar si se debe ejecutar o no algn paso de la mquina de estados del procesoXXX, y por las interrupciones y otros procesos para conocer datos como ser elestado, quien lo ejecuta, y si fue o no exitoso. Adems, cada proceso tiene uncampo de direccin MAC e IP correspondiente.

8.1. Estructura del main

void main (void)

{

//inicializaciones

for(;;){

1Arquitectura de sistema en la cual se chequea en el loop de programa principal banderasde diferentes procesos, las cuales se activan cuando se da paso a las rutinas de atencin delas correspondientes interrupciones. Al activarse una bandera, en el loop principal se llama auna funcin handler la cual atiende el respectivo proceso. Al nalizar se desactiva la banderacorrespondiente para permitir que se vuelva a repetir el proceso citado anteriormente.[19]

2Aqu las XXX denotan los nombres de los protocolos tales como ARP, ICMP, TCP, SNTP,etc.

24

8.2. EJEMPLO DE FLUJO NORMAL DEL PROGRAMA HAOPL

if(FC.ARP.on_process) ARP_step();

if(FC.ICMP.on_process) ICMP_step();

if(FC.SNTP.on_process) SNTP_step();

}

}

En el loop principal, se chequea si los procesos estn o no activos y en caso deestarlo se da un paso en la mquina de estados. Los procesos se ponen inactivosen caso de estar a la espera de algn evento externo, y son despertados cuandoeste evento ocurre. El paso en que se encuentran es manejado por el handler delproceso, dentro de la funcin XXX_step() o por otros procesos o interrupcionesen caso de error a travs de la funcin XXX_error().Dada la gran cantidad de archivos, interfaces publicas y funciones, se debiser muy cuidadoso en la organizacin fsica del cdigo. Para esto, se utiliza unarchivo de inclusin global del proyecto (includes.h) el cual incluye las interfacespblicas de todos los protocolos y handlers. Por otra parte, dada la gran can-tidad de estructuras utilizadas, las mismas estn denidas en un nico archivo(struct.h) para evitar diseminarlas por todo el cdigo y hacer ms fcil su mod-icacin.Un comentario aparte, es que los handlers de los protocolos tambin utilizanotros protocolos mediante las funciones XXX_start() lo que justica utilizarcampos XXX_requester para poder saber quien debe ser noticado en caso dexito o error de un proceso.Como ejemplo, SNTP_step llama a ICMP_start, que inicia un proceso ICMP.A su vez ICMP_step() llama a ARP_start() que inicia un proceso ARP.

8.2. Ejemplo de ujo normal del programa

Para mostrar el ujo del programa para el caso de uso aplicado en las pruebasEthernet (ver pgina subseccin 12.1.1), usamos las siguientes convenciones:

El diagrama de estados del programa es el siguiente:Si miramos la gura Figura 8.2 horizontalmente se aprecia la evolucin de

los estados de cada tarea asociada a un protocolo. Si seguimos los nmeros, seaprecia la secuencia de eventos que se suceden desde que se inicia el pedidode tiempo desde la UART hasta que se procesa el timestamp que devuelve elservidor SNTP. Como se ve, SNTP despierta a ICMP e ICMP despierta a ARP.

8.3. Recepcin de paquetes

Al recibir el mdulo un paquete por medio del chip controlador Ethernet,este se lo indica al microcontrolador por medio de un pedido de interrupcin.Acto seguido, la rutina que atiende este pedido dentro del rmware realiza dosacciones: la primera es prender una bandera la cual indica que existe un paquetepor procesar y que se chequea en el loop principal del programa y la segunda es

25

8.3. RECEPCIN DE PAQUETES HAOPL

Figura 8.1: Convenciones del diagrama de estados del programa.

Figura 8.2: Diagrama de estados del programa para el caso de las pruebas decomunicacin Ethernet realizadas.

26

8.3. RECEPCIN DE PAQUETES HAOPL

Figura 8.3: Diagrama del chequeo de protocolo

la desactivacin de las interrupcin mencionada.Ya dentro del loop principal se da paso a una funcin (check_prot) que chequeael protocolo del paquete recibido, y en base a esto y a los estados (process_step)de los diferentes procesos se los procesa o descarta. Si un paquete es descartado(ya sea por ser de un protocolo, IP o puerto invlido o porque no se estaba es-perando), se retorna de la funcin sin modicar ninguna de las banderas de ujoy dejando la interrupcin respectiva habilitada. Por otra parte, si el paquete esvlido, puede requerir procesamiento inmediato y ser este el nico procesamien-to necesario (p.e un ICMP_request, un PING contra el mdulo, necesita unarespuesta inmediata) o dejarse almacenado para ser procesado posteriormente.En el primer caso, se procesa dentro de la funcin y se sale de la misma dejandolas interrupciones habilitadas. En el segundo caso, se despierta al proceso dueodel paquete y se sale de la funcin deshabilitando la interrupcin correspondi-ente, que ser habilitada luego que el paquete sea procesado. De esta forma elsistema queda pronto para recibir nuevos paquetes.La forma en que se chequea el protocolo en la funcin check_prot puede verseen el diagrama de la gura Figura 8.3

27

Captulo 9

Comunicacin entrewebserver y mdulo

El mdulo y el webserver realizan sus procesos de comunicacin utilizandobsicamente el protocolo TCP de capa de transporte, y en otros casos pun-tuales se utiliza HTTP sobre capa de aplicacin. El proceso siempre consisteen la creacin de un socket TCP llevando a cabo un three-way handshake[20] yluego existen dos posibilidades dependiendo del mensaje a transmitir. Por unlado, para la informacin que el mdulo enva al server se utiliza el mtodoHTTP GET a ciertas pginas. Por el otro lado, para enviar informacin contrael mdulo se ahorran todos los bytes que signican los encabezados utilizadosen HTTP y directamente sobre el socket TCP, que adems se abre a determi-nados puertos dependiendo del mensaje a transmitir, se envan ciertas stringsprejadas.Los procesos de comunicacin que se llevan a cabo se resumen en:

Transmisiones que inicia el webserver

Transmisin de las tablas de agenda de eventos Peticin de ejecucin de un comando PLCBus instantneo Peticin de envo del log de eventos Peticin de envo del estado de los artefactos (status)

Transmisiones que inicia el mdulo

Envo de direccin IP del mdulo Envo del log de eventos, luego de la peticin Envo del status, luego de la peticin

Los sockets TCP que son abiertos por medio del mdulo, se generan al puer-to 80(HTTP) ya que se utiliza el mtodo GET[20]. Por otro lado, los puertosdel mdulo utilizados se pueden observar en la tabla 9.1

Las siguientes descripciones detallan los procesos mencionados en la tabla9.1. Cabe mencionar que las mismas muestran los procesos en el estado de

28

9.1. ENVO DE TABLAS HAOPL

PUERTO FUNCIN

60030 Envo de una tabla de agenda actualizada60031 Peticin de envio de todas las tablas60032 Envo de paquetes con IP del mdulo60033 Ejecucin instantnea de comando PLCBus60034 Envo de status60035 Envo del log

Cuadro 9.1: Puertos utilizados en el mdulo

desarollo anterior a la implementacin de la encriptacin y autenticacin en losmismos, por lo que las descripciones no muestran exactamente lo que en realidadocurre. Sin embargo, este hecho se aprovecha desde el punto de vista de quepuede mostrarse los mencionados procesos de una forma clara y entendible.

9.1. Envo de tablas

Las tablas diarias de agendado se transmiten en dos circunstancias diferentes:

Por iniciativa del webserver, transmisin de alguna tabla actualizada porparte del usuario

Por iniciativa del mdulo, se pide al webserver el envo de todas las tablas,no necesariamente actualizadas. Este ltimo proceso se lleva a cabo cuandoel mdulo se reinicia.

Para el primer caso, el desarrollo de este proceso se resume en los siguientespasos:

1. Webserver abre socket TCP/IP persistente (three-way handshake)

2. Webserver manda una tabla. En el como carga til de TCP (TCP payload)se agrega: [TABLEn]+[word con largo de la tabla]+[tabla del da n]

3. Mdulo contesta: [OKn]1

4. Server cierra socket

Se repiten los pasos 2 y 3 hasta que se hayan enviado las tablas necesarias.En estos pasos puede ser que el paquete de repuesta [OKn] hacia el servidorde aplicaciones se pierda y no sea recibido. En este caso, el webserver reenviarhasta 3 veces el paquete con la tabla. Si luego de esto la respuesta no es recibi-da, se muestra un mensaje en la pgina web indicando que existe un error deconexin con el mdulo.

Para el segundo caso, el desarrollo del proceso es como sigue:

1n indica un nmero del 0 al 6 en formato ASCII para indicar la tabla de qu da se trata

29

9.2. ACTUALIZACIN DE IP HAOPL

1. Mdulo abre socket TCP/IP al puerto 80 del server y enva paquete GETcon el siguiente encabezado:GET /send_all.php?mod_id=X HTTP/1.1\r\nHost: www.radiocostadeoro.com:80\r\n\r\n2

2. Se realiza el proceso para algunas tablas descrito anteriormente con lasalvedad de que al abrirse un nuevo socket, este ser contra el puerto60031 y no el 60030

3. Luego que se envan las 7 tablas, se responde con un mensaje de xitoHTTP 200 OK, se cierra el socket

El detalle de estos procesos puede observarse en la gura Figura 9.1. Se ob-serva en los primeros paquetes, en color verde, el establecimiento de la conexinllevando a cabo el three-way handshake y luego se enva el mensaje de GET.Acto seguido se abre un nuevo socket, pero esta vez contra el puerto 60031 delmdulo. Se aprecian los dos paquetes consecutivos con las banderas [PSH, ACK]y sus detalles que muestran que dejan ver claramente la conformacin de estos.

9.2. Actualizacin de IP

Ya que el mdulo est concebido para estar instalado en un hogar, el tipode conexin a Internet ms comn para este caso es con direccin IP dinmica,es decir que el proveedor de Internet otorga una nueva IP cada cierto perodode tiempo a la conexin del hogar. Esto requiere que se haya implementadouna solucin para que el mdulo se mantenga reportndose al servidor e in-dicndole su IP, para que cuando este quiera contactar al mdulo sepa a dndehacerlo.La forma de reportarse es simplemente cada 250 segundos enviar un mensajeGET a cierta pgina que capta la IP de destin de ese mensaje. A saber:

1. Mdulo abre socket TCP/IP al puerto 80 del server

2. Se enva paquete GET con el siguiente encabezado:GET /get_ip.php?mod_id=X HTTP/1.1\r\nHost: www.radiocostadeoro.com:80\r\n\r\n

3. Se responde con un mensaje de xito HTTP 200 OK y se cierra el socket

9.3. Ejecucin de un comando

Cuando el usuario nal as lo desee, puede accionar instantneamente cualquieractuador que poseea instalado. Al ocurrir esto se desarrolla entre webserver ymdulo de esta forma:


2la variable mod_id est vinculada al usuario nal del sistema. Cada usuario y mdulocorrespondiente tiene asociado un nico mod_id

30

9.3. EJECUCIN DE UN COMANDO HAOPL

Figura 9.1: Extracto de una captura en el Wireshark mostrando envos de tablas

31

9.3. EJECUCIN DE UN COMANDO HAOPL

Figura 9.2: Extracto de una captura en el Wireshark mostrando proceso deactualizacin de IP

32

9.4. ACTUALIZACIN DEL STATUS HAOPL

Figura 9.3: Extracto de una captura en el Wireshark mostrando proceso de envode comando

2. Webserver manda como TCP payload: [COMMD]+[4 bytes de comandoPLCBus]

3. Mdulo contesta: [OK]+[byte de respuesta PLCBus]


Puede ser que el paquete de repuesta hacia el servidor de aplicaciones sepierda y no sea recibido. En este caso, el webserver reenviar hasta 3 veces elpaquete con la tabla. Si luego de esto la respuesta no es recibida, se muestraun mensaje en la pgina web indicando que existe un error de conexin con elmdulo.

9.4. Actualizacin del status

Este intercambio sucede cuando desea saberse el estado de los artefactosinstalados en el hogar. Es el nico intercambio que se realiza en dos etapas: la

33

9.5. ENVO DE LOG DE EVENTOS AGENDADOS HAOPL

primera consta de la apertura de un socket TCP/IP, el envo de la peticin destatus y el cerrado del socket. La segunda consta del envo de un paquete GEThacia el servidor incluyendo la informacin en las variables incluidas.

1. A pedido del usuario, el webserver abre socket TCP/IP persistente.

2. Webserver manda como carga til de TCP: [STATS]+[byte con cantidadde artefactos a encuestar]+[direcciones PLCBus a encuestar]

3. Mdulo contesta: [OK]

4. Server cierra socket y el mdulo encuesta a los artefactos

5. Al recibir la respuesta de los actuadores, el mdulo abre socket al puerto80 y manda un paquete GET el siguiente encabezado:GET /status_receive.php?mod_id=X&dir1=B1B2B21B30B31&dir2=B1B2B21B30B31&...&dirz=B1B2B21B30B31HTTP/1.1\r\nHost: www.radiocostadeoro.com:80\r\n\r\n

6. Servidor manda mensaje de respuesta HTTP 200 OK y cierra socket

Los bytes B20 B21 y B30 B31 se envian dependiendo del artefacto e indicannivel de brillo y dimmer rate respectivamente. El objeto de cerrar el socket inicialy luego incluir la informacin relevante dentro de las variables del paquete GETse debe a que el proceso de encuestar a los artefactos puede llegar a tomar ciertotiempo dependiendo de la cantidad a encuestar.

9.5. Envo de log de eventos agendados

El mdulo guarda un registro histrico de los eventos agendados que hansido ejecutados (log de eventos). Esta informacin tambin se encuentra en elservidor de aplicaciones, aunque no en su versin ms actual. Si el usuarioas lo desea esta informacin puede actualizarse en el servidor y el proceso deintercambio de informacin transcurre as:


2. Webserver manda como TCP payload: [EVLOG]

3. Mdulo contesta: [128 bytes de respuesta de log]


Puede ser que el paquete de repuesta hacia el servidor de aplicaciones sepierda y no sea recibido. En este caso, el webserver reenviar hasta 3 veces elpaquete con la tabla. Si luego de esto la respuesta no es recibida, se muestraun mensaje en la pgina web indicando que existe un error de conexin con elmdulo.

34


Figura 9.4: Extracto de una captura en el Wireshark mostrando proceso de envode status

35


Figura 9.5: Extracto de una captura en el Wireshark mostrando proceso de envode comando

36

Captulo 10

Ejecucin y manejo deeventos y comandos

10.1. Introduccin

En la siguiente seccin del documento se hace un breve recuento del trabajorealizado en lo relativo a la comunicacin ejecucin y manejo de los eventosy comandos, as como para las tareas necesarias para la implementacin dela comunicacin entre el mdulo PLCBus y nuestro mdulo. Se recomiendaleer previamente la documentacin sobre el protocolo de comunicacin con elPLCBus-1141[21], en especial para la comprensin de la subseccin que tratasobre las pruebas con el protocolo.

10.1.1. Deniciones previas

Evento

Reere a un conjunto de comandos, ejecutados de forma simultnea1 en elsentido de que su ejecucin es consecutiva, y sin tiempos de espera entre ellos.

Comando

Reere a una trama conformada de acuerdo a la especicacin del protocolode comunicacin de PLCBus, cuya nalidad es provocar una accin de los ac-tuadores.

Respuesta

Reere a la o las tramas recibidas como consecuencia del envo de un comando,y que contienen informacin referida a la ejecucin del mismo.

1Relativo, ya que el mecanismo implementado no permite enviar un comando hasta norecibir la respuesta del anterior.

37

10.2. CORROBORACIN DEL PROTOCOLO PLCBUS HAOPL

10.2. Corroboracin del protocolo PLCbus

10.2.1. Conguracin del dispositivo PLCbus 1141

Por una cuestin de orden, antes de realizar las modicaciones al dispositivoPLCBus-1141 necesarias para adaptarlo a nuestro proyecto, se decidi realizaruna vericacin rpida de los comandos del protocolo PLCBus. En este puntose comenzaron a encontrar problemas vinculados al protocolo y a la empresaPLCBus que fabrica y distribuye los dispositivos. En primer lugar, encontramosque la documentacin era escasa y errnea (p.e. confundan byte con bit sis-temticamente). Adems, fue imposible conseguir un driver para conectar laPC y el PLCBus-1141 que funcionara. Luego de haber probado todos los driversque se nos recomendaba usar por parte de los distribuidores y fabricantes delproducto sin xito, se decidi probar un driver VCOM[22]2 genrico. Para laconguracin del mismo se requieren los parmetros VID y PID3 del dispos-itivo. Estos pueden conocerse utilizando un snier de puerto USB o editandolos archivos *.inf del driver correspondientes. Encontramos que los VID y PIDdel PLCBus-1141 obtenidos con el snier, no coincidan con los registrados enel driver distribuido por PLCBus lo cual haca que el mismo no funcionara. Sibien nuestra teora era que esto se deba a un cambio en el proveedor de los ca-bles adaptadores USB-RS232 (por eso la diferencia de VID y PID), no se podadescartar que se debiera a un error en el mismo por lo que se decidi eliminarel cable USB y hacer la modicacin para RS232 sin haber podido vericar elfuncionamiento del mdulo previamente.Posteriormente se pudo vericar el funcionamiento del cable haciendo un loop-back con el mismo, lo cual hace suponer que el problema se debi efectivamentea un cambio de proveedor.Una vez solucionado este problema, nos dispusimos a corroborar el protocoloutilizando el software HomePlanner 2.0[23] y un snier de RS232. Para cor-roborarlo, se enviaron comandos de encendido/apagado a diferentes direccionessin importar si las mismas correspondan o no a mdulos existentes en la reddomtica. Con la informacin de los comandos recabada por medio del snier,complementamos la documentacin existente del protocolo pudiendo corregirvarios errores y ambigedades planteadas en el mismo.En este punto se consider prudente comenzar una corroboracin manual delprotocolo utilizando una terminal para puertos COM. Esto era un paso necesarioya que hasta el momento no se haba podido vericar si la informacin acercadel formato de entramado y baudrate con la que se contaba era correcta. Dehecho, la especicacin del protocolo solo menciona el baudrate y no da ningndetalle acerca del entramado. Asumimos que la misma se realizaba con 8 bits,1 de parada y sin paridad (8-N-1) dado que esta es la conguracin ms comnen comunicaciones serie asncronas. Para nuestra sorpresa, el PLCBus-1141 noresponda a ningn comando enviado, a los que s responda cuando se enviabanpor medio del HomePlanner 2.0. Se probaron entonces diferentes combinacionesde repeticiones de comandos, tiempos entre comandos, chequeo de paridad, etc.pero no se obtuvo resultado alguno. Se prob entonces cambiar de software paradescartar que este fuera la raz del problema, lo que fue exitoso. Luego de probar

2Puerto COM virtual, se utiliz USB CDC/ACM Device Driver Demo Version, 2008,Thesycon

3Vendor ID y Product ID que identican al dispositivo USB

38


varios programas de Terminal diferentes y ver que no todos funcionaba correc-tamente con el 1141, se concluy de que existan detalles en la implementacinque escapaban a nuestro control los cuales hacan que la comunicacin fuerao no exitosa. Afortunadamente, esto no tuvo mayor incidencia en el resto deldesarrollo aunque si implic un retraso considerable respecto a lo planicado.

10.2.2. Pruebas de funcionamiento

Para vericar que la conguracin utilizada funcionara correctamente, seplanearon las siguientes pruebas:

1. Prueba de envo de comandos corruptos

2. Prueba de saturacin del transmisor

Para la primera prueba, se enviaron comandos supuestamente errneos deacuerdo a lo especicado por el protocolo, de modo de simular errores en lacomunicacin con el PLCBus-1141 y ver si se produca algn tipo de respuestaque pudiese interferir con el normal funcionamiento del driver (p.e. respuestade envo satisfactorio de un comando inexistente). Se encontr que, a diferenciade lo que se esperaba, el mdulo responda a comandos errneos. Sin embargo,para que el mdulo responda a los mismos, estos deben ser deformaciones delos comandos aceptados por el protocolo y producen el mismo efecto que loscomandos correctos.Para aclarar un poco este punto, tomemos el siguiente ejemplo:El mensaje constituido por la siguiente trama 02 05 0E 12 22 00 00 03 (encendermdulo de direccin B3, con vericacin de encendido)4. Si en su caso se envala trama 02 FF 0E 12 22 (largo de trama errneo, los campos DATA1 y DATA2perdidos as como ETX) se ejecuta correctamente el encendido del mdulo y sedevuelve la conrmacin.Esto es preocupante porque demuestra que el protocolo no es respetado porparte de los fabricantes lo cual les quita seriedad. Adems, en caso de que unatrama se cortara, podra ser interpretada como un comando diferente al que sepretendi enviar:Si a la trama 02 05 02 12 22 00 00 03 (encender B3 con vericacin) se le pier-den los primeros 2 bytes tenemos resultante el mensaje:02 12 22 00 00 03 (apagar todas las unidades en la direccin de hogar HOMEA).El potencial error se encuentra si se utiliza 02 en el campo USER_CODE, o A3en el campo HOME_UNIT. Es necesario entonces tener mucho cuidado con eltiempo que se interrumpe un envo de comandos, lo cual podra incluso ameritarque el envo de los mismos se haga de forma atmica (deshabilitando los pedidosde interrupcin en el procesador). Esto no requiere mayores modicaciones alsoftware y no implica afectar signicativamente el funcionamiento del microcon-trolador ya que el envo propiamente dicho dura apenas 6.7ms cada 400ms5.Dado que en cualquier caso, la conrmacin contiene la informacin del coman-do enviado (lo que el PLCBus-1141 interpret y envi por la lnea) basta convericar que la conrmacin corresponda al comando para asumir que se envi

4Los nmeros representan valores hexadecimales5Todava esta siendo discutido en el grupo si es o no necesario.

39


correctamente.La otra prueba planeada fue una prueba de saturacin consistente en enviaruna gran cantidad de comandos consecutivos y vericar que los mismos fueranejecutados. Esta prueba se realiz enviando paquetes de hasta 20 comandos es-paciados 1 segundo, obteniendo como tasa mnima de xito el 80%, lo cual nospermiti comprobar denitivamente que la conguracin elegida era la correcta.

10.2.3. Ensayos sobre tiempos de respuesta

Como parte de la vericacin del protocolo PLCBus, se realizaron ensayoscon el n de determinar los tiempos involucrados en el envo de los comandos.Para esto, se procedi iniciando un contador al completar la transmisin de uncomando y terminarlo al recibir la primer conrmacin valida.

variable tiempo (ms) delta(ms)231 288,288 0,2496233 290,784 -2,2464232 289,536 -0,9984228 284,544 3,9936228 284,544 3,9936231 288,288 0,2496234 292,032 -3,4944232 289,536 -0,9984231 288,288 0,2496232 289,536 -0,9984

promedio: 288,5376

El mismo experimento se repiti para los comandos con vericacin los cualesdan 2 mensajes de respuesta al comando: el primero es el interno del 1141 y elsegundo es la vericacin del mdulo (p.e. encendi correctamente o no). Eneste caso se hicieron medidas para averiguar el tiempo mximo que tarda enllegar el segundo comando, utilizando la misma metodologa.

variable tiempo (ms) delta(ms)251 313,248 -4,368245 305,76 3,12250 312 -3,12250 312 -3,12249 310,752 -1,872246 307,008 1,872245 305,76 3,12247 308,256 0,624248 309,504 -0,624244 304,512 4,368

promedio: 308,88

De los resultados anteriores se desprende que en realidad, la cota de 400msque dice la documentacin del protocolo esta sobredimensionada y que se puedemejorar la performance del sistema si se utiliza la cota hallada experimental-mente.

40

10.3. DESCOMPOSICIN MODULAR HAOPL

10.3. Descomposicin modular

El anlisis permiti determinar 4 mdulos bien diferenciados de acuerdo asu responsabilidad y alcance:

1. Scheduler

2. Reloj

3. UART

4. Motor de PLCBus

Elmdulo Scheduler es un motor de tareas de varios pasos, que se encargadel control de los eventos agendados a ejecutar, as como de tareas accesoriasnecesarias.6

El mdulo Reloj, se encarga de llevar la hora del sistema a partir de la inter-rupcin de un Timer y de avisar al Scheduler si es necesario que acte7.El mdulo Motor de PLCBus, se encarga del control general de la ejecucinde comandos de los tipos de eventos descriptos anteriormente, recibiendo paraello peticiones (de TCP en caso de comandos instantneos y status, y Scheduleren caso de agendados).Garantiza que se ejecuten correctamente de acuerdo a las prioridades e imple-menta retrasmisiones en caso de ser necesario. Adems, se encarga del proce-samiento de las respuestas, generando logs, o enviando las respuestas al Server.El mdulo de UART es el encargado de manejar la comunicacin serie con elPLCBus 1141, implementando el envo y recepcin, vericacin de la conforma-cin de las tramas y ltrado de tramas que no correspondan a la comunicacinen curso.La siguiente gura muestra un diagrama bsico de la interaccin que se da entrelos diferentes mdulos para lograr la correcta ejecucin de eventos y comandos8.

10.4. Mdulo UART

10.4.1. Envo y recepcin

Este mdulo implementa el enlace con el mdulo PLCBus 1141, intercam-biando tramas con el mismo de acuerdo al formato especicado por el protocolode comunicacin con PLCBus.Para implementar la comunicacin con el mdulo PLCBus-1141, se utiliza laUART del microprocesador congurada a una velocidad de 9600bps de acuerdoa lo especicado en el protocolo.El formato de la trama no se encuentra especicado en el protocolo pero se de-termino que era la conguracin tpica de 8 bits, 1 bit de parada y sin chequeode paridad.El mdulo esta compuesto por un trasmisor, implementado utilizando la ISRde UDRE9 desencadenada al vaciarse el registro de salida, luego de nalizar el

6Ej: re sincronizar la hora, buscar el prximo evento a ejecutar y comunicar a PLCBus lanecesidad de ejecutar un evento.

7 Ej: es hora de ejecutar un evento, es hora de re sincronizarse8Ver Figura 10.19Uart Data Register Empty, indica que el registro de salida est vaco.

41

10.4. MDULO UART HAOPL

Figura 10.1: Interaccin entre los mdulos que componen el software

envo de un byte, y por un receptor implementado utilizando la ISR de RX_Cla cual se ejecuta al terminar de recibir correctamente un byte.El envo de una trama se realiza escribiendo la misma en un buer de saliday colocando en el registro de salida el primer byte. A continuacin, la ISR deUDRE incrementa el ndice del array correspondiente al comando el cual es unndice de 3 bits que cuenta circularmente de 0 a 7 y coloca en el registro desalida el byte siguiente.Para la recepcin de las respuestas, los bytes recibidos se almacenan en un buerde entrada a partir de que se detecta el comienzo de la trama (STX).Se verica byte a byte la correcta conformacin de la trama recibida (STX,length, direccin, ETX) y en caso de no superar los ltros, se descarta y secontina a la espera de la respuesta.El sistema funciona en modalidad half-duplex, lo que signica que cuando setrasmite no se escucha, y viceversa, de forma de organizar la comunicacin en unrgimen de pregunta-respuesta, un criterio de diseo adoptado desde el principiocon la nalidad de simplicar el desarrollo.

10.4.2. Deteccin de errores

Una de las razones por las cuales fue elegido el protocolo PLCBus, fue por sumenor tasa de error en comparacin con otros protocolos sobre lneas elctricas.El sistema pretende ser autnomo, y funcionar sin un usuario vericando que sehayan ejecutado los comandos, por lo que es crtico poder detectar y manejarerrores por menos probables que sean.Durante el estudio y vericacin del protocolo, se observo que todas las respues-tas se identican con el mismo cdigo de usuario y direccin del mdulo a quien

42

10.5. RELOJ (TIME.C Y TIME.H) HAOPL

se envi el comando, salvo comandos enviados a varios mdulos10 que puedenno tener la misma direccin.A su vez, durante las pruebas de vericacin del protocolo, se detectaron algunoserrores frecuentes:

1. Largo de la respuesta diferente a lo establecido por el protocolo

2. Respuestas con cdigo de usuario invalido

3. Respuestas con direccin invlida

4. Trama mal conformada

Por esto, se implementa a nivel de la recepcin un ltrado de las tramas te-niendo en cuenta el cdigo de usuario y la direccin, adems del cumplimientodel formato de trama.Dado que existen excepciones, se implementa un mecanismo que permite desac-tivar el ltrado por direcciones, por medio del control de una bandera dedicadaa este n.Como los parmetros necesarios para validar las respuestas dependen del co-mando enviado, se opt por un esquema de trasmisiones del tipo half-duplex, loque facilita la identicacin de la relacin entre comandos y sus respuestas.Para realizar la vericacin de la conformacin de las respuestas, se utiliza unndice para la recorrida del array de entrada. Este ndice se pone en 0 luego deque se trasmite, lo que indica que se est a la espera del comienzo de una trama,y contina valiendo 0 mientras no se reciba el STX (02h) de forma de que, si poralguna razn se recibiera una trama empezada, la misma no sera reconocida.Al recibirse el STX, se auto incrementa el ndice y los datos sucesivos son al-macenados de forma consecutiva en el array de entrada, hasta recibir el novenobyte, correspondiente a ETX (03h), lo que marca la nalizacin de la recepcin.Al recibirse el ltimo byte de la trama, se llama a una funcin que verica si latrama representa o no la nalizacin de la comunicacin11.Si por algn motivo se debe descartar una trama, se marca el penltimo byte dela trama en el buer (correspondiente a RX_TX_SWITCH) con valor 0, lo quees interpretado por nuestro motor como la ausencia de respuesta. Adems, sereinicia el ndice a 0, habilitando la recepcin de una nueva trama de respuesta.

10.5. Reloj (time.c y time.h)

Este mdulo implementa un reloj de tiempo real que segundo a segundodetermina si es necesario realizar alguna accin, en funcin de la hora interna yla hora de los eventos programados. Se implementa por medio de una rutina deatencin a las interrupciones generadas por el Timer112, el nico de los timerscapaz de generar interrupciones cada un segundo a partir del reloj interno13.La rutina incrementa la variable interna que se encarga de llevar la hora14, y

10Un ejemplo es el comando ALL LIGTHS OFF, al cual se responde desde una direccinja.

11Ver seccin 10.7 Motor de PLCbus12timer/counter de 16 bits13Contando hasta 15625 a frecuencia f/1024 =15625*1024/16Mhz = 1s14Llevada en forma de segundos a partir de las 0 horas AM o PM

43

10.6. SCHEDULER (SCHEDULER.C Y SCHEDULER.H) HAOPL

al llegar a las 12hs (43200s) modica la bandera que indica si la hora es AM oPM. Adems, en caso de llegar a las 12hs PM cambia el da actual. Cuando estosucede, se llama a una funcin auxiliar la cual busca el primer evento agendadopara el da corriente y lo congura como el prximo evento a ejecutar.En cada instancia de la interrupcin, se compara el valor de la hora del sistemacon la del prximo evento y con horas prejadas para la re sincronizacin. Encaso de coincidir con alguna de estas notica al scheduler de la necesidad deejecutar una accin, y es este quien se encarga de las tareas necesarias.Como es imposible ajustar la frecuencia exactamente a 16Mhz, puede existiruna pequea deriva en la hora interna, que acumulada podra signicar un des-fasaje considerable. Por esto se implementa un mecanismo que ejecuta la resincronizacin peridica del reloj interno.Esta re sincronizacin se realiza al llegar una hora determinada (MOD_IDsegundos). MOD_ID es un nmero identicador del sistema, en el rango 200-43000 que permite diferenciarlo de los dems sistemas. El objetivo de realizarla sincronizacin a esta hora es evitar que todos los mdulos pidan la hora almismo tiempo, lo cual producira una sobrecarga del servidor de fecha y hora15,e incluso podra signicar la negacin del servicio por confundirse con un ataqueal servidor.Como se desconoce a priori que tan grave puede llegar a ser este desfasaje almomento de la re sincronizacin, es necesario tomar algunas precauciones paraevitar un funcionamiento anmalo. Se contempla entonces la posibilidad de queel reloj interno adelante en relacin a la hora real, lo cual implicara un saltohacia atrs en el tiempo al llegar la hora de re sincronizar. Esto puede producirque se desencadene una nueva sincronizacin por volver a transitarse la horade la misma. Esto, si bien no es crtico para el sistema, puede ser fcilmenteevitable y ya que fue detectado en una etapa temprana de desarrollo, se decidiimplementar una bandera que desactive la sincronizacin durante 40 segundosluego de la primera (tiempo ms que prudencial) como forma de evitar errores.En algunos casos es necesario mantener en funcionamiento el reloj pero evi-tar la ejecucin de tareas programadas por lo que se implementa una bandera(FC.SCHEDULER.ON) que habilita o deshabilita la ejecucin de eventos agen-dados, sin afectar al resto del sistema.

10.6. Scheduler (scheduler.c y scheduler.h)

Este mdulo se encarga de llevar a cabo las secuencias necesarias para la eje-cucin de comandos agendados. Acta como intermediario entre el reloj, quiennotica la necesidad de ejecutar eventos, y el motor de PLCBus, quien los eje-cuta. Adems, se encarga de realizar tareas accesorias, como ser la actualizacinde la hora.La estructura de este mdulo es similar al de los dems mdulos de tareas, esdecir, una funcin _step() llamada desde el loop principal dentro del round-robin, y funciones para la inicializacin, comienzo y detencin del mismo.Se implementan tres tareas:

INICIAL

15En caso de que se transforme en un producto comercial de distribucin masiva

44

10.7. MOTOR DE PLCBUS HAOPL

Esta tarea es desencadenada al recibir tablas actualizadas provenientes del servi-dor. Se encarga de pedir inicialmente la fecha y hora utilizando para esto elmdulo de SNTP. Esto es necesario ya que la actualizacin de tablas puede re-querir un tiempo considerable de uso exclusivo del procesador, produciendo undesfasaje entre el reloj interno y la hora real. Al obtener respuesta, el mduloSNTP se encarga de congurar la hora e iniciar el mdulo de reloj. La tarea seencarga tambin de buscar en las tablas el prximo evento a ejecutar y cong-urarlo para su ejecucin, utilizando para esto funciones auxiliares16.

EJECUTAR_CMD

Esta tarea es desencadenada por el mdulo reloj17 al llegar la hora de ejecucindel evento agendado.Transere el evento a ejecutar (por medio de un puntero a la ubicacin en memo-ria ash) al motor PLCBus para que se encargue de su ejecucin, y luego buscay agenda el prximo evento a ser ejecutado.

RESYNC

Esta tarea es desencadenada por el mdulo reloj al llegar la hora de la re sin-cronizacin. Se encarga de actualizar fecha y hora18, corrigiendo as posiblesdesfasajes.Este desfasaje puede ser un retraso del reloj interno respecto a la hora real, porlo que al re sincronizarse podra producirse un salto hacia delante en el tiempo,y esto a su vez producir que un evento agendado no sea ejecutado. Basadosen la teora de que es mejor tarde que nunca, al terminar de obtener la nuevafecha y hora, la rutina verica que el evento apuntado no se haya vencido sinser ejecutado, y en caso de ser as, procede con su ejecucin.

10.7. Motor de PLCbus

El motor de PLCBus es el encargado de controlar y ordenar la ejecucinde comandos, as como de vericar que estos sean ejecutados correctamente,retrasmitir en caso de ser necesario, y efectuar las tareas de post proceso de losmismos.El funcionamiento del motor de PLCBus se basa en un ncleo que implementael motor de tareas, el cual se encarga del ujo de este mdulo motor y de la tomade decisiones. El proceso se descompone en varias etapas, que incluyen el envode los comandos, la vericacin de las respuestas, el reenvo de los comandos yel post proceso19.Al igual que los dems motores de tareas implementados, el ncleo se imple-menta por medio de una funcin_step() llamada desde el loop principal en casode encontrarse en ejecucin la tarea. Al ejecutarse esta rutina se chequea si ex-iste alguna tarea de post proceso pendiente y se ejecuta. Si no es as, se enva

16Estas funciones se encuentran implementadas en tablas.c.17ISR de timer1 en time.c18Se realiza una peticin a SNTP, quien consulta al servidor NTP sobre la hora19Entendido como las tares posteriores, consistentes en recongurar el sistema y prepararse

para la prxima ejecucin, la generacin de registros y envo de informacin al servidor.

45

10.7. MOTOR DE PLCBUS HAOPL

uno de los comandos de los eventos pendientes respetando las prioridades. Alrealizarse el envo, el motor se coloca en un estado busy, del cual sale al recibiruna respuesta al comando.

10.7.1. Tipos de eventos

En esta etapa, se extendi el anlisis de requerimientos para el envo y recep-cin de comandos identicndose 3 tipos de eventos diferenciados entre si porcaractersticas como el numero de comandos que los conforman, la criticidad desu ejecucin y el procesamiento necesario pa

Documents

Universidad de la República Facultad de Ingeniería ...iie.fing.edu.uy/publicaciones/2009/GBT09/GBT09.pdf · Universidad de la República ... Santiago Morrison por su colaboración