CAN

PROTOTIPO DE SISTEMA DOMÓTICO UTILIZANDO BUS
CAN
Palabras clave
Bus de campo, domótica, CAN, DSP, sensor, actuador, Ethernet, PIC,
protocolo,GSM/GPRS
Introducción
El aumento en la complejidad de los sistemas de control y en especial el desarrollo
del control distribuido exigen sistemas de comunicación adecuados a las necesidades de
éstos. Esta exigencia junto a la necesidad por parte de los usuarios de sistemas de
control abiertos y a la evolución de las tecnologías de comunicación propiciaron la
aparición de los buses de campo. Aunque inicialmente los buses de campo fueron
diseñados para la industria, algunos de ellos se han extendido a otros campos de
aplicación debido fundamentalmente a las ventajas que ofrecen frente a los sistemas
tradicionales1.
Con la intención de aprovechar estas ventajas, en el Departamento de Ingeniería
Electrónica de la Universidad de Sevilla hemos desarrollado un sistema de domótica
articulado en torno a una red de bus CAN y protocolos para la comunicación de los
dispositivos que componen el mismo.
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.
Existen varios buses de campo que se han venido utilizando en domótica desde
hace algunos años. Tal es el caso de X10, EHS, BatiBUS o Lonworks.
X10 es un estándar que aprovecha la instalación eléctrica de la casa para controlar
dispositivos. Utiliza ráfagas de 120 KHz en los cruces por cero de la señal de la red
eléctrica, esto supone una velocidad de transmisión de 50 bits/s. A pesar de la facilidad
para instalar este sistema, su velocidad es claramente insuficiente y está muy recortado
en prestaciones.
“ANALISIS DEL ESTADO DEL ARTE DE LOS BUSES DE CAMPO APLICADOS AL CONTROL
DE PROCESOS INDUSTRIALES” Héctor Kaschel C., Ernesto Pinto L.
1
En el caso de EHS, la información se transmite también por la red eléctrica o por
un cable de pares separado utilizando una modulación FSK. Las velocidades que se
consiguen son del orden de los 2400 bits/s.
BatiBUS por su parte utiliza una técnica de acceso al medio similar a la de CAN
(CSMA-CA) pero sólo alcanza una velocidad de 4800 bits/s.
Lonworks sí puede entenderse como un bus de campo de altas prestaciones.
Permite la interconexión de subredes de dispositivos, soporta múltiples medios de
transmisión y alcanza velocidades aceptables (Hasta 1,25 Mbit/s). Aunque Echelon, la
empresa que lo diseñó, se empeña en decir que es un estándar abierto, la realidad
demuestra que sólo se puede operar en este bus con unos microcontroladores registrados
por Echelon denominados “Neuron Chip”. Lonworks permite tener redes fiables y
robustas pero por otro lado resultan ser caras y complejas.
CAN reúne muchas de las ventajas que tienen el resto de buses de campo bajo un
estándar verdaderamente abierto, sencillo y barato que permite una mayor libertad a la
hora de definir los protocolos de las capas superiores. Esto junto con las características
que se describen a continuación fue lo que nos impulsó a escoger CAN como soporte
para las comunicaciones en el interior del sistema.
CAN (Contoller Area Network)
CAN es un bus de campo inventado por Bosch ampliamente usado en automoción.
Consta únicamente de dos líneas sobre las que se transmiten los datos en forma
diferencial con velocidades de hasta 1 Mbit/s. De aquí se desprende la primera ventaja,
la simplicidad en el cableado.
Las dos características fundamentales de CAN son2:
-
-
2
En el nivel de enlace, el protocolo de CAN no utiliza los identificadores como
direcciones de los nodos de la red sino que éstos indican el tipo de contenido
del mensaje. Por ejemplo: podríamos asignar un identificador para los datos de
temperatura, otro para los de velocidad, etc. De esta manera se pueden
establecer comunicaciones punto a multipunto ya que sólo los nodos a los que
interese el mensaje lo recibirán.
El tipo de acceso al medio es basado en contienda pero con la particularidad de
que no se desperdicia tiempo, debido a que las colisiones se resuelven
mediante un arbitraje de bits en el que gana el nodo con más prioridad sin que
esto suponga la modificación de ninguno de los bits que este nodo ha
transmitido. Esto es algo parecido a lo que ocurre en un canal D de un acceso
RDSI.
“CAN SPECIFICATION VERSION 2.0” Bosch. http://www.can.bosch.com/docu/can2spec.pdf
Topología del sistema
Módem
GSM/GPRS
ELEMENTO DE
COMUNICACIÓN
CON EL EXTERIOR
RED
GSM/GPRS
ELEMENTO
MAESTRO
BUS CAN
PASARELA
GPRS
Ethernet
APLICACIÓN
DE CONTROL
Internet
M
A
Q
U
E
T
A
NODO
NODO
Figura 1. Esquema del sistema
La figura anterior muestra la disposición de los elementos del sistema. En él
podemos destacar el elemento maestro, que se encarga del control del sistema. Este
elemento está constituido por un DSP de Texas Instruments del tipo TMS320F2812 3. El
elemento maestro se encarga entre otras cosas de:
-
-
3
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 y contraseñas para el servidor, números de teléfono a
los que enviar las alarmas, etc. Para ello dispone de una memoria EEPROM.
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 correspondientes.
http://focus.ti.com/docs/prod/folders/print/tms320f2812.html
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.
Otro de los elementos destacados del sistema es el Elemento de Comunicación con
el Exterior. Se trata básicamente de un módulo RCM22004, que contiene un procesador
Rabbit 2000. Este módulo está preparado para ser conectado en redes Ethernet
10/100BaseT, razón fundamental por la que escogimos este módulo para desempeñar
las tareas de comunicación con el exterior. Este módulo controla además el módem
GSM/GPRS GM29 de Sony-Ericsson5 a través de uno de sus puertos serie y está
permanentemente comunicado por otro de sus puertos serie con el elemento maestro. El
software que se ha creado para este módulo se encarga principalmente de hacer las
veces de servidor unificado para el acceso remoto. De esta manera el mismo servidor da
acceso al sistema tanto si el usuario utiliza un ordenador conectado a Internet como si lo
hace a través de un terminal móvil GPRS. El módulo RCM2200 está montado sobre una
placa base que ha sido creada al efecto puesto que el módulo por sí solo no puede
funcionar. Esta placa ha sido diseñada de acuerdo con las funciones que desempeña en
el sistema pero además sirve de sistema de desarrollo para el Rabbit 2000 si se utiliza
por separado.
El módem GSM/GPRS se encarga básicamente de canalizar los mensajes de
alarma a través de SMSs al usuario y al servicio de emergencias correspondiente. Se ha
optado por utilizar SMSs para enviar las alarmas debido a que su recepción es casi
instantánea.
Los elementos sensores y actuadores se agrupan en nodos. En cada nodo puede
haber uno o más actuadores o sensores que pueden ser de diferentes tipos y que pueden
estar ubicados en distintos sectores o habitaciones. Los nodos que han sido
implementados en el sistema contienen un microcontrolador PIC18F2486 sobre una
placa con circuitos de acondicionamiento de señal para los sensores y actuadores que
tiene a su cargo. Esta familia de microcontroladores PIC de Microchip es adecuada
debido a que disponen de líneas de entrada analógica con convertidores analógicodigital y además tienen un controlador CAN. Aunque estos procesadores no tienen una
gran potencia de cálculo, cumplen de sobra los requisitos que se necesitan para manejar
sensores de temperatura, de luz, de proximidad, etc. Además estos procesadores
incorporan una pequeña memoria EEPROM para datos en los que se pueden guardar los
identificadores de los elementos sensores y actuadores que controla.
Los sensores que se han instalado en la maqueta han sido de tres tipos:
-
Sensores de temperatura. Basados en termopares de tipo K
Sensor de proximidad por ultrasonidos.
Sensor de luminosidad. Basado en fotorresistencia
Los actuadores que se han instalado en la maqueta han sido de tres tipos:
4
http://www.rabbitsemiconductor.com/products/rcm2200/index.shtml
http://www.sonyericsson.com/downloads/GM28%20Datasheet%20R1C.pdf
6
http://ww1.microchip.com/downloads/en/DeviceDoc/41159d.pdf
5
-
Luces.
Ventilador.
Interruptor manual para controlar la iluminación.
Toda la instalación se ha hecho sobre una maqueta desmontable creada al efecto y
con una estructura adecuada al sistema que alberga.
Protocolos
Para coordinar los elementos del sistema se han diseñado dos protocolos, uno para
la red interna de bus CAN al que hemos llamado protocolo interno y otro para la
comunicación entre el servidor y la aplicación cliente sobre Internet al que hemos
llamado protocolo externo.
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
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 con identificador de
mayor valor. Por este motivo, se han reservado los valores del 0h al 28h 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
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 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 2 y en el campo de datos envía un byte en el que codifica el valor de la
temperatura medida en grados celsius.
El campo ‘Número de elemento’ sirve para identificar al elemento que origina el
mensaje o al que va destinado si fuera necesario. 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.
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. La aplicación para terminales móviles está 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 básicos.
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 nodo 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.
Instalación de nuevos nodos
Cuando un nuevo nodo se inserta en la red, envía automáticamente una petición
para que el elemento maestro del sistema le asigne un número de nodo y números de
elementos para los distintos sensores y actuadores que tenga a su cargo. Una vez que el
elemento maestro le asigna los números, el nodo los guarda en memoria no volátil. Por
su parte, el elemento maestro también registra los nuevos elementos en su memoria
EEPROM. Por cada elemento conectado, el maestro guarda los siguientes parámetros:
-
Nodo al que pertenece
Número de elemento
Tipo de elemento
Sector donde se encuentra ubicado
Evidentemente, los nodos por si solos no pueden facilitar el último parámetro al
maestro. El parámetro sector se refiere a la zona de la casa donde se encuentra el
elemento. Por comodidad, en el prototipo se han hecho coincidir los sectores con las
habitaciones de la maqueta. El parámetro sector debe pues proporcionarlo el usuario a
través de la aplicación cliente. Cuando hay elementos pendientes de este parámetro, el
maestro lo indica al elemento de comunicación con el exterior para que este a su vez lo
notifique al usuario en cuanto éste se conecte al sistema.
Control de elementos
Para un correcto comportamiento de los elementos, éstos pueden requerir que el
usuario le especifique una serie de parámetros. Así por ejemplo un sensor de
temperatura puede tener la funcionalidad de termostato siempre que le asignemos un
valor superior y otro inferior. Para ello, los nodos deben tener la capacidad de retener al
menos en memoria RAM dichos parámetros. Se podrían almacenar también en memoria
no volátil si fuera necesario aunque no es recomendable puesto que estos parámetros
pueden variar muchas veces y las memorias no volátiles como las EEPROM o Flash
pueden programarse un número limitado de veces. Además estas operaciones están
sujetas a la disponibilidad de este tipo de memoria en los nodos. En el caso de los nodos
implementados en el prototipo, sólo se dispone de una memoria EEPROM de datos de
256 bytes.
Estos parámetros se clasifican en dos tipos: parámetros de funcionamiento y de
dependencia.
Los parámetros de funcionamiento normalmente almacenan valores que afectan al
funcionamiento general del elemento. Volviendo al ejemplo anterior, los parámetros
límite superior y límite inferior serían parámetros de funcionamiento. Hay que destacar
que cargar un valor en un parámetro no implica su uso, esto es, si cargamos un valor en
el parámetro límite superior, el sensor de temperatura no se va a comportar como un
termostato a menos que le enviemos el correspondiente comando para que active el
modo termostato.
Los parámetros de dependencia sirven para especificar qué elementos van a influir
en el comportamiento del sistema. Esto es muy útil cuando tenemos elementos que
dependen de la información que proporcionen otros como por ejemplo el ventilador, que
dependerá del dato de temperatura que proporcione algún elemento sensor de su sector.
Si el valor de temperatura es superior a un límite que previamente se ha especificado
como parámetro de funcionamiento, el ventilador se pondrá en marcha. El nodo que
controla el ventilador deberá reservar un espacio para el parámetro de dependencia en el
que almacenará el número de elemento del sensor de temperatura que le haya asociado
el usuario. Durante su funcionamiento deberá recoger los datos de temperatura que
envíe dicho sensor y comprobarlos para actuar en consecuencia.
Futuras líneas de trabajo
La expansión natural del sistema sería de cara a aumentar el tipo de sensores y
actuadores. En esta línea sería interesante abordar el diseño de controladores para los
electrodomésticos más usuales.
También sería muy interesante trabajar en dispositivos de seguridad y
televigilancia. Así por ejemplo podrían integrarse webcams en el sistema para poder
tener vigilada la casa en todo momento a través de Internet.
Otra línea de trabajo podría ser la mejora de las aplicaciones de control para PC y
para terminales móviles.
Bibliografía



http://www.casadomo.com/canal_domotica.asp?TextType=1100
“CAN Specification Version 2.0” Bosch
http://www.can.bosch.com/docu/can2spec.pdf
“ANALISIS DEL ESTADO DEL ARTE DE LOS BUSES DE CAMPO
APLICADOS AL CONTROL DE PROCESOS INDUSTRIALES” Héctor
Kaschel C., Ernesto Pinto L.