capítulo 3. descripción del sistema

CAPÍTULO 3. DESCRIPCIÓN DEL SISTEMA
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
Análisis y aplicación de los buses de campo a la domótica
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:
53
Análisis y aplicación de los buses de campo a la domótica
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:
54
Análisis y aplicación de los buses de campo a la domótica
-
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
55
Análisis y aplicación de los buses de campo a la domótica
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 pulldown 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
56
Análisis y aplicación de los buses de campo a la domótica
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.
57
Análisis y aplicación de los buses de campo a la domótica
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
58
Análisis y aplicación de los buses de campo a la domótica
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
DTX
Tipo
Salida
DRX
Entrada
E33
Salida
Descripción
Línea de transmisión serie del DSP. Se conecta a la línea RRX de la placa
“Madriguera”
Línea de recepción serie del DSP. Se conecta a la línea RTX de la placa
“Madriguera”
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:
59
Análisis y aplicación de los buses de campo a la domótica
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.
60
Análisis y aplicación de los buses de campo a la domótica
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.
61
Análisis y aplicación de los buses de campo a la domótica
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.
62
Análisis y aplicación de los buses de campo a la domótica
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.
63
Análisis y aplicación de los buses de campo a la domótica
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”
64
Análisis y aplicación de los buses de campo a la domótica
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.
65
Análisis y aplicación de los buses de campo a la domótica
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
RTX
RRX
E33
Tipo
Salida
Entrada
Entrada
Descripción
Línea de transmisión serie del Rabbit
Línea de recepción serie del Rabbit
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
DCD
RD
TD
Pin del Rabbit
PD5
PC3 (Puerto serie C)
PC2 (Puerto serie C)
Tipo
Entrada
Entrada
Salida
Pin DB-9
1
2
3
66
Análisis y aplicación de los buses de campo a la domótica
DTR
GND
DSR
RTS
CTS
RI
PE0
PD4
PE1
PD3
PE4
Salida
Entrada
Salida
Entrada
Entrada
4
5
6
7
8
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.
67
Análisis y aplicación de los buses de campo a la domótica
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
0
0
1
1
SMODE1
0
1
0
1
Modo de arranque
Normal. El Rabbit ejecuta el programa cargado en la memoria Flash
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
68
Análisis y aplicación de los buses de campo a la domótica
Interruptor
SM0_ON
SM0_OFF
SM1_ON
SM1_OFF
Número
3
4
1
2
Función
Cuando se activa, SMODE0=1
Cuando se activa, SMODE0=0
Cuando se activa, SMODE1=1
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
69
Análisis y aplicación de los buses de campo a la domótica
Analizando este circuito se llega a la conclusión de que la frecuencia de corte es la
siguiente:
fP =
RP + R1
2πRP R1C
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
1
2
3
4
Pin del Rabbit
PB5
PB4
PB3
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:
70
Análisis y aplicación de los buses de campo a la domótica
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
71
Análisis y aplicación de los buses de campo a la domótica
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.
72
Análisis y aplicación de los buses de campo a la domótica
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
73
Análisis y aplicación de los buses de campo a la domótica
-
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:
74
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 25 Conectores analógicos
Señal
GND
Ax
VCC5
Pin asociado en el PIC
ANx
-
Descripción
Tierra del sistema
Entrada analógica
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.
75
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 26 Conectores digitales
Señal
D1
D2
D3
D4
D5
D6
D7
D8
D9
D10
D11
D12
D13
D14
Pin asociado del PIC
RC0
RC1
RC2
RC7
RC6
RC5
RC4
RC3
RB0
RB1
RB4
RB5
RB6
RB7
Función
E/S digital
E/S digital
E/S digital
E/S digital, RX canal serie asíncrono
E/S digital, TX canal serie asíncrono
E/S digital, salida de datos síncrona
E/S digital, entrada de datos síncrona
E/S digital, reloj para datos síncronos
E/S digital
E/S digital
E/S digital
E/S digital
E/S digital
E/S digital
Jumper
JP1
JP2
JP3
JP20
JP19
JP18
JP17
JP16
JP9
JP8
JP7
JP6
JP5
JP4
Conector
C1
C1
C1
C2
C2
C3
C3
C3
C5
C5
C5
C5
C5
C5
Tabla 3. 8 Descripción de las señales del bloque digital
76
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 27 Pines de selección de pull-up/pull-down para bloques de resistencias
Jumper de selección
JP21
JP23
JP22
JP24
Conector al que afecta
C1
C2
C3
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)
2)
3)
4)
5)
6)
Desconectar el nodo de la alimentación
Retirar los jumpers JP10, JP11, JP12, JP13, JP14 y JP15
Conectar el cable de programación al conector C6 y a la programadora JDM
Programar el PIC
Desconectar el cable de programación
Volver a colocar los jumpers que fueron retirados previamente.
77
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 28 Conector de programación y jumpers asociados
Pin
1
2
3
4
5
6
Señal
VSS
VPP
SDATA
SCLK
PGM
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
78
Análisis y aplicación de los buses de campo a la domótica
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
79
Análisis y aplicación de los buses de campo a la domótica
-
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
80
Análisis y aplicación de los buses de campo a la domótica
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
Controlador de luz
Ventilador
Sensores
Sensor de temperatura basado en termopar
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:
81
2
A
3
Análisis y aplicación de los buses de campo a la domótica
1
2
3
A
1
Fig. 3. 32 Esquemático del circuito de adaptación del termopar
Analizando este circuito se desprende la siguiente ecuación:
⎛ R2 ⎞
Vout = Vref + Vtp⎜ 1 +
⎟
⎝
R1 ⎠
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:
Vref =
VCC5 ⋅ R4
R3 + R4
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
82
Análisis y aplicación de los buses de campo a la domótica
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:
Vout =
VCC5 ⋅ R1
R1 + RFOTO
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.
83
Análisis y aplicación de los buses de campo a la domótica
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
3
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
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:
84
Análisis y aplicación de los buses de campo a la domótica
-
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
3
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
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.
85
Análisis y aplicación de los buses de campo a la domótica
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
86
Análisis y aplicación de los buses de campo a la domótica
-
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.
87
Análisis y aplicación de los buses de campo a la domótica
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:
88
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 41 Conector de audio
Pin
1
2
3
4
Señal
MICN
BEARN
BEARP
MICP
Sentido
Entrada
Salida
Salida
Entrada
Descripción
Entrada negativa del micrófono
Salida negativa del auricular
Salida positiva del auricular
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
1
2
3
Señal
VCC
HR_IN
Sentido
Entrada
4
TO_IN
Entrada
5
6
GND
Entrada
Entrada
Límites
Descripción
De 5 a 32 V Alimentación
No conectada
De –0,5 a Apaga el módem si está a nivel alto entre 1 y 2
32V
segundos y resetea el módem si está a nivel
alto más de 3,5 segundos.
De –0,5 a Enciende el módem si está a nivel alto más de
32V
0,2 segundos
No conectada
Tierra
Tabla 3. 13 Descripción de las señales del conector de alimentación
89
Análisis y aplicación de los buses de campo a la domótica
3.5.2 MANEJO DEL MÓDEM
[20].
Como ya se ha mencionado anteriormente, el módem se controla mediante comandos AT
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á.
90
Análisis y aplicación de los buses de campo a la domótica
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”
91
Análisis y aplicación de los buses de campo a la domótica
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.
92
Análisis y aplicación de los buses de campo a la domótica
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.
93
Análisis y aplicación de los buses de campo a la domótica
Fig. 3. 44 Imagen de la programadora JDM
Pin
1
2
3
4
5
6
Señal
VSS
VPP
SDATA
SCLK
PGM
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:
94
Análisis y aplicación de los buses de campo a la domótica
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
11 bits
COMANDO
10 bits
NÚMERO DE ELEMENTO
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
Sensor de temperatura
Sensor de proximidad
Actuador para luces
Valor
280h
300h
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
95
Análisis y aplicación de los buses de campo a la domótica
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
96
Análisis y aplicación de los buses de campo a la domótica
-
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
ACTIVARTEL
ALARMA
ANUMTEL
APARAM
ASIGSECTOR
BORRARSECTOR
CONFIGDIR
DESACTIVARTEL
DIR
EJECUTAR
ENVIOCONTRA
ERROR
EXPULSAR
INFOSIS
LIBERAR
LPARAM
MARCA
MODELO
NUEVACONTRA
NUEVO
NUEVOSECTOR
NUMPET
OK
PEDIRMARCA
PEDIRMODELO
RESERVA
RESPUESTA
SOLDIR
SOLINFOSIS
SOLNUMPET
SOLTEL
TEL
VPARAM
LIBERARTODO
INI
DESCRIPCIÓN
SENTIDO *
Activar un número de teléfono
U>>S
Alarma
S>>U
Añadir un número de teléfono
U>>S
Asignar
un
valor
a
un
parámetro
de
U>>S
funcionamiento/dependencia
Asignar un elemento a un sector
U>>S
Borrar un sector
U>>S
Configurar la dirección del inmueble
U>>S
Desactivar un número de teléfono
U>>S
Dirección del inmueble almacenada
S>>U
Ejecución de un comando de protocolo interno
U>>S
Envío de la contraseña
U>>S
Error
S>>U
Expulsa un elemento del registro del sistema
U>>S
Información del sistema almacenada
S>>U
Liberar el buzón asociado a una petición
U>>S
Solicitud de lectura de un parámetro de func./dependencia
U>>S
Marca del elemento
S>>U
Modelo del elemento
S>>U
Asignación de nueva contraseña
U>>S
Aviso de nuevos elementos registrados
S>>U
Asignación de nuevo sector
U>>S
Devuelve un nuevo número de petición
S>>U
OK. (Contraseña correcta)
S>>U
Solicitud de lectura de la marca del elemento
U>>S
Solicitud de lectura del modelo del elemento
U>>S
Reserva de un buzón CAN de recepción
U>>S
Respuesta a una petición de datos
S>>U
Solicitud de lectura de la dirección del inmueble
U>>S
Solicitud de información general del sistema
U>>S
Solicita un nuevo número de petición
U>>S
Solicitud de lectura de un número de teléfono
U>>S
Número de teléfono almacenado
S>>U
Valor almacenado de un parámetro de func./dependencia
S>>U
Libera todos los recursos del maestro
C>>M
Información para inicializar el elemento de comunicación
M>>C
97
NUM
10
1
11
12
13
14
15
16
17
18
19
20
39
21
22
23
24
25
26
27
28
40
29
30
31
32
33
34
35
41
36
37
38
91
90
Análisis y aplicación de los buses de campo a la domótica
CIP
Modificación de la dirección IP
C>>M
(*) 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
8
ORDEN
(Resto de la trama)
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
8
POSICION
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
98
92
Análisis y aplicación de los buses de campo a la domótica
ALARMA
Estructura:
ORDEN
TIPO ALARMA
8
8
SECTOR
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:
1 Usuario1
2 Usuario2
3 Policía
4 Bomberos
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
8
TIPOINFO
8
TIPOELEM
NUMELEM
DEP/FUN
NUMPARAM
NBYTES
DATOS
16 (11LSB)
8
8
8
8
Nbytes x 8
99
Análisis y aplicación de los buses de campo a la domótica
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
100
Análisis y aplicación de los buses de campo a la domótica
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:
1 Usuario1
2 Usuario2
3 Policía
4 Bomberos
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:
101
Análisis y aplicación de los buses de campo a la domótica
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
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.
COMANDO
Número del comando a ejecutar sobre el elemento especificado. Sólo se tienen en
cuenta los 10 bits menos significativos
NUMELEM
Número entero que indica el número de elemento al que va dirigido el mensaje.
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
102
Análisis y aplicación de los buses de campo a la domótica
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.
NUMELEM
Número entero que indica el número de elemento al que va dirigido el mensaje.
INFOSIS
Estructura:
ORDEN
NELEM
ELEM 1
8
8
40
…
ELEM n
NSECT
SECTOR 1 … SECTOR m
40
8
-
-
ELEM x
TIPO
NUM
NODO
SECTOR
16 (11 LSB)
8
8
8
SECTOR y
NUM
NB
DESCR
8
8
8 x NB
103
Análisis y aplicación de los buses de campo a la domótica
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
8
PETICION
8
TIPOINFO
8
TIPOELEM
NUMELEM
DEP/FUN
NUMPARAM
16 (11LSB)
8
8
8
104
Análisis y aplicación de los buses de campo a la domótica
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
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
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
105
Análisis y aplicación de los buses de campo a la domótica
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
106
Análisis y aplicación de los buses de campo a la domótica
NBM
Número entero que indica el número del nuevo sector.
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.
107
Análisis y aplicación de los buses de campo a la domótica
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:
0 Sin parámetro
1 Valor
2 Bloque
3 Serie
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.
108
Análisis y aplicación de los buses de campo a la domótica
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
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
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
109
Análisis y aplicación de los buses de campo a la domótica
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
110
Análisis y aplicación de los buses de campo a la domótica
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
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
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
111
Análisis y aplicación de los buses de campo a la domótica
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
8
32
32
32
NB1 x 8
8
… NB4
8
TEL4
ACT
NBC
CONTRA NBD
DIR
NSECT
NB4 x 8
8
8
NBC x 8
8 x NBD
8
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
112
Análisis y aplicación de los buses de campo a la domótica
ACT
NBC
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”
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
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:
113
Análisis y aplicación de los buses de campo a la domótica
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
114
Análisis y aplicación de los buses de campo a la domótica
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
115
Análisis y aplicación de los buses de campo a la domótica
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
movimiento detecta reposo hasta que se apaga la luz
TEDR
de
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:
116
Análisis y aplicación de los buses de campo a la domótica
- 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
117
Análisis y aplicación de los buses de campo a la domótica
- 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
118
Análisis y aplicación de los buses de campo a la domótica
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
119
Análisis y aplicación de los buses de campo a la domótica
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.
120
Análisis y aplicación de los buses de campo a la domótica
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.
121
Análisis y aplicación de los buses de campo a la domótica
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
122
Análisis y aplicación de los buses de campo a la domótica
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”.
123
Análisis y aplicación de los buses de campo a la domótica
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.
124
Análisis y aplicación de los buses de campo a la domótica
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
125
Análisis y aplicación de los buses de campo a la domótica
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.
126
Análisis y aplicación de los buses de campo a la domótica
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
1
2
3
4
Descripción
Usuario 1
Usuario 2
Policía
Bomberos
Tabla 3. 18 Relación entre la posición de la lista y el número de teléfono
127
Análisis y aplicación de los buses de campo a la domótica
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.
128
Análisis y aplicación de los buses de campo a la domótica
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.
129