capÍtulo 3. descripciÓn del...

3.1 INTRODUCCIÓN

Con el objetivo de aplicar los conocimientos adquiridos sobre buses de campo y demostrar

la utilidad de esta tecnología, se ha creado un sistema domótico prototipo basado en bus CAN. Durante el diseño se ha tenido en cuenta que el sistema debía tener las siguientes

características: - Ampliable. Para permitir la inclusión de nuevos sensores y actuadores de muy

diferentes tipos sin tener que modificar los protocolos o el software de los elementos existentes.

- Abierto. Con especificaciones claras para que otras personas puedan desarrollar su propio hardware e incluirlo en el sistema y ofreciendo la posibilidad de que de este proyecto surjan otros que lo complementen.

- Controlable de forma remota. Para permitir la monitorización del estado de la casa y la intervención en el sistema desde cualquier ordenador conectado a Internet y desde terminales móviles.

- Con maqueta. Para lograr un entorno más cercano a la realidad donde poder probar el sistema.

Como resultado, se ha obtenido un sistema articulado en torno a un bus CAN y que tiene

la siguiente estructura:

Fig. 3. 1 Estructura del sistema completo

CAPÍTULO 3. DESCRIPCIÓN DEL SISTEMA

Análisis y aplicación de los buses de campo a la domótica

53

La figura anterior muestra la disposición de los elementos del sistema. En él podemos destacar el elemento maestro, que está constituido por un DSP de Texas Instruments del tipo TMS320F2812. El elemento maestro se encarga entre otras cosas de gestionar la información del sistema, registrar elementos y hacer de puente entre el usuario y los diferentes elementos sensores y actuadores que integran la red.

Otro de los elementos destacados del sistema es el Elemento de Comunicación con el

Exterior. Se trata básicamente de un módulo RCM2200, que contiene un procesador Rabbit 2000. Este módulo está preparado para ser conectado en redes Ethernet 10/100BaseT, y su misión es la de proporcionar canales de comunicación con el usuario ya sea a través de Internet o a través del módem GSM. El acceso al sistema por parte del usuario se puede realizar de dos maneras, a través de un ordenador conectado a Internet o a través de un terminal móvil GPRS[8], en ambos casos la vía de entrada al sistema es el conector Ethernet incorporado en el elemento de comunicación con el exterior. Por otra parte el sistema puede informar al usuario de ciertos eventos urgentes a través de mensajes SMS y para ello utiliza el módem GSM, aunque esta forma de comunicación es unidireccional, ya que el usuario no puede interactuar con el sistema por medio de mensajes SMS.

Se define como elemento a cualquier sensor o actuador que se encuentra en el sistema.

Los elementos sensores y actuadores se agrupan por nodos. Estos nodos son tratados a su vez como elementos, y se encargan de controlar el funcionamiento de sensores y actuadores y de darles el soporte necesario para que puedan operar en red.

Se define como sector a cualquier área en las que se divide la casa. Un sector puede

abarcar el espacio que el usuario quiera, de esta manera, un sector puede ser una habitación, un conjunto de habitaciones o incluso una determinada parte de una habitación. Todos los elementos deben estar ubicados en algún sector. Esta división en sectores es útil a la hora de localizar una incidencia detectada por algún elemento.

Se ha previsto montar todos estos elementos sobre una maqueta desmontable de madera

que tiene la siguiente distribución:


54

Fig. 3. 2 Distribución de la maqueta

Rodeando las paredes exteriores se encuentra todo el cableado y los circuitos de modo

que sólo los sensores y actuadores invaden el interior. Los nodos van sujetos a las paredes exteriores junto con las placas de adaptación de los sensores y actuadores. En la parte de suelo adyacente exterior a las habitaciones se coloca el cableado, compuesto por el bus CAN y las tres líneas de alimentación (+5V,+15V y GND). A lo largo de estos cables existe una serie de conexiones para derivar la alimentación y el bus CAN hacia cada uno de los nodos de la red.

3.2 ELEMENTO MAESTRO

El elemento maestro es el dispositivo encargado del control del sistema. Este elemento está constituido fundamentalmente por un DSP del tipo TMS320F2812 de Texas Instruments®. El elemento maestro lleva a cabo las siguientes tareas: - Almacenar y administrar la información general del sistema, como la distribución de

sensores y actuadores en los sectores o habitaciones, dirección IP, máscara de subred, contraseñas para el servidor, números de teléfono a los que enviar las alarmas, etc. Para ello dispone de una memoria EEPROM externa.

- Gestionar los números de identificación de los nodos y los elementos sensores y actuadores.

- Trasladar las órdenes del usuario a los elementos de la red para que actúen en consecuencia y recoger los datos solicitados por el usuario.

- Generar alarmas si se dan las condiciones para ello. En concreto, el elemento maestro debe guardar una lista de los elementos registrados en

el sistema, en la que figurará por cada elemento la siguiente información:


55

- Nodo al que pertenece - Número de elemento - Tipo de elemento - Sector donde se encuentra ubicado Aunque inicialmente se han colocado sensores y actuadores que producen un tipo de

información que no supone una carga computacional elevada para el DSP, en futuras ampliaciones del sistema podría ser necesario disponer de un elemento capaz de procesar señales con algoritmos complejos, tarea que podría ser asignada al DSP del elemento maestro.

3.2.1 EL DSP TMS320F2812

El DSP TMS320F2812 constituye el núcleo del elemento maestro. Se eligió un DSP por

ser un dispositivo con una potencia computacional alta y con mayores prestaciones que un microcontrolador convencional. Se seleccionaron DSPs que cumplieran las necesidades del sistema, entre las cuales figuraba la exigencia de que incorporaran un controlador CAN integrado. Finalmente la búsqueda se redujo a dos DSPs, el TMS320LF2407 y el TMS320F2812, siendo este último el DSP seleccionado debido a las mayores prestaciones que ofrecía frente al otro DSP sobre todo en lo relativo al controlador CAN.

A continuación se detallan algunas de las características más importantes del TMS320F2812 [9]:

- CPU de alto rendimiento de 32 bits. - Funcionamiento a 150MHz - Arquitectura de buses Harvard - Operaciones atómicas - Puerto JTAG - Mapa de memoria unificado - Código compatible con otras CPUs de Texas Instruments. - Memoria Flash de 128K x 16 - Memoria ROM OTP de 1K x 16 - Bloques de memoria RAM que suman 18K x 16 - Periféricos:

o 3 contadores de 32 bits o Módulo de protección de acceso a la memoria flash con clave o Watchdog o 2 Event managers para el control de motores o Interfaz serie síncrona SPI o 2 interfaces serie asíncronas SCI (UART) o Puerto serie multicanal con buffer McBSP o Controlador CAN o Convertidor analógico-digital de 12 bits y 16 canales con tasa de muestreo de

hasta 12.5 millones de muestras por segundo o Hasta 56 pines de entrada/salida de propósito general

Es conveniente destacar que el Departamento de Ingeniería Electrónica ya había adquirido

este DSP pero incorporado a la tarjeta eZdsp[10] para el F2812 de Spectrum Digital®. Esta tarjeta es un sistema de desarrollo para este DSP y se comunica con la aplicación Code Composer a través del puerto paralelo o del puerto JTAG, ambos incorporados en la placa. Muchos de los pines del DSP están mapeados en los distintos conectores repartidos por la


56

placa. La tarjeta eZdsp es autónoma y puede ser utilizada directamente sin más que proporcionarle alimentación y conectarla al PC por el puerto paralelo si se quiere programar. No es necesario poner las líneas de entrada no utilizadas a VCC o GND a través de pull-up o pull-down ya que la tarjeta se encarga de proteger sus líneas de entrada/salida.

Fig. 3. 3 Imagen de la placa eZdsp

3.2.2 PLACA BASE PARA LA TARJETA EZDSP

La placa base para la tarjeta eZdsp denominada “PAEM” es la encargada de dar soporte al

DSP y de adaptar e interconectar sus señales con el resto del sistema. La tarjeta eZdsp junto con la placa PAEM constituyen el hardware del elemento maestro.

Fig. 3. 4 Imagen de la placa PAEM

3.2.2.1 ALIMENTACIÓN La placa PAEM no suministra la alimentación a la tarjeta eZdsp, en su lugar se realiza a

través de un conector circular y un cable que conecta directamente la tarjeta eZdsp con la fuente


57

de alimentación del sistema, que ya de por sí proporciona los 5V que necesita la tarjeta para funcionar.

Fig. 3. 5 a) Alimentación de la tarjeta eZdsp; b) Circuito de alimentación a 3.3V de la placa PAEM Por otra parte la placa PAEM sí genera la alimentación para otros dispositivos, en concreto

para los dispositivos internos de la placa y para los circuitos de interfaz. Para ello dispone de un regulador de tensión ajustable del tipo LM317 de National Semiconductor ® que proporciona una tensión constante de 3.3V, que es la tensión a la que funcionan las líneas digitales de E/S del DSP. Con esta referencia de tensión se alimentan los circuitos que van conectados al DSP como la memoria EEPROM o el adaptador de niveles de tensión que une el DSP y el Rabbit. El potenciómetro que se observa en la figura 3.5b es utilizado para ajustar la tensión a 3.3V

3.2.2.2 TRANSCEIVER CAN El transceiver CAN sirve de adaptación entre el bus CAN y el controlador CAN integrado en el DSP. Del DSP parten dos líneas: CANTX y CANRX, que son de transmisión y recepción respectivamente, pero estas líneas no pueden ser conectadas directamente al bus puesto que como ya se explicó en el capítulo 2, las dos líneas del bus CAN no son ni de entrada ni de salida, sino que transmiten la información en el bus de forma diferencial, por esta razón es necesario utilizar un transceiver CAN que adapte las señales y separe los flujos de entrada y salida. El transceiver seleccionado fue el SN65HVD230 [11] de Texas Instruments ® debido a que funciona a 3.3V como las líneas de E/S del DSP y transmite al bus en modo diferencial. Una de las características de este transceiver es que puede desactivarse y pasar a un modo de bajo consumo (stand-by) si no va a ser utilizado. Para cambiar el modo se utiliza el jumper de la figura 3.6 de modo que si se unen los pines 1 y 2 con el jumper, el transceiver entra en modo “stand-by” mientras que si se unen los pines 2 y 3, el transceiver se activa. Finalmente, la placa PAEM se conecta al bus can mediante el conector que se indica en la figura 3.6.


58

Fig. 3. 6 Imagen del circuito de adaptación al bus CAN

3.2.2.3 MEMORIA EEPROM La placa PAEM dispone del circuito integrado 25AA640 [12] de Microchip ®, que es una

memoria EEPROM 8K x 8 bits. A esta memoria se accede a través de una interfaz serie síncrona SPI (serial peripheral interface). Como el DSP dispone de una interfaz de este tipo, la placa PAEM conecta el DSP y la memoria por este puerto, de modo que el DSP juega el papel de maestro y la memoria el de esclavo. Como ya se ha mencionado anteriormente, esta memoria es utilizada para almacenar información del sistema. Cabe pensar que sería más sencillo utilizar la propia memoria Flash del DSP para almacenar la información del sistema, pero lo cierto es que esa memoria flash es utilizada como memoria de programa y debido a la estructura interna del DSP, la CPU no permite acceder en escritura a dicha memoria flash si las instrucciones del programa se están recogiendo de esa memoria, es decir, no se pueden iniciar operaciones de escritura por el propio software si éste está almacenado en la memoria flash. Por esta razón se decidió que había que incluir una memoria externa. Se eligió la memoria EEPROM 25AA640 debido a su sencilla interfaz serie(no necesita ubicarse en el mapa de memoria) y a su tamaño, que resulta suficiente para almacenar la información del sistema.

3.2.2.4 CONECTOR DE ENCENDIDO DEL MÓDEM GSM A través del conector de la figura 3.7, el DSP gestiona las señales de encendido y

apagado del módem GSM. Estas señales van conectadas a la fuente de alimentación del sistema, que es la encargada de elevar el nivel de estas señales y enviarlas a los pines TO_IN y HR_IN del módem GSM. Por tanto el encendido y apagado del módem lo realiza el elemento maestro por software.

Fig. 3. 7 Imagen del conector de encendido/apagado del módem GSM


59

3.2.2.5 CONEXIÓN HACIA EL ELEMENTO DE COMUNICACIÓN CON EL EXTERIOR Como ya se dijo, el elemento maestro y el elemento de comunicación con el exterior se

comunican a través del puerto serie asíncrono. Las señales del puerto serie asíncrono del DSP están mapeadas en el conector de la figura 3.8. La descripción de cada una de las señales se muestra a continuación:

Señal Tipo Descripción DTX Salida Línea de transmisión serie del DSP. Se conecta a la línea RRX de la placa

“Madriguera” DRX Entrada Línea de recepción serie del DSP. Se conecta a la línea RTX de la placa

“Madriguera” E33 Salida Alimentación a 3.3V

Tabla 3. 1 Descripción de las señales de la conexión entre el DSP y el Rabbit.

Fig. 3. 8 Imagen del conector para la interfaz DSP-Rabbit

3.2.3 SISTEMA DE DESARROLLO PARA EL ELEMENTO MAESTRO El objetivo de este apartado no es describir a fondo el sistema de desarrollo, sino más bien

ofrecer una visión general del mismo destacando algunos aspectos interesantes del funcionamiento de dicho sistema.

El entorno de desarrollo utilizado es el Code Composer [13] de Texas Instruments®. Este programa tiene la particularidad de que necesita tener conectada la tarjeta eZdsp al PC por el puerto paralelo para arrancar. Es recomendable seguir estos pasos antes de utilizar el programa:

1) Conectar primero el puerto paralelo 2) Conectar la alimentación de la placa 3) Resetear el emulador mediante la aplicación SDConfig 4) Arrancar el Code Composer. Una vez arrancado, el entorno de desarrollo tiene el siguiente aspecto:


60

Fig. 3. 9 Imagen del entorno de desarrollo

En Code Composer los programas se estructuran en forma de proyectos que se

componen de una serie de ficheros clasificados según su función. Los tipos de ficheros que componen un proyecto se citan a continuación:

- Libraries (Bibliotecas). Son ficheros con extensión .lib que contienen información

sobre el DSP y son utilizados en la compilación. Estos ficheros vienen incluidos con el Code Composer.

- Include (Ficheros de cabecera). Son ficheros con la extensión .h que contienen algunas definiciones utilizadas por el código en C. Se incluyen automáticamente al proyecto durante la compilación a medida que el compilador encuentra referencias a los mismos en el código fuente.

- Linker Command Files (Ficheros de comando para el enlazador). Son ficheros con la extensión .cmd que contienen información acerca de las secciones de memoria. Sirven para ubicar las secciones de código y datos dentro del mapa de memoria del DSP. El enlazador los utiliza para generar el programa ejecutable.

- Source (Ficheros de código fuente). Son ficheros con la extensión .c ó .asm y contienen el código fuente del programa. Este código puede estar escrito tanto en lenguaje C como en ensamblador y puede estar repartido en varios archivos. La programación en lenguaje C permite construir programas una forma más sencilla que si trabajamos en ensamblador pero hay determinados algoritmos en los que es conveniente utilizar ensamblador debido a que se puede conseguir un código más optimizado y que por tanto se ejecuta más rápido.


61

Una vez que se ha creado un proyecto y se ha escrito el código fuente el programa se compila y se enlaza generándose un archivo ejecutable por el DSP. Si no hay errores en la fase de compilación podremos cargar dicho fichero en el DSP pulsando en File Load Program...

Hay que señalar que por defecto la tarjeta eZdsp viene configurada para arrancar desde la zona de memoria RAM denominada H0, que tiene una capacidad de 8K x 16 bits, por lo tanto el fichero .cmd debe especificar que el código vaya en esa zona. Esta configuración es adecuada cuando se está depurando un programa, pero por supuesto es posible cambiarla modificando la posición de ciertos jumpers de la tarjeta eZdsp. De esta manera se puede hacer, por ejemplo, que el DSP arranque desde la memoria Flash, opción recomendable cuando queremos cargar en el DSP una versión definitiva de un programa ya que además de esta manera el DSP no necesita estar conectado al entorno de desarrollo para que éste le transmita el programa cada vez que se resetea.

Una vez cargado el programa en el DSP se puede proceder a la ejecución y depuración

del mismo. Code Composer hace un seguimiento y controla la ejecución del programa en el DSP, de este modo permite el establecimiento de breakpoints en el código o la visualización e intervención en el contenido de cualquier registro o zona de memoria en tiempo de ejecución además de la posibilidad de detener y reanundar la ejecución en cualquier momento.

Los registros de los periféricos internos del DSP están ubicados en el mismo mapa de

memoria que los datos y el código y se puede acceder a ellos como a una posición de memoria más. Existen muchas formas de acceder a dichos registros ya sea utilizando C o ensamblador pero es recomendable seguir la estrategia usada en los ejemplos que Texas Instruments proporciona en su página web. Esta estrategia consiste básicamente en definir estructuras de datos del mismo tamaño que los registros de los periféricos y agruparlas por tipo de periférico en el mismo orden en el que aparecen en el mapa de memoria. Después se declaran estructuras de esos tipos y se asocian a determinadas secciones que se ubican precisamente en el mismo lugar donde están los registros del periférico mediante un fichero .cmd. De esta manera las variables declaradas se hacen coincidir con los registros de los periféricos y cuando accedemos a dichas variables estamos accediendo en realidad al periférico.

3.3 ELEMENTO DE COMUNICACIÓN CON EL EXTERIOR

Este elemento, como su propio nombre indica, concentra todas las tareas de comunicación

con el exterior del sistema, proporcionando acceso al mismo a través de varias vías. La primera y más importante forma de comunicación con el sistema es a través de un PC

conectado a Internet. Para hacer posible la comunicación, el elemento dispone de conexión a Internet a través de una red de área local de tipo Ethernet 10/100BaseT. El usuario puede controlar el sistema utilizando una aplicación cliente para PC que se comunica con el servidor implementado dentro del elemento.

La segunda forma de comunicación con el sistema es a través de un terminal móvil GPRS,

que deberá tener instalado previamente una aplicación cliente. Esta aplicación se conecta al mismo servidor que para el caso de un PC, la diferencia con la aplicación para PC radica en que la de terminales móviles no soporta toda la funcionalidad del protocolo externo y por tanto ofrece menores prestaciones, esto se debe a las limitaciones propias de los terminales móviles en cuanto a capacidad de proceso, presentación de la información, etc.


62

La tercera vía de comunicación no se utiliza para acceder al sistema sino más bien para canalizar los mensajes urgentes hacia el exterior. Esto se hace a través de un módem GSM/GPRS que está controlado por el elemento de comunicación con el exterior.

La estructura cliente - servidor que se ha seleccionado para el sistema puede describirse

como sigue: El sistema está pensado de manera que en el elemento de comunicación con el exterior haya un único servidor implementado que atienda las peticiones del usuario a través de un puerto específico (puerto 5001). Para poder acceder al servidor, el usuario debe disponer de la aplicación cliente, que previamente habrá instalado en el PC, y de los ficheros de manejo para cada elemento, así mismo, la aplicación puede generar archivos de configuración tales como la lista que relaciona cada elemento con su fichero de manejo asociado. Existen muchas aplicaciones en red que necesitan ser instaladas en un ordenador para funcionar, esto tiene sus ventajas y sus inconvenientes. Entre las ventajas de esta opción están la simplicidad en el diseño y la posibilidad de desarrollar protocolos específicos que aumentan las posibilidades de explotación del sistema. El principal inconveniente es que para acceder al sistema desde cualquier ordenador conectado a Internet habría que instalar previamente el programa y los ficheros de manejo, y además el usuario debería llevar esos archivos en algún soporte.

Otra de las opciones que se barajó fue la de implementar en el elemento de comunicación

con el exterior un servidor web y acceder al sistema en forma de página web. Aunque es posible implementar un servidor de ese tipo en el elemento, las posibilidades de acceso al sistema están más limitadas debido a que tanto HTML como otros formatos de archivo de páginas web no permiten la flexibilidad de un protocolo específico y acabarían complicando demasiado el diseño. Por otra parte esta opción demandaría demasiados recursos de memoria al módulo RCM2200 y con toda seguridad habría que añadir chips de memoria al módulo. A pesar de la comodidad para el usuario ya que no tiene que instalar ningún programa ni llevar ningún archivo, las desventajas son evidentes y por esta razón esta opción fue descartada.

Una variante de la opción anterior consistiría en servir una página web con un applet Java

que hiciera de aplicación cliente. En este caso se podría utilizar un protocolo específico pero el elemento de comunicación tendría que implementar ahora dos servidores, uno web y otro específico, lo que resultaría en un diseño más complicado y que seguiría teniendo el problema de la falta de memoria. Esto es así porque a pesar de que el módulo RCM2200 posee memoria flash para programas, el propio software almacenado en esa memoria no puede acceder en escritura al bloque de memoria y se necesitaría un bloque de memoria flash adicional que aumentaría la capacidad hasta los 512 KBytes. Por todo ello esta opción también fue descartada.

Actualmente se está estudiando la opción de mantener en el elemento de comunicación

únicamente el servidor específico, tal y como se describe en la opción seleccionada, pero alojando en un servidor web convencional de Internet los ficheros de manejo y la aplicación en forma de Applet Java. Esto tendría como consecuencia que el usuario no tiene que llevar los ficheros en ningún soporte y no tiene que instalar ningún programa. De cara al diseño, sigue manteniendo la simplicidad y flexibilidad de la opción seleccionada. Tal vez el único problema aparecería a la hora de guardar información de configuración para la aplicación, habría que ver si es posible que el applet pudiera modificar ficheros alojados en el servidor web convencional o si es posible guardar dicha información en la memoria EEPROM externa del elemento maestro junto con la información del sistema siempre y cuando la cantidad de memoria demandada se ajuste a la cantidad disponible.


63

Hay que recordar que las aplicaciones cliente están fuera del alcance de este proyecto, y que los problemas derivados de la estructura cliente – servidor surgen principalmente en esta parte. Aún así se ha creído conveniente mencionar aquí el problema y la solución adoptada en tanto en cuanto la elección afectaba en parte a la aplicación servidora, que sí entra dentro del alcance del proyecto.

3.3.1 EL MÓDULO RCM2200

El módulo RCM2200 de Rabbit Semiconductors ® constituye el núcleo del elemento de

comunicación con el exterior. Se trata de un sistema de microprocesador basado en el Rabbit 2000 ® con funcionalidad añadida para su interconexión a una red Ethernet del tipo 10BaseT.

A continuación se citan las principales características del módulo RCM2200 [14]: - Microprocesador Rabbit 2000 a 22.1MHz - 26 líneas digitales de entrada/salida: 16 configurables como entrada o salida, 7

entradas fijas, 3 salidas fijas - Bus de datos de 8 bits - Bus de direcciones de 20 bits, de los cuales sólo 4 son accesibles (A0 – A3) - Registros de control de periféricos fuera del mapa de memoria. - Cinco contadores de 8 bits y dos de 10 bits - Alimentación a 5V - Memoria Flash de 256K x 8 - Memoria SRAM de 128K x 8 - Interfaz Ethernet 10BaseT con conector RJ-45 - Cuatro puertos serie. Todos pueden funcionar en modo asíncrono y dos de ellos

pueden hacerlo además en modo síncrono alcanzando velocidades de hasta 691Kbps en modo asíncrono y 5,5Mbps en modo síncrono.

- Watchdog - Reloj adicional para fecha y hora. El hecho de que este módulo incorpora la interfaz Ethernet fue decisivo a la hora de

seleccionar este módulo. Otra de las razones para su elección fue que disponía de suficientes puertos serie para conectar el módulo a otros elementos del sistema. La cantidad de memoria flash es suficiente para albergar el programa y dispone a su vez de suficiente memoria RAM. Además posee bastantes entradas/salidas de propósito general. El Departamento de Ingeniería Electrónica ya disponía de dos módulos Rabbit en el momento de la elección el RCM2200 y otro módulo basado en el Rabbit 3000. A pesar de que el Rabbit 3000 tiene algunas prestaciones más que el Rabbit 2000, el RCM2200 ya reúne todos los requisitos necesarios para el sistema y además el módulo que acompaña al Rabbit 3000 no dispone de interfaz Ethernet.


64

Fig. 3. 10 Imagen del módulo RCM2200

3.3.2 PLACA BASE PARA EL RCM2200

Desafortunadamente ninguno de los módulos Rabbit es autónomo y necesita ser

alimentado a través de unas tiras de pines donde además están mapeadas algunas de las señales de entrada y salida del procesador. Rabbit Semiconductors comercializa una placa denominada “Prototyping board" sobre la que se inserta el módulo Rabbit. Esta placa se conecta también al PC para poder utilizar el entorno de desarrollo. Aparte de encarecer el coste total del proyecto, esta placa resulta poco específica para nuestras necesidades, razón por la que se decidió construir una placa base propia adecuada a las necesidades del sistema. Como resultado se creó la placa base para el RCM2200 denominada “Madriguera”.

Aunque esta placa fue diseñada para su uso dentro del sistema domótico, se le añadieron dispositivos de propósito general como LEDs y botones de manera que la placa también puede ser usada independientemente como sistema de desarrollo para el RCM2200 facilitando el desarrollo de nuevas aplicaciones basadas en este módulo.

A continuación se muestra un diagrama funcional de la placa base “Madriguera”:

Fig. 3. 11 Diagrama funcional de la placa base para el RCM2200 “Madriguera”


65

Como se aprecia en la figura anterior, la placa base proporciona las conexiones entre el RCM2200 con el módem GSM, el DSP y el PC. La conexión con el PC sólo se utiliza para programar el Rabbit usando el entorno de desarrollo y no es necesario mantener esta conexión durante el funcionamiento normal del sistema domótico.

De forma adicional se han añadido a la placa un conjunto de LEDs y botones para facilitar la depuración de los programas y poder disponer de una interfaz manual con el usuario.

Fig. 3. 12 Imagen de la placa base “Madriguera” con el módulo RCM2200 insertado

3.3.2.1 ALIMENTACIÓN La placa se alimenta en el rango de tensiones que va de 10V a 15V. Dos reguladores de

tensión se encargan de proporcionar la tensión necesaria a los elementos de la placa. Estos reguladores proporcionan dos líneas de alimentación, una a 5V y otra a 10V. A pesar de que casi todos los elementos se alimentan a 5V incluido el módulo RCM2200, hubo que proveer a la placa de alimentación adicional a 10V para poder operar con el MAX239 de Maxim®, que es el transceiver encargado de adaptar las tensiones a las especificadas en la norma RS-232 para las 9 líneas.

La alimentación se efectúa a través del conector que se muestra en la figura 3.13.


66

Fig. 3. 13 Toma de alimentación e interruptor general

3.3.2.2 CONEXIÓN SERIE AL DSP El Rabbit 2000 utiliza el puerto serie D en modo asíncrono para comunicarse con el DSP.

Se decidió conectarlos así puesto que el DSP posee dos puertos serie asíncronos y que este tipo de puertos proporciona una interfaz sencilla en full-dúplex más adecuada cuando se comunican elementos de la misma jerarquía, en contraposición con los puertos serie síncronos, que se utilizan mayormente en arquitecturas maestro-esclavo. Debido a la diferencia de tensión de trabajo entre el DSP (3.3V) y el Rabbit (5V) es necesario intercalar un adaptador para poder interconectarlos. El circuito integrado que cumple esta misión es el SN74LVC2T45 de Texas Instruments®, que es capaz de soportar señales digitales de hasta 420 Mbps, muy por encima de las necesidades del sistema. La conexión física se hace a través de los conectores que se muestran en la siguiente figura:

Fig. 3. 14 Conexión serie al DSP

Señal Tipo Descripción RTX Salida Línea de transmisión serie del Rabbit RRX Entrada Línea de recepción serie del Rabbit E33 Entrada Alimentación a 3.3V

Tabla 3. 2 Descripción de las señales de la conexión entre el Rabbit y el DSP

3.3.2.3 PUERTO SERIE La placa dispone de un puerto serie que implementa una interfaz RS-232, por tanto

dispone de las 9 señales que especifica la norma. Utiliza un conector DB-9 hembra y está cableado como un DTE, es decir, como un equipo terminal de datos. A continuación se detalla la correspondencia entre las señales del Rabbit2000 y las de la interfaz RS-232:

Señal RS-232 Pin del Rabbit Tipo Pin DB-9 DCD PD5 Entrada 1 RD PC3 (Puerto serie C) Entrada 2 TD PC2 (Puerto serie C) Salida 3


67

DTR PE0 Salida 4 GND - - 5 DSR PD4 Entrada 6 RTS PE1 Salida 7 CTS PD3 Entrada 8 RI PE4 Entrada 9

Tabla 3. 3 Correspondencia de las señales de la interfaz RS-232 A efectos de programación hay que decir que las líneas de transmisión y recepción están

controladas por el puerto serie C del Rabbit. En cuanto a las líneas de control hay que tener especial cuidado puesto que lo que hay que manejar son realmente las propias señales negadas, esto es así porque los transceivers para RS-232, como el MAX239 que lleva la placa, son inversores por motivos técnicos, así pues debemos trabajar con las señales negadas para que a la salida del conector DB-9 tengamos las señales correctas. Este puerto serie es utilizado en el sistema para la conexión entre el elemento de comunicación con el exterior y el módem GSM/GPRS.

3.3.2.4 CONECTORES PROG Y DIAG Los conectores PROG y DIAG junto con el conector PROG del Rabbit se utilizan para

programar y depurar los programas creados con el entorno de desarrollo. Junto con la placa base “Madriguera” se proporciona un cable especial para unir estos conectores.

Para programar el Rabbit y hacer un seguimiento de la ejecución del programa hay que

unir con el cable especial el conector PROG con el conector PROG del Rabbit poniendo especial cuidado de que el cable rojo quede en el extremo más cercano a la flecha pintada sobre la placa en el caso del conector PROG y que el cable rojo quede en la esquina del módulo RCM2200 para el caso del conector PROG del Rabbit. Cuando el cable está conectado en esta posición, el Rabbit queda controlado por el sistema de desarrollo.

Si unimos con el cable especial el conector PROG del Rabbit y el conector DIAG,

podemos utilizar el puerto serie A del Rabbit como un puerto serie de propósito general y conectarlo a un PC a través del cable de programación DB9 – DB9 que se proporciona con la placa, pero en vez de ser controlado por el entorno de desarrollo, ahora podría ser controlado con cualquier aplicación que maneje el puerto serie del PC. De nuevo hay que tener la precaución de conectar el cable rojo en el extremo del conector DIAG más cercano a la flecha pintada sobre la placa.

Una vez cargado el programa en el Rabbit y si no va a ser utilizado el puerto serie A del

Rabbit a través del conector DIAG, el cable especial puede ser retirado. En este caso tras encender la placa o tras un reset, el Rabbit ejecuta el programa que esté almacenado en su memoria Flash.


68

Fig. 3. 15 (a) Conectores de programación/diagnóstico; (b) Cable de programación 3.3.2.5 EL PUERTO DE PROGRAMACIÓN Este puerto es utilizado para conectar la placa base “Madriguera” con un PC. Se trata de

un puerto serie con conector DB-9 hembra cableado como un DCE, es decir como equipo de datos.

El puerto de programación, junto con los conectores DIAG y PROG, es utilizado para programar el Rabbit y para seguir la ejecución de los programas mediante el entorno de desarrollo para el Rabbit. Tal y como ya se apuntó en el apartado anterior, este cable puede servir para comunicar una aplicación distinta del entorno de desarrollo con el Rabbit siempre y cuando el cable especial se coloque en la posición adecuada.

3.3.2.6 INTERRUPTORES Los interruptores que aparecen el la figura 3.16 controlan los niveles de tensión en las

líneas SMODE0 y SMODE1 del conector PROG del Rabbit. La misión de estas líneas es indicar al procesador el modo de arranque tras un reset. Aunque los interruptores permiten asignar cualquiera de las cuatro combinaciones posibles, sólo nos centraremos en dos:

SMODE0 SMODE1 Modo de arranque 0 0 Normal. El Rabbit ejecuta el programa cargado en la memoria Flash 0 1 - 1 0 - 1 1 Cold boot. Carga y ejecuta el programa transferido desde el entorno de

desarrollo. La ejecución del programa es controlable desde el PC Tabla 3. 4 Modos de arranque del Rabbit

A continuación se muestra la situación en la placa de los distintos interruptores y se detalla

la función de cada interruptor y su relación con las líneas SMODE0 y SMODE1:

Fig. 3. 16 Situación de los interruptores en la placa


69

Interruptor Número Función SM0_ON 3 Cuando se activa, SMODE0=1 SM0_OFF 4 Cuando se activa, SMODE0=0 SM1_ON 1 Cuando se activa, SMODE1=1 SM1_OFF 2 Cuando se activa, SMODE1=0

Tabla 3. 5 Función de los interruptores Es recomendable que la manipulación de los interruptores se realice con la alimentación

desconectada y que nunca estén activados a la vez SM0_ON y SM0_OFF o SM1_ON y SM1_OFF ya que se provocaría un cortocircuito con daños irreversibles para la placa.

Por defecto los interruptores activados son SM0_ON y SM1_ON para permitir la

programación del Rabbit. Si queremos pasar al modo de arranque normal es preferible retirar el cable especial antes que reconfigurar los interruptores, ya que desconectando el cable especial, el Rabbit entenderá que las señales SMODE0 y SMODE1 están a 0, activando por consiguiente el modo de arranque normal.

3.3.2.7 LEDS La placa dispone de 8 LEDs rojos de propósito general activos a nivel bajo controlables

desde las líneas PA0 – PA7 del Rabbit de manera que la línea PA0 controla el LED 0, la línea PA1 controla el LED 1, y así sucesivamente hasta el LED 7. Las líneas del Rabbit se conectan a los LEDs a través de resistencias de 1200Ω, que regulan la intensidad que recorre dichos diodos ajustándose a las especificaciones de corriente para los pines del Rabbit. La intensidad por cada LED está en torno a los 3mA, valor suficiente como para encender el LED y asumible por el Rabbit.

La posición de los LEDs en la placa es la que se muestra en la figura:

Fig. 3. 17 Posición de los LEDs en la placa

3.3.2.8 BOTONES Existen 4 botones de propósito general con filtro paso baja incluido para eliminar rebotes

en la medida de lo posible. El circuito de los botones junto con los pull-up sobre los pines PB2 a PB5 que ya están presentes en el módulo RCM2200 conforman el siguiente esquema:

Fig. 3. 18 Esquema del circuito de los botones con el pull up


70

Analizando este circuito se llega a la conclusión de que la frecuencia de corte es la

siguiente:

Evaluando el comportamiento transitorio para diferentes valores de C y R1 se escogió un

valor de compromiso que eliminaba los rebotes pero que no alargaba excesivamente las transiciones. Estos valores son 470Ω para R1 y 1µF para C, resultando en una frecuencia de corte de 342Hz. A continuación se muestra la respuesta al escalón de este circuito:

Fig. 3. 19 Comportamiento del circuito ante un escalón (pulsación del botón)

Los botones son activos a nivel bajo y sus señales son recogidas en los siguientes pines

del Rabbit:

Botón Pin del Rabbit 1 PB5 2 PB4 3 PB3 4 PB2

Tabla 3. 6 Correspondencia entre botones y pines del rabbit En la siguiente figura se muestra la situación de los botones en la placa:

fR R

R R CPP

P

=+ 1

12π


71

Fig. 3. 20 Situación de los botones en la placa

3.3.3 SISTEMA DE DESARROLLO PARA EL RCM2200 El entorno de desarrollo empleado para programar el Rabbit es el Dynamic C de Zworld

Inc. ®. Como su propio nombre indica, es un entorno basado en el lenguaje C con algunas modificaciones y la posibilidad de incluir código en ensamblador para procesadores Rabbit.

Fig. 3. 21 Vista del entorno de desarrollo Dynamic C

Es muy importante configurar algunos aspectos antes de empezar a usar Dynamic C [15].

Es necesario escoger el módulo que vamos a programar, que en este caso sería el RCM2200, El puerto serie del PC que se va a utilizar y la velocidad de transmisión. Todas estas opciones de configuración se pueden encontrar en: Options Project Options


72

Fig. 3. 22 Vista de la ventana de configuración Project Options

Como ya se ha dicho, el lenguaje de programación que se utiliza en Dynamic C es una variante del lenguaje C estándar. Entre las características nuevas que añade Dynamic C hay que destacar la multitarea cooperativa, que permite un mejor aprovechamiento del tiempo a la hora de realizar múltiples tareas gracias a un tipo especial de sentencias denominadas costatements. El hecho de trabajar con un lenguaje de alto nivel como el C implica también que debe haber un conjunto subyacente de funciones de bajo nivel que den soporte al programa. Por este motivo, Dynamic C incorpora al programa una BIOS durante la compilación. Esta BIOS no sólo da soporte al programa, sino que también establece comunicación con el entorno de desarrollo para poder depurar el programa, seguir la ejecución del mismo y permitir la intervención del usuario. Gracias a esta BIOS, el entorno de desarrollo permite colocar breakpoints y monitorizar los valores de las variables del programa. Es recomendable poner especial cuidado a la hora de programar los puertos series del Rabbit ya que podría haber un conflicto con la BIOS. El motivo es que la BIOS utiliza el puerto serie A del Rabbit para comunicarse con el entorno de desarrollo, por tanto si se cambia la configuración general de los puertos series o se intenta utilizar dicho puerto, la comunicación con el entorno de desarrollo se verá interrumpida y se perderá el control sobre la ejecución del programa, lo cual no quiere decir que no se pueda utilizar el puerto serie A, sino que no es recomendable cuando estamos usando el entorno de desarrollo.

Por último reseñar que existen varias opciones a la hora de compilar de las cuales nos

centraremos en dos: - Compilar y ejecutar en memoria RAM. Carga el programa compilado en la memoria

RAM del Rabbit. Esta opción es recomendable cuando se trata de probar un programa.

- Compilar y ejecutar en memoria Flash. Carga el programa compilado en la memoria Flash del Rabbit. Esta opción es recomendable cuando queremos almacenar una versión definitiva del programa. La fase de carga del programa en el microprocesador es más lenta pero el programa queda grabado en memoria no volátil y es ejecutado automáticamente tras un reset o tras conectar la alimentación sin necesidad de que el procesador esté conectado al entorno de desarrollo.


73

3.4 SENSORES Y ACTUADORES

En este apartado se describirán los circuitos que implementan los nodos y los elementos

sensores y actuadores. Hasta el momento, el prototipo del sistema sólo incorpora sensores y actuadores sencillos, aunque podrían instalarse elementos más complejos en un futuro.

3.4.1 NODOS DE LA RED CAN

Según se desprende del esquema del sistema, los elementos sensores y actuadores se

agrupan por nodos. En cada uno de los nodos puede haber uno o varios elementos y cada uno de estos elementos puede ser de distinto tipo. Los elementos pertenecientes a un nodo no tienen por qué estar ubicados todos en el mismo sector de la casa. Los nodos proporcionan un soporte para digitalizar y dar formato a los datos obtenidos de los sensores y para controlar los actuadores, por tanto, todo el software asociado a los elementos reside en los nodos. Por otra parte, los nodos también implementan sus funciones propias y proporcionan acceso a la red CAN.

La estrategia que se ha seguido para implementar los nodos y sus elementos es la de

crear nodos en forma de placas independientes genéricas a las cuales se les pueden acoplar, por medio de conectores, otras placas de adaptación de señal que contengan los sensores y actuadores. Debido a que la mayoría de los elementos necesitan pocas líneas de control para funcionar, esta estrategia de placas genéricas proporciona una mayor versatilidad y simplicidad al sistema puesto que un nodo puede albergar distintos tipos de elementos y puede reconfigurarse cada vez que se desee para introducir otros elementos, con el consiguiente ahorro en placas.

Fig. 3. 23 Nodo genérico

La implementación de los nodos se ha llevado a cabo mediante microcontroladores. Un

nodo necesita estar dotado de las siguientes características para poder operar: - Líneas analógicas disponibles - Líneas digitales disponibles - Controlador y transceiver CAN - Convertidor analógico - digital


74

- Microcontrolador reprogramable - En algunos casos, interfaces serie específicas (SPI, I2C, Interfaz serie asíncrona, etc.) De acuerdo con estas características, el esquema funcional de un nodo sería así:

Fig. 3. 24 Esquema funcional de un nodo

3.4.1.1 ENTRADAS ANALÓGICAS Se pueden utilizar hasta un máximo de 5 entradas analógicas cuyo rango de entrada está

entre 0 y 5V, tomando como referencia la señal GND del sistema, aunque también es posible configurar algunas de las entradas analógicas como referencias positiva y negativa y poder así convertir señales que no tengan como referencia la tierra del sistema. Para más información sobre las características de conversión analógica – digital consultar el datasheet del PIC18F248 [16].

Cada una de las entradas analógicas AN0, AN1, AN2, AN3 y AN4 están mapeadas en los

conectores C7, C8, C9, C10 y C11, respectivamente. Estos conectores tienen 3 pines en los que se ofrecen las señales GND y VCC5 junto con la correspondiente entrada analógica, de esta manera, el nodo puede suministrar la alimentación a la placa de acondicionamiento de señal del sensor o actuador en cuestión. La situación de estos pines se muestra en la siguiente figura:


75

Fig. 3. 25 Conectores analógicos

Señal Pin asociado en el PIC Descripción GND - Tierra del sistema Ax ANx Entrada analógica VCC5 - Línea de alimentación a 5V en continua

Tabla 3. 7 Descripción de las señales del bloque analógico 3.4.1.2 ENTRADAS Y SALIDAS DIGITALES Hay 14 entradas/salidas digitales disponibles en cada nodo repartidas en varios

conectores (C1, C2, C3 y C5). Cada una de ellas se puede configurar como entrada o salida dependiendo del valor de los registros internos del PIC. Todas las entradas/salidas digitales trabajan en el rango de 0 a 5V y dependiendo de la señal en cuestión la entrada y la salida serán TTL, ST (Schmitt Trigger con niveles CMOS) o CMOS. Para más información consultar el datasheet del PIC18F248.

Algunos de estos pines tienen además funciones adicionales, como por ejemplo los pines

D4 y D5, que pueden configurarse como un canal serie asíncrono, o los pines D6, D7 y D8, que pueden configurarse como canal serie síncrono.

Además, todas las líneas digitales disponen de una resistencia configurable para ejercer

funciones de pull-up/pull-down cuando funcionan como entradas pudiéndose conectar o desconectar dicha resistencia de la línea digital mediante un jumper. Hay que reseñar que la característica como pull-up o pull-down de estas resistencias es configurable por bloques, esto es, para cada conector hay un jumper asociado que hace que todas las resistencias vinculadas a las líneas de dicho conector funcionen como pull-up o pull-down según la posición de un determinado jumper. Estos jumpers se colocan sobre grupos de 3 pines donde el pin central está conectado a las resistencias y los otros dos pines están conectados a VCC5 y a GND. Según se conecte el pin central con el de su derecha o el de su izquierda, las resistencias funcionarán como pull-up o pull-down. La disposición de estos pines se muestra en la figura 3.27.


76

Fig. 3. 26 Conectores digitales

Señal Pin asociado del PIC Función Jumper Conector D1 RC0 E/S digital JP1 C1 D2 RC1 E/S digital JP2 C1 D3 RC2 E/S digital JP3 C1 D4 RC7 E/S digital, RX canal serie asíncrono JP20 C2 D5 RC6 E/S digital, TX canal serie asíncrono JP19 C2 D6 RC5 E/S digital, salida de datos síncrona JP18 C3 D7 RC4 E/S digital, entrada de datos síncrona JP17 C3 D8 RC3 E/S digital, reloj para datos síncronos JP16 C3 D9 RB0 E/S digital JP9 C5 D10 RB1 E/S digital JP8 C5 D11 RB4 E/S digital JP7 C5 D12 RB5 E/S digital JP6 C5 D13 RB6 E/S digital JP5 C5 D14 RB7 E/S digital JP4 C5

Tabla 3. 8 Descripción de las señales del bloque digital


77

Fig. 3. 27 Pines de selección de pull-up/pull-down para bloques de resistencias

Jumper de selección Conector al que afecta JP21 C1 JP23 C2 JP22 C3 JP24 C5

Tabla 3. 9 Relación entre los jumpers de selección y los conectores a los que afectan

3.4.1.3 PROGRAMACIÓN El conector de programación se utiliza para cargar el programa en el PIC. Existe un cable

que conecta la programadora JDM con el nodo a través de este conector. Es muy importante tener en cuenta las siguientes recomendaciones antes de cargar un programa:

1) Desconectar el nodo de la alimentación 2) Retirar los jumpers JP10, JP11, JP12, JP13, JP14 y JP15 3) Conectar el cable de programación al conector C6 y a la programadora JDM 4) Programar el PIC 5) Desconectar el cable de programación 6) Volver a colocar los jumpers que fueron retirados previamente.


78

Fig. 3. 28 Conector de programación y jumpers asociados

Pin Señal 1 VSS 2 VPP 3 SDATA 4 SCLK 5 PGM 6 VDD

Tabla 3. 10 Descripción de pines del conector de programación (C6)

3.4.1.4 INTERFAZ CAN Para poder conectarse a la red interna, el nodo posee un transceiver CAN del tipo

MCP2551 [17] de Microchip ®. Este transceiver adapta las señales CANRX y CANTX del PIC a los niveles de tensión y la forma de transmitir propios del nivel físico de CAN. Este transceiver se puede desactivar por medio de un jumper, JP25. Si este jumper une el pin central con el de arriba (VCC5), el transceiver pasa a modo stand-by, mientras que si el jumper une el pin central con el de abajo (GND), el transceiver se activa y permite intervenir en el bus CAN.

Fig. 3. 29 Interfaz CAN


79

El conector C4 es el que se usa para conectar el nodo directamente al bus CAN. Este conector dispone de dos líneas, CANH y CANL, y es muy importante conectarlas correctamente al bus CAN.

3.4.1.5 ALIMENTACIÓN Y OTROS SUBCIRCUITOS La alimentación se proporciona a través de la borna que se muestra en la figura 3.30. Esta

borna tiene dos conexiones, la primera es para el raíl de alimentación a 5V (VCC5) y la segunda es para la referencia de tensión (GND).

La placa también dispone de un botón de reset y un led rojo conectado a la línea RA4 del

PIC. Hay que señalar que dada la configuración del circuito, el LED es activo a nivel bajo, esto es así porque el pin RA4 cuando se configura como salida, opera en modo OD (a drenador abierto), y sólo es capaz de imponer ceros lógicos, dejando el pin en alta impedancia cuando se impone un uno lógico a la salida.

Como último detalle, citar que los nodos están equipados con cristales de cuarzo que

generan una señal de reloj de 20 MHz.

Fig. 3. 30 Subsistemas de alimentación, reset y señalización por LED

3.4.2 EL PIC18F248 Para la implementación de los nodos se requería un microprocesador que tuviera un

controlador CAN integrado, convertidores analógico – digitales y líneas digitales de entrada/salida disponibles. Basándose en estas especificaciones, se buscó un microcontrolador adecuado entre los que ofrece el mercado. La familia PIC18FXX8 de Microchip tiene integrado un controlador CAN, y también disponen de otras interfaces de comunicación y líneas analógicas. Dentro de los dispositivos que componen la familia se escogió el PIC18F248 porque reunía todos los requerimientos para el proyecto y a la vez era el más compacto y barato de todos ellos.

El microcontrolador PIC18F248 tiene las siguientes características [16]: - Frecuencia de reloj: hasta 40 MHz - Frecuencia de trabajo: hasta 10 MIPS - Instrucciones de 16 bits - Bus de datos de 8 bits - Memoria Flash de programa de 16Kbytes


80

- Memoria RAM de datos de 768 bytes - Memoria EEPROM de datos de 256 bytes - 22 líneas de E/S digital - Hasta 5 canales analógicos para conversión a digital - Módulo SPI - Módulo I2C - USART - 3 contadores - Módulo CAN compatible con CAN spec. 2.0 B Active. 3 buzones para transmisión y 2

para recepción con 6 filtros. - ICSP (In circuit serial programming) - Formato: SPDIP – 28 pines.

3.4.3 SISTEMA DE DESARROLLO PARA EL PIC18F248

Microchip proporciona un entorno de desarrollo para sus microcontroladores llamado MPLAB ®. Este entorno de desarrollo permite crear programas para la gran mayoría de los microcontroladores PIC.

Como en otros muchos entornos de desarrollo, los programas se organizan en proyectos,

en los que se incluyen todos los ficheros de código y liberías necesarios. Incluye un editor adaptado para poder escribir el código de una manera cómoda.

Fig. 3. 31 Flujo de diseño de programas para el PIC18F248

En el caso del PIC18F248, la programación se realiza en ensamblador, por lo tanto, el código se almacena en archivos “.asm”. Se pueden usar ficheros “.inc” y “.h” para las declaraciones, de la misma manera que se usan los ficheros “.h” en un programa en lenguaje C. El entorno de desarrollo dispone del correspondiente compilador y linker para generar un archivo ejecutable “.hex”. El entorno permite definir una serie de opciones utilizadas durante la compilación, como por ejemplo, el modelo de microprocesador, los bits de configuración del dispositivo, etc. Una vez compilado el código, se puede simular seleccionando en el menú: Debugger Select Tool MPLAB SIM. El entorno de simulación es bastante intuitivo y sencillo de manejar. Como otros tantos simuladores, MPLAB SIM permite observar el valor de los registros durante la simulación y modificar sus valores. Es posible simular señales de entrada en los pines del PIC aunque es complicado y no se puede hacer de forma interactiva, sino a través de ficheros.

Una vez que el programa ha sido compilado y se ha generado el archivo ejecutable “.hex”

se puede proceder a cargar el programa. Existen varias herramientas hardware para ello, por un lado las que ofrece Microchip, como la PICSTART Plus, que permite programar una amplia variedad de microcontroladores PIC y que utiliza como software el propio MPLAB, y por otro lado tenemos soluciones más sencillas y baratas que se pueden encontrar en Internet, como es el caso de las programadoras JDM, muy baratas y fáciles de construir. Para utilizar una


81

programadora JDM se puede utilizar como software el programa IC-PROG, que puede descargarse de Internet de forma gratuita. 3.4.4 ELEMENTOS INSTALADOS

Los elementos que se van a instalar en el sistema son bastante sencillos, aunque se

podrían incluir sensores y actuadores más complejos en el futuro. Por el momento, los elementos que integrarán el sistema son:

Actuadores Sensores Controlador de luz Sensor de temperatura basado en termopar Ventilador Detector de movimiento por ultrasonidos Sensor de luminosidad Interruptor manual

Tabla 3. 11 Lista de actuadores y sensores del prototipo

La información referente a los comandos y parámetros disponibles para cada tipo de elemento puede consultarse en el anexo A.1. En los siguientes subapartados se describirá el hardware y la funcionalidad de cada elemento.

3.4.4.1 SENSORES DE TEMPERATURA Para elaborar los sensores de temperatura se han planteado varias opciones: - Usar termopares de tipo K [18]. - Usar sensores de temperatura integrados con salida digital. - Usar sensores de temperatura integrados con salida analógica. De estas tres opciones, se ha escogido la primera por ser más interesante aunque es la

más complicada, ya que hay que diseñar un circuito de adaptación de señal. Un termopar es básicamente una unión de dos metales o aleaciones distintas que por

efecto del calor genera una diferencia de potencial de contacto debido a la diferencia entre los niveles de Fermi en ambos metales. Esta diferencia de potencial es muy pequeña, del orden de milivoltios, y varía muy poco con aumentos significativos de temperatura aunque lo hace de una forma bastante lineal con la temperatura dentro de un amplio rango, lo que los hace bastante fiables. Los termopares responden muy rápidamente a los cambios de temperatura y su pequeño tamaño permite su instalación en muchos lugares.

El hecho de que la señal que generan los termopares sea muy débil, hace necesaria la

amplificación y adecuación de la señal. Por este motivo se propone el circuito de la figura 3.32, que es muy parecido al que se diseñó para la placa PICMEO 2 aunque ha sido modificado y mejorado. El circuito propuesto es el siguiente:


82

12

3A

123

A

Fig. 3. 32 Esquemático del circuito de adaptación del termopar

Analizando este circuito se desprende la siguiente ecuación:

Donde Vout es la tensión de salida, Vtp es la diferencia de potencial en el termopar y Vref

equivale a la siguiente expresión:

Se observa pues un comportamiento lineal si no tenemos en cuenta los efectos de

segundo orden en el circuito. A continuación se muestran los resultados experimentales del circuito. En el eje de ordenadas se muestra la tensión y en el eje de abcisas la temperatura.

Fig. 3. 33 Resultados experimentales del circuito de adaptación del termopar

Vout Vref VtpRR

= + +⎛⎝⎜

⎞⎠⎟1

21

VrefVCC R

R R=

⋅+5 4

3 4


83

Estos resultados experimentales se obtuvieron bajo las siguientes condiciones: R1=18Ω, R2=22000Ω, Vref=2.62V, VCC5=5V.

De estos resultados se extrae que la resolución analógica es de 21.42 mV/ºC. Por tanto,

teniendo en cuenta que la resolución que ofrece el convertidor analógico – digital del PIC es de 10 bits, la resolución digital es de 4.38 niveles/ºC.

Los sensores de temperatura han sido dotados a nivel funcional (por software) con varios

mecanismos, de modo que les permite: - Comportarse como termostatos ajustables. - Monitorizar la temperatura enviando muestras con una frecuencia configurable. - Ser calibrados en pleno funcionamiento. - Avisar si la temperatura es excesivamente alta en previsión de un posible incendio. 3.4.4.2 SENSORES DE LUMINOSIDAD Los sensores de luminosidad son bastante sencillos y se basan en fotorresistencias

NORPS12. Como se observa en la figura 3.34, el circuito no es más que un divisor de tensión.

Fig. 3. 34 Circuito de adaptación de la fotorresistencia

La fotorresistencia baja su impedancia a medida que aumenta la luminosidad llegando a

valores cercanos a los 400Ω a 1000 lux y a valores de 1MΩ en la oscuridad. Del circuito anterior se desprende la siguiente ecuación:

En el caso del prototipo que se pretende construir, no es importante el valor exacto de la

luminosidad en lux. La fotorresistencia sólo se usa para detectar situaciones de iluminación insuficiente, por lo tanto, y aunque la tensión registrada en la entrada del PIC no depende linealmente con la luminosidad o con la impedancia de la fotorresistencia, el valor obtenido es representativo para la finalidad que se persigue. Si se quisiera obtener un valor exacto habría que recalcular por software el verdadero valor de Rfoto.

El sensor de luminosidad está dotado de la siguiente funcionalidad: - Puede detectar umbrales de luminosidad. - Puede monitorizarse el valor registrado por el convertidor analógico-digital

configurando el tiempo de muestreo.

VoutVCC RR RFOTO

=⋅

+5 1

1


84

3.4.4.3 SENSOR DE PROXIMIDAD POR ULTRASONIDOS El sensor de proximidad que se utilizará está basado en cápsulas de ultrasonidos a 33

KHz, una emisora y otra receptora. El circuito de adaptación estaba ya realizado debido a que esta placa forma parte de otro proyecto fin de carrera. La salida de esta placa es digital y proporciona una señal todo-nada que se activa a nivel alto cuando detecta movimiento y automáticamente vuelve a ponerse a nivel bajo cuando detecta reposo.

Fig. 3. 35 Cápsulas de ultrasonidos y circuito de adaptación.

El sensor de proximidad está dotado de la siguiente funcionalidad: - Detecta movimiento. - Detecta reposo. - Puede monitorizar el nivel de eco recibido. Sólo aplicable si la señal de entrada es

analógica. En el caso del prototipo que se ha creado, esta función no está disponible. 3.4.4.4 LUCES El controlador o actuador de luces es muy simple en lo que a hardware se refiere, ya

consta básicamente de un LED y su resistencia de protección conectados al colector de un transistor que hace de llave y está conectado a su vez a una línea digital de salida del PIC. Se ha optado por utilizar LEDs de luz blanca en vez de bombillas debido a que estas últimas consumen demasiada energía mientras que el consumo de los LEDs es mucho menor y proporcionan una iluminación suficiente si se tiene en cuenta que se va a trabajar sobre una maqueta.

1

2

3

Fig. 3. 36 Circuito de adaptación del LED

A pesar de la simplicidad del hardware de control de las luces, el software es bastante

complejo y su funcionalidad muy amplia:


85

- Puede funcionar en modo dependiente controlada por uno o varios interruptores. - Puede funcionar en modo dependiente controlada por un detector de movimiento. - Puede funcionar en modo dependiente controlada por un sensor de luminosidad. - Se le puede aplicar un temporizador con valor fijo. - Se le puede aplicar temporización inteligente. Sólo cuando depende de un detector de

movimiento. - Puede funcionar de manera independiente. 3.4.4.5 VENTILADOR Para la realización del ventilador se empleará un motor de poca potencia y el circuito de

control de la figura 3.37. Debido a que el motor se comporta como una inductancia, se ha colocado un diodo en paralelo para poder derivar las corrientes que se producen durante los transitorios a través de él, de esta manera, se permite al transistor conmutar sin problemas.

1

2

3

Fig. 3. 37 Circuito de control del ventilador

A nivel funcional los ventiladores pueden: - Actuar en modo dependiente controlados por un sensor de temperatura. - Actuar en modo independiente. - Seleccionar la velocidad. 3.4.4.6 INTERRUPTORES Los interruptores son los elementos más simples del sistema, ya que constan solamente

de un interruptor y un pequeño filtro anti-rebotes hecho con una resistencia y un condensador. La salida se conecta directamente a una entrada digital del PIC. A nivel funcional es más simple aún, ya que lo único que puede hacer es indicar a los demás elementos que ha sido pulsado.

3.5 SUBSISTEMA DE AVISO DE ALARMAS

Existen ciertos tipos de eventos ante los cuales el sistema debe reaccionar

inmediatamente avisando al usuario y al servicio de emergencias correspondiente al tipo de evento. Dado que hoy en día el uso de la telefonía móvil está muy extendido, la probabilidad de que una persona tenga un terminal conectado a una red de telefonía móvil es alta. Esto convierte a las redes móviles en la mejor herramienta para comunicar a alguien una noticia urgente.


86

Las redes de telefonía móvil ponen a disposición de los clientes una serie de servicios de comunicación entre los que se incluyen el servicio de mensajes cortos (SMS) o el servicio de datos GPRS. Los mensajes cortos proporcionan un servicio de envío y recepción de texto casi inmediato, con capacidad suficiente como para detallar un aviso de alarma. Por otra parte GPRS también proporciona un servicio casi instantáneo y además permite enviar datos de carácter general sin límite, el inconveniente está en que para que un terminal móvil pueda recibir una notificación a través de GPRS es necesario que haya una aplicación que esté permanentemente esperando las notificaciones y esté ejecutándose en el terminal móvil. Los terminales móviles por naturaleza están limitados en prestaciones y la gran mayoría no soportan multitarea, por lo tanto es inviable tener una aplicación continuamente ejecutándose ya que no permitiría realizar otras operaciones con el terminal hasta que la aplicación se cerrase. Además, la ejecución de aplicaciones incrementa el consumo en estos terminales donde la energía es ya de por sí limitada. Por todas estas razones se decidió implementar el subsistema de aviso de alarmas con un módem GSM y enviar los mensajes de alarma a través del servicio de mensajes cortos SMS. A la hora de elegir el módem GSM se barajaron varias opciones:

- Usar el GM29 de Sony-Ericsson® - Usar el GM47 de Sony-Ericsson® - Adquirir otro módem GSM de otro fabricante Dado que prácticamente cualquier módem GSM cumple los requisitos funcionales que

necesita el sistema, se descartó la última opción ya que los otros dos módems ya habían sido adquiridos por el Departamento de Ingeniería Electrónica.

Los módems GSM/GPRS GM29 y GM47 ofrecen características similares en cuanto a

funcionalidad y servicios, pero la gran diferencia está en que el GM29 posee un zócalo para la tarjeta SIM, conector DB9 para el control del módem y conectores para alimentación y señales de voz, pudiendo ser utilizado directamente. Por el contrario, el GM47 dispone de más señales de control mapeadas en una ristra de pines, pero es necesaria la creación de una placa adicional que le dé soporte e incluya los elementos que le faltan, como puede ser el zócalo para la tarjeta SIM. Por tanto, y debido a la facilidad de manejo se decidió optar por el GM29.

3.5.1 EL MÓDEM GSM/GPRS GM29

El módem GSM/GPRS GM29 es utilizado en el sistema para canalizar los mensajes de

alerta hacia el exterior. Estos mensajes van dirigidos al usuario y al servicio de emergencia correspondiente y se emiten en caso de incendio, detección de intrusos, etc. Los números de teléfono a los que enviar los mensajes los guarda el maestro del sistema y son configurables.

A continuación se detallan algunas de las características del módem GM29 [19]: - Banda dual GSM 900/1800 MHz - Cumple con el estándar GSM fase 2+ - Servicios de datos: GPRS, CSD, HSCSD y SMS - Servicio de voz - Servicio de Fax grupo 3, clases 1 y 2 - Interfaz serie RS-232 de 9 líneas - Alimentación en el rango de 5 a 32 Vdc - Conector de audio de 4 líneas - Conector para antena - Potencia de emisión: 2W a 900MHz y 1W a 1800MHz


87

- Zócalo para tarjeta SIM

Fig. 3. 38 Imagen del módem GSM/GPRS GM29

El control del módem se hace a través de la interfaz serie RS-232, para ello el módem

GM29 dispone de un conector DB9. El módem se controla gracias a una serie de comandos AT especificados en las normas GSM 07.05 y 07.07. También soporta un juego extendido de comandos AT específicos de Ericsson para añadir una mayor funcionalidad.

3.5.1.1 SERVICIOS El módem soporta el servicio de mensajes cortos SMS tanto en modo PDU como en modo

texto con un máximo de 160 caracteres cuando se utiliza codificación en 7 bits, pudiendo concatenar hasta 6 mensajes seguidos. La diferencia fundamental entre el modo texto y el modo PDU es básicamente que en el modo PDU los datos se envían al módem como un flujo de bytes con la estructura de la PDU que se especifica para el comando AT correspondiente, codificando los parámetros numéricos en bits a diferencia del modo texto, en el que los parámetros numéricos son representados con caracteres. El envío de mensajes en modo texto es un poco más sencillo, razón por la cual el sistema utiliza este modo cuando tiene que enviar mensajes.

Aunque el módem no dispone de micrófono y auricular, puede realizar llamadas de voz si

se le conectan estos elementos a través de la interfaz analógica de 4 líneas balanceadas. El módem también ofrece mecanismos de cancelación de ecos y supresión de ruido para mejorar la calidad de la señal.

El módem soporta tres protocolos de datos además del protocolo de SMS, y son: - GPRS (Global Packet Radio Service). Los módems son terminales de clase B, que

permiten la activación simultánea de servicios GSM y GPRS. Concretamente el GM29 podría clasificarse en la categoría (4+1) (Soporta 1 slot por trama en enlace ascendente y 4 slots por trama en enlace descendente). Con estas características, se pueden conseguir velocidades de hasta 85,6 Kbps, dependiendo de la disponibilidad de la red.

- CSD (Circuit Switched Data). Permite establecer un circuito de datos a 9,6 Kbps - HSCSD (High Speed Circuit Switched Data). Permite establecer un circuito de datos

(2+1) consiguiendo velocidades de hasta 19,2 Kbps.


88

3.5.1.2 INTERFACES DEL MÓDEM

El módem tiene 5 interfaces con el exterior. La primera de ellas es el conector coaxial para

antena, que es del tipo FME macho preparado para antenas de 50Ω de impedancia.

Fig. 3. 39 Imagen del conector de la antena y del puerto serie RS-232

El módem soporta una interfaz serie RS-232 a través de su conector DB9 hembra

cableado como DCE. Este puerto se utiliza para controlar el módem y está unido al puerto serie de la placa “Madriguera” mediante el cable etiquetado como “CABLE RABBIT/MODEM”, que conecta directamente pin a pin todas las líneas de la interfaz. El zócalo para tarjetas SIM se encuentra en la parte superior del módem. Soporta tarjetas SIM a 5 y a 3V. Cuando se inserta una tarjeta SIM y se introduce el código PIN correcto, el LED que hay junto al zócalo parpadeará mientras haya cobertura suficiente, en caso contrario el LED permanecerá encendido de forma continua.

Fig. 3. 40 Zócalo para la tarjeta SIM

El conector de audio es del tipo RJ-9 de 4 hilos y sirve para acoplar al módem un

micrófono y un altavoz que permitan realizar llamadas de voz. La descripción de los pines del conector es la siguiente:


89

Fig. 3. 41 Conector de audio

Pin Señal Sentido Descripción 1 MICN Entrada Entrada negativa del micrófono 2 BEARN Salida Salida negativa del auricular 3 BEARP Salida Salida positiva del auricular 4 MICP Entrada Entrada positiva del micrófono

Tabla 3. 12 Descripción de las señales del conector de audio El conector de alimentación es del tipo RJ-11 de 6 hilos y sirve para alimentar, encender,

apagar y resetear el módem.

Fig. 3. 42 Conector de alimentación

Pin Señal Sentido Límites Descripción 1 VCC Entrada De 5 a 32 V Alimentación 2 - No conectada 3 HR_IN Entrada De –0,5 a

32V Apaga el módem si está a nivel alto entre 1 y 2 segundos y resetea el módem si está a nivel alto más de 3,5 segundos.

4 TO_IN Entrada De –0,5 a 32V

Enciende el módem si está a nivel alto más de 0,2 segundos

5 - No conectada 6 GND Entrada Tierra

Tabla 3. 13 Descripción de las señales del conector de alimentación


90

3.5.2 MANEJO DEL MÓDEM

Como ya se ha mencionado anteriormente, el módem se controla mediante comandos AT

[20]. A continuación se detallan los pasos esenciales para utilizar el módem y se describen los

comandos AT más importantes: 1) Antes de enviar estos comandos mediante la interfaz RS-232 hay que insertar una

tarjeta SIM válida y encender el módem según lo explicado en el apartado anterior. 2) Utilizar el comando AT+CPIN=”<pin>”. Ejemplo: AT+CPIN=”2222” (en el caso de

que el pin sea 2222). No olvide introducir el carácter “Retorno de carro” tras cada comando para que sea ejecutado.

3) Si el PIN es correcto y hay cobertura, el LED comenzará a parpadear.

Es importante reseñar que todos los comandos empiezan por los caracteres “AT” y han de terminar con el carácter “retorno de carro” para que sean ejecutados.

La mayoría de los comandos para módems GSM pueden ser utilizados de tres maneras: 1) AT+<comando>=<parámetros>. Es la forma utilizada para ejecutar comandos de

acción o de asignación de parámetros. 2) AT+<comando>?. Es la forma utilizada para obtener el estado de los parámetros. 3) AT+<comando>=?. Es la forma utilizada para obtener una descripción de los

parámetros y de los valores admisibles. DE CONTROL DE LLA ATA

Este comando es usado para hacer que el módem conteste a una llamada. Tras

descolgar, inicia la negociación con el módem remoto para establecer una comunicación de datos. Una vez que ha conseguido establecer la comunicación, lo notifica transmitiendo al DTE “CONNECT”. En caso de fallo al establecer la comunicación, lo notificará transmitiendo al DTE “NO CARRIER”.

Sintaxis: ATA

ATD Este comando es usado para marcar un número de teléfono y establecer una

comunicación. El módem descuelga, marca el número y cuando el módem remoto contesta, transmite la portadora y negocia el establecimiento de la conexión notificando el resultado al DTE a través del mensaje “CONNECT”, en caso de haber establecido la comunicación, o los mensajes “BUSY”, “ERROR”, “NO CARRIER” o “NO DIALTONE” en caso de fracaso.

Sintaxis: ATD<num> Ejemplo: ATD666555444

ATH Este comando es usado para colgar y descolgar. Si el parámetro p vale 1, el módem

descolgará y si vale 0, colgará.


91

Sintaxis: ATH<p> Ejemplo: ATH0

ATO Retorna al modo de datos en línea desde el modo comando. Cuando el módem está en

modo comando, responde a todos los comandos AT y cuando está en modo de datos en línea se limita a transmitir al DTE los datos recibidos del módem remoto y a enviar a dicho módem los datos procedentes de DTE. Por tanto, el comando ATO pone al módem en modo de datos en línea. Para pasar al modo comando hay que enviar la secuencia de escape, que normalmente es “+++”, y esperar un determinado tiempo.

Sintaxis: ATO

COMANDOS DE SERVICIOS DE RED

AT+CPIN Este comando es usado para introducir el código PIN y poder tener acceso a la red.

Lleva como parámetro el código en forma de cadena de caracteres delimitada por comillas. Si el código introducido es incorrecto, el módem contesta con el comando +CME ERROR.

Sintaxis: AT+CPIN=<pin> Ejemplo: AT+CPIN=”0000”

AT+CLIP Este comando es usado para activar o desactivar el servicio de identificación de la línea

llamante. Si el parámetro vale 0, se desactiva el servicio y si vale 1, se activa el servicio. Si el servicio está activado, ante una llamada entrante, el módem enviará el comando AT+CLIP con el número de teléfono de la línea llamante.

Sintaxis: AT+CLIP=<p> Ejemplo: AT+CLIP=1

AT+CPMS Este comando es usado para seleccionar las zonas de memoria donde almacenar los

diferentes tipos de mensajes. El parámetro mem1 se refiere a la memoria de donde se leerán y borrarán mensajes. El parámetro mem2 se refiere a la memoria sobre la que se realizan las operaciones de escritura y envío. El parámetro mem3 se refiere a la memoria en la que se guardarán los mensajes recibidos. Todos estos parámetros son cadenas de caracteres que pueden tomar los siguientes valores:

“SM” Almacenamiento en SIM “ME” Almacenamiento en la memoria del módem Sintaxis: AT+CPMS=<mem1>,<mem2>,<mem3> Ejemplo: AT+CPMS=”ME”,”ME”,”SM”


92

AT+CMGF Este comando es usado para indicar al módem el formato a utilizar para enviar o recibir

un SMS. Si el parámetro vale 0, se utiliza el modo PDU, y si vale 1, se utiliza el modo texto. Al principio de este apartado se explican las diferencias entre ambos modos

Sintaxis: AT+CMGF=<n> Ejemplo: AT+CMGF=1

AT+CMGS Este comando es usado para enviar un SMS en modo texto. Tiene varios parámetros y

se comporta de una forma especial respecto a otros comandos. El parámetro <da> especifica el número de teléfono del destinatario del mensaje y es de tipo cadena de caracteres. El parámetro <toda> indica el formato de dicho número. Si el parámetro <toda> vale 145, el número de teléfono ha de ser especificado con su número internacional, es decir empezando con el carácter +, el código del país y por último el número completo del usuario. Una vez introducidos estos parámetros hay que añadir el carácter “retorno de carro” (CR), tras el cual, el módem transmitirá el “prompt” (“> “) que indicará que el módem está listo para recibir el texto del mensaje. Cuando se haya introducido el texto hay que enviar el carácter CTRL+Z (número 26) para confirmar el envío o el carácter ESC (número 27) para cancelar el envío. Si el mensaje es enviado correctamente, el módem devuelve el comando AT+CMGS con un número como parámetro. Si el mensaje no pudo ser enviado correctamente, el módem devolverá el comando AT+CME ERROR.

Sintaxis: AT+CMGS=<da>,<toda>,<CR> <texto><CTRL+Z/ESC> Ejemplo: AT+CMGS="+34666555444",145 enviamos CR tras el 145

Esperamos a que salga el prompt > Este es el texto que vamos a enviar ahora mismo

enviamos CTRL+Z tras la palabra “mismo”

3.6 SISTEMAS AUXILIARES

3.6.1 EL SISTEMA DE DESARROLLO PICMEO 2

El sistema de desarrollo PICMEO 2 fue creado por el autor del presente proyecto fin de

carrera en el contexto de un trabajo en el Departamento de Ingeniería Electrónica de la Escuela Superior de Ingenieros de Sevilla. Se trata de una placa de desarrollo para el PIC18F448, y debido a la similitud con los microcontroladores usados en los nodos (PIC18F248) se utilizó la placa PICMEO 2 para las primeras pruebas con los sensores y actuadores y también para las primeras pruebas sobre el bus CAN. Al ser una placa configurable de propósito general, constituye un entorno idóneo para el aprendizaje y para la realización de pruebas antes de diseñar un sistema específico. Aunque la placa PICMEO 2 no forma parte del prototipo domótico, algunos de los diseños que se hicieron en su día para la PICMEO 2 han podido reaprovecharse en el presente proyecto. Toda la información referente al sistema PICMEO 2 se encuentra en el anexo A.3.


93

Fig. 3. 43 Sistema de desarrollo PICMEO 2

3.6.2 PROGRAMADORA JDM

Las programadoras JDM son ampliamente utilizadas en la programación de pequeños

microcontroladores y memorias EEPROM. Este tipo de programadoras son muy baratas y sencillas de construir y sus esquemáticos se pueden encontrar fácilmente en Internet. Se trata de un circuito de programación que se conecta al PC a través de un puerto serie y no necesita ser alimentado de forma externa ya que obtiene la alimentación del propio puerto serie. Por otra parte, la programadora va conectada a unas determinadas líneas del microcontrolador que llevan a cabo la programación utilizando un canal serie y sin necesidad de tener que aislar el microcontrolador del circuito donde se encuentre instalado. Este proceso se conoce como “In Circuit Serial Programming” (ICSP) y es utilizado por los PIC18F248. Para programar un nodo hay que conectar la programadora JDM al PC a través del puerto serie utilizando el cable proporcionado para ello y después utilizar el cable especial para unir el conector de 6 pines que tiene la programadora JDM con el conector C6 del nodo siguiendo las recomendaciones descritas en el apartado 3.4.1.3. El cable de programación para conectar el PC y la programadora JDM no es más que un cable de 9 hilos directo, es decir, cada uno de los pines del conector DB9 va conectado con su homólogo en el otro conector DB9.


94

Fig. 3. 44 Imagen de la programadora JDM

Pin Señal 1 VSS 2 VPP 3 SDATA 4 SCLK 5 PGM 6 VDD Tabla 3. 14 Descripción de la interfaz ICSP

3.6.3 FUENTE DE ALIMENTACIÓN Para las pruebas se ha utilizado una fuente de alimentación genérica aunque el sistema

debería tener su propia fuente que proporcionara dos raíles de alimentación, uno a +5V y otro a +15V, además de una línea de tierra. Además, la fuente de alimentación debería disponer un subcircuito de activación del módem GSM. Este subcircuito haría posible encender o apagar el módem manualmente mediante botones y también mediante las señales de control del DSP, que activarían la señal de encendido tras arrancar el sistema.

3.7 PROTOCOLOS Para coordinar los elementos del sistema se han diseñado dos protocolos específicos del

nivel de aplicación, uno para la red interna de bus CAN al que se ha denominado protocolo interno y otro para la comunicación entre el servidor y la aplicación cliente sobre Internet al que se ha denominado protocolo externo.

A continuación se muestra la torre de protocolos del sistema según el modelo OSI:


95

Fig. 3. 45 Torre de protocolos del sistema domótico

En la figura aparece otro tipo de protocolo no mencionado hasta ahora, el protocolo

intermedio. Este protocolo, salvo casos puntuales es exactamente igual que el protocolo externo, por esta razón no se va a comentar a fondo este protocolo, sino que en todo caso se señalarán las diferencias con el protocolo externo. 3.7.1 PROTOCOLO INTERNO (RED DE BUS CAN)

El protocolo interno es un protocolo de la capa de aplicación aunque está íntimamente

ligado con la capa de enlace debido a las peculiaridades del bus CAN, que como ya se dijo, utiliza identificadores en el nivel de enlace para anunciar el contenido del mensaje. Este identificador junto con el campo de datos forma justamente la PDU del nivel de aplicación. Se ha utilizado la especificación CAN 2.0 B que permite usar identificadores de 29 bits. Esos 29 bits se han estructurado en tres campos:

TIPO DE ELEMENTO COMANDO NÚMERO DE ELEMENTO 11 bits 10 bits 8 bits

Tabla 3. 15 Estructura del identificador CAN El campo ‘Tipo de elemento’ indica el tipo de elemento que origina el mensaje o al tipo de elementos que va dirigido el mensaje. Permite hasta 2048 tipos distintos de elementos. Mientras menor sea el número codificado en este campo, mayor prioridad tendrán los mensajes, esto es debido al mecanismo de acceso al medio de CAN, que da preferencia a estos mensajes en caso de colisión con una trama que posea un identificador de mayor valor. Por este motivo, se han reservado los valores del 0h al 20h para mensajes urgentes como por ejemplo las alarmas. A título de ejemplo se citan a continuación algunos de los valores que han sido asignados en el sistema prototipo:

Descripción del elemento Valor Sensor de temperatura 280h Sensor de proximidad 300h Actuador para luces 480h

Tabla 3. 16 Números asignados a algunos tipos de elemento Cualquier elemento puede originar un mensaje para transmitir algún tipo de información

o para solicitar que otros lleven a cabo una determinada acción. El motivo del mensaje se


96

especifica en el campo ‘Comando’. Este campo permite definir hasta 1024 comandos diferentes para cada tipo de elemento. Dependiendo de las necesidades del comando se pueden incluir o no parámetros, que en caso de existir irían situados en el campo de datos de la trama de nivel de enlace. Por ejemplo: cuando un sensor de temperatura tiene que enviar el dato de temperatura que ha registrado, utiliza el comando 25 y en el campo de datos envía un byte en el que codifica el valor de la temperatura medida en grados centígrados. Los parámetros de cada comando se definen en las especificaciones de cada tipo de elemento. Esta información se encuentra detallada en el anexo A.1, donde se proporcionan las especificaciones de los elementos definidos hasta el momento. Existen también una serie de comandos comunes a todos los elementos. Se utilizan para obtener la marca y modelo del elemento, asignación y lectura de parámetros tanto de funcionamiento como de dependencia, etc. Estos comandos tienen asignados unos determinados números que no pueden ser utilizados en ningún elemento para otros fines.

El campo ‘Número de elemento’ sirve para identificar al elemento que origina el mensaje o

al que va destinado si fuera necesario. Este número de 8 bits identifica al elemento dentro del tipo al que pertenece, pudiendo tener hasta 255 elementos (el valor 0 está reservado) de un mismo tipo dentro del sistema. En el caso de los mensajes que no van dirigidos a un elemento en concreto sino a un grupo de elementos o cuando el elemento que envía/recibe el mensaje es necesariamente único en el sistema, como por ejemplo los mensajes de alarma, este campo carece de sentido y lleva el valor 0. El campo ‘Número de elemento’ junto con el campo ‘Tipo de elemento’ definen de manera unívoca a cualquier elemento del sistema. Los números de elemento los asigna el elemento maestro mediante un mecanismo de plug & play que se describe en el apartado 3.7.4 junto con otros esquemas de comunicación que se dan en el sistema.

3.7.2 PROTOCOLO EXTERNO (INTERNET)

El protocolo externo es un protocolo de la capa de aplicación y se transmite sobre TCP.

Este protocolo permite controlar el sistema desde un PC conectado a Internet o desde un terminal móvil GPRS. Aunque las aplicaciones cliente están fuera del alcance del proyecto, hay que decir que la aplicación para terminales móviles estará hecha en J2ME (Java 2 Micro Edition) y no emplea la funcionalidad completa del protocolo debido a las limitaciones de este tipo de dispositivos, en su lugar, sólo dispone de los comandos más básicos. El protocolo externo se estructura en tramas de longitud variable delimitadas al comienzo por una bandera. El primer campo de la trama es siempre la orden, codificada en 8 bits. El resto de campos difieren de una trama a otra dependiendo de la orden.

Antes de proseguir con la descripción detallada de las tramas, se van a definir ciertos

conceptos básicos necesarios para entender el funcionamiento del protocolo. El tipo de información que se intercambian el usuario y el sistema se ha dividido en tres categorías:

- Valor. Son datos con una longitud máxima de hasta 8 bytes. Este límite se

establece en 8 bytes precisamente porque las tramas del protocolo interno pueden contener hasta 8 bytes de datos cada una. Este tipo de información es utilizado principalmente para transmitir datos numéricos, campos de bits, etc. Ejemplo: Dato de temperatura.

- Bloque. Son datos de tamaño variable que superan los 8 bytes, y por tanto no pueden ser transmitidos dentro de una trama del protocolo interno. Se hace necesario repartirlos en varias tramas, y para ello se reserva el primer byte del


97

campo de datos de la trama del protocolo interno como campo de control. El bit más significativo de este campo (FIN) indica que se trata de la última trama del bloque si está activado o que se trata de una trama intermedia del bloque si está desactivado. Los siete bytes restantes del campo de datos se utilizan para transmitir propiamente la información. Ejemplo: Modelo del elemento (cadena de caracteres).

- Serie. Son datos cortos similares a los valores, por tanto no sobrepasan los 8 bytes, pero que se transmiten con cierta periodicidad. Se utilizan fundamentalmente para tareas de monitorización. Ejemplo: Monitorización de la temperatura.

3.7.2.1 TRAMAS DEL PROTOCOLO EXTERNO

ORDEN DESCRIPCIÓN SENTIDO * NUM ACTIVARTEL Activar un número de teléfono U>>S 10 ALARMA Alarma S>>U 1 ANUMTEL Añadir un número de teléfono U>>S 11

APARAM Asignar un valor a un parámetro de funcionamiento/dependencia U>>S 12

ASIGSECTOR Asignar un elemento a un sector U>>S 13 BORRARSECTOR Borrar un sector U>>S 14 CONFIGDIR Configurar la dirección del inmueble U>>S 15 DESACTIVARTEL Desactivar un número de teléfono U>>S 16 DIR Dirección del inmueble almacenada S>>U 17 EJECUTAR Ejecución de un comando de protocolo interno U>>S 18 ENVIOCONTRA Envío de la contraseña U>>S 19 ERROR Error S>>U 20 EXPULSAR Expulsa un elemento del registro del sistema U>>S 39 INFOSIS Información del sistema almacenada S>>U 21 LIBERAR Liberar el buzón asociado a una petición U>>S 22 LPARAM Solicitud de lectura de un parámetro de func./dependencia U>>S 23 MARCA Marca del elemento S>>U 24 MODELO Modelo del elemento S>>U 25 NUEVACONTRA Asignación de nueva contraseña U>>S 26 NUEVO Aviso de nuevos elementos registrados S>>U 27 NUEVOSECTOR Asignación de nuevo sector U>>S 28 NUMPET Devuelve un nuevo número de petición S>>U 40 OK OK. (Contraseña correcta) S>>U 29 PEDIRMARCA Solicitud de lectura de la marca del elemento U>>S 30 PEDIRMODELO Solicitud de lectura del modelo del elemento U>>S 31 RESERVA Reserva de un buzón CAN de recepción U>>S 32 RESPUESTA Respuesta a una petición de datos S>>U 33 SOLDIR Solicitud de lectura de la dirección del inmueble U>>S 34 SOLINFOSIS Solicitud de información general del sistema U>>S 35 SOLNUMPET Solicita un nuevo número de petición U>>S 41 SOLTEL Solicitud de lectura de un número de teléfono U>>S 36 TEL Número de teléfono almacenado S>>U 37 VPARAM Valor almacenado de un parámetro de func./dependencia S>>U 38 LIBERARTODO Libera todos los recursos del maestro C>>M 91 INI Información para inicializar el elemento de comunicación M>>C 90


98

CIP Modificación de la dirección IP C>>M 92 (*) U>>S (del usuario hacia el sistema); S>>U (del sistema hacia el usuario) M>>C (del maestro al elemento de comunicación); C>>M (del elemento de comunicación al maestro)

Tabla 3. 17 Resumen de tramas de los protocolos externo e intermedio El comienzo de las tramas es común y se omitirá en las descripciones particulares de

cada trama. La estructura común sigue la siguiente estructura FLAG NBTOT ORDEN (Resto de la trama)

8 16 Todas las tramas comienzan con el flag 01111110. Esta bandera se utiliza para mantener

sincronizadas la aplicación cliente y la aplicación servidora. Ambas aplicaciones reciben los datos como flujos de bytes y extraen de esos flujos los datos a medida que los van necesitando. Dependiendo de la orden contenida en la trama, pueden conocer la estructura de campos de la trama y por tanto pueden determinar cuántos bytes tienen que extraer. Si se detecta algún error en la estructura de la trama o no se recibe la bandera inicial al principio de la trama, la aplicación entenderá que se ha perdido el sincronismo de trama y buscará byte por byte la bandera. Una vez que haya encontrado la bandera se comprueba la estructura de la siguiente trama y si resulta correcta, significa que se ha recuperado el sincronismo, si no, la aplicación buscará de nuevo la bandera. El campo NBTOT es un valor entero de 16 bits que indica la longitud total de la trama incluidos los campos FLAG y NBTOT.

A continuación se describirán en detalle cada una de las tramas especificadas. Para cada

trama se especificarán los campos con su longitud en bits expresada debajo y la función de los mismos.

ACTIVARTEL Estructura: ORDEN POSICION

8 8 Función: Activa el número de teléfono guardado en la posición indicada. En caso de

alarma, el sistema enviará un mensaje SMS a dicho teléfono si corresponde y está activado.

Campos: ORDEN: 10 POSICION:

Número entero que expresa la posición en la lista del número de teléfono a activar. Valores posibles:

1 Usuario1 2 Usuario2 3 Policía 4 Bomberos


99

ALARMA Estructura: ORDEN TIPO ALARMA SECTOR

8 8 8 Función: Indica al usuario que ha ocurrido algún suceso en el sistema del que debe ser

informado. Esta trama da lugar al envío de mensajes SMS desde el elemento de comunicación con el exterior para avisar de la alarma.

Campos: ORDEN: 1 TIPO ALARMA:

Número entero que expresa la posición en la lista del número de teléfono a activar. Valores posibles:

1 Incendio 2 Intrusos

SECTOR: Número del sector en el que ha ocurrido la incidencia.

ANUMTEL Estructura: ORDEN POSICION NBYTES NUMERO

8 8 8 NBYTES x 8 Función: Añade el número de teléfono en la posición de la lista indicada. Campos: ORDEN: 11 POSICION

Número entero que expresa la posición en la lista donde se guardará el número de teléfono. Valores posibles:


NBYTES Expresa el número de bytes que componen el campo NÚMERO

NÚMERO Cadena de caracteres de longitud variable que expresa el número de teléfono siguiendo la numeración internacional: símbolo ‘+’, prefijo nacional, prefijo provincial, número de abonado. Ejemplo: “+34954000000”

APARAM Estructura:

ORDEN TIPOINFO TIPOELEM NUMELEM DEP/FUN NUMPARAM NBYTES DATOS

8 8 16 (11LSB) 8 8 8 8 Nbytes x 8


100

Función: Asigna un valor a un parámetro de funcionamiento o de dependencia Campos: ORDEN: 12 TIPOINFO

Número entero que expresa el tipo de información que contiene el campo de datos Valores posibles:

0 Sin parámetro 1 Valor 2 Bloque 3 Serie

TIPOELEM Número entero que indica el tipo de elemento al que va dirigido el mensaje. Sólo se tienen en cuenta los 11 bits menos significativos.

NUMELEM Número entero que indica el número de elemento al que va dirigido el mensaje. DEP/FUN Indica si se trata de un parámetro de funcionamiento o de dependencia. Valores posibles:

0 Parámetro de funcionamiento 1 Parámetro de dependencia

NUMPARAM Número entero que indica el número de parámetro de funcionamiento/dependencia NBYTES Número entero que indica el número de bytes que componen el campo de datos DATOS Conjunto de bytes que componen el dato que se asignará al parámetro. ASIGSECTOR Estructura: ORDEN TIPOELEM NUMELEM SECTOR

8 16 (11 LSB) 8 8 Función: Asocia un elemento con el sector en el que está ubicado Campos: ORDEN: 13 TIPOELEM

Número entero que indica el tipo de elemento al que va dirigido el mensaje. Sólo se tienen en cuenta los 11 bits menos significativos.

NUMELEM Número entero que indica el número de elemento al que va dirigido el mensaje.

SECTOR Número entero que indica el sector al que va a ser asociado el elemento. BORRARSECTOR Estructura: ORDEN SECTOR

8 8


101

Función: Borra de la lista el sector especificado Campos: ORDEN: 14 SECTOR Número entero que indica el sector que va a ser borrado. CONFIGDIR Estructura: ORDEN NBD DIR

8 8 8 x NBD Función: Configura la dirección del inmueble donde está instalado el sistema Campos: ORDEN: 15 NBD

Número entero que indica el número de bytes que componen el campo DIR DIR

Cadena de caracteres donde se especifica la dirección completa del inmueble. DESACTIVARTEL Estructura: ORDEN POSICION

8 8 Función: Desactiva el número de teléfono guardado en la posición indicada. En caso de

alarma, el sistema no enviará un mensaje SMS a dicho teléfono si no corresponde o está desactivado.

Campos: ORDEN: 16 POSICION:

Número entero que expresa la posición en la lista del número de teléfono a desactivar. Valores posibles:


DIR Estructura: ORDEN PETICION NBD DIR

8 8 8 8 x NBD Función: Devuelve la dirección del inmueble que está almacenada en el sistema Campos:


102

ORDEN: 17 PETICION Número de petición asociado a la consulta NBD

Número entero que indica el número de bytes que componen el campo DIR DIR

Cadena de caracteres donde se especifica la dirección completa del inmueble. La cadena debe estar terminada con el carácter ‘\0’

EJECUTAR Estructura:

ORDEN TIPOINFO TIPOELEM COMANDO NUMELEM NBYTES DATOS

8 8 16 (11LSB) 16 (10 LSB) 8 8 Nbytes x 8 Función: Ordena la ejecución de un comando a un elemento determinado Campos: ORDEN: 18 TIPOINFO




COMANDO Número del comando a ejecutar sobre el elemento especificado. Sólo se tienen en cuenta los 10 bits menos significativos


NBYTES Número entero que indica el número de bytes que componen el campo de datos DATOS Conjunto de bytes que componen el parámetro asociado al comando si lo hubiera. ENVIOCONTRA Estructura: ORDEN NB CONTRASEÑA

8 8 NB x 8 Función: Envía al sistema la contraseña introducida por el usuario para su validación Campos: ORDEN: 19 NB

Número entero que indica el número de bytes que componen la contraseña CONTRASEÑA


103

Cadena de hasta 8 caracteres que contiene la contraseña marcada por el usuario

ERROR Estructura: ORDEN CODIGO

8 8 Función: Devuelve un código de error. Campos: ORDEN: 20 CODIGO Número entero que codifica un código de error. Valores posibles: 1 Contraseña Incorrecta EXPULSAR Estructura: ORDEN TIPOELEM NUMELEM

8 16 (11LSB) 8 Función: Devuelve un código de error. Campos: ORDEN: 39 TIPOELEM

Número entero que indica el tipo de elemento al que va dirigido el mensaje. Sólo se tienen en cuenta los 11 bits menos significativos.


INFOSIS Estructura: ORDEN NELEM ELEM 1 … ELEM n NSECT SECTOR 1 … SECTOR m

8 8 40 40 8 - - ELEM x TIPO NUM NODO SECTOR

16 (11 LSB) 8 8 8 SECTOR y NUM NB DESCR

8 8 8 x NB


104

Función: Devuelve la información general del sistema. Concretamente devuelve la tabla de elementos registrados y la tabla de sectores

Campos: ORDEN: 21 NELEM Número entero que indica el número de elementos registrados en la tabla. ELEM x

Estructura de datos que contiene la información referente a un elemento. Se transmiten tantas estructuras como indique el campo NELEM. Cada una de las estructuras consta de los siguientes campos:

TIPO Número entero que indica el tipo de elemento. Sólo se tienen en cuenta los 11 bits menos significativos.

NUM Número entero que indica el número de elemento.

SECTOR Número de sector en el que está ubicado el elemento.

NODO Número del nodo asociado al elemento

NSECT Número entero que indica el número de sectores registrados en la tabla.

SECTOR y Estructura de datos que contiene la información referente a un sectore. Se transmiten tantas estructuras como indique el campo NSECT. Cada una de las estructuras consta de los siguientes campos:

NUM Número entero que indica el número de sector.

NBD Número entero que indica el número de bytes que componen el campo DESCR.

DESCR Cadena de caracteres de longitud variable que describe el sector.

LIBERAR Estructura: ORDEN PETICION

8 8 Función: Libera el buzón asociado a una petición Campos: ORDEN: 22 PETICION

Número entero que indica la petición que reservó el buzón LPARAM Estructura:

ORDEN PETICION TIPOINFO TIPOELEM NUMELEM DEP/FUN NUMPARAM

8 8 8 16 (11LSB) 8 8 8


105

Función: Lee el valor de un parámetro de funcionamiento o dependencia de un

determinado elemento Campos: ORDEN: 23 PETICION

Número entero que indica la petición asociada a la solicitud de lectura de parámetro TIPOINFO




NUMELEM Número entero que indica el número de elemento al que va dirigido el mensaje. DEP/FUN Indica si se trata de un parámetro de funcionamiento o de dependencia. Valores posibles:

0 Parámetro de funcionamiento 1 Parámetro de dependencia

NUMPARAM Número entero que indica el número de parámetro de funcionamiento/dependencia MARCA Estructura: ORDEN PETICION NBM MARCA

8 8 8 8 x NBM Función: Devuelve la marca del elemento Campos: ORDEN: 24 PETICION Número de petición asociado a la consulta NBM

Número entero que indica el número de bytes que componen el campo MARCA. MARCA

Cadena de caracteres de longitud variable que contiene la marca del elemento. MODELO Estructura: ORDEN PETICION NBM MODELO

8 8 8 8 x NBM Función: Devuelve el modelo del elemento


106

Campos: ORDEN: 25 PETICION Número de petición asociado a la consulta NBM

Número entero que indica el número de bytes que componen el campo MODELO. MODELO

Cadena de caracteres de longitud variable que contiene el modelo del elemento. NUEVACONTRA Estructura: ORDEN NB CONTRASEÑA

8 8 NB x 8 Función: Envía al sistema la nueva contraseña. Esta orden sólo está disponible una vez

que se haya iniciado sesión con la antigua contraseña. Campos: ORDEN: 26 NB Número entero que indica el número de bytes que componen la contraseña CONTRASEÑA Cadena de hasta 8 caracteres que contiene la contraseña marcada por el usuario

NUEVO Estructura: ORDEN TIPOELEM NUMELEM

8 16 (11 LSB) 8 Función: Indica que se ha registrado un nuevo elemento Campos: ORDEN: 27 TIPOELEM

Número entero que indica el tipo de elemento registrado NUMELEM

Número entero que indica el número que se le ha asignado al elemento registrado NUEVOSECTOR Estructura: ORDEN NUM NBD DESCR

8 8 8 8 x NBD Función: Añade un nuevo sector al sistema Campos: ORDEN: 28 NUM


107

Número entero que indica el número del nuevo sector. NBM

Número entero que indica el número de bytes que componen el campo DESCR. DESCR

Cadena de caracteres de longitud variable que describe el sector.

NUMPET Estructura: ORDEN PET

8 8 Función: Devuelve un número de petición que previamente ha sido solicitado por la

aplicación cliente. Este número será utilizado en posteriores peticiones. Campos: ORDEN: 40 PET

Número de petición asignado. OK Estructura: ORDEN

8 Función: Confirma alguna solicitud. Se aplica al mecanismo de autentificación y cuando

es recibida por el usuario significa que la contraseña introducida es correcta y que por tanto se establece una sesión.

Campos: ORDEN: 29 PEDIRMARCA

Estructura: ORDEN PETICION TIPOELEM NUMELEM

8 8 16 (11 LSB) 8 Función: Solicita la marca del elemento especificado Campos: ORDEN: 30 PETICION Número de petición asociado a la consulta TIPOELEM

Número entero que indica el tipo de elemento del que se quiere conocer la marca. Sólo se tienen en cuenta los 11 bits menos significativos.

NUMELEM Número entero que indica el número de elemento del que se quiere conocer la marca.


108

PEDIRMODELO Estructura: ORDEN PETICION TIPOELEM NUMELEM

8 8 16 (11 LSB) 8 Función: Solicita el modelo del elemento especificado Campos: ORDEN: 31 PETICION Número de petición asociado a la consulta TIPOELEM

Número entero que indica el tipo de elemento del que se quiere conocer el modelo. Sólo se tienen en cuenta los 11 bits menos significativos.

NUMELEM Número entero que indica el número de elemento del que se quiere conocer el modelo.

RESERVA Estructura:

ORDEN PETICION TIPOINFO TIPOELEM COMANDO NUMELEM

8 8 8 16 (11LSB) 16 (10 LSB) 8 Función: Reserva un buzón del elemento maestro para recibir tramas del protocolo interno

con el identificador formado con los campos TIPOELEM, COMANDO y NUMELEM.

Campos: ORDEN: 32 PETICION

Número entero que indica la petición asociada TIPOINFO

Número entero que expresa el tipo de información que se espera recibir en el buzón Valores posibles:


TIPOELEM Número entero que indica el tipo de elemento que enviará los mensajes al buzón. Sólo se tienen en cuenta los 11 bits menos significativos.

COMANDO Número del comando que se debe recibir en el buzón. Sólo se tienen en cuenta los 10 bits menos significativos

NUMELEM Número entero que indica el número de elemento que enviará los mensajes al buzón.


109

RESPUESTA Estructura:

ORDEN PETICION TIPOINFO NBYTES DATOS

8 8 8 8 Nbytes x 8 Función: Devuelve al usuario los datos solicitados en la petición indicada Campos: ORDEN: 33 PETICION

Número entero que indica la petición asociada a los datos devueltos TIPOINFO



NBYTES Número entero que indica el número de bytes que componen el campo de datos DATOS Conjunto de bytes que componen los datos devueltos por el elemento. SOLDIR Estructura: ORDEN PETICION

8 8 Función: Solicita la dirección del inmueble almacenada en el sistema Campos: ORDEN: 34 PETICION

Número entero que indica la petición asociada a la solicitud SOLINFOSIS Estructura: ORDEN

8 Función: Solicita la información del sistema Campos: ORDEN: 35


110

SOLNUMPET Estructura: ORDEN

8 Función: Solicita un número de petición al servidor. Campos: ORDEN: 41 SOLTEL Estructura: ORDEN PETICION POSICION

8 8 8 Función: Solicita el número de teléfono almacenado en la posición indicada Campos: ORDEN: 36 PETICION

Número entero que indica la petición asociada a la solicitud POSICION

Número entero que indica la posición en la lista del número de teléfono que se quiere recuperar

TEL Estructura: ORDEN PETICION NBYTES TEL

8 8 8 NBYTES x 8 Función: Devuelve el número de teléfono solicitado en la petición indicada Campos: ORDEN: 37 PETICION

Número entero que indica la petición asociada a la solicitud NBYTES

Expresa el número de bytes que componen el campo TEL TEL

Cadena de caracteres de longitud variable que expresa el número de teléfono siguiendo la numeración internacional: símbolo ‘+’, prefijo nacional, prefijo provincial, número de abonado. Ejemplo: “+34954000000”

VPARAM Estructura: ORDEN PETICION TIPOINFO NBYTES DATOS

8 8 8 8 Nbytes x 8


111

Función: Devuelve el valor de un parámetro de funcionamiento o de dependencia de un

determinado elemento Campos: ORDEN: 38 PETICION

Número entero que indica la petición asociada a la solicitud TIPOINFO



NBYTES Número entero que indica el número de bytes que componen el campo de datos DATOS Conjunto de bytes que componen el dato contenido en el parámetro. 3.7.2.2 DIFERENCIAS CON EL PROTOCOLO INTERMEDIO Como ya se dijo anteriormente, el protocolo intermedio es muy parecido al protocolo

externo salvo una serie de excepciones que se detallan a continuación: La primera de las diferencias se refiere a las alarmas. Aunque la trama de alarma es la

misma para el protocolo intermedio que para el protocolo externo, el comportamiento ante la misma de los dispositivos involucrados es distinta. Mientras que la recepción de la trama de alarma en el Rabbit desencadena la generación de mensajes SMS, la aplicación cliente se limita a notificarlo al usuario cuando recibe esta trama.

La segunda diferencia está en la trama LIBERARTODO, exclusiva del protocolo

intermedio, que sirve para liberar todos los buzones del elemento maestro que hubiera reservado la aplicación cliente cuando se pierde la conexión con el usuario de manera súbita. Esta trama la envía el elemento de comunicación con el exterior hacia el elemento maestro, y su estructura es muy sencilla, ya que únicamente consta del campo ORDEN:

LIBERARTODO Estructura: ORDEN

8 ORDEN: 91 Otra de las diferencias se refiere a las tramas implicadas en el mecanismo de

autentificación, es decir, ENVIOCONTRA, OK y ERROR. Estas tramas no están disponibles en el protocolo intermedio puesto que no necesitan ser transmitidas al elemento maestro. El


112

mecanismo de autentificación es responsabilidad absoluta del elemento de comunicación con el exterior.

La última diferencia está en las tramas de inicialización, que sirven para intercambiar

datos de configuración del sistema entre el elemento maestro y el elemento de comunicación con el exterior. Por un lado tenemos la trama de inicialización (INI), que va desde el elemento maestro hacia el elemento de comunicación con el exterior. Tras un reset, el elemento maestro extrae la información del sistema de su memoria EEPROM, la carga en forma de estructuras en su memoria RAM y pasa parte de ella al elemento de comunicación con el exterior mediante la trama INI. Los datos que se envían son:

- Dirección IP - Máscara de subred - Dirección del router - Lista de número de teléfonos - Dirección del inmueble - Contraseña - Lista de sectores La estructura de esta trama es: INI Estructura:

ORDEN IP MASK ROUTER NB1 TEL1 … NB4 TEL4 ACT NBC CONTRA NBD DIR NSECT 8 32 32 32 8 NB1 x 8 8 NB4 x 8 8 8 NBC x 8 8 8 x NBD 8

SECTOR1 … SECTORm - -

Las estructuras SECTOR están formadas por los siguientes campos: SECTOR y NUM NBDS DESCR

8 8 NBDS x 8 ORDEN: 90 IP

Número entero de 32 bits que representa la dirección IP del elemento de comunicación con el exterior

MASK Número entero de 32 bits que representa la máscara de subred para el elemento de comunicación con el exterior

ROUTER Número entero de 32 bits que representa la dirección IP del router predeterminado

NBx Expresa la longitud en bytes del campo TELx correspondiente

TELx


113

Cadena de caracteres de longitud variable que expresa el número de teléfono siguiendo la numeración internacional: símbolo ‘+’, prefijo nacional, prefijo provincial, número de abonado. Ejemplo: “+34954000000”

ACT Conjunto de 8 bits que indica qué teléfonos están activados. Si el bit correspondiente está a 1, el teléfono está activado, y si está a 0, el teléfono está desactivado:

Bit 0 Usuario1 Bit 1 Usuario2 Bit 2 Policía Bit 3 Bomberos

NBC Número entero que indica el número de bytes que componen la contraseña

CONTRA Cadena de caracteres de longitud la especificada en el campo NBC y que contiene la contraseña almacenada en el sistema.

NBD Número entero que indica el número de bytes que componen la dirección

DIR Cadena de caracteres de longitud variable que indica la dirección del inmueble almacenada en el sistema.

NSECT Número entero que indica el número de sectores que hay en la lista almacenada en el sistema.

SECTOR Estructura de datos que contiene la información referente a un sector. Se transmiten tantas estructuras como indique el campo NSECT. Cada una de las estructuras consta de los siguientes campos:

NUM Número entero que indica el número de sector

NBDS Número entero que indica el número de bytes que ocupa el campo DESCR.

DESCR Cadena de caracteres de longitud variable que indica el nombre del sector.

Por otra parte tenemos la trama CIP, que se utiliza para indicar al elemento maestro la

nueva configuración para el acceso a Internet. Cuando el sistema el sistema es instalado por primera vez o cuando el sistema cambia de red necesita saber su nueva dirección IP, su nueva máscara de subred y su nueva dirección del router para poder ser controlado. Debido a que en principio el sistema no conoce estos nuevos datos, no podemos transmitírselos a través del enlace Ethernet, por ello y para solucionar este problema se decidió que estos datos se transmitirían a través de uno de los puertos serie del rabbit (puerto A) utilizando una aplicación especial para PC. El puerto A está accesible precisamente a través del conector que se utiliza para programar el rabbit y se puede utilizar el mismo cable para conectarlo con el PC. Habrá que conectar además el cable de programación uniendo el conector del módulo RCM2200 con el conector DIAG. Una vez hecho esto, el sistema guarda la nueva configuración y tras resetearlo, ya se puede utilizar con total normalidad. La trama CIP es la encargada de trasladar la información al elemento maestro, y su estructura es la siguiente:


114

CIP Estructura: ORDEN IP MASK ROUTER

8 32 32 32 ORDEN: 92 IP

Número entero de 32 bits que representa la dirección IP del elemento de comunicación con el exterior

MASK Número entero de 32 bits que representa la máscara de subred para el elemento de comunicación con el exterior

ROUTER Número entero de 32 bits que representa la dirección IP del router predeterminado

3.7.3 FICHEROS DE MANEJO La aplicación para PC hace uso de ficheros de manejo para su funcionamiento. Estos

ficheros hacen una función similar a los drivers para los sistemas operativos y han de ser proporcionados con cada elemento que haya en la red. De esta forma se evita que el protocolo externo tuviera que ser revisado cada vez que introduzcamos nuevos tipos de elementos en la red CAN ya que estos ficheros “indican” a la aplicación cómo debe manejar los elementos y qué funciones puede realizar sobre ellos. Para realizar estas funciones específicas, la aplicación cliente puede componer tramas con ayuda de los ficheros de manejo en los que encapsula la trama del protocolo interno que debe ser enviada al elemento dentro de una trama del protocolo externo.

Antes comentar la estructura de los ficheros de manejo se explicarán algunos conceptos 3.7.3.1 TIPOS DE PARÁMETROS Parámetros de funcionamiento. Son parámetros que almacenan los elementos y que

influyen directamente en el comportamiento de los mismos. Cada elemento define sus propios parámetros de funcionamiento, que están numerados y son accesibles a través de un juego de comandos de protocolo interno común a todos los elementos. Estos parámetros pueden ser de distintos tipos: enteros, flotantes, caracteres, etc. Por ejemplo: los sensores de temperatura tienen un parámetro de funcionamiento llamado TMUESTREO, que indica el tiempo de muestreo en segundos, y es un número entero de 16 bits sin signo. Modificando este parámetro se pueden obtener más o menos muestras de temperatura en un determinado tiempo.

Parámetros de dependencia. Son parámetros que almacenan algunos elementos y que

influyen indirectamente en el comportamiento de los mismos. Cada elemento define sus propios parámetros de dependencia, que están numerados y son accesibles a través de un juego de comandos de protocolo interno común a todos los elementos. Estos parámetros son siempre del mismo tipo y contienen el identificador de otro elemento que influirá sobre el comportamiento del elemento en cuestión. Estos parámetros se utilizan fundamentalmente en actuadores que


115

dependen de eventos que ocurren en otros elementos. Por ejemplo: el actuador de luces tiene un parámetro de dependencia llamado INT1 que hace depender la luz de un determinado interruptor. En el parámetro INT1 se introduciría el número de elemento del interruptor a asociar. El resto del identificador lo generaría el propio elemento, y escucharía todos los mensajes cuyo tipo de elemento sea “Interruptor”, cuyo comando sea CE (Cambio de estado del interruptor) y cuyo número sea el especificado en el parámetro de dependencia. De este modo la luz podría ser controlada a través de ese interruptor.

3.7.3.2 ESTRUCTURA DE LOS FICHEROS DE MANEJO Los ficheros de manejo se presentan en forma de archivos de texto con la siguiente

estructura: 1) Características generales. Este apartado comienza con la palabra clave “GENERAL”, y los diferentes campos van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. El conjunto de todos los campos de este apartado va encerrado entre llaves (). Los campos de este apartado dan información sobre las características generales del elemento, y son:

- Marca. Indica la marca del elemento. Cadena de caracteres - Modelo. Indica el modelo del elemento. Cadena de caracteres - Tipo. Indica el tipo de elemento. Número decimal en forma de cadena de

caracteres.

Ejemplo: GENERAL Mimarca ActuadorLuz2000 1152 2) Parámetros de funcionamiento. Este apartado comienza con la palabra clave “PFUN” seguida del número de parámetros de funcionamiento, en forma de cadena de caracteres, y de las descripciones de los parámetros de funcionamiento si las hubiera. Cada descripción va encerrada entre llaves. Los diferentes campos que forman la descripción van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. Los campos de información para cada parámetro de funcionamiento son:

- Número de parámetro. Indica el número del parámetro de funcionamiento. Número decimal en forma de cadena de caracteres

- Tipo de datos. Indica el tipo de datos que contiene el parámetro. Cadena de caracteres. Los valores posibles son:

BYTE entero 8 bits INT entero 16 bits LONG entero 32 bits CHAR carácter 8 bits BOOLEAN Verdadero/Falso 8 bits FLOAT flotante 32 bits


116

STRING cadena de caracteres Los modificadores posibles a los tipos numéricos son: SIGNED con signo UNSIGNED sin signo (por defecto) - Descripción del parámetro. Indica la función del parámetro. Cadena de

caracteres. - Mnemónico. Nombre corto que identifica al parámetro. Cadena de caracteres. - Descripción de valores posibles. Especifica mediante un texto qué valores es

posible asignar al parámetro. Si se quiere omitir este campo introduzca una línea en blanco en su lugar. Cadena de caracteres.

- Unidades. Especifica mediante un texto las unidades en que se mide el parámetro. Si se quiere omitir este campo, introduzca una línea en blanco en su lugar.

- Tipo de información. Indica qué tipo de información lleva el parámetro. Cadena de caracteres. Valores posibles:

VALOR BLOQUE SERIE

Ejemplo: PFUN 2 Se describen dos parámetros de funcionamiento 1 INT Indica el nº de segundos desde que el detector de

movimiento detecta reposo hasta que se apaga la luz TEDR segundos VALOR 2 INT Indica el nº de segundos que la luz permanece encendida

tras detectar movimiento o pulsar un interruptor TF segundos VALOR 3) Parámetros de dependencia. Este apartado comienza con la palabra clave “PDEP” seguida del número de parámetros de dependencia, en forma de cadena de caracteres, y de las descripciones de los parámetros de dependencia si las hubiera. Cada descripción va encerrada entre llaves. Los diferentes campos que forman la descripción van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. Los campos de información para cada parámetro de dependencia son:


117

- Número de parámetro. Indica el número del parámetro de dependencia. Número decimal en forma de cadena de caracteres

- Tipo de elemento influyente. Indica el tipo de elemento que genera dependencia. Número decimal en forma de cadena de caracteres.

- Mnemónico. Nombre corto que identifica al parámetro. Cadena de caracteres. - Descripción del parámetro. Indica la función del parámetro. Cadena de

caracteres.

Ejemplo: PDEP 1 1 1600 INT1 Número del primer interruptor del que depende la luz 4) Parámetros específicos de comandos. Este apartado comienza con la palabra clave “P” seguida del número de parámetros específicos, en forma de cadena de caracteres, y de las descripciones de los parámetros de comandos si las hubiera. Cada descripción va encerrada entre llaves. Los diferentes campos que forman la descripción van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. Los campos de información para cada parámetro de comando son idénticos a los de los parámetros de funcionamiento.

Ejemplo: P 1 1 BOOLEAN Estado de la luz STAT VALOR 5) Comandos disponibles. Este apartado comienza con la palabra clave “COM” seguida del número de comandos, en forma de cadena de caracteres, y de las descripciones de los comandos disponibles para el elemento si los hubiera. Cada descripción va encerrada entre llaves. Los diferentes campos que forman la descripción van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. Los campos de información para cada comando son:

- Número de comando. Indica el número del comando. Número decimal en forma de cadena de caracteres.

- Mnemónico. Nombre corto del comando. Cadena de caracteres


118

- Parámetros [opcional]. Por cada parámetro que necesite el comando se hará una referencia con la siguiente estructura: se escribirá la palabra “PARAM”, un espacio y el número del parámetro de comando en forma de cadena de caracteres. Se pueden poner ninguna, una o varias de estas referencias para cada comando.

Ejemplo: COM 2 1 LSTAT PARAM 1 2 LON 6) Acciones. Este apartado comienza con la palabra clave “AC” seguida del número de acciones, en forma de cadena de caracteres, y de las descripciones de las acciones disponibles si las hubiera. Cada descripción va encerrada entre llaves. Los diferentes campos que forman la descripción van separados por el carácter “Retorno de carro”, es decir, cada campo se expresa en una línea diferente. Los campos de información para cada acción son:

- Descripción. Indica la función de la acción. Cadena de caracteres - Mnemónico. Nombre corto de la acción. Cadena de caracteres - Solicitudes. Por cada comando que necesite enviar la acción hacia el sistema se

hará una referencia con la siguiente estructura: se escribirá la palabra “SOLIC”, un espacio y el número del comando en forma de cadena de caracteres. Se pueden poner una o varias de estas referencias para cada acción.

- Respuestas. Por cada comando que necesite recibir la acción desde el sistema se hará una referencia con la siguiente estructura: se escribirá la palabra “RESP”, un espacio y el número del comando en forma de cadena de caracteres. Se pueden poner ninguna, una o varias de estas referencias para cada acción.

- Acción cancelatoria. Por cada comando que se necesite enviar al sistema para detener la acción se hará una referencia con la siguiente estructura: se escribirá la palabra “CANCEL”, un espacio y el número del comando en forma de cadena de caracteres. Se pueden poner ninguna, una o varias de estas referencias para cada acción.

Ejemplo: AC 1 Ver el estado de la luz


119

LUZSTAT SOLIC 8 el comando 8 es SOLSTAT RESP 9 el comando 9 es LSTAT

3.7.4 ESQUEMAS DE COMUNICACIÓN Para explicar la relación entre las tramas de protocolo interno y externo y para facilitar la

comprensión del funcionamiento del sistema se describirán a continuación una serie de situaciones en las que se explica cómo actúan los protocolos y los mensajes que se intercambian.

Escenario 1: Mecanismo de autentificación, inicio y cierre de sesión.

Fig. 3. 46 Autentificación, inicio y cierre de sesión

Para iniciar una sesión, el usuario utiliza la aplicación cliente, que le pedirá la dirección IP

del sistema que quiere controlar y la contraseña. Si la dirección IP es correcta y el servidor no está ocupado, se establece una conexión TCP, y una vez establecida, la aplicación cliente envía la contraseña al sistema en una trama ENVIOCONTRA para que sea verificada. Si la contraseña no es correcta, el servidor (Rabbit) envía una trama ERROR con un código, que en este caso tiene el valor 1 y quiere decir “Contraseña incorrecta”. Después de enviar esta trama y de forma automática, el servidor corta la comunicación con la aplicación cliente. Si la contraseña es correcta, el servidor contesta con una trama OK, que indica que la contraseña era correcta y que se ha iniciado la sesión.

Una vez establecida la sesión, la aplicación cliente solicita automáticamente la información

del sistema mediante la trama SOLINFOSIS. Esta trama atraviesa el sistema hasta el elemento maestro (DSP), que es el que guarda toda la información del sistema. El elemento maestro contesta enviando una trama INFOSIS en la que introduce la lista de elementos registrados y la lista de sectores. Cuando esta información llega a la aplicación cliente, ésta compara la información recibida con la información que tuviera almacenada y si detecta alguna modificación, actualiza sus registros con la información recibida. En caso de detectar nuevas entradas en la lista de elementos registrados, se solicitará al usuario que especifique la ubicación de los ficheros de manejo correspondientes a los nuevos elementos.

Una vez que el usuario termina de realizar las operaciones sobre el sistema y decide

cerrar la sesión, la aplicación envía una trama CIERRE al sistema. Cuando el Rabbit recibe esta


120

trama, corta la conexión con la aplicación cliente. Por su parte el DSP libera los buzones asociados a peticiones si estuvieran aún reservados.

Escenario 2: Ejecución de un comando con respuesta en forma de valor.

Fig. 3. 47 Petición de la temperatura

Se supone que la sesión ya está establecida. El usuario pide la temperatura a través de

una de las acciones que la aplicación cliente le presenta. La aplicación accede al fichero de manejo del sensor de temperatura y lee la información de la acción correspondiente. En este fichero se le indica que deberá enviar el comando SOLT y deberá recibir el comando VTEMP, ambos aplicables en el ámbito del protocolo interno. El primer paso que lleva a cabo la aplicación es la reserva de un buzón para recibir el comando VTEMP, para ello define la petición número 1, que tendrá validez mientras dure el proceso de solicitud de temperatura, y envía una trama RESERVA indicando que los datos obtenidos se liguen al contexto de la petición 1. Además envía el identificador completo (Tipo de elemento, Comando, Número de elemento) del mensaje que espera recibir, especificando que el tipo de información que se espera es en forma de valor (menor de 8 bytes). Cuando esta trama llega al DSP, éste reserva uno de sus buzones libres y lo configura para recibir el tipo de tramas de protocolo interno que ha sido especificado, asociando este buzón a la petición 1.

La aplicación, siguiendo con las instrucciones del fichero de manejo, envía una trama

EJECUTAR en la que incluye el identificador completo de la trama de protocolo interno que quiere transmitir en la red CAN. El comando que va en el identificador es el comando SOLT, que solicita el valor de la temperatura al sensor de temperatura en cuestión. Cuando este sensor de temperatura recibe la trama de protocolo interno, contesta automáticamente con el comando VTEMP y añade como dato el valor de temperatura que registra en ese momento. Como este dato sólo ocupa un byte, se puede transmitir en una sola trama de protocolo interno, por eso se dice que el tipo de información es “Valor”. El DSP recibe esta trama por el buzón que había reservado y cuando esto sucede, se desencadenan dos acciones: por un lado se genera una trama RESPUESTA, en la que se introduce el dato de temperatura y la petición asociada para que la aplicación pueda determinar el contexto en el que se enmarca ese dato, y por otro lado, el DSP libera el buzón de la petición 1, puesto que como se esperaba una respuesta en forma de valor, ya no van a llegar más tramas con ese identificador.

Cuando la aplicación recibe la trama RESPUESTA, extrae el dato solicitado y siguiendo

las especificaciones que sobre ese parámetro existen en el fichero de manejo, lo presenta debidamente al usuario.


121

Escenario 3: Ejecución de un comando con respuesta en forma de bloque.

Fig. 3. 48 Petición del modelo de un sensor de temperatura

Se supone que la sesión ya está establecida. El usuario pide el modelo de un sensor de

temperatura a la aplicación cliente. La aplicación no necesita acceder al fichero de manejo del sensor de temperatura en este caso puesto que las operaciones de obtención del modelo y marca de un elemento se tramitan a través de comandos comunes preestablecidos. La aplicación en realidad no necesita conocer los comandos de protocolo interno para obtener esta información ya que se limita a utilizar una orden específica: la trama de protocolo externo denominada PEDIRMODELO. La aplicación transmite por tanto esta trama indicando el identificador del elemento (exceptuando el comando) y asociándole un número de petición, en este caso el 2, que se mantendrá vigente mientras dure el proceso de solicitud del modelo del elemento. En este caso concreto no hace falta especificar que se trata de información en forma de bloque puesto que la información solicitada es una cadena de caracteres, y las cadenas de caracteres se tratan como bloques de bytes, no como valores ni series de datos. Pueden existir otras situaciones en las que se trata con información específica para un determinado elemento y en esos casos sí es necesario especificar que la información se maneje como bloque, ya que la aplicación no puede saber a priori cómo tratarla. En esos casos es el fichero de manejo el que determina el tipo de información.

Cuando esta trama llega al DSP, éste reserva uno de sus buzones libres y lo configura

para recibir tramas con el identificador del elemento especificado pero con el comando común CCMODELO, y asocia este buzón a la petición 2. Además el propio DSP compone una trama de protocolo interno que contiene el identificador del elemento y el comando común CCSOLMOD, que significa “solicitar el modelo del elemento”.

Cuando este sensor de temperatura recibe la trama de protocolo interno, contesta

automáticamente con el comando CCMODELO y añade como parámetro parte de la cadena de caracteres que expresa el modelo. El elemento envía tantas tramas CCMODELO como sean necesarias para completar la transmisión de la cadena, teniendo en cuenta que en cada trama sólo puede transmitir hasta 7 bytes de la cadena, puesto que el primer byte se reserva para control. En la última trama activa el bit FIN de ese byte de control indicando que ya no se van a transmitir más tramas.

Mientras tanto el DSP ha ido acumulando en un buffer los trozos de la cadena que ha ido

recibiendo a través del buzón que había reservado, y cuando recibe la trama marcada con el bit FIN activo, entiende que ahí acaba la cadena. A continuación libera el buzón de la petición 2, puesto que ya no van a llegar más tramas con ese identificador y envía una trama MODELO asociada a la petición 2 con el identificador del elemento y la cadena de caracteres completa terminada con el carácter ‘\0’.

Cuando la aplicación recibe la trama MODELO, extrae el dato solicitado y lo presenta

debidamente al usuario.


122

Escenario 4: Ejecución de un comando con respuesta en forma de serie de datos.

Fig. 3. 49 Monitorización de la temperatura

Se supone que la sesión ya está establecida y que el parámetro TMUESTREO del sensor

de temperatura está establecido a 2 segundos. El usuario pide monitorizar la temperatura a través de una de las acciones que la aplicación cliente le presenta. La aplicación accede al fichero de manejo del sensor de temperatura y lee la información de la acción correspondiente. En este fichero se le indica que deberá enviar el comando SDTS, que deberá recibir el comando DDTS, y deberá utilizar el comando DS para detener la serie, todos ellos aplicables en el ámbito del protocolo interno. El primer paso que lleva a cabo la aplicación es la reserva de un buzón para recibir el comando DDTS, para ello define la petición número 3, que tendrá validez mientras dure el proceso de monitorización de la temperatura, y envía una trama RESERVA indicando que los datos obtenidos se liguen al contexto de la petición 3. Además envía el identificador completo (Tipo de elemento, Comando, Número de elemento) del mensaje que espera recibir, especificando que el tipo de información que se espera es en forma de serie. Cuando esta trama llega al DSP, éste reserva uno de sus buzones libres y lo configura para recibir el tipo de tramas de protocolo interno que ha sido especificado, asociando este buzón a la petición 3.

La aplicación, siguiendo con las instrucciones del fichero de manejo, envía una trama

EJECUTAR en la que incluye el identificador completo de la trama de protocolo interno que quiere transmitir en la red CAN. El comando que va en el identificador es el comando SDTS, que solicita una serie de datos con el valor de la temperatura al sensor de temperatura en cuestión. Cuando este sensor de temperatura recibe la trama de protocolo interno, contesta automáticamente con el comando DDTS y añade como dato el valor de temperatura que registra en ese momento, que es un dato que sólo ocupa un byte (no pude ocupar más de 8. El DSP recibe esta trama por el buzón que había reservado y cuando esto sucede, se genera una trama RESPUESTA, en la que se introduce el dato de temperatura y la petición asociada para que la aplicación pueda determinar el contexto en el que se enmarca ese dato, especificando además que se trata de una serie de datos.

Cuando la aplicación recibe la trama RESPUESTA, extrae el dato solicitado y siguiendo

las especificaciones que sobre ese parámetro existen en el fichero de manejo, lo presenta debidamente al usuario.

Transcurrido el tiempo indicado en el parámetro TMUESTREO (en este caso vale 2

segundos) que reside en el sensor de temperatura, se desencadena la transmisión de otra trama de protocolo interno con el comando DDTS y el nuevo dato de temperatura actualizado. Esto vuelve a suceder de forma periódica hasta que el usuario decide detener la monitorización. Es en


123

este instante cuando la aplicación utiliza la acción cancelatoria y envía una trama EJECUTAR dirigida al sensor de temperatura con el comando DS. Cuando la trama llega al DSP, este desencapsula la trama de protocolo interno y hace llegar el comando DS hasta el sensor de temperatura que inmediatamente detiene la serie de datos.

Para no dejar buzones reservados, la aplicación genera automáticamente una trama

LIBERAR indicando la petición para que el DSP libere todos los buzones asociados a esa petición y recupere su estado inicial.

Escenario 5: Modificación de un parámetro de funcionamiento y desconexión

súbita.

Fig. 3. 50 Modificación de un parámetro de funcionamiento y desconexión súbita

Se supone que la sesión ya está establecida y que el parámetro TMUESTREO del sensor de temperatura está establecido a 5 segundos. En este caso el usuario quiere obtener el valor del parámetro de funcionamiento denominado TMUESTREO. La aplicación accede al fichero de manejo para recabar información acerca de dicho parámetro y saber de esta manera cómo tratarlo. Por el contrario, la aplicación no necesita extraer información acerca de ningún comando ya que el manejo de parámetros de funcionamiento y dependencia se tramita a través de comandos comunes y además la aplicación en realidad no necesita conocer los comandos de protocolo interno para obtener esta información ya que se limita a utilizar una orden específica: la trama de protocolo externo denominada LPARAM. La aplicación transmite por tanto esta trama indicando el identificador del elemento (exceptuando el comando) y asociándole un número de petición, en este caso el 2, que se mantendrá vigente mientras dure el proceso de solicitud del modelo del elemento. Junto con esto se especifica el número del parámetro TMUESTREO, que se trata de un parámetro de funcionamiento y el tipo de información, que en este caso se trata como valor puesto que es un dato numérico de 1 byte.

Cuando esta trama llega al DSP, éste reserva uno de sus buzones libres y lo configura

para recibir tramas con el identificador del elemento especificado pero con el comando común CCVP, y asocia este buzón a la petición 2. Además el propio DSP compone una trama de protocolo interno que contiene el identificador del elemento y el comando común CCLP, que significa “leer parámetro”.


124

Cuando este sensor de temperatura recibe la trama de protocolo interno, contesta automáticamente con el comando CCVP y añade como parámetro el valor del parámetro TMUESTREO, que en este caso es de 5 segundos. El DSP recibe esta trama y compone una trama de protocolo externo del tipo VPARAM que tiene los mismos parámetros que LPARAM que mandó la aplicación salvo que ahora se le adjunta como dato el valor del parámetro solicitado. Por otra parte el DSP libera el buzón que reservó puesto que ya no va a recibir más tramas con ese identificador.

A continuación el usuario solicita modificar dicho parámetro. Para ello la aplicación acude

al fichero de manejo para conocer el formato de dicho parámetro, poder pedírselo al usuario en el formato apropiado y poder validar el dato introducido por el usuario. Una vez que el usuario introduce el nuevo valor del parámetro, la aplicación inicia la transmisión de una trama APARAM con el nuevo valor, que en este caso es de 2 segundos. Cuando la trama llega al DSP, éste compone una trama de protocolo interno que contiene el identificador del elemento y el comando común CCAP, que significa “asignar parámetro”. El sensor de temperatura recoge esta trama y modifica el valor de su parámetro. De ahora en adelante el tiempo de muestreo de la temperatura será de 2 segundos. Nótese que modificar un parámetro de funcionamiento o dependencia no significa activar su funcionalidad, así por ejemplo asignar este valor al parámetro TMUESTREO no implica que el elemento inicie una serie de datos, para que eso ocurriera haría falta invocar el comando SDTS como se puede apreciar en la figura 3.50.

Los siguientes mensajes intercambiados que aparecen en la figura sirven para pedir la

monitorización de la temperatura, al igual que ocurría en el escenario anterior y por esta razón se omite la explicación de estos intercambios salvo en el último paso, donde ocurre una ruptura brusca de la conexión entre la aplicación cliente y el servidor (Rabbit).

Cuando hay una ruptura de la comunicación de este tipo, es posible, y en este caso

ocurre, que puede haber series de datos activas. Al cerrarse bruscamente la aplicación, ésta no tiene tiempo de enviar las tramas correspondientes a la acción cancelatoria y como el elemento maestro no conoce los comandos para detener esa serie de datos, no puede pararla, por consiguiente, se mantiene un tráfico inútil en la red CAN. Éste no es el único problema, sino que además habría buzones del DSP que seguirían reservados inútilmente. Para solucionar esto, cuando el Rabbit detecta una de estas interrupciones súbitas de la comunicación, hace uso de la trama de protocolo intermedio denominada LIBERARTODO que fuerza al DSP a liberar todos los buzones asociados a peticiones y hace que éste envíe una trama especial a la red CAN. Esta trama especial tiene como objetivo detener todas las series de datos de todos los elementos que actualmente estén activas eliminando de esta forma ese tráfico inútil. Para que este mensaje llegue a todos los elementos de la red, se transmite utilizando uno de los tipos de elemento reservados por el sistema que además tienen mayor prioridad. En concreto se trata del tipo de elemento denominado como M o Maestro. El número de elemento es 0 puesto que el elemento maestro es único en el sistema y este campo carece pues de sentido. Como comando se utiliza el comando DS, que debe ser entendido por todos los elementos. En nuestro caso, al ser recibido por el sensor de temperatura, éste entiende que debe detener inmediatamente la serie de datos que estaba transmitiendo, y así lo hace.


125

Escenario 6: Mecanismo de Plug&Play.

Fig. 3. 51 Mecanismo de Plug&Play

Tras un reset, el DSP carga la información del sistema que tiene almacenada en la

memoria EEPROM externa, transmite al Rabbit la información necesaria para su funcionamiento y por último comprueba si hay elementos nuevos. Para ello envía a la red CAN una trama con el identificador siguiente: como tipo de elemento utiliza el tipo denominado CA o Canal de Asignación, que se corresponde con uno de los valores reservados por el sistema y que tienen mayor prioridad. Utiliza el comando NUEVO?, que debe ser entendido por todos los elementos de la red. El número de elemento es 0 puesto que el canal de asignación es único en el sistema y este campo carece pues de sentido.

Esta trama es recibida por todos los nodos, y sólo contestan a ella los nuevos nodos o los

nodos registrados que tengan elementos nuevos. En este caso tenemos un nodo nuevo y asociado a ese nodo un nuevo sensor de temperatura.

Como el nodo es nuevo, no tiene asignado ningún número ni para él ni para el sensor de

temperatura que tiene a su cargo, por tanto no puede intervenir en el sistema y se dedica únicamente a escuchar el canal de asignación a la espera de que el maestro pregunte si hay elementos nuevos. Es en este momento cuando el nodo contesta con el identificador del canal


126

de asignación pero con el comando nuevo nodo y como parámetro utiliza un número aleatorio que le identificará provisionalmente hasta que el DSP le asigne un número de elemento definitivo.

Cuando el DSP recibe esta trama dentro de un intervalo de tiempo determinado (1

segundo) inicia el proceso de instalación del elemento. Como se trata de un nodo, le asigna un número de elemento que no esté siendo utilizado ya por otro nodo del sistema, cuando encuentra el número apropiado, se lo envía al nuevo nodo a través del canal de asignación junto con el mismo número aleatorio que envió el nodo que intenta ser instalado. A la recepción de la trama, el nuevo nodo asume el número que le ha asignado el DSP y lo guarda en memoria no volátil. Por su parte el DSP registra el nuevo nodo en su lista aunque desconoce el sector en el que se encuentra ubicado puesto que los elementos no pueden facilitar esta información. A continuación envía una trama NUEVO al Rabbit donde especifica el identificador del nuevo elemento. Como aún no se ha establecido una conexión con el usuario, el Rabbit deja pendiente este mensaje para cuando se conecte.

El DSP vuelve a enviar el comando NUEVO? en busca de nuevos elementos. En este

caso todavía hay un elemento por instalar, se trata del sensor de temperatura, y por eso el elemento contesta a través del canal de asignación con el comando NUEVOELEM añadiendo como parámetros un número aleatorio que le identificará provisionalmente hasta que el DSP le asigne un número definitivo, y además incluirá el número del nodo al que está asociado, ya que el DSP necesita registrar esta información en el caso de elementos que no sean nodos. El resto del proceso se desarrolla de manera análoga al proceso de instalación del nodo salvo que en vez de utilizar el comando ANUMNODO se utiliza el comando ANUMELEM. De nuevo el mensaje se queda en el Rabbit a la espera de que el usuario se conecte.

Mientras tanto el DSP vuelve a enviar el comando NUEVO? y tras esperar el intervalo de

tiempo que se mencionó antes, se da cuenta que no ha recibido contestación alguna y en ese momento entiende que ya no hay más elementos nuevos y que ha terminado el proceso de instalación.

Cuando el usuario establece conexión con el sistema, el Rabbit le transmite los mensajes

pendientes utilizando la trama NUEVO con el identificador del nuevo elemento registrado. Cuando la aplicación recibe esta trama, solicita automáticamente la marca y modelo del nuevo elemento. No se comentarán en detalle los intercambios para obtener esta información ya que son del mismo tipo que los que ocurrían en el escenario 3.

Una vez que la aplicación tiene la marca y el modelo del elemento nuevo, lo notifica al

usuario y le pide que indique el sector donde se encuentra ubicado el elemento y la ruta al fichero de manejo de ese elemento. Con esta información por un lado la aplicación actualiza su lista en la que relaciona los elementos con sus ficheros de manejo y por otra parte envía una trama ASIGSECTOR al sistema en la que asocia el elemento con el número de sector que ha especificado el usuario. A la recepción de esta trama, el DSP completa la información que le faltaba acerca del nuevo elemento y actualiza su lista de elementos registrados.

Nótese que siempre que el DSP modifica su lista de elementos registrados, lo refleja

inmediatamente en su memoria EEPROM externa. A continuación se repite el proceso para el sensor de temperatura, tras el cual finaliza el

proceso de plug&play.


127

Nota: es recomendable instalar los nuevos nodos de uno en uno para evitar posibles conflictos.

Escenario 7: Gestión de los números de teléfono para notificación de alarmas.

Fig. 3. 52 Gestión de números de teléfonos y notificación de alarmas

Los números de teléfonos son utilizados por el elemento de comunicación con el exterior

para enviar mensajes SMS con las alarmas. Dependiendo del tipo de alarma el sistema determina a qué números hay que enviar mensajes de alerta. Por regla general intenta mandar mensajes a los usuarios y a la policía en caso de detectar un intruso en la casa e intenta mandar mensajes a los usuarios y a los bomberos en caso de incendio. En este caso concreto se van a configurar números de teléfonos y se verá cómo actúa el sistema tras detectar un incendio.

En primer lugar, el usuario asigna el número de teléfono +34666777888 a la posición 1 de

la lista de teléfonos mediante la trama ANUMTEL. El número de teléfono debe estar expresado en su formato internacional con el signo ‘+’ todo ello como una cadena de caracteres. Se recuerda que la lista de teléfonos tenía la siguiente estructura:

Posición Descripción 1 Usuario 1 2 Usuario 2 3 Policía 4 Bomberos

Tabla 3. 18 Relación entre la posición de la lista y el número de teléfono


128

Cuando esta trama llega al Rabbit y al DSP actualiza sus respectivas tablas. En el caso

del DSP los cambios también se reflejan en la memoria EEPROM. A continuación el usuario solicita activar el teléfono de la posición 1 de la lista (Usuario1). Se recuerda que si un teléfono está desactivado, el sistema no le mandará mensajes SMS en caso de alarma. De nuevo esta trama actualiza las tablas del Rabbit y el DSP y los cambios se reflejan en la memoria EEPROM del elemento maestro. En el siguiente paso el usuario desea configurar la dirección del inmueble. Para ello utiliza la trama CONFIGDIR junto con la dirección en forma de cadena de caracteres. Al formar parte de la información general del sistema, los datos contenidos en la trama actualizan las listas del Rabbit y el DSP, guardándose los cambios en la memoria EEPROM.

Después el usuario solicita un número de teléfono, para ello indica la posición en la lista,

que en este caso (4) se refiere al teléfono de los bomberos. Para ello utiliza la trama SOLTEL indicando además un número de petición para que al devolver la información la aplicación pueda determinar el contexto en el que se enmarca la misma. Se asume que el teléfono de los bomberos era 8888. Ese es el número que devuelve el DSP mediante la trama TEL, asociado como no podía ser de otra forma a la petición 1. A continuación el usuario solicita la dirección almacenada, proceso que se desarrolla de manera análoga a la solicitud del número de teléfono, por lo que no se va a comentar en detalle. El último paso que lleva a cabo el usuario es desactivar el teléfono correspondiente a Usuario2.

Una vez terminada la configuración se detecta un incendio en la casa, por lo que el DSP

genera mensajes de alarma tanto a la red CAN como al exterior. En el caso de la red CAN, los mensajes se canalizan a través de uno de los identificadores reservados por el sistema, en concreto el de ALARMA, indicando el tipo de alarma. Todos los elementos de la red CAN deben estar preparados para recibir estos mensajes y actuar en consecuencia. Habrá elementos que no alteren su comportamiento y otros que sí lo hagan, así por ejemplo en caso de incendio un interruptor no hará nada mientras que un ventilador se parará automáticamente para no avivar las llamas. Por otra parte el DSP envía hacia el exterior la trama ALARMA, indicando el tipo de alarma, que en este caso es “Incendio”, y el sector donde se ha producido la incidencia. Cuando esta trama llega al Rabbit se desencadena la generación de mensajes SMS. Tal y como se desprende de los pasos anteriores, la situación es la siguiente:

- Están activados todos los teléfonos menos el correspondiente a Usuario2 - Estamos ante una alarma por incendio en el sector “cocina” - El teléfono de los bomberos es 8888 - El teléfono del Usuario1 es +34666777888 - La dirección del inmueble es “C/Torneo, 15 SEVILLA” Teniendo en cuenta estos datos, el Rabbit intentará mandar mensajes a los usuarios 1 y 2

y a los bomberos, puesto que se trata de un incendio, pero se dará cuenta que el usuario 2 está desactivado, por tanto envía mensajes únicamente al usuario1 y a los bomberos con el texto que se muestra en la figura.


129

Escenario 8: Gestión de sectores.

Fig. 3. 53 Gestión de sectores

Para borrar un sector, la aplicación utiliza la trama BORRARSECTOR indicando el número

de sector. Cuando esta trama llega al Rabbit y al DSP, éstos eliminan dicho sector de su lista y en el caso del DSP los cambios se guardan en la memoria EEPROM externa.

Para añadir un sector, la aplicación utiliza la trama NUEVOSECTOR indicando el número

de sector. Nótese que es la propia aplicación la que asigna el número de sector escogiendo un número que no esté siendo utilizado. Esta es la diferencia respecto a otros escenarios en los que era el DSP el que asignaba los números. Cuando esta trama llega al Rabbit y al DSP, éstos añaden dicho sector a su lista y en el caso del DSP los cambios se guardan en la memoria EEPROM externa.

3.7.5 NORMALIZACIÓN

Se podría pensar que la especificación del protocolo interno plantea problemas a la hora

de asignar valores a los nuevos tipos de elemento que surjan o a la hora de numerar los comandos disponibles para un elemento. Evidentemente todas las entidades que decidieran fabricar elementos para este sistema domótico tendrían que respetar y conocer las asignaciones hechas hasta el momento y a su vez deberían dar a conocer las nuevas asignaciones propuestas para sus nuevos tipos de elemento, consensuarlas con el resto de fabricantes e incluirlas en la lista de tipos de elemento existentes. Se hace necesario por tanto que exista una única entidad que velara por el cumplimiento de las normas existentes y asignara valores a los nuevos tipos de elemento que surjan en el futuro.

Este problema no es único de este sistema, sino que ocurre con bastante frecuencia en

otros ámbitos, lo que ha dado lugar a la aparición de ciertos organismos que regulan un estándar. Por ejemplo, en el caso del estándar IEEE 802.3, más conocido como Ethernet, existen direcciones MAC que deben ser únicas para que no haya conflicto en una red de este tipo, y el organismo encargado de asignar estas direcciones entre los fabricantes de tarjetas Ethernet es el mismo IEEE. Otro ejemplo de organismos normalizadores serían los encargados de gestionar los diferentes dominios de internet (.com, .es, .net, etc.). La existencia de estos organismos hace posible que tecleando una dirección URL desde cualquier ordenador conectado a Internet en cualquier parte del mundo, siempre se pueda acceder a la misma página.

A pesar de que no existe aún ninguna entidad de este tipo que normalice los sistemas

domóticos como el que se describe en este proyecto, ya se han realizado algunas asignaciones a los elementos incluidos en el prototipo del sistema que acompaña este proyecto. Por tanto, provisionalmente, sería el Departamento de Ingeniería Electrónica de la Universidad de Sevilla el responsable de asignar y gestionar los tipos de elemento.

capÍtulo 3. descripciÓn del...

Documents