Software para un sistema domótico basado en CAN
Full text
UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA PROYECTO FINAL DE CARRERA TÍTULO: Software para un sistema domótico basado en CAN AUTOR: Salvador Arnal Julián DIRECTOR: Lenin Guillermo Lemus Zúñiga FECHA: Noviembre - 2010 TITULACIÓN: Ingeniería Informática
Software para un sistema domótico basado en CAN Salvador Arnal Julián - II -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - III - DOMCAN DOMCANDOMCAN DOMCAN Software para un sistema Domótico basado en CAN
Software para un sistema domótico basado en CAN Salvador Arnal Julián - IV -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - V - Agradecimientos: A Ella .
Software para un sistema domótico basado en CAN Salvador Arnal Julián - VI -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - VII - I ÍNDICE I ÍNDICE .................................................................................................................................................. VII II ÍNDICE DE FIGURAS ......................................................................................................................XI III ÍNDICE DE TABLAS .....................................................................................................................XIII CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS ................................................................................... 1 1.1. M OTIVACIÓN ...................................................................................................................................... 1 1.2. O BJETIVOS DEL PFC........................................................................................................................... 1 CAPÍTULO 2. PLANTEAMIENTO INICIAL .......................................................................................... 3 2.1. E L N ODO H ARDWARE ......................................................................................................................... 3 2.1.1. Chipset ..................................................................................................................................... 4 2.1.2. Características Generales: ...................................................................................................... 6 2.2. L A D OMÓTICA .................................................................................................................................... 6 2.2.1. Dispositivos.............................................................................................................................. 6 2.2.2. La Arquitectura ........................................................................................................................ 8 2.3. E L B US DE C OMUNICACIONES CAN................................................................................................... 9 2.3.1. Características principales.................................................................................................... 10 2.3.2. Máscaras y Filtros ................................................................................................................. 12 CAPÍTULO 3. HERRAMIENTAS EMPLEADAS .................................................................................. 15 3.1. E NTRONO DE PROGRAMACIÓN M IKRO C........................................................................................... 15 3.2. E NTORNO DE PROGRAMACIÓN V ISUAL S TUDIO 2005 E XPRESS ........................................................ 17 3.3. P ROGRAMADOR PIC’ S ...................................................................................................................... 18 3.4. P ASARELA RS232/CAN.................................................................................................................... 19 CAPÍTULO 4. DIAGRAMAS UML ......................................................................................................... 21 4.1. D IAGRAMA DE DOMINIO ................................................................................................................... 21 4.2. D IAGRAMA DE DESPLIEGUE .............................................................................................................. 22 4.3. D IAGRAMA DE SECUENCIA ............................................................................................................... 23 4.4. D IAGRAMAS DE E STADOS ................................................................................................................. 24 CAPÍTULO 5. APLICACIÓN DE ADMINISTRACIÓN ....................................................................... 25 5.1. E STRUCTURA DE LA INTERFAZ .......................................................................................................... 25 5.1.1. Barra de Menús...................................................................................................................... 26 5.1.2. Barra de herramientas........................................................................................................... 26 5.1.3. Área de dibujo........................................................................................................................ 27 5.1.4. Árbol de Elementos ................................................................................................................ 27 5.1.5. Tabla de propiedades ............................................................................................................. 28 5.2. U SO DE LA APLICACIÓN .................................................................................................................... 28 5.2.1. Crear Muros........................................................................................................................... 28 5.2.2. Crear Nodos........................................................................................................................... 29 5.2.3. Crear Pulsadores ................................................................................................................... 30 5.2.4. Crear Dispositivos ................................................................................................................. 31 5.2.5. Crear Funciones..................................................................................................................... 31 5.2.6. Crear Acciones....................................................................................................................... 33 5.3. P ROGRAMACIÓN DE LOS N ODOS ....................................................................................................... 34
Software para un sistema domótico basado en CAN Salvador Arnal Julián - VIII - CAPÍTULO 6. FIRMWARE DE LA PASARELA ................................................................................... 35 CAPÍTULO 7. FIRMWARE DEL NODO ................................................................................................ 37 7.1. D IAGRAMA DE FLUJO ........................................................................................................................ 37 7.2. D IRECCIONAMIENTO MAC............................................................................................................... 38 7.3. F UNCIONES Y A CCIONES ................................................................................................................... 38 7.4. D ISTRIBUCIÓN DE LA MEMORIA ........................................................................................................ 40 7.4.1. Área de programa .................................................................................................................. 40 7.4.2. Área de configuración............................................................................................................ 40 7.4.3. Área de Acciones.................................................................................................................... 41 7.4.4. Área de Funciones.................................................................................................................. 41 CAPÍTULO 8. CATÁLOGO DE MENSAJES ......................................................................................... 43 8.1. E STRUCTURA GENERAL DE LOS MENSAJES ........................................................................................ 43 8.2. D IÁLOGOS DE C ONFIGURACIÓN ........................................................................................................ 43 8.2.1. Mensaje C_MAC_PETICION ................................................................................................ 44 8.2.2. Mensaje C_MAC_ACK .......................................................................................................... 44 8.2.3. Mensaje C_ACCION_LOCAL ............................................................................................... 44 8.2.4. Mensaje C_ACCION_REMOTA ............................................................................................ 45 8.2.5. Mensaje C_FUNCION........................................................................................................... 46 8.2.6. Mensaje C_BORRAR_FUNCIONES...................................................................................... 46 8.2.7. Mensaje C_BORRAR_ACCIONES ........................................................................................ 46 8.3. D IÁLOGOS DE A DMINISTRACIÓN ...................................................................................................... 47 8.3.1. Mensaje A_ESTADO_PETICION .......................................................................................... 47 8.3.2. Mensaje A_ESTADO_ACK .................................................................................................... 47 8.3.3. Mensaje A_RESET ................................................................................................................. 48 8.3.4. Mensaje A_PING_PETICION................................................................................................ 48 8.3.5. Mensaje A_PING_ACK.......................................................................................................... 48 8.4. D IÁLOGOS DE F UNCIONAMIENTO ..................................................................................................... 49 8.4.1. Mensaje F_FUNCION ........................................................................................................... 49 CAPÍTULO 9. CONCLUSIONES............................................................................................................. 51 9.1. F UTURAS LÍNEAS DE TRABAJO .......................................................................................................... 51 9.2. V ALORACIÓN P ERSONAL .................................................................................................................. 52 CAPÍTULO 10. BIBLIOGRAFIA............................................................................................................. 53 ANEXO A : BUS CAN............................................................................................................................ 55 A.1 O RÍGENES Y ARQUITECTURA DE CAPAS ............................................................................................. 55 A.1.1 Capa física ............................................................................................................................. 55 A.1.2 Capa de enlace de datos ........................................................................................................ 58 A.2 E STRUCTURA DE UN NODO CAN ...................................................................................................... 59 A.3 F ORMATO DE CODIFICACIÓN Y SINCRONIZACIÓN DE DATOS .............................................................. 61 A.4 T RAMAS ........................................................................................................................................... 62 A.4.1 Tipo de tramas........................................................................................................................ 62 A.4.2 Trama de datos....................................................................................................................... 63 A.4.3 Trama remota (Remote Frame).............................................................................................. 65 A.4.4 Trama de error....................................................................................................................... 66 A.4.5 Trama de sobrecarga.............................................................................................................. 68 A.4.6 Espaciado entre tramas.......................................................................................................... 68 A.5 A CCESO MÚLTIPLE Y ARBITRAJE DE ACCESO AL BUS ......................................................................... 69 A.6 D ETECCIÓN DE E RRORES .................................................................................................................. 72 A.6.1 Detección de errores .............................................................................................................. 72 A.6.2 Aislamiento de nodos defectuosos.......................................................................................... 73
Software para un sistema domótico basado en CAN Salvador Arnal Julián - IX - A.7 A CCESO MÚLTIPLE Y ARBITRAJE DE ACCESO AL BUS ......................................................................... 75 A.7.1 Acoplamiento de unidades de control .................................................................................... 76 A.7.2 Diagnóstico............................................................................................................................ 78 A.8 E SPECIFICACIONES ........................................................................................................................... 79 A.9 I MPLEMENTACIONES ......................................................................................................................... 80 A.9.1 Stand-Alone CAN Controller.................................................................................................. 80 A.9.2 Integrated CAN Controller..................................................................................................... 81 A.9.3 Single-chip CAN Node ........................................................................................................... 81 ANEXO B : CÓDIGO FUENTE ........................................................................................................... 83 ANEXO C : PALABRAS CLAVE.......................................................................................................... 91
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 2 -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 3 - CAPÍTULO 2. PLANTEAMIENTO INICIAL 2.1. El Nodo Hardware El nodo hardware fue desarrollado por Pere Joan Antoni Chordá en su Proyecto Final de Carrera [1]. Uno de los objetivos del diseño era que se pudiera instalar dentro de una caja estándar de conexiones de una vivienda, de ahí su reducido tamaño. Figura 1: Nodo Hardware El coste para una tirada de 1000 unidades seria de 10.42 € por nodo, muy por debajo de cualquier solución actual que se encuentre en el mercado.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 4 - 2.1.1. Chipset El chipset del nodo está formado por dos circuitos integrados: Un microcontrolador PIC18F2580 con las siguientes características: Figura 2: Datasheet PIC18F2580
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 5 - Un transceiver MCP2551: Figura 4: Datasheet MCP2551 (Parte 2) Figura 3 : Datasheet MCP2551 (Parte 1)
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 6 - 2.1.2. Características Generales: • Entradas analógicas: 8 entradas para conectar sensores analógicos. Como por ejemplo sensores de iluminación y temperatura. • Entradas digitales: 8 conexiones para señales de entrada con dos estados, como por ejemplo pulsadores o sensores con salida todo/nada. • Salidas digitales: 8 conexiones para activar y desactivar actuadores, como por ejemplo relés, triacs o dimmers. • Salidas analógicas: 8 conexiones para controlar actuadores, con entradas 0~10Vcc ó 4~20mA. • Puerto para bus CAN: un puerto de comunicación entre nodos. 2.2. La Domótica Según el diccionario de la Real Academia Española (RAE) el término domótica proviene de la unión de la palabra “domus” (que significa “casa” en latín) y el sufijo “- tica” (esta terminación remite a “automática”, y hoy en general induce al significado de "gestión por medios informáticos"). Etimológicamente lo que se entiende por domótica es el conjunto de sistemas capaces de automatizar y controlar las diferentes instalaciones de una vivienda. Los conceptos de automatización y control se asocian al encendido, apagado, apertura, cierre y regulación de aparatos y sistemas de instalaciones eléctricas. En resumen se podría definir como la integración de la tecnología en el diseño inteligente de un recinto, ya sea una vivienda o no. 2.2.1. Dispositivos La extensión de una solución domótica puede variar desde un único dispositivo que realiza una sola acción, hasta amplios sistemas que controlan prácticamente todas las instalaciones dentro de la vivienda. Los distintos dispositivos de un sistema domótico se clasifican en los siguientes grupos: • Controlador: Gestiona el sistema según la programación y la información que recibe, como si de un microprocesador se tratara.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 7 - • Actuador: Es un dispositivo capaz de ejecutar y/o recibir una orden del controlador y realizar una acción sobre un aparato o sistema concreto (encendido/apagado, subida/bajada, apertura/cierre, etc.) • Sensor: Es el dispositivo que monitoriza el entorno captando información que transmite al sistema (sensores de agua, gas, humo, temperatura, viento, humedad, lluvia, iluminación, etc.). • Bus: Es el medio de transmisión que transporta la información entre los distintos dispositivos ya sea por un cableado propio, por la redes de otros sistemas (red eléctrica, red telefónica, etc.) o de forma inalámbrica. • Interfaz: Se refiere a los dispositivos (interruptores, conectores, pantallas, etc.) en los que se muestra la información del sistema para los usuarios y/o donde los mismos pueden interactuar con el sistema. Figura 5: Dispositivos en una red domótica Hay que señalar que todos los dispositivos de un sistema domótico no tienen porqué estar físicamente separados, sino que varios de ellos pueden estar combinados en un mismo nodo o controlador. Por ejemplo, un nodo puede estar compuesto por un controlador, varios actuadores y sensores, y diferentes interfaces. Tampoco es estrictamente necesario que los cinco tipos de dispositivos se incluyan en una misma instalación domótica. Hay algunas arquitecturas que no requieren de un bus. Lo mismo se puede decir por el resto de tipos de dispositivos.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 8 - 2.2.2. La Arquitectura La arquitectura empleada es una arquitectura descentralizada: existen varios controladores (nodos a partir de ahora), conectados por un bus, que envían información entre ellos y a los actuadores e interfaces conectados a los controladores. Todo ello también según el programa, la configuración y la información que reciben de los sensores, sistemas interconectados y usuarios. Figura 6: Arquitectura descentralizada La instalación domótica que se propone estará compuesta por un número definido de nodos inteligentes. Cada nodo abarcará una zona distinta de la vivienda. De cada nodo colgarán sus respectivos actuadores y sensores que permitirán realizar el control de la vivienda. Aunque es una instalación basada en una arquitectura descentralizada esto nos permitirá de cada uno de los nodos se autosuficiente,
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 9 - proporcionando a la red domótica mas flexibilidad e independencia de actuación. Lo más relevante de este diseño es que no existe nodo Maestro, todos los nodos son maestros y esclavos simultáneamente. La información fluirá por el bus y cada nodo tomara las decisiones que crea convenientes en función de los datos que escucha en el bus. Este modelo de arquitectura seleccionado requiere de un bus para que los nodos se puedan comunicar entre ellos. 2.3. El Bus de Comunicaciones CAN El protocolo de comunicación CAN fue originalmente desarrollado y especificado en los años 80 por la compañía alemana Robert Bosch en un intento por resolver los problemas de comunicación entre los diferentes sistemas de control de los coches. No es necesario decir que la idea no tardó en pasar de los vehículos al sector de la automatización y control. CAN está estructurado de acuerdo con el modelo OSI en una arquitectura colapsada de dos capas, esto es, la capa física y la capa de enlace de datos. Como el resto de capas del modelo OSI (red, transporte, sesión, presentación y aplicación) no están especificadas por el protocolo, es necesario diseñarlas. Sobre todo es de vital importancia especificar un protocolo de alto nivel (HLP). La especificación original de CAN, publicada por Robert BSCH GMBH, se llama Especificación de CAN 2.0-A. La razón por la cual existe una parte A es porque una especificación actualizada de CAN se publicó después por la misma compañía, y contenía tanto la parte A, como una nueva versión de CAN llamada parte B. La especificación CAN 2.0-B es compatible con la Parte A. La diferencia se localiza básicamente en el formato del encabezado del mensaje del identificador. La especificación CAN 2.0-A define sistemas CAN con un estándar de 11 bits del identificador. En cambio, CAN 2.0-B especifica la trama extendida con 29 bits en el identificador. La especificación de CAN 2.0 es de dominio público. La mayoría de las implementaciones actuales de HW CAN usan la nueva versión de la especificación, incluso aunque sólo sea de forma pasiva (solo transmite mensajes estándar, pero comprueba si recibe mensajes estándar y mensajes extendidos).
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 10 - 2.3.1. Características principales A continuación se mostraran algunas de las propiedades fundamentales del CAN. Prácticamente todas ellas suponen una ventaja respecto otros tipos de buses convencionales usados en instalaciones domótica estándar: 1. La comunicación está basada en mensajes y no en direcciones. Un mensaje es diferenciado por el campo llamado identificador, que no indica el destino del mensaje, pero sí describe el contenido del mismo. 2. No hay un sistema de direccionamiento de los nodos en el sentido convencional. Los mensajes se envían según su prioridad. 3. La prioridad entre los mensajes la define el identificador. Se trata de una prioridad para el acceso al bus. 4. Es un sistema multimaestro. Cuando el bus está libre, cualquier nodo puede empezar la transmisión de un mensaje, y el mensaje con mayor prioridad gana la arbitración del bus. (Esta prioridad viene marcada por ID del mensaje). 5. Todos los nodos CAN son capaces de transmitir y recibir datos y varios pueden acceder al bus de datos simultáneamente. 6. Un nodo emisor envía el mensaje a todos los nodos de la red, cada nodo, según el identificador del mensaje, lo filtra y decide si debe procesarlo inmediatamente o descartarlo. Como consecuencia el sistema se convierte en multicast en el cual un mensaje puede estar dirigido a varios nodos al mismo tiempo. 7. Gran fiabilidad y robustez en la transmisión. Detecta errores, los señaliza, envía mensaje de error y reenviará el mensaje corrupto una vez que el bus vuelva a estar activo. Además puede operar en ambientes con condiciones extremas de ruido e interferencias gracias a que es un bus diferencial. 8. Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de comunicar subsistemas de diferentes fabricantes sobre una red común o bus. 9. Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a punto.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 11 - 10. El procesador principal delega la carga de comunicaciones a un periférico inteligente (controlador), por lo tanto el procesador principal dispone de mayor tiempo para ejecutar sus propias tareas. Figura 7: Sistema multicast Algunas limitaciones de CAN: 1. Velocidad limitada por la longitud de la red. Cada red puede alcanzar como máximo los 5000m de longitud (10 kbps) o una velocidad máxima de 1 Mbps (40 m). La longitud del bus también esta limitada en función del transceiver de can que utilicemos. EL HW de Microchip admite como velocidad más baja 16kbps que equivale a un bus máximo de 3300m. El transceiver de Panasonic admite velocidad de transmisión desde 0 hasta 1Mb. Esto implica que con un buen cableado podríamos cubrir distancias de 10Km sin problemas. 2. La cantidad de nodos abonados a la red es variable pero limitada. Esta limitación viene marcada según el HW (transceiver de can utilizado). Para el caso del HW Microchip el número máximo de nodos es 121.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 18 - desarrollo sigue siendo una aplicación de 32 bits Visual C++ 2005 soporta compilación para x86-64 (AMD64 e Intel 64) e IA-64 (Itanium). El SDK incluye compiladores de 64 bits así como versiones de 64 bits de las librerías. Las ediciones Express se han diseñado para principiantes, aficionados y pequeños negocios, todas disponibles gratuitamente a través de la página de Microsoft se incluye una edición independiente para cada lenguaje: Visual Basic, Visual C++, Visual C#, Visual J# para programación .NET en Windows, y Visual Web Developer para la creación de sitios Web ASP.NET. Las ediciones Express carecen de algunas herramientas avanzadas de programación así como de opciones de extensibilidad. El lenguaje elegido para el desarrollo ha sido el C#, por la experiencia personal en este leguaje. Figura 12: IDE Visual Studio 2005 Express 3.3. Programador PIC’s Necesario para cargar el firmware en los nodos, se ha empleado un programador GTPLite y el programa WinPic80. Es un programador realmente rápido y compatible
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 19 - con todos SO de Windows, además dan soporte para actualizar el FW del programador y actualizan constantemente todos los micros que soporta. La interfaz es intuitiva y fácil de usar. Este programador nos permitirá programar los chips sin necesidad de extraerlos de la placa. Figura 13: Programador GTPLite 3.4. Pasarela RS232/CAN El nodo pasarela fue diseñado para poder comunicar la red CAN bus con el PC. El nodo utilizado es un prototipo creado, del que únicamente existen dos unidades, pero el nodo final mantendrá sus características, si bien se espera que sus dimensiones sean más reducidas. Esta conexión nos ofrece varias utilidades: • Herramienta de depuración de programas. • Interactuar con los nodos de la red CAN bus. • Creación de una pasarela mediante un PC CAN <-> Internet
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 20 - Figura 1: Hardware pasarela RS232/CAN
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 21 - CAPÍTULO 4. Diagramas UML 4.1. Diagrama de dominio Figura 14: Diagrama de dominio
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 22 - 4.2. Diagrama de despliegue Nodo PC -RS232 1 -Nodo 1 -Bus Par Tranzado Nodo Terminador -Can 1 -Can 1 CANet Nodo RS232 Nodo 1 Nodo -Can 1Nodo 2 Nodo -Can 1Nodo 3 Nodo -Can 1Nodo 4 Nodo -Can 1Nodo I Nodo Terminador -Can 1Nodo N Entrada Salida 0..8 0..8 0..1 0..1 Figura 15: Diagrama de despliegue
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 23 - 4.3. Diagrama de secuencia Figura 16: Diagrama de secuencia
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 24 - 4.4. Diagramas de Estados Figura 17: Diagrama de estados del nodo Sin MAC Inicialización En Espera Gestionando Mensaje CAN Gestionando Mensaje 232 Enviando Mensaje 232 Enviando Mensaje CAN Figura 18: Diagrama de estados de la pasarela
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 25 - CAPÍTULO 5. APLICACIÓN DE ADMINISTRACIÓN El principal objetivo a la hora de desarrollar la aplicación de administración era poder exprimir al máximo la potencia del nodo, sin obligar al usuario a adquirir conocimientos técnicos. Por ello se ha optado por una interfaz grafica con una filosofía de “Arrastrar y Soltar”, en la que la configuración de los nodos se hace de una forma muy visual, empleando mayoritariamente el ratón. 5.1. Estructura de la interfaz Figura 19: Interfaz administración
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 26 - La interfaz se ha dividido en 5 zonas: 5.1.1. Barra de Menús La barra de menús permite al usuario abrir, cerrar y guardar ficheros, cambiar el nivel del zoom, el tamaño del dibujo o enviar la configuración de los nodos. Figura 20: La Barra de Menús Para facilitar el uso, además de los menús contextuales, se ha añadido una barra de botones que permite acceder a los principales comandos del menú. 5.1.2. Barra de herramientas Permite seleccionar la herramienta que se va a utilizar para modificar el dibujo de la configuración. Figura 21: Interfaz administración Los botones disponibles, por orden de arriba abajo son: • Seleccionar: Permite seleccionar un elemento del dibujo para modificarlo o borrarlo. • Borrar: Elimina el elemento seleccionado. • Pared: Dibuja una pared. Las paredes no tienen otra utilidad que ayudar al usuario a la hora de identificar la posición de los elementos del dibujo. • Nodo: Añade un nodo de control. • Pulsador: Añade un dispositivo de entrada a un nodo. • Dispositivo: Añade un dispositivo de salida a un nodo. • Función: Crea una función en un nodo.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 27 - • Acción: Crea una acción en un nodo. 5.1.3. Área de dibujo Representa la distribución de nodos y dispositivos de entrada y salida conectados a cada uno. Figura 22: Área de dibujo Cuando se están creando funciones o acciones también se refleja en el área de dibujo el estado de las entradas y salidas que configuran la función o acción. 5.1.4. Árbol de Elementos Permite ver en una estructura en árbol todos los elementos del dibujo, así como seleccionar un elemento en concreto.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 34 - Ahora se puede nombrar la acción con un nombre acorde con la acción que producirá. Se debe añadir una duración (en cuartos de segundo). Este tiempo indica cuanto tiempo tiene que mantenerse la configuración de Entradas/Salidas para que se active esta acción. Por último, se debe definir el “Destinatario” y la “Función” que se debe ejecutar. 5.3. Programación de los Nodos Una vez se ha terminado de configurar todos los nodos con sus funciones y acciones, se puede mandar la programación a los nodos, a través del puerto serie al nodo pasarela, y este enviará a cada nodo su configuración. Para ello se tiene que pulsar el botón de “Programar” que hay en la barra de menús. El tiempo de programación depende del número de información que hay que enviar, y hay que tener en cuenta cada vez se borra toda la información en los nodos y se manda de nuevo toda la configuración.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 35 - CAPÍTULO 6. FIRMWARE DE LA PASARELA El firmware de la pasarela es realmente simple, ya que simplemente actúa como traductor entre los mensajes de 232 y los de CAN. Para evitar problemas con la tabla de caracteres en 232, los mensajes se mandan como una cadena de texto de los bytes en su representación en hexadecimal, terminando siempre con un retorno de carro. Los mensajes de 232 tendrán siempre una longitud de 24 caracteres, siendo los 8 primeros para indicar la dirección MAC del destinatario y los 16 siguientes para indicar el contenido del mensaje de CAN. Por ejemplo, si se desea decir al nodo con MAC 0x10A2036B que tiene que realizarla función 0x12, el texto que se enviaría por 232 seria: 10A2036B6012000000000000 Por último, el nodo pasarela actúa como un sniffer, leyendo todos los mensajes que haya en el bus CAN y enviándolos como texto por 232. Debido a que el buffer de lectura de 232 del chipset de la pasarela tiene solo una longitud de 2 caracteres, no se puede asegurar que cada vez que se lea un mensaje por 232 sea un mensaje completo, por lo que se ha optado por ir almacenando los datos que se leen por 232 hasta que se obtiene un mensaje completo, y entonces procesarlo.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 36 - Figura 36: Diagrama de flujo de la pasarela
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 37 - CAPÍTULO 7. FIRMWARE DEL NODO 7.1. Diagrama de flujo Encendido / Reset Existe MAC? Leer Bus CAN SI Esperar Dirección MAC Establecer MAC NO Leer Entradas y Salidas Hay Mensaje? Procesar Mensaje Mensaje de Configuración? SI NO SI NO Hay Función? Preparar salidas Es Local?SI Preparar salidasSI Enviar Mensaje NO Modificar Salidas NO Figura 37: Diagrama de flujo del nodo
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 38 - 7.2. Direccionamiento MAC Cada nodo, cuando se le carga el firmware por primera vez, tiene asignada una MAC igual a 0 y no funcionará correctamente hasta que se la asigne una. En principio, cada MAC identifica de forma única a cada nodo, pero no hay nada que impida que dos nodos compartan la misma MAC, y de hecho, en algunas configuraciones puede ser interesante que esto ocurra. Los nodos están atentos a todos los mensajes que circulen por el bus CAN, pero solo harán caso a aquellos que estén dirigidos a su dirección MAC, con la excepción de un mensaje enviado a la MAC 0x0000 que será tratado por todos los nodos. 7.3. Funciones y Acciones Los nodos funcionan por lo que hemos llamado Funciones y Acciones. Una función es cualquier combinación de estados de entradas y salidas que se mantiene constante durante una determinada duración de tiempo. Las acciones se han subdividido en dos tipos: Acciones locales: Cambian el estado de las salidas de un nodo. Acciones remotas: Ejecutan una acción en otro nodo Un Ejemplo práctico sería el siguiente: Un nodo dispone de cuatro actuadores (salidas). Los actuadores están conectados a dos motores que controlan la subida y bajada de dos persianas. Las posibles acciones locales que se definirían en el nodo serian: Acción Mascara Valor Duración Subir Persiana A 00001100 00000100 5 Bajar Persiana A 00001100 00001000 5 Parar Persiana A 00001100 00000000 5 Subir Persiana B 00000011 00000001 5 Bajar Persiana B 00000011 00000010 5 Parar Persiana B 00000011 00000000 5 Subir Persianas 00001111 00000101 5 Bajar Persianas 00001111 00001010 5 Parar Persianas 00001111 00000000 5 Tabla 2: Acciones Persianas
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 39 - Por ejemplo, la acción “Subir Persiana B” está actuando sobre las salidas 6 y 7 y está activando la salida 7 y desactivando la 6 durante 5 segundos, pasado este tiempo, desactivará todas. Para las funciones, hay que especificar tanto el estado de las entradas como de las salidas, ya que el funcionamiento de un pulsador puede depender del estado actual, siguiendo con el ejemplo anterior, si añadimos 4 pulsadores al nodo, podríamos definir estas siguientes funciones: ENTRADAS SALIDAS Máscara Valor Máscara Valor Duración Acción 00000011 00000001 00000010 00000000 1 Subir Persiana B 00000011 00000001 00000010 00000010 1 Parar Persiana B Tabla 3: Funciones Persianas Estas funciones se activarán que cuando accionamos el pulsador de la entrada 7 y no esté activo el pulsador el de la entrada 6, asumiendo que etiquetamos el pulsador 7 para subir la persiana B y el 6 para bajarla, el nodo no haría nada si pulsamos los dos botones a la vez. Sin embargo el botón de subir actuará de distinta forma dependiendo de cual sea el estado de las salidas, ya que si la salida que controla el bajado de la persiana está activa, se parara, pero en caso contrario se iniciará la subida de la persiana El campo duración indica cuanto tiempo (en ¼ de segundo) debe estar activa la configuración de entradas y salidas para que se ejecute la acción definida. De esta forma, podríamos definir una acción de subir persiana que dure todo el recorrido y otra que dure la mitad, y con el mismo pulsador de subir la persiana, podríamos ejecutar la acción de subirla completa o subirla hasta la mitad en función de cuanto lo mantengamos pulsado Por último, podríamos añadir un nodo o en la otra punta de habitación, o en otra habitación, y si queremos controlar las persianas desde los pulsadores conectados a ese nodo, las acciones que definiríamos serian acciones remotas, y en lugar almacenar la configuración de salidas para el propio nodo, tendríamos la dirección MAC del otro nodo y la acción que queremos ejecutar en ese nodo Un ejemplo en el que se utilizarían mensajes de broadcast seria el siguiente: En todos los nodos que controlan la iluminación se define una acción que sea
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 40 - “apagar todo” Desde un nodo situado en la entrada de la vivienda, se programa una acción remota sobre la MAC de broadcast con la acción de “apagar todo” De esta forma, al salir de la vivienda, pulsaríamos un botón que lanzaría el mensaje y todas las luces se apagarían. 7.4. Distribución de la memoria Se utiliza la el propio espacio de memoria reservado para el programa para almacenar la configuración del nodo, por ello se ha dividido el espacio total 32Kb en 4 secciones: • Área de programa: Almacena el código ejecutable, al reducir el espacio disponible para el programa, se ha tenido mucho cuidado al programar no sobrepasar el límite establecido. • Área de configuración: Almacenas datos de configuración como la dirección MAC y las funciones y acciones que están disponibles • Área de Acciones: Almacena las configuraciones de las Acciones • Área de Funciones: Almacena las configuraciones de las Funciones 7.4.1. Área de programa Empieza en la dirección 0x0000. 7.4.2. Área de configuración Empieza en la dirección 0x2000 y ocupa 32 palabras. Hay un primer bloque de 8 palabras, de las que se utilizan las dos primeras para almacenar la dirección MAC del nodo. Luego se utiliza un bloque de 8 palabras en la que cada bit sirve apara indicar si existe o no una acción determinada, por lo que se pueden definir 128 acciones distintas. Por último hay otro bloque de 8 palabras en la que cada bit sirve apara indicar si existe o no una función determinada, por lo que se pueden definir 128 funciones
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 41 - distintas. El motivo de utilizar 32 palabras aunque no se empleen todas es porque es el tamaño del bloque de escritura del chip. 7.4.3. Área de Acciones Empieza en la dirección 0x2040. Para el bloque de las acciones se utilizan cuatro palabras por cada acción, con las siguientes estructuras: Dato Long Descripción Tipo 8 0x21 Mascara Entradas 8 Valor Entradas 8 Mascara Salidas 8 Valor Salidas 8 Duración 8 En cuartos de segundo. Siguiente Acción 8 Hace referencia a una acción del propio nodo. Resto 8 Tabla 4: Almacenamiento de una Acción local Dato Long Descripción Tipo 8 0x22 MAC Destinatario 32 Función Remota 8 Siguiente Acción 8 Hace referencia a una Acción del propio nodo. Resto 8 Tabla 5: Almacenamiento de una Acción remota 7.4.4. Área de Funciones Empieza en la dirección 0x3000 y se utilizan cuatro palabras por cada acción, con la siguiente estructura:
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 42 - Dato Long Descripción Mascara Entradas 8 Valor Entradas 8 Mascara Salidas 8 Valor Salidas 8 Duración 8 En cuartos de segundo. Acción 8 Hace referencia a una acción del propio nodo. Resto 16 Tabla 6: Almacenamiento de una función
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 43 - CAPÍTULO 8. CATÁLOGO DE MENSAJES Todos los mensajes DOMCAN tienen sentido en el contexto de un diálogo entre dos nodos. Este apartado recoge la lista de diálogos definidos al amparo del protocolo DOMCAN. Los diálogos se han clasificado en tres grupos atendiendo al contexto de utilización. Para cada diálogo se indican los nodos que los utilizan y el papel de cada una de ellos. También se describen detalladamente los mensajes y las reglas principales que gobiernan el diálogo. 8.1. Estructura general de los mensajes La principal característica a tener en cuenta a la hora de definir el protocolo ha sido la longitud máxima del campo de datos de las tramas enviados a través de la red CAN: 8 bytes, por lo que se ha intentando optimizar al máximo la información que se manda en cada trama, de forma que cada mensaje tenga un significado completo y no haga falta segmentar un mensaje en varias tramas. Como la mayoría de los mensajes son asíncronos y no requieren respuesta, en el campo del identificador de la trama se indica la dirección MAC del nodo de destino, de forma que todos nodos están abonados a todos los mensajes y es el firmware del nodo el que se encarga de decidir si debe leer el mensaje o ignorarlo. Para los mensajes broadcast que deben ser leídos por todos los nodos se utiliza la dirección MAC 0x0000000 El primer nibble del campo de datos de cada trama identifica el tipo de mensaje. Si es necesario, se utiliza el segundo nibble para indicar un subtipo. El significado del resto de bytes depende del tipo de mensaje. Cuando un mensaje no requiere utilizar todos los bytes de la trama, se rellena el resto a 0x00 8.2. Diálogos de Configuración Estos mensajes son generados por un nodo especial que es el que está conectado a la aplicación de control y son empleados para establecer el comportamiento de cada nodo. Por motivos de seguridad, no se permite utilizar estos mensajes con la dirección de broadcast (salvo el mensaje C_MAC)
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 50 -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 51 - CAPÍTULO 9. CONCLUSIONES Las aplicaciones creadas han cubierto todos los objetivos propuestos al inicio del proyecto: 1. Implementación del Software de administración: Se ha desarrollado una aplicación de Windows que permite definir tanto los elementos del sistema (nodos y dispositivos de entrada/salida) como su comportamiento (funciones y acciones). 2. Implementación del Software de los nodos: Se ha creado un firmware común para todos los nodos, que dispone un sistema de configuración que permite variar el comportamiento del nodo en función de las necesidades. La configuración es gestionada por el propio firmware mediante un protocolo de mensajes que se ha definido expresamente para ello. 3. Implementación del Software de pasarela: Se ha creado el firmware que va en el nodo pasarela, y que es el responsable de establecer la comunicación entre la aplicación creada para la administración de los nodos con los nodos conectados al bus CAN. 9.1. Futuras líneas de trabajo Aun le quedan muchas mejoras que implementar a la aplicación de administración y a los firmwares de los nodos, entre ellas las más importantes son: • Poder utilizar los siguientes dispositivos de entrada/salida: o Dispositivos analógicos, como por ejemplo un dimmer para controlar la intensidad de la iluminación. o Sensores analógicos, como por ejemplo un sensor de temperatura. o Dispositivos digitales que requieran el uso de varias salidas, como por ejemplo un panel de leds. o Sensores digitales que requieran el uso de varias entradas, por ejemplo un teclado numérico. • Optimizar la reprogramación de los nodos para poder reprogramar los nodos de forma individual. • Se ha detectado una carencia en el dispositivo Hardware de los nodos, la ausencia de una memoria externa para almacenar la configuración. En la versión actual se utiliza la propia memoria flash del chip, lo que limita la vida
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 52 - de este a 100.000 reprogramaciones. Por lo que se ha sugerido al creador que en futuras versiones incluya una memoria externa. • Posibilidad de cargar ficheros DWG (Autocad) para definir el diseño del hogar. • Crear una servidor Web en la aplicación de administración a fin de poder controlar el sistema domótico de forma remota. Como objetivo a largo plazo, se estudiará la posibilidad de comercializar el sistema completo: los nodos se venderían ya programados con el firmware y la aplicación de administración se distribuiría gratuitamente. 9.2. Valoración Personal Aunque el trabajo realizado haya sido extenso y se haya podido completar un sistema completo funcional, que en breve se pondrá en explotación en casa de Pere, estimo que se ha cubierto únicamente un 15% de todo el trabajo necesario para hacer una comercialización viable del producto, objetivo a largo plazo, pero que se quedaba fuera del objetivo del proyecto. Por otro lado considero que se está desaprovechando en exceso el protocolo CAN, ya que se está utilizando para un proyecto que se aleja considerablemente del objetivo principal de este protocolo de comunicación. Se han tenido que descartar todos los tipos de mensaje que dispone, y se ha ignorado el sistema de mascaras y filtros. Esto no es una crítica a la elección de CAN, ya que las pruebas realizadas han demostrado la fiabilidad del protocolo. Lo que quiero decir, es que creo, que el protocolo CAN tiene suficiente versatilidad para ser utilizado en otros ámbitos, en lugar de quedar relegado a la industria de la automoción. Por último, comentar el único inconveniente que veo a todo el sistema, la necesidad de cablear todo el hogar, tanto para el bus de datos como para alimentación, motivo por el que puede provocar rechazo a futuros usuarios y puede hacernos perder cuota de mercado frente a otras soluciones domótica que son más caras, pero que no requieren de instalación adicional. Por lo que considero, que aunque hemos querido hacer una solución destinada a un público sin conocimientos técnicos, la necesidad de realizar el cableado, aunque es una tarea sencilla, atraerá más a usuarios con unos conocimientos básicos de electrónica.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 53 - CAPÍTULO 10. BIBLIOGRAFIA [1] Sistema domótico basado en CAN, SEP/2010, Pere Joan Antoni Chordá [2] http://www.todopic.com/ [3] http://www.can-cia.org [4] http://www.mikroe.com/ [5] http://www.microchip.com/ [6] MICROCONTROLADORES: FUNDAMENTOS Y APLICACIONES CON PIC Pallás, Ramón ; Valdés, Fernando MARCOMBO, EDICIONES TÉCNICAS [7] http://www.micropic.es [8] http://www.microcontroladorespic.com [9] http://www.winpic800.com/ [10] http://www.todopic.com.ar/foros [11] http://msdn.microsoft.com [12] Microcontrolador PIC16F84. Desarrollo de proyectos. Enrique Palacios y otros. Ed.: Ra-Ma [13] El Lenguaje unificado de Modelado. Manual de referencia.. James Rumbaugh, Ivar Jacobson y Grady Booch. Ed. Addison Wesley [14] The complete reference C# 4.0, Herb Schildt, Ed. McGraw Hill. [15] http://server-die.alc.upv.es/asignaturas/PAEEES/2005-06/A03-A04%20- %20Bus%20CAN.pdf
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 54 -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 55 - ANEXO A : BUS CAN A.1 Orígenes y arquitectura de capas Las implementaciones hardware de CAN cubren de forma estandarizada las capas físicas y de enlace del modelo de comunicaciones OSI (Open Systems Interconection), mientras diversas soluciones de software no estandarizadas cubren la capa de aplicación. Las estandarizaciones ISO (International Standard Organization), a diferencia de las normas BOSCH, especifican también el medio de comunicación. Por lo tanto una implementación CAN a partir de las especificaciones de BOSCH no siempre será compatible con las normas ISO. Figura 38: Capa física A.1.1 Capa física La capa física de CAN, es responsable de la transferencia de bits entre los distintos nodos que componen la red. Define aspectos como niveles de señal, codificación,
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 56 - sincronización y tiempos en que los bits se transfieren al bus. En la especificación original de CAN, la capa física no fue definida, permitiendo diferentes opciones para la elección del medio y niveles eléctricos de transmisión. Las características de las señales eléctricas en el bus, fueron establecidas más tarde por el ISO 11898 para las aplicaciones de alta velocidad y, por el estándar ISO 11519 para las aplicaciones de baja velocidad. Figura 39: Estándar 11519 Los nodos conectados en este bus interpretan dos niveles lógicos denominados: Dominante y Recesivo. • Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales). • Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 5V con CAN_H = 0V y CAN_L = 5V (nominales). A diferencia del bus de alta velocidad, el bus de baja velocidad requiere dos resistencias en cada transceptor: RTH para la señal CAN_H y RTL para la señal CAN_L. Esta configuración permite al transceptor de bus de baja velocidad (fault-tolerant) detectar fallas en la red. La suma de todas las resistencias en paralelo, debe estar en el rango de 100-500.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 57 - Figura 40: Red Bus CAN de Baja Velocidad (Fault Tolerant) Figura 41: Estándar 11898 Los nodos conectados en este bus interpretan los siguientes niveles lógicos: • Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales). • Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 0V con CAN_H = CAN_L = 2.5V (nominales). El par de cables trenzados (CAN_H y CAN_L) constituyen una transmisión de línea. Si dicha transmisión de línea no está configurada con los valores correctos, cada trama transferida causa una reflexión que puede originar fallos de comunicación. Como la comunicación en el bus CAN fluye en ambos sentidos, ambos extremos de red deben de estar cerrados mediante una resistencia de 120. Ambas resistencias deberían poder disipar 0.25 w. de potencia.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 58 - Figura 42: Red Bus CAN de Alta Velocidad A.1.2 Capa de enlace de datos La capa de enlace de datos es responsable del acceso al medio y el control lógico y está dividida a su vez en dos niveles. • El subnivel LLC (Logical Link Control): Gestiona el filtrado de los mensajes, las notificaciones de sobrecarga y la administración de la recuperación. • El subnivel MAC (Medium Acces Control): Es el núcleo del protocolo CAN y gestiona el tramado y desentramado de los mensajes, el arbitraje a la hora de acceder al bus y el reconocimiento de los mensajes, así como el chequeo de posibles errores y su señalización, el aislamiento de fallos en unidades de control y la identificación del estado libre del bus para iniciar una transmisión o recepción de un nuevo mensaje.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 59 - A.2 Estructura de un nodo CAN Dentro de un nodo CAN, se pueden distinguir una serie de módulos interconectados entre ellos: un bus de direcciones, datos y un control (paralelo) enlazando el controlador central, la memoria de los datos y el programa (donde esta almacenado el software de aplicación y el controlador de red de alto nivel), los dispositivos de entrada y salida y, la interfaz de comunicación. Desde el punto de vista del controlador, la interfaz de comunicación se puede ver como un conjunto de buzones, donde cada uno de estos sirve como registro lógico de interfaz entre el controlador local y los nodos remotos. Si un nodo quiere comunicarse, tiene que dar de alta los correspondientes buzones de recepción y transmisión antes de hacer ninguna operación. Figura 43: Estructura de un nodo CAN Teniendo en cuenta esta arquitectura, el funcionamiento sigue los siguientes pasos:
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 66 - A.4.4 Trama de error Las tramas de error son generadas por cualquier nodo que detecta un error. Consiste en dos campos: Indicador de error ("Error Flag") y Delimitador de error (“Error Delimeter”). El delimitador de error consta de 8 bits recesivos consecutivos y permite a los nodos reiniciar la comunicación limpiamente tras el error. El Indicador de error es distinto según el estado de error del nodo que detecta el error: Figura 50: Trama error Si un nodo en estado de error "Activo" detecta un error en el bus interrumpe la comunicación del mensaje en proceso generando un "Indicador de error activo" que consiste en una secuencia de 6 bits dominantes sucesivos. Esta secuencia rompe la regla de relleno de bits y provocará la generación de tramas de error en otros nodos. Por tanto el indicador de error puede extenderse entre 6 y 12 bits dominantes sucesivos. Finalmente se recibe el campo de delimitación de error formado por los 8 bits recesivos. Entonces la comunicación se reinicia y el nodo que había sido interrumpido reintenta la transmisión del mensaje. Si un nodo en estado de error "Pasivo" detecta un error, el nodo transmite un "Indicador de error pasivo" seguido, de nuevo, por el campo delimitador de error. El indicador de error de tipo pasivo consiste en 6 bits recesivos seguidos, por tanto, la trama de error para un nodo pasivo es una secuencia de 14 bits recesivos. De aquí se deduce que la transmisión de una trama de error de tipo pasivo no afectará a ningún nodo en la red, excepto cuando el error es detectado por el propio nodo que está transmitiendo. En ese caso los demás nodos detectarán una violación de las reglas de
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 67 - relleno y transmitirán a su vez tramas de error. Tras señalar un error por medio de la trama de error apropiada cada nodo transmite bits recesivos hasta que recibe un bit también recesivo, luego transmite 7 bits recesivos consecutivos antes de finalizar el tratamiento de error. La regla de relleno de bits que aparece líneas superiores, consiste en que cada cinco bits de igual valor se introduce uno de valor inverso tal y como se ve en la figura siguiente: Figura 51: Relleno de bits en trama de error Otro método para la detección de errores es el chequeo de la trama: Figura 52: Trama detección de error El campo CRC contiene información adicional a la trama, éste se calcula con un polinomio generador de igual manera en el receptor y en el emisor. Esto permite detectar errores aleatorios en hasta 5 bits o una secuencia seguida de 15 bits corruptos. El campo ACK, en el caso del emisor será recesivo y el receptor deberá sobrescribirlo como dominante y el primero comprobará, mediante la monitorización, que el mensaje ha sido escuchado. Si no sucede así, la trama se considerará corrupta.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 68 - A.4.5 Trama de sobrecarga Una trama de sobrecarga tiene el mismo formato que una trama de error activo. Sin embargo, la trama de sobrecarga sólo puede generarse durante el espacio entre tramas. De esta forma se diferencia de una trama de error, que sólo puede ser transmitida durante la transmisión de un mensaje. La trama de sobrecarga consta de dos campos, el Indicador de Sobrecarga, y el delimitador. El indicador de sobrecarga consta de 6 bits dominantes que pueden ser seguidos por los generados por otros nodos, dando lugar a un máximo de 12 bits dominantes. El delimitador es de 8 bits recesivos. Una trama de sobrecarga puede ser generada por cualquier nodo que debido a sus condiciones internas no está en condiciones de iniciar la recepción de un nuevo mensaje. De esta forma retrasa el inicio de transmisión de un nuevo mensaje. Un nodo puede generar como máximo 2 tramas de sobrecarga consecutivas para retrasar un mensaje. Otra razón para iniciar la transmisión de una trama de sobrecarga es la detección por cualquier nodo de un bit dominante en los 3 bits de "intermission". Por todo ello una trama de sobrecarga de 5 generada por un nodo dará normalmente lugar a la generación de tramas de sobrecarga por los demás nodos dando lugar, como se ha indicado, a un máximo de 12 bits dominantes de indicador de sobrecarga. A.4.6 Espaciado entre tramas El espacio entre tramas separa una trama (de cualquier tipo) de la siguiente trama de datos o interrogación remota. El espacio entre tramas ha de constar de, al menos, 3 bits recesivos. Esta secuencia de bits se denomina "intermission". Una vez transcurrida esta secuencia un nodo en estado de error activo puede iniciar una nueva transmisión o el bus permanecerá en reposo. Para un nodo en estado error pasivo la situación es diferente, deberá espera una secuencia adicional de 8 bits recesivos antes de poder iniciar una transmisión. De esta forma se asegura una ventaja en inicio de transmisión a los nodos en estado activo frente a los nodos en estado pasivo.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 69 - A.5 Acceso múltiple y arbitraje de acceso al bus Unas de las características que distingue a CAN con respecto a otras normas, es su técnica de acceso al medio denominada como CSMA/CD+CR o "Carrier Sense, Multiple Access/Collision Detection + Collision Resolution" (Acceso Múltiple con detección de portadora, detección de colisión más Resolución de colisión). Cada nodo debe vigilar el bus en un periodo sin actividad antes de enviar un mensaje (Carrier Sense) y además, una vez que ocurre el periodo sin actividad cada nodo tiene la misma oportunidad de enviar un mensaje (Multiple Access). En caso de que dos nodos comiencen a transmitir al unísono se detectará la colisión. El método de acceso al medio utilizado en bus CAN añade una característica adicional: la resolución de colisión. En la técnica CSMA/CD utilizada en redes Ethernet ante colisión de varias tramas, todas se pierden. CAN resuelve la colisión con la supervivencia de una de las tramas que chocan en el bus. Además la trama superviviente es aquella a la que se ha identificado como de mayor prioridad. La resolución de colisión se basa en una topología eléctrica que aplica una función lógica determinista a cada bit, que se resuelve con la prioridad del nivel definido como bit de tipo dominante. Definiendo el bit dominante como equivalente al valor lógico '0' y bit recesivo al nivel lógico '1' se trata de una función AND de todos los bits transmitidos simultáneamente. Cada transmisor escucha continuamente el valor presente en el bus, y se retira cuando ese valor no coincide con el que dicho transmisor ha forzado. Mientras hay coincidencia la transmisión continua, finalmente el mensaje con identificador de máxima prioridad sobrevive. Los demás nodos reintentarán la transmisión lo antes posible. Se ha de tener en cuenta que la especificación CAN de Bosh no establece cómo se ha de traducir cada nivel de bit (dominante o recesivo) a variable física. Cuando se utiliza par trenzado según ISO 11898 el nivel dominante es una tensión diferencial positiva en el bus, el nivel recesivo es ausencia de tensión, o cierto valor negativo, (los transceptores no generan corriente sobre las resistencias de carga del bus). Esta técnica aporta la combinación de dos factores muy deseados en aplicaciones industriales distribuidas: la posibilidad de fijar con determinismo la latencia en la transmisión de mensajes entre nodos y el funcionamiento en modo multimaestro sin necesidad de gestión del arbitraje, es decir control de acceso al medio, desde las capas de software de protocolo. La prioridad queda así determinada por el contenido del
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 70 - mensaje, en CAN es un campo determinado, el identificador de mensaje, el que determina la prioridad. Figura 53: Arbitraje En un bus único, un identificador de mensaje ha de ser asignado a un solo nodo concreto, es decir, se ha de evitar que dos nodos puedan iniciar la transmisión simultánea de mensajes con el mismo identificador y datos diferentes. El protocolo CAN establece que cada mensaje es único en el sistema, de manera que por ejemplo, si en un automóvil existe la variable “presión de aceite”, esta variable ha de ser transmitida por un nodo concreto, con un identificador concreto, con una longitud fija concreta y coherente con la codificación de la información en el campo de datos.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 71 - Figura 54: Ejemplo de arbitraje en un bus CAN
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 72 - A.6 Detección de Errores Una de las características más importantes y útiles de CAN es su alta fiabilidad, incluso en entornos de ruido extremos, el protocolo CAN proporciona una gran variedad de mecanismos para detectar errores en las tramas. Esta detección de error es utilizada para retransmitir la trama hasta que sea recibida con éxito. Otro tipo de error es el de aislamiento, y se produce cuando un dispositivo no funciona correctamente y un alto por ciento de sus tramas son erróneas. Este error de aislamiento impide que el mal funcionamiento de un dispositivo condicione el funcionamiento del resto de nodos implicados en la red. A.6.1 Detección de errores En el momento en que un dispositivo detecta un error en una trama, este dispositivo transmite una secuencia especial de bits, “el error flag”.Cuando el dispositivo que ha transmitido la trama errónea detecta el error flan, transmite la trama de nuevo. Los dispositivos CAN detectan los errores siguientes: • Error de bit: Durante la transmisión de una trama, el nodo que transmite monitoriza el bus. Cualquier bit que reciba con polaridad inversa a la que ha transmitido se considera un error de bit, excepto cuando se recibe durante el campo de arbitraje o en el bit de reconocimiento. Además, no se considera error de bit la detección de bit dominante por un nodo en estado de error pasivo que retransmite una trama de error pasivo. • Error de relleno (Stuff Error): Se considera error de relleno la detección de 6 bits consecutivos del mismo signo, en cualquier campo que siga la técnica de relleno de bits, donde por cada 5 bits iguales se añade uno diferente. • Error de CRC: Se produce cuando el cálculo de CRC realizado por un receptor no coincide con el recibido en la trama. El campo CRC (Cyclic Redundant Code) contiene 15 bits y una distancia de Hamming de 6, lo que asegura la detección de 5 bits erróneos por mensaje. Estas medidas sirven para detectar errores de transmisión debido a posibles incidencias en el medio físico como por ejemplo el ruido. • Error de forma (Form Error): Se produce cuando un campo de formato fijo se recibe alterado como bit.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 73 - • Error de reconocimiento (Acknowledgement Error): Se produce cuando ningún nodo cambia a dominante el bit de reconocimiento. Si un nodo advierte alguno de los fallos mencionados, iniciará la transmisión de una trama de error. El protocolo CAN especifica diversos fallos en la línea física de comunicación, como por ejemplo línea desconectada, problemas con la terminación de los cables o líneas cortocircuitadas. Sin embargo, no especificará como reaccionar en caso de que se produzca alguno de estos errores. A.6.2 Aislamiento de nodos defectuosos Para evitar que un nodo en problemas condicione el funcionamiento del resto de la red, se han incorporado a la especificación CAN medidas de aislamiento de nodos defectuosos que son gestionadas por los controladores. Un nodo pude encontrarse en uno de los tres estados siguientes en relación a la gestión de errores: • Error Activo (Error Active): Es el estado normal de un nodo. Participa en la comunicación y en caso de detección de error envía una trama de error activa • Error pasivo (Error Passive): Un nodo en estado de error pasivo participa en la comunicación, sin embargo ha de esperar una secuencia adicional de bits recesivos antes de transmitir y sólo puede señalar errores con una trama de error pasiva. • Anulado (Bus Off): En este estado, deshabilitará su transceptor y no participará en la comunicación. La evolución entre estos estados se basa en dos contadores incluidos en el controlador de comunicaciones. Contador de errores de transmisión (TEC) y Contador de errores de recepción (REC).
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 74 - Figura 55: Evolución entre estados de error.
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 75 - A.7 Acceso múltiple y arbitraje de acceso al bus Como ya se comentó anteriormente en el apartado A.1, la mayor parte de las aplicaciones que posee el CAN están concentradas en la industria automovilística donde realiza el control del motor, de la mecánica del automóvil así como los sistemas de entretenimiento. Esto es debido en parte a que el sistema CAN fue especialmente diseñado en sus orígenes con la idea de aplicarlo en el mundo de los automóviles para la transmisión de datos entre los sistemas electrónicos de control y regulación, como por ejemplo: • Control del cambio. • Control electrónico del motor o de la bomba de inyección. • Sistema antibloqueo (ABS). • Sistema de tracción antideslizante (ASR). • Control de estabilidad (ESP). • Regulación del momento de arrastre del motor (MSR). • Inmovilizador. • Ordenador de a bordo, etc. Relacionado con la industria automovilística, el CAN se extiende al transporte público y otras máquinas móviles como aviones, helicópteros, trenes, barcos y los controles de tráfico y sistemas de información conductor/pasajero. Pero en general el CAN se aplica en cualquier sistema de control industrial: sistemas de control de plantas y maquinaria, redes entre máquinas, maquinaria agrícola, instrumental médico, sistemas de supervisión, etc. y en la automatización de edificios: control de ascensores, aire acondicionado, sistemas de calefacción y refrigeración, control de iluminación, etc. En resumen, en cualquier sistema que precise control en tiempo real distribuido y con escaso flujo de datos. Por lo tanto, esto augura un gran futuro para el CAN. Incluso actualmente ya se puede considerar que el CAN a alcanzado un nivel extraordinario de madurez e implantación ya que los fabricantes y procesadores digitales de señal están
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 82 - Figura 60: Single-Chip CAN Node
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 83 - ANEXO B : CÓDIGO FUENTE El objetivo de este anexo es mostrar parte del código generado para el PIC, a fin de comentar las secciones que se han considerado más significativas. Se han definido 2 enumerados, boolean para simular el tipo boleano, y acción para no tener que recordar los códigos de cada tipo de mensaje. enum boolean { FALSE = 0, TRUE = 1 }; enum accion{ C_MAC = 0x10, C_MAC_ACK= 0x1C, C_ACCION_LOCAL = 0x21, C_ACCION_REMOTA = 0x22, C_FUNCION = 0x30, C_BORRAR_FUNCIONES = 0x41, C_BORRAR_ACCIONES = 0x42, A_ESTADO = 0x51, A_ESTADO_ACK = 0x52, A_RESET = 0x40, A_PING_PETICION = 0x51, A_PING_ACK = 0x52, F_FUNCION = 0x60 }; La estructura trama se utiliza para que sea más cómodo trabajar con el envío y recepción de mensajes por CAN struct trama{ unsigned char accion; unsigned long remitente; unsigned long destinatario; unsigned long nueva_mac; unsigned char layout; unsigned char valor; unsigned char rcv;
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 84 - unsigned char error; unsigned char flags; unsigned char len; unsigned char datos[8]; }; Se utilizan dos variables globales (datos_rec y datos_env) para el envío y recepción de mensajes de CAN struct trama datos_rec; struct trama datos_env; El array buffer se utiliza para almacenar los caracteres recibidos por 232 hasta que son procesados. El código fuente es el mismo tanto para el nodo como para la pasarela, y es mediante la variable IS_232 como se indica como va a comportarse el nodo. unsigned char buffer_232[64]; unsigned char IS_232 = TRUE; Mediante estas variables se define donde comienzan los distintos bloques de memoria. De esta forma, si el tamaño del programa crece demasiado, se puede desplazar el inicio de los demás bloques sin necesidad de modificar el resto de código. unsigned long MEM_MAC = 0x2000; unsigned long MEM_ACCIONES = 0x2040; unsigned long MEM_FUNCIONES = 0x3000; El main, después de inicializar todos los datos, ejecuta un bucle infinito, que lo único que hace es leer el bus CAN y, si el código es para la pasarela, el bus 232. void main() { Init_IO(); Init_CAN(); Init_DATOS();
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 85 - LATA = 0x00; while( TRUE ) { if(IS_232){ Leer_232(); } Leer_Can(); } } El método Init_DATOS, lee la MAC del nodo, y si esta es 0x00000000, se queda en un bucle hasta que recibe el mensaje de cambiar la MAC. void Init_DATOS(void){ unsigned char esperar; FLASH_Read_N_Bytes(MEM_MAC,buffer,4); MAC = 0x00000000; MAC |= buffer[0]<<8; MAC |= buffer[1]; MAC |= MAC<<16; MAC |= buffer[2]<<8; MAC |= buffer[3]; if( MAC == 0x00000000 ){ esperar = TRUE; while( esperar ){ Leer_Can(); if( MAC != 0x00000000 ){ do_BORRAR(); esperar = FALSE; } } } } El método Leer_CAN, intenta leer un mensaje del bus de CAN, y si el mensaje es para el nodo, se llamará al método Parser_CAN. void Leer_CAN(void){ unsigned char i;
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 86 - datos_rec.rcv = CANRead(&datos_rec.destinatario, datos_rec.datos , &datos_rec.len, &datos_rec.flags); datos_rec.accion = NADA; if( datos_rec.rcv ) { if( datos_rec.destinatario == MAC ){ for( i = datos_rec.len ; i < 8 ; i++){ datos_rec.datos[i]=0x00; } Parser_CAN(); } } } El método Parser_CAN, lo único que tiene es un switch con un case para cada uno de los tipos de mensaje que se pueden recibir, y llama al método que corresponda en cada caso. Función para modifica la MAC. Como el procedimiento para escribir en la memoria flash trabaja en bloques de 64 bytes, primero hay que leer un bloque entero, modificar la parte que queremos y escribimos todo el bloque. void do_CAMBIAR_MAC(void){ FLASH_Read_N_Bytes(MEM_MAC,buffer,64); MAC = datos_rec.nueva_mac; buffer[0] = MAC>>24 & 0xFF; buffer[1] = MAC>>16 & 0xFF; buffer[2] = MAC>> 8 & 0xFF; buffer[3] = MAC & 0xFF; FLASH_Erase_Write_64(MEM_MAC, buffer); } Función para añadir una nueva acción. En este caso, hay que modificar el bit correspondiente a la función que añadimos en la zona de configuración y calcular el bloque y la posición en el que hay que escribir los datos de la acción. void do_CONFIGURAR_ACCION(void){ datos_rec.accion--; bloque = datos_rec.accion>>3; offset = bloque<<3 & 0xFF; offset = datos_rec.accion - offset; FLASH_Read_N_Bytes(MEM_MAC,buffer,64);
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 87 - buffer[bloque+16] |= 0x40>>offset; FLASH_Erase_Write_64(MEM_MAC, buffer); offset = offset<<3 & 0xFF; FLASH_Read_N_Bytes(MEM_ACCIONES + ( bloque * 64), buffer, 64 ); buffer[offset] = datos_rec.tipo; if( datos_rec.tipo == C_ACCION_REMOTA){ buffer[offset+1] = datos_rec.nueva_mac>>24 & 0xFF;; buffer[offset+2] = datos_rec.nueva_mac>>16 & 0xFF; buffer[offset+3] = datos_rec.nueva_mac>>8 & 0xFF; buffer[offset+4] = datos_rec.nueva_mac & 0xFF; buffer[offset+5] = datos_rec.funcion_remota; }else{ buffer[offset+1] = datos_rec.entrada_mascara; buffer[offset+2] = datos_rec.entrada_valor; buffer[offset+3] = datos_rec.salida_mascara; buffer[offset+4] = datos_rec.salida_valor; buffer[offset+5] = datos_rec.tiempo; } buffer[offset+6] = datos_rec.funcion_next; buffer[offset+7] = 0x00; FLASH_Erase_Write_64(MEM_FUNCIONES + ( bloque * 64), buffer); } Para borrar las funciones, solo hay que poner a 0 los bits de la parte de configuración. void do_BORRAR_FUNCIONES(void){ unsigned char i; FLASH_Read_N_Bytes(MEM_MAC,buffer,64); for( i=16 ; i<32 ; i++ ){ buffer[i]=0x00; } FLASH_Erase_Write_64(MEM_MAC, buffer); } El método “do_EJECUTAR_ACCION”, puede ser llamado como resultado de una “función” o por una llamada de ejecutar una función remota. void do_EJECUTAR_ACCION(unsigned char acc){ unsigned char mascara; unsigned char valor; unsigned char tiempo; unsigned char i; acc--; bloque = acc>>3; offset = bloque<<3 & 0xFF; offset = acc - offset; FLASH_Read_N_Bytes(MEM_MAC,buffer,64);
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 88 - if( buffer[bloque+16] & 0x40>>offset ){ offset = offset<<3 & 0xFF; FLASH_Read_N_Bytes(MEM_ACCIONES + ( bloque * 64), buffer, 64 ); if( buffer[offset] == C_ACCION_REMOTA ){ datos_env.tipo = F_FUNCION; datos_env.destinatario = 0x00000000; datos_env.destinatario |= buffer[offset+1]<<24; datos_env.destinatario |= buffer[offset+2]<<16; datos_env.destinatario |= buffer[offset+3]<<8; datos_env.destinatario |= buffer[offset+4]; datos_env.funcion = buffer[offset+5]; Enviar_CAN(); }else{ tiempo = buffer[offset+5]; mascara = buffer[offset+1]; valor = buffer[offset+2]; for( i=0; i<8 ; i++ ){ if( mascara & 0x40>>i){ if( valor & 0x40>>i ){ Tiempos_Entradas[i]=tiempo; }else{ Tiempos_Entradas[i]=0x00; } } } mascara = buffer[offset+3]; valor = buffer[offset+4]; for( i=0; i<8 ; i++ ){ if( mascara & 0x40>>i){ if( valor & 0x40>>i ){ Tiempos_salidas[i]=tiempo; }else{ Tiempos_salidas[i]=0x00; } } } } } } El método “Comprobar_Salidas” es el que se encarga cambiar el estado de las salidas. Está asociado a una interrupción que se lanza cada 250ms. void Comprobar_Salidas(void){ unsigned char N_LATA; unsigned char i; N_LATA = 0x00; for( i=0 ; i<8 ; i++){
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 89 - if( Tiempos_Salidas[i] > 0 ){ N_LATA |= 0x40>>i; if( Tiempos_Salidas[i] < 0xFF ){ Tiempos_Salidas[i]--; } } } LATA = N_LATA; } El método “Comprobar_Entradas” es el encargado de comprobar el estado las entradas, y de lanzar una acción cuando se cumple alguna función. Al igual que “Comprobar_Salidas” está asociado a una interrupción que se lanza cada 250ms void Comprobar_Entradas(void){ unsigned char acc_act; unsigned char tiempo; entradas_actual = PORTC; if( entradas_anterior != entradas_actual && ~entradas_actual ){ estado_actual = pulso_XX(entradas_actual,2); tiempo = 2 + pulso_TM(entradas_actual); if( estado_actual && (NUM_ACCIONES > 0) ){ for( acc_act = 0 ; acc_act < NUM_FUNCIONES ; acc_act++){ FLASH_Read_N_Bytes(MEM_ACCIONES + ( acc_act * 8), buffer, 8 ); if( !( (estado_actual & buffer[0]) ^ buffer[1] ) ){ if( tiempo >= buffer[4] ){ do_EJECUTAR_ ACCION (buffer[5]); entradas_anterior = entradas_actual; return; } } } } } entradas_anterior = entradas_actual; }
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 90 -
Software para un sistema domótico basado en CAN Salvador Arnal Julián - 91 - ANEXO C : Palabras clave CAN, PIC, PIC18, PIC18F2580, RS232, MCP2551, DOMOTICA, MICROCHIP