TouCAN : mejora y ampliación de funcionalidades

Trabajo Final de Grado en Ingenier´ıa Inform´atica TouCAN: Mejoras y Ampliaci´on de Funcionalidades Aridany Santana S´anchez Tutores Antonio Carlos Dom´ınguez Brito Jorge Cabrera G´amez 30 de noviembre de 2014 Agradecimientos Me gustar´ıa comenzar este documento mostrando mi agradecimiento a todas aquellas personas que de forma directa o indirecta han colaborado en la realizaci´on este proyecto. En primer lugar agradecer a mis tutores Jorge Cabrera G´amez y Antonio Carlos Dom´ınguez Brito el apoyo y asesoramiento recibido durante el desarrollo de este Trabajo Final de Grado (TFG). Mis m´as sincero agradecimiento a mi familia por su ´animo, paciencia y motivaci´on durante la realizaci´on de este trabajo. Por ´ultimo, me gustar´ıa felicitar a John Wu Wu[24] y Jose Antonio Lardo Dom´ıguez [22] por el trabajo realizado en sus respectivos TFG que dieron origen a la primera versi´on de la librer´ıa TouCan v1.0 y que ha sido la base de este TFG. i ii Resumen TouCAN es una librer´ıa creada en su primera versi´on (v1) como Trabajos de Fin de Grado en Ingenier´ıa Inform´atica por John Wu Wu[24] y Jose Lareo Dom´ınguez[22] bajo la tutorizaci´on de los profesores Antonio C. Dom´ınguez Brito y Jorge Cabrera G´amez. Define un protocolo de comunicaci´on para la interconexi´on de una red de microcontroladores basados en la plataforma de prototipado electr´onico Arduino y trabaja sobre el protocolo de comunicaci´on CAN Bus (Controller Area Network)[4], ampliamente utilizado por la industria desde la d´ecada de los 80. El objetivo principal de este Trabajo Final de Grado en Ingenier´ıa Inform´atica consiste en proporcionar robustez a la librer´ıa incorporando mejoras y nuevas funcionalidades. Entre las principales mejoras destacan el control frente a fallos de comunicaci´on, reinicio o reset de los microcontroladores, as´ı como la ca´ıda de los mismos. Otra caracter´ıstica incluida en esta revisi´on consiste en la asignaci´on din´amica de identificadores de dispositivos que conforman un sistema empotrado distribuido, permitiendo la posibilidad de “conexi´on en caliente” de nuevos nodos microcontroladores a la red de forma din´amica. A estos cambios, tambi´en se han a˜nadido mejoras en la interfaz de la API que simplifica el uso y aprendizaje de la misma. As´ı como una nueva herramienta denominada TouCANSniffer que permite capturar y analizar todo el tr´afico generado en la red. En nuestra opini´on, las nuevas caracter´ısticas y funcionalidades a˜nadidas en TouCAN v2.0 proporcionan el potencial necesario para ser considerada seriamente como base de cualquier nuevo proyecto que integre una red distribuida de microcontroladores. iii iv Abstract TouCAN is library created in its first version as Final Degree Projects in Computer Science by John Wu Wu[24] and Jose Lareo Dom´ınguez[22] under the supervision of professors Antonio C. Dom´ınguez Brito and Jorge Cabrera G´amez. It defines a communication protocol for interconnecting a network of microcontrollers based on the electronic prototyping platform Arduino. It operates using the CAN (Controller Area Network)[4] bus communication protocol that has been widely used by the industry since the 80s. TouCAN stands out as a light, friendly and robust library. The main goal of this Final Degree Project in Computer Science is to provide robustness to the library including new functionality and improvements. Some of the main included new features are: control against communication failures, restarting and reset of microcontrollers, and detection devices which have stopped operation. Also another included feature is the dynamic assignment of identifiers for devices that allow us to hot plug new nodes dinamically. Moreover, we have also included further improvements which simplify the use and learning. In addition there is also new tool called TouCANSniffer that allow us capture and analyze all packets generated in the network. All these new improvements included in TouCAN give the library the robustness necessary to be used in any project which integrates a microcontroller network. v vi ´ Indice General 1. Introducci´on 1 1.1. Estadoactual ............................. 1 1.2. Objetivos................................ 2 2. An´alisis del Problema 3 2.1. TouCAN Microcontrolador . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Topolog´ıa ........................... 4 2.1.2. TouCANTrama........................ 6 2.1.3. TouCAN Tipos de Comunicaciones . . . . . . . . . . . . . . 8 2.1.4. Tramas s´ıncronas . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.5. Tramas as´ıncronas . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.6. TouCAN Estructuras de Datos . . . . . . . . . . . . . . . . 12 2.1.6.1. TouCAN - Estructura tCAN . . . . . . . . . . . . 12 2.1.6.2. TouCAN - Estructura node . . . . . . . . . . . . . 13 2.1.6.2.1. Identificadores . . . . . . . . . . . . . . . 15 2.1.7. TouCAN Plantillas . . . . . . . . . . . . . . . . . . . . . . 16 2.2. TouCANSupervisor.......................... 17 2.2.1. Trama ............................. 17 3. Competencias 19 3.1. CII01.................................. 19 3.2. CII02.................................. 19 3.3. CII04.................................. 20 3.4. CII18.................................. 20 4. Aportaciones 21 5. Normativa y Legislaci´on 23 5.1. Normativa ............................... 23 5.1.1. Ley Org´anica de Protecci´on de Datos. . . . . . . . . . . . . 23 5.1.2. C´odigoTipo.......................... 23 5.1.3. Inscripci´on de un programa inform´atico en LOPD . . . . . . 23 5.2. Licencias................................ 24 vii 4Cap´ıtulo 2. An´alisis del Problema 2.1. TouCAN Microcontrolador TouCAN Microcontrolador es una API que facilita la interconexi´on de la plataforma Arduino en una red con topolog´ıa CAN Bus. Est´a basada en la librer´ıa ARCAN[23] dot´andola de un sencillo protocolo de comunicaci´on. Entre sus principales caracteristicas destacan: la facilidad de uso y la optimizaci´on de los recursos del dispositivo. 2.1.1. Topolog´ıa En la primera versi´on de TouCAN v1.0 se definen tres tipos de nodos o dispositivos que pueden coexisitir en una red de microcontroladores: Esclavo o nodo com´un: Son los nodos pasivos en la red. No inician peticiones por iniciativa propia, s´olo atienden las peticiones de los Masters. Actuan como nodo sensores y/o actuadores en una red de microcontroladores. Maestro: A diferencia de los nodos Esclavos, puede iniciar una comunicaci´on con otros nodos en la red o conectarse a un Supervisor. Supervisor: A diferencia de los nodos anteriores, no se conecta directamente a la red bus CAN[4] sino a trav´es de los nodos Maestros. Entre sus tareas cabe destacar la monitorizaci´on del bus, iniciar peticiones a trav´es de algunos de los nodos maestros, establecer velocidades de transmisi´on, etc. La siguiente imagen 2.1 representa un esquema b´asico de una red TouCAN compuesta por tres nodos Esclavos, dos Maestros y un Supervisor. 2.1. TouCAN Microcontrolador 5 Figura 2.1: Esquema red TouCAN v1.0 6Cap´ıtulo 2. An´alisis del Problema 2.1.2. TouCAN Trama El protocolo bus CAN[4] define dos tipos de tramas que difieren en la longitud del campo identificador. La trama est´andar definida en la especificaci´on 2.0A tiene un ID de 11 bits mientras el identificador de la trama extendida asciende a 29 bits y est´a definida en la especificaci´on 2.0B. TouCAN hace uso de la trama extendida para definir su propio protocolo. Utiliza los 29 bits del campo identificador para establecer el origen, destino y el tipo de trama. La imagen 2.2 muestra las diferencias entre una trama CAN 2.0B[4] y una trama TouCAN. Por otro lado, la figura 2.3 contiene un ejemplo de estructura TouCAN. ID0..ID10: 11 bits reservados para establecer el origen del mensaje. EID0..EID10: 11 bits reservados para identificar el destinatario del mensaje. EID11..EID15: 5 bits utilizados para identificar el tipo de trama. La versi´on TouCAN v1.0 implementa tan solo 6 tipos de tramas de las 32 posibles. EID16..EID17: Bits inutilizados en la versi´on TouCAN v1.0. DLC0..DLC03: 4 Bits destinados a especificar la longitud del campo de datos. Data field: El protocolo establece un m´aximo de 8 bytes para el campo de datos. Figura 2.2: Comparativa entre una trama CAN 2.0B y TouCAN Trama 2.1. TouCAN Microcontrolador 7 Figura 2.3: Trama TouCAN 8Cap´ıtulo 2. An´alisis del Problema 2.1.3. TouCAN Tipos de Comunicaciones El protocolo TouCAN define dos tipos de comunicaciones: s´ıncrona: Este tipo de petici´on garantiza la recepci´on de la respuesta a una determinada solicitud. ´ Util para solicitar un dato puntual a un dispositivos de la red. La siguiente imagen 2.4 representa un ejemplo de comunicaci´on s´ıncrona. Figura 2.4: Ejemplo petici´on s´ıncrona 2.1. TouCAN Microcontrolador 9 as´ıncrona: A diferencia de la petici´on s´ıncrona, no se garantiza la recepci´on de todos los mensajes. La comunicaci´on es establecida por un nodo master que solicita a otro nodo el env´ıo peri´odico de un dato hasta que la petici´on sea cancelada. La siguiente imagen 2.5 muestra un ejemplo de petici´on as´ıncrona entre un nodo Maestro y otro Esclavo. El Maestro establece una comunicaci´on as´ıncrona y espera la recepci´on de N paquetes antes de finalizar la comunicaci´on con el Esclavo. Figura 2.5: Ejemplo petici´on As´ıncrona. Nodo Maestro solicita N paquetes a nodo Esclavo 10 Cap´ıtulo 2. An´alisis del Problema 2.1.4. Tramas s´ıncronas Request (petici´on): Codificaci´on en el protocolo,00000 (macro REQU). Esta trama es la responsable de realizar una petici´on s´ıncrona. ´ Unicamente puede ser emitida por un nodo Master o Supervisor. Garantiza la respuesta o en su defecto, informan de la p´erdida del paquete para realizar un reintento. El usuario tiene total libertad para utilizar el campo de datos e implementar un protocolo sobre TouCAN. Answer (respuesta): Esta trama es utilizada por cualquier nodo de la red para responser a una petici´on request. Est´a codificada con el valor 00001 (macro ANSW ). La figura 2.6 muestra un ejemplo de comunicaci´on s´ıncrona entre un nodo Maestro y Esclavo donde se especifica el nombre y el c´odigo de cada una de las tramas que intervienen. Figura 2.6: Ejemplo petici´on S´ıncrona 2.1. TouCAN Microcontrolador 11 2.1.5. Tramas as´ıncronas Start (comienzo): Codificaci´on en el protocolo: 00011 (macro STRT). Es enviada por un nodo Master o Supervisor para solicitar al destinatario que le envie un conjunto de datos de forma peri´odica. La frecuencia de env´ıo se indica en milisegundos en el primer byte de datos del mensaje. El resto de datos son libres para que el usuario los utilice para implementar otro protocolo a un nivel superior. Acknowledge (reconocimiento): Codificaci´on en el protocolo 01000 (macro ACKN). Esta trama es esperada por un maestro inmediatamente despu´es de enviar un “start” o “stop”. Bulk (env´ıo masivo): Codificaci´on en el protocolo 00101 (macro BFRM). Esta trama no garantiza la recepci´on del paquete y es utilizada como respuesta a una petici´on de tipo “start”. (Respuesta as´ıncrona) Stop (finalizaci´on): Codificaci´on en el protocolo: 00100 (macro STOP). Informa al destinatario el cese de env´ıo de paquetes as´ıncronos, “bulk”. Reject: Codificaci´on en el protocolo, 00010 (macro REJE). Informa que no ha sido posible atender la petici´on, indicando el motivo por el cual ha sido rechazada. Un Maestro o Supervisor puede mantener comunicaciones s´ıncronas y as´ıncronas con un mismo nodo de forma simult´anea. Sin embargo, un nodo com´un o Esclavo no puede mantener comunicaciones simult´aneas con m´a de un maestro o supervisor. La siguiente imagen 2.7 muestra un ejemplo de comunicaci´on as´ıncrona entre un nodo Maestro y Esclavo donde se especifica el nombre y el c´odigo de cada una de las tramas que intervienen. Figura 2.7: Ejemplo petici´on As´ıncrona entre un nodo Maestro y otro Esclavo 12 Cap´ıtulo 2. An´alisis del Problema 2.1.6. TouCAN Estructuras de Datos TouCAN v1.0 define dos tipos de estructuras de datos denominadas: node y tCAN. La primera representa un nodo en la red y es utilizada por los dispositivos Maestros. La segunda define la estructura de un mensaje TouCAN utilizada en el envio y recepci´on de mensajes por los distintos nodos que conforman un determinado sistema. 2.1.6.1. TouCAN - Estructura tCAN tCAN es la estructura que representa un mensaje en la librer´ıa TouCAN. Act´ua como buffer de recepci´on y transmisi´on del MCP2515[8] al enviar o recibir mensajes a trav´es del bus CAN[4]. El siguiente fragmento de c´odigo representa una estructura tCAN. typedef struct { unsigned int i d s ; unsigned int i d d ; int frametype ; str uct { byte r t r : 1 ; byte l e n g t h : 4; }header ; byte data [ 8 ] ; }tCAN ; id s: Almacena el ID de origen del mensaje. id d: Almacena el ID destinatario del mensaje. frametype: Identifica el tipo de trama a enviar. struct header: Almacena el tipo de trama a nivel de CAN y la longitud del campo de datos. data[8]: Contiene los datos del mensaje. 2.1. TouCAN Microcontrolador 13 2.1.6.2. TouCAN - Estructura node Esta estructura es utilizada exclusivamente por los dispositivos Maestros y representa de forma l´ogica un nodo en la red. Se define est´aticamente en un vector de nodos en cada Maestro. typedef struct { unsigned int id ; // synchronous par t boolean S s u p e r v i s o r o p ; float S timestamp ; byte S answer ; byte S l e n g t h ; byte S data [ 8 ] ; // Asynchronous par t bo olea n A s u p e r v i s o r o p ; float A timestamp ; byte A ack ; byte w r i t t e n ; byte A length ; byte A data [ 8 ] ; }tCAN ; // v e c t o r de node node nodes [NNODES + 1 ] ; id: ID del dispositivo con el que se ha iniciado una comunicaci´on. S supervisor op: Se trata de un campo que indica si la comunicaci´on s´ıncrona con el nodo ha sido iniciada por el maestro o por el supervisor (recordemos que si bien un supervisor no est´a conectado directamente a la red, puede realizar peticiones a otros nodos a trav´es del maestro al que se encuentra conectado). Sus valores posibles son true si es una comunicaci´on del supervisor y false si es del maestro. S timestamp: Cuando el valor es mayor que 0 indica que existe una comunicaci´on s´ıncrona con otro nodo. S answer: Indica que se ha recibido una respuesta s´ıncrona del nodo destino. Los posibles valores son: 0No se ha recibido respuesta. 1Se ha recibido una respuesta. 2Se ha recibido una respuesta, pero esta ha sido rechazada. Nota: Si se trata de una petici´on de otro maestro, esta propiedad adquiere otro significado, siendo 0 que el maestro no ha recibido peticiones de otros maestros ´o 1 en caso contrario. S length: Almacena la longitud del campo de datos recibidos, corespondiente a una respuesta s´ıncrona. 20 Cap´ıtulo 3. Competencias 3.3. CII04 Capacidad para elaborar el pliego de condiciones t´ecnicas de una instalaci´on inform´atica que cumpla los est´andares y normativas vigentes. Esta competencia queda cubierta en el cap´ tulo “Pliego de Condiciones” 8 donde se especifican cada una de las condiciones asociadas al proyecto. 3.4. CII18 Conocimiento de la normativa y la regulaci´on de la inform´atica en los ´ambitos nacional, europeo e internacional. El cumplimiento de esta competencia queda descrita en el cap´ıtulo “Normativa y Legislaci´on” 5. Cap´ıtulo 4 Aportaciones Actualmente la comunidad Arduino est´a en auge. Multitud de empresas y usuarios apuestan por esta tecnolog´ıa para llevar a cabo proyectos de gran envergadura en distintas ´areas como la rob´oticia, dom´otica, videojuegos, electrodom´esticos entre otros. Por otro lado CAN[4] es un protocolo asentado utilizado por la industria desde hace varias d´ecadas. TouCAN se cre´o con el objetivo inicial de proporcinar una librer´ıa software libre f´acil de utilizar y optimizada para microcontroladores con pocos recursos, que tomara ventaja de las capacidades de una red de plataformas Arduinos conectados a trav´es de una red CAN Bus. Este proyecto ha aportado un nivel m´as de robutez a la librer´ıa TouCAN aportando mejoras relacionadas con la detecci´on y recuperaci´on de fallos de comunicaciones y reset de los microcontroladores. La asignaci´on din´amica simplifica comunicaci´on entre dispositivos y permite la conexi´on en “Caliente”. TouCANSniffer facilita la tarea de debug analizando el tr´afico de mensajes en la red. Todas estas aportaciones convierten a TouCAN en una herramienta a ser considerada seriamente en proyectos donde se desee integrar redes de microcontroladres de forma econ´omica, sencilla, eficiente y libre. 21 22 Cap´ıtulo 4. Aportaciones Cap´ıtulo 5 Normativa y Legislaci´on A continuaci´on se incluye la legislaci´on vigente que afecta al presente Trabajo Fin de Grado. 5.1. Normativa 5.1.1. Ley Org´anica de Protecci´on de Datos. La presente Ley Org´anica de Protecci´on de Datos [12] tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades p´ublicas y los derechos fundamentales de las personas f´ısicas, y especialmente de su honor e intimidad personal y familiar. Es de aplicaci´on a los datos de car´acter personal registrados en soporte f´ısico, que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores p´ublico y privado. 5.1.2. C´odigo Tipo Se definen como c´odigos deontol´ogico o de buena conducta o pr´actica profesionales. Est´an regulados en la Ley Org´anica de Protecci´on de Datos de Car´acter Personal[12], que es la que establece en nuestro pa´ıs los cimientos b´asicos de los aspectos legales en cuanto a protecci´on de datos de car´acter personal se refiere. Tienen por objeto adecuar lo establecido en la LOPD y en el RLOPD a las peculiaridades de los tratamientos efectuados por quienes se adhieren a ellos, conteniendo reglas o est´andares espec´ıficos con el objetivo de armonizar los tratamientos de datos efectuados por los adheridos; facilitar el ejercicio de los derechos de los afectados y, en definitiva, favorecer el cumplimiento de lo dispuesto en la normativa de protecci´on de datos. 5.1.3. Inscripci´on de un programa inform´atico en LOPD A continuaci´on se detalla los requisitos necesarios para la inscripci´on de un programa inform´atico en la LOPD. 23 24 Cap´ıtulo 5. Normativa y Legislaci´on La totalidad del c´odigo fuente, en CD-ROM o en soporte papel, debidamente encuadernada y paginada. En los programas de ordenador editados ha de presentarse un resumen por escrito de al menos 20 folios del c´odigo fuente, siempre y cuando reproduzcan elementos esenciales del mismo. Deber´a ir encuadernado y con portada donde figure el t´ıtulo y autor de la obra. Una memoria en soporte papel, debidamente encuadernada y paginada con el resumen de la aplicaci´on, el lenguaje de programaci´on, el entorno operativo, el listado de nombres de los ficheros que contiene y el diagrama de flujo. Puede aportarse el ejecutable del programa, de forma opcional. Los escritos y solicitudes que se dirijan a cualqueira de las oficinas del Registro podr´an presentarse en las formas y ante los ´organos que prev´e la ley 30/1992, de R´egimen Jur´ıdico de las Administraciones P´ublicas y del Procedimiento Administrativo Com´un. Tambi´en podr´an presentarse en cualquiera de los registros a que se refiere el presente reglamente, tanto central como territorial, lo cuales los remitir´an, el dia siguiente al de su presentaci´on, al registro indicado en la solicitud. 5.2. Licencias A continuaci´on se detallan algunas de las licencias que afectan al software utilizado durante el desarrollo del presente proyecto. 5.2.1. GNU GPL La Licencia P´ublica General de GNU[9] es la licencia m´as ampliamente usada en el mundo del software y garantiza a los usuarios finales (personas, organizaciones, compa˜n´ıas) la libertad de usar, estudiar, compartir (copiar) y modificar el software. Su prop´osito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiaci´on que restrinjan esas libertades a los usuarios. Esta licencia fue creada originalmente por Richard Stallman fundador de la Free Software Foundation (FSF) para el proyecto GNU. 5.2.2. LGPL La Licencia P´ublica General Menor (del ingl´es: Lesser General Public License o LGPL) [10] es una modificaci´on de la licencia GPL descrita anteriormente. La LGPL permite que los desarrolladores utilicen programas bajo la GPL o LGPL sin estar obligados a someter el programa final bajo dichas licencias. 5.2.3. Eclipse Public License La Licencia P´ublica Eclipse (EPL) [7] es una licencia de software de c´odigo abierto utilizada por la Funciaci´on Eclipse para su software. Est´a dise˜nada para ser una licencia favorable a los negocios. No requiere ning´un seguimiento en los cambios y s´olo exige la publicaci´on del c´odigo fuente cuando las modificaciones 5.2. Licencias 25 se consideran un trabajo derivado y no una extensi´on o un m´odulo separado. Los trabajos derivados deben ser publicados siempre bajo la licencia EPL. 5.2.4. Creative Commons Las licencias Creative Commons[5] ´o CC tienen su origen en la licencia GNU GPL, cuyo objetivo es el de ofrecer al autor de una obra un mecanismo sencillo y efic´az a la hora de establecer una serie de condiciones asociadas a la obra. Las condiciones que se pueden imponer son las siguientes: Reconocimiento (Attribution): En cualquier explotaci´on de la obra autorizada por la licencia har´a falta reconocer la autor´ıa. Figura 5.1: Reconocimiento. No Comercial (Non commercial): La explotaci´on de la obra queda limitada a usos no comerciales. ´o Figura 5.2: No Comercial. Sin obras derivadas (No Derivate Works): La autorizaci´on para explotar la obra no incluye la transformaci´on para crear una obra derivada. Figura 5.3: Sin obras derivadas. Compartir Igual (Share alike): La explotaci´on autorizada incluye la creaci´on de obras derivadas siempre que mantengan la misma licencia al ser divulgadas. Figura 5.4: Compartir Igual. 26 Cap´ıtulo 5. Normativa y Legislaci´on Cap´ıtulo 6 Requisitos Para poder conseguir los objetivos marcados inicialmente del proyecto se ha hecho uso, durante el desarrollo de ´este, de una serie de recursos. Se han desglosado en dos grupos: hardware y software. 6.1. Hardware A nivel de hardware las necesidades fueron las siguientes: 1. Arduino Uno rev3. 4 unidades. 2. CAN-BUS shield. 4 unidades. 3. Protoboard. 4. Resistencias. 2 unidades de 120 ohm. 5. Cables. Par de cobre trenzado. 6. Cables USB de A a B. 4 Unidades 7. PC. En concreto se ha utilizado un PC con CPU Intel Core QuadCore a 2Ghz, Memoria ram de 8GB y una gr´afica GeForce 9400M. 6.2. Sofware A nivel de software fue necesario: 1. Distribuci´on GNU/Linux En concreto se utiliz´o Debian 6.0 de 64 bits. 2. Sofware de desarrollo Eclipse 3.8, GNU g++ y Arduino IDE(processing). 3. Sofware documental LaTexT, ImageMagick 6.7.7-10. 27 28 Cap´ıtulo 6. Requisitos Cap´ıtulo 7 Metodolog´ıa y Plan de Trabajo Como metodolog´ıa de desarrollo se utilizaron las t´ecnicas de desarrollo software propias del Proceso Unificado (Unified Process)[20]. El Proceso Unificado proporciona un marco de desarrollo gen´erico adaptable a proyectos espec´ıficos cuyas caracter´ısticas son las siguientes: 1. Iterativo e Incremental: El Proceso Unificado est´a compuesto por cuatro fases distintas: Inicio, Elaboraci´on, Construcci´on y Transici´on. En cada una de las fases se har´a un determinado n´umero de iteraciones con el objetivo de mejorar e incluir mejoras de funcionalidades dando lugar a un incremento del proyecto en desarrollo. 2. Dirigido por los casos de uso: Por medio de los casos de uso se especificar´a en las iteraciones los requisitos funcionales y los contenidos. 3. Centrado en la arquitectura: En el desarrollo del software no se usar´a un ´unico modelo que describa todo el sistema. Se optar´a por un enfoque con m´ultiples modelos y vistas que describan la arquitectura de software del sistema. 4. Enfocado en los riesgos: Se requiere identificar los riesgos cr´ıticos en una etapa temprana. De este modo los resultados de cada iteraci´on deben seleccionarse en un orden que asegure que los riesgos principales son considerados primero. 29 36 Cap´ıtulo 9. Desarrollo Figura 9.1: Esquema de la red TouCAN v2.0 9.2. Tramas TouCAN 37 9.2. Tramas TouCAN A las tramas ya existentes en la versi´on v1.0 de TouCAN se han incorporado nuevos comandos responsables de la asignaci´on din´amica de ID y de la monitorizaci´on de dispositivos en la red. En esta revisi´on los nodos son reconocidos por un nombre de cinco caracteres. A continuaci´on se detallan las tramas incorporadas en esta revisi´on. 9.2.1. Proceso de asignaci´on din´amica de ID Request ID: Codificaci´on en el protocolo, 11100 (macro REID). Funci´on utilizada por los nodos Master y Slave para solicitar un ID al nodo Server. En los cinco primeros bytes del campo de datos contienen el nombre del dispositivo que realiza la solicitud. La imagen 9.2 corresponde a una trama REID. Data0..Data4 : Los primeros cinco bytes contienen el nombre del dispositivo. Data5..Data7 : Sin utilizar. Figura 9.2: TouCAN v2.0 - Ejemplo trama REID Response ID: Codificado con el valor, 11101 (macro BRID). Trama tipo broadcast, es enviada siempre por el nodo Server a todos los dispositivos de la red, aunque solo es procesada por el nodo que realiz´o la petici´on “Request ID”. La figura 9.3 es un ejemplo de trama BRID. Data0..Data4 : Los primeros cinco bytes contienen el nombre del dispositivo que realiz´o la petici´on. Data5 : Puede contener dos valores, 0 operaci´on realizada con ´exito ´o 255 si se ha producido un error. Data6..Data7 Los dos ´ultimos bytes del campo de datos almacenan el ID asignado al dispositivo o un c´odigo de error seg´un el valor del byte 5. Figura 9.3: TouCAN v2.0 - Ejemplo trama BRID 38 Cap´ıtulo 9. Desarrollo Confirm ID: Codificada en el protocolo con el valor, 11110 (macro BCID). Trama tipo broadcast, enviada por el nodo que realiz´o la petici´on “Request ID” para confirmar el ID asignado al nodo Server e informar al resto de dispositivos Master de la red. Ejemplo de trama BCID en la imagen: 9.4 Data0..Data4 : Los primeros cinco bytes contienen el nombre del dispositivo. Data5..Data7 : Sin utilizar. Figura 9.4: TouCAN v2.0 - Ejemplo trama BCID 9.2.2. Proceso de reconocimiento de dispositivos en la red Request check devices network: Trama codificada con el c´odigo, 11010 (macro BCDN). Es un paquete broadcast, utilizado ´unicamente por el nodo Server para recuperar la lista de dispositivos en la red despu´es de un reinicio. Ejemplo de trama BCDN en la imagen: 9.5 Data0..Data7 : Esta trama no hace uso del campo data. Figura 9.5: TouCAN v2.0 - Ejemplo trama BCDN 9.2. Tramas TouCAN 39 Response check devices network: Codificado en el protocolo con el c´odigo, 11011 (macro RCDN). Respuesta de los nodos Master y Slave a una petici´on “Request check devices network”. El destinatario del paquete el el nodo Server. Ejemplo de trama RCDN en la figura 9.6 Data0..Data4 : Los primeros cinco bytes contienen el nombre del dispositivo. Data5..Data7 : Sin utilizar. Figura 9.6: TouCAN v2.0 - Ejemplo trama RCDN 9.2.3. Proceso verificaci´on de estados de los dispositivos. Request echo: Codificada en el protocolo con el valor, 11000 (macro ECSE). Paquete echo enviado por el nodo Server a cada uno de los dispositivos de la red para verificar cuales est´an activos y cuales no. La imagen 9.7 corresponde a un ejemplo de trama ECSE. Data0..Data7 : Esta trama no hace uso del campo data. Figura 9.7: TouCAN v2.0 - Ejemplo trama ECSE Response echo: Codificaci´on en el protocolo con el valor, 11001 macro (REEC). Emitido por los nodos Master y Slave como respuesta a una petici´on “Request echo”. Ejemplo de trama REEC en la figura: 9.8 Data0..Data7 : Esta trama no utiliza el campo data. Figura 9.8: TouCAN v2.0 - Ejemplo trama REEC 40 Cap´ıtulo 9. Desarrollo Remove device: Codificado en el protocolo con el valor, 10100 (macro ECRD). Paquete broadcast utilizado para informar que un dispositivo ha causado baja en la red. Enviado por el nodo Server y procesado ´unicamente por los nodos Master. Los dos primeros bytes del campo de datos almacenan el ID del nodo a eliminar. Este paquete permite mantener actualizada la lista de dispositivos de todos los nodos Master de la red. Data0..Data1 : Identificador del dispositivo que ha causado baja en la red. Data5..Data7 : Sin utilizar. Figura 9.9: TouCAN v2.0 - Ejemplo trama ECRD 9.2.4. Proceso actualizaci´on lista dispositivos - Nodo Maestro Request devices list: Codificado con el c´odigo, 10101 (macro: DLGT). Trama utilizada por un nodo Master para solicitar la lista completa de dispositivos al nodo Server. La imagen 9.10 corresponde a un ejemplo de la trama DLGT Data0..Data7 : Esta trama no hace uso del campo data. Figura 9.10: TouCAN v2.0 - Ejemplo trama DLGT 9.2. Tramas TouCAN 41 Response devices number: Codificaci´on en el protocolo con el valor, 10110 (macro DLNU). Devuelve el n´umero de dispositivo en en los dos primeros bytes del campo de datos. Enviado por el nodo Server al Master que realiz´o la petici´on: “Request devices list”. Ejemplo de trama en la figura: 9.11 Data0..Data1 : N´umero de registros en la tabla de dispositivos. Data2..Data7 : Sin utilizar. Figura 9.11: TouCAN v2.0 - Ejemplo trama DLNU Response device name: Codificaco en el protocolo con el valor, 10111 (macro DLNA). Este paquete es utilizado por el nodo Server para enviar al Master la lista de dispositivos. Env´ıa tantos paquetes como dispositivos contenga la tabla. El campo de datos contiene el ID y el nombre del nodo. Data0..Data4 : Los primeros cinco bytes contienen el nombre del dispositivo. Data5..Data6 : Identificador del dispositivo Data7..Data7 : Sin utilizar Figura 9.12: TouCAN v2.0 - Ejemplo trama DLNA 42 Cap´ıtulo 9. Desarrollo 9.3. Refactorizaci´on y Optimizaci´on Antes de comenzar con la desarrollo de las nuevas funcionalidades se consideraron necesarias la optimizaci´on de algunos aspectos de la librer´ıa con la ´unica finalidad de facilitar la implementaci´on de las nuevas mejoras. Los siguientes apartados describen los cambios realizados. 9.3.1. Refactorizaci´on La liber´ıa TouCAN est´a compuesta por una ´unica clase con las propiedades y m´etodos de los distintos nodos en un ´unico archivo. Esto no impide a un nodo Esclavo iniciar una comuniciaci´on con otros dispositivos, cuando por definici´on los nodos Esclavos son dispositivos pasivos que no pueden comenzar una comunicaci´on. Por otro lado, a medida que aumenta la complejidad de la librer´ıa, con mejoras y nuevas funcionalidades, esta estrategia puede resultar dif´ıcil de mantener. Con la finalidad de mantener la premisia inicial de una librer´ıa amigable y f´acil de ampliar se decidi´o refactorizar la librer´ıa aplicando el principio de responsabilidad ´unica SRP [19]. Donde, cada objeto debe tener una simple responsabilidad, y que debe estar contenida ´unicamente en la clase. Las dos im´agenes a continuaci´on muestran una comparativa entre los diagramas de clases de TouCAN revisi´on v1.0 y v2.0 Figura 9.13: Diagrama Clases, TouCAN v1.0 9.3.1.1. Descripci´on Clases A continuaci´on se describen las caracter´ısticas principales de cada una de las clases de la librer´ıa TouCAN revisi´on v2.0. tCAN: Representa un mensaje en la librer´ıa TouCAN. Act´ua como buffer de recepci´on / transmisi´on del MCP2515[8] al enviar o recibir mensajes a trav´es del bus CAN[4] TouCANSPIManager: Encapsula todas las operaciones espec´ıficas sobre el controlador MCP2515[8]. Es el responsable, en ´ultima instancia, en transmitir/- recibir los mesajes a trav´es del bus CAN[4]. TouCANNodeBase: Clase abstracta. Encapsula los m´etodos y propiedades comunes a TouCANNode y TouCANSniffer. 9.3. Refactorizaci´on y Optimizaci´on 43 Figura 9.14: Diagrama de clases, TouCAN v2.0 TouCANNode: Clase abstracta. Encapsula todas las operaciones comunes a los distintos nodos. Entre sus responsabilidades destaca la inicializaci´on del dispositivo, la solicitud de un identificador y la respuesta a una petici´on s´ıncrona/asincrona. TouCANSniffer: Esta clase deriva de TouCANNode y a˜nade los m´etodos necesarios para recopilar todos los paquetes de la red y reenviarlos a un nodo SupervisorSniffer a trav´es del puerto serie. TouCANSlave: Esta clase hereda de TouCANNode y representa un dispositivo Esclavo. Contiene todas las operaciones espec´ıficas del nodo. TouCANMasterBase: Clase abastracta que deriva de TouCANNode y contiene las funciones comunes a los nodos: Maestro y Servidor. TouCANMaster: Esta clase hereda de TouCANMasterBase y representa un dispositivo tipo Maestro. Contiene todas las operaciones esec´ıficas del nodo. TouCANServer: Esta clase hereda de TouCANMasterBase y representa un dispositivo TipoServer. Contiene todas las operaciones espec´ıficas del nodo. TouCANConnectionTable: Esta clase es la responsable de almacenar la informaci´on sobre las comunicaciones activas de un nodo tipo Maestro o Servidor con el resto de dispositivos en la red. El tama˜no m´aximo es establecido por la constante: TOU CAN CONNECTION TABLE SIZE. La primera posici´on del vector de comunicaciones est´a reservado para atender a las peticiones de otros nodos Maestros o del Servidor. 44 Cap´ıtulo 9. Desarrollo 9.3.2. Tabla de conexiones La tabla de conexi´on surge con la finalidad de reducir el uso de recursos necesarios para mantener la lista de dispositivos y limitar el n´umero de conexiones simult´aneas. Hay que recordar, que en la primera versi´on de TouCAN, el programa de usuario es el responsable de declarar y configurar el vector de nodos est´aticamente. En esta revisi´on la operaci´on recae sobre el propio framework. Este ´ultimo punto est´a directamente relacionado con la optimizaci´on de los m´etodos de la API responsables de enviar/recibir mensajes. La imagen 9.18 reflejan los cambios que esta mejora implica en un programa de usuario. Antes de enviar una trama s´ıncrona o as´ıncrona es necesario llamar al m´etodo, getDeviceIDByName(...), para obtener el ID del dispositivo con el que se desea establecer una comunicaci´on. Por otro lado, antes de enviar un paquete, el framework verifica la existencia de una entrada libre en la tabla de comunicaci´on para realizar el env´ıo. Si no hay una disponible el mensaje no es enviado y se notifica al usuario con un mensaje de error. El siguiente diagrama de flujo, imagen:9.15, describe como un nodo Maestro obtiene un nodo de conexi´on antes de enviar un mensaje. Figura 9.15: Diagrama de flujo - Obtener nodo de conexi´on 9.3. Refactorizaci´on y Optimizaci´on 45 Las entradas en la tabla de conexiones son liberadas cuando un dispositivo causa baja en el sistema o al finalizar una comunicaci´on s´ıncrona o as´ıcrona. 9.3.2.1. Estructura de datos TouCANDevice es una estructura de datos que representa un nodo en la red. La clase TouCANDeviceTable define un vector de tama˜no, TOU CAN DEVICE TABLE SIZE, donde almacena la informaci´on correspondiente a cada uno de los dispositivos de la red. typedef struct { unsigned int id ; char name [ 5 ] ; byte s t a t e ; byte c o n n e c t i o n i d ; byte echo ; float t i m e a c t i v i t y ; }TouCANDevice ; unsigned int id: Contiene el ID del dispositivo. char name[5]: Almacena el nombre del dispositivo. byte state: Almacena uno de los siguientes valores: DEVICE STATUS UNINITIALIZED Valor por defecto. Dispositivo no inicializado. DEVICE STATUS PENDING CONFIRMATION Asignaci´on temporal de ID. Pendiente de confirmaci´on por parte del nodo. DEVICE STATUS CONFIRMED Dispositivo inicializado correctamente. byte connection id:Identificador de la tabla de conexi´on asociado al dispositivo. Esta propiedad es configurada al iniciar una comunicaci´on. byte echo: Propiedad utilizada al realizar la tarea de monitorizaci´on de dispositivos en la red. 0Valor por defecto. 1Paqute echo enviado. 2Recibida respuesta a paquete echo. float time activity: Sello temporal del ´ultimo paquete recibido. 52 Cap´ıtulo 9. Desarrollo El m´etodo TouCANServer::checkNodesInNetwork(), disponible ´unicamente en el nodo Servidor, garantiza la recuperaci´on de la tabla de dispositivos despu´es de un reset. El proceso consiste en solicitar el ID y nombre de los dispositivos activos en la red y actualizar la tabla de dispositivo con la informaci´on de cada uno. Es recomendable invocar el m´etodo desde la fuci´on setup del programa de usuario para disponer de los datos actualizados al inicio del programa principal en el servidor. El diagrama de secuencia de la figura 9.25 corresponde a una petici´on de reconocimiento de dispositivos realizada por el nodo Servidor despu´es de un reinicio. Figura 9.25: TouCAN v2.0 - Diagrama de secuencia - checkNodesInNetwork 9.5.1.2. Tramas A continuaci´on se describen las tramas que intervienen en el proceso de recuperaci´on de la tabla de dispositivos de un nodo Servidor depu´es de un reset o reinicio. BCDN: Paquete broadcast, utilizado ´unicamente por el nodo Server para solicitar el ID y nombre de cada uno de los dispositivos de la red. RCDN: Respuesta de los nodos Master y Slave a una petici´on “Request check devices network”. 9.5.1.3. Implementaci´on Como se coment´o en el p´arrafo anterior, el m´etodo responsable de actualizar la lista de dispositivos es checkNodesInNetwork. Este m´etodo env´ıa un paquete broadcast, identificado por la macro BCDN, a todos los dispositivos de la red solicitando el identificador y el nombre de cada uno. La figura 9.26 corresponde a una trama BCDN. Figura 9.26: TouCAN v2.0 - Trama BCDN. Todos los nodos en la red deben responder a un mensaje BCDN con el comando RCDN configurando el campo data con el nombre del dispositivo. La imagen 9.27 9.5. Control frente a fallos de comunicaci´on, reinicio y reset 53 corresponde a una trama RCDN enviada por un nodo con identificador 17 y nombre LUZ01. Figura 9.27: TouCAN v2.0 - Trama RCDN. El nodo Servidor actualiza la lista de dispositivos con la informaci´on obtenida en los paquetes RCDN. Durante el proceso de reconocimiento todos los paquetes distintos de RCDN son descartados. El diagrama 9.28 describe el proceso completo de detecci´on de equipos en la red. 54 Cap´ıtulo 9. Desarrollo Figura 9.28: Diagrama de actividad. Actualizaci´on de la tabla de dispositivo de un nodo Servidor. 9.5. Control frente a fallos de comunicaci´on, reinicio y reset 55 9.5.2. Nodo Master - Actualizar lista dispositivo 9.5.2.1. Descripci´on Un nodo Maestro debe tener la tabla de dispositivos sincronizada con el nodo Servidor en todo momento. Sin embargo, existen diversos escenarios que pueden ocasionar diferencias entre ambas tablas. Reset: El reinicio de un nodo Maestro libera las entradas en la tabla de dispositivo. Conexi´on Supervisor: La conexi´on de un Supervisor a un nodo Maestro genera el reinicio de este ´ultimo. P´erdida de paquetes: La p´erdida de un paquete de confirmaci´on de asignaci´on de ID, BCID. Inicio: Cuando un nodo Maestro inicia con posterioridad a otros dispositivos. La revisi´on v2.0 de TouCAN incorpora un mecanismo que permite a los nodos Maestros solicitar una copia de la tabla de dispositivos a un Supervisor. Esta operaci´on se realiza a trav´es del m´etodo TouCANMaster::getDeviceList y garantiza la sincronizaci´on de la tabla de dispositivos. En la siguiente figura 9.29 el nodo Maestro, MAS01, solicita la lista de dispositivos al nodo Servidor, despu´es de un reset en una red compuesta por cuatro dispositivos. Figura 9.29: TouCAN v2.0 - Diagrama de secuencia - Actualizaci´on lista de dispositivos 56 Cap´ıtulo 9. Desarrollo 9.5.2.2. Tramas A continuaci´on se detallan las tramas que intervienen en el proceso de actualizaci´on de la tabla de dispositivo de un nodo Master. DLGT Trama utilizada por un nodo Master para solicitar la lista completa de dispositivos al nodo Server. DLNU: Devuelve el n´umero de dispositivo en los dos primeros bytes del campo de datos. Enviado por el nodo Server al Master que realiz´o la petici´on: “Request devices list”. DLNA: Este paquete es utilizado por el nodo Server para enviar al Master la lista de dispositivos. Env´ıa tantos paquetes como dispositivos contenga la tabla. El campo de datos contiene el ID y el nombre del nodo. 9.5.2.3. Implementaci´on El proceso de actualizaci´on o sincronizaci´on consiste en solicitar la lista de dispositivos al nodo Servidor a trav´es del comando DLGT. Este envıa en primer lugar una trama con el n´umero de dispositivos almacenados y a continuacion envia tantos paquetes DLNA como entradas existan en la tabla de dispositivos. El diagrama 9.34 describe el proceso de actualizaci´on al completo. A continuaci´on se describe el proceso de sincronizaci´on de la tabla de dispositivos en una red compuesta por cuatro dispositivos: 1. SERVER: Nodo Servidor con identificador 0. 2. MAS01: Nodo Maestro con identificador 1. 3. LUZ01: Nodo com´un con identificador 2. 4. LUZ02: Nodo Esclavo con identificador 3. La imagen 9.30 corresponde a una petici´on DLNA del nodo MAS01. Despu´es de solicitar la lista de dispositivo el nodo queda a la espera de una respuesta por parte del servidor. Durante este proceso, cualquier paquete distinto a DLNU oDLNA son descartados. Figura 9.30: TouCAN v2.0 - Envio trama DLGT El Server recibe la petici´on y env´ıa un primer paquete con el n´umero de dispositivos en la red, comando DLNU. El n´umero de dispositivos no contempla al servidor y al maestro que realiz´o la petici´on. Este escenario est´a compuesto por 4 dispositivos. Sin embargo, el n´umero de nodos enviados corresponde a 2.(LUZ01 y LUZ02) Imagen 9.31 9.5. Control frente a fallos de comunicaci´on, reinicio y reset 57 Figura 9.31: TouCAN v2.0 - Envio trama DLNU A continuaci´on el Servidor envia dos paquetes DLNA correspondiente a los nodos: LUZ01 yLUZ02 que ser´an procesados por MAS01 para actualizar la lista de dispositivos. Im´agenes 9.32 y 9.33 Figura 9.32: TouCAN v2.0 - Envio trama DLNA Figura 9.33: TouCAN v2.0 - Envio trama DLNA 58 Cap´ıtulo 9. Desarrollo Figura 9.34: Diagrama de actividad. Actualizaci´on de la lista de dispositivos de un nodo Master. 9.5. Control frente a fallos de comunicaci´on, reinicio y reset 59 9.5.3. Nodo Server - Verificar estado dispositivos (ECHO) 9.5.3.1. Descripci´on La versi´on inicial de la librer´ıa carece de un mecanismo que permita verificar el estado de los nodos de la red con cierta periodicidad. Esta situaci´on puede afectar de forma negativa al rendimiento del sistema cuando un nodo causa baja y otros continuan enviandole paquetes. La revisi´on TouCAN v2.0 incorpora un mecanismo, denominado ECHO, que verifica el estado de los nodos con cierta periodicidad para determinar cuales continuan activos y cuales no. Los nodos que han causado baja son notificados a los Maestros para que actualicen sus tabla de dispositivos. La siguiente imagen 9.35 describe la secuencia de tramas durante el proceso de vierificaci´on de estado de dispositivos, en una red conformada por cuatro dispositivos: un nodo servidor, dos maestros MAS01 y LUZ01 y un nodo esclavo, ESLAVE. Donde el nodo maestro, LUZ01, ha dejado de estar operativo. Figura 9.35: TouCAN v2.0 - Diagrama de secuencia comando ECHO 60 Cap´ıtulo 9. Desarrollo 9.5.3.2. Tramas En esta secci´on se detallan las tramas que intervienen en el proceso de verificaci´on de dispositivos en la red, ECHO. ECSE: Trama enviada por el nodo Servidor para verificar si alg´un dispositivo a causado baja en el sistema. El comando es enviado a todos los nodos con los cuales no ha mantenido una comunicaci´on en cierto intervalo de tiempo. REEC: Respuesta emitida por los nodos Maestros y Esclavos a una petici´on ECSE. ECRD: Paquete broadcast utilizado para informar que un dispositivo ha causado baja en la red. Enviado por el nodo Servidor y procesado ´unicamente por los nodos Maestros. Los dos primeros bytes del campo de datos almacenan el ID del nodo a eliminar. Este paquete permite mantener actualizada la lista de dispositivos de todos los nodos Master de la red. 9.5. Control frente a fallos de comunicaci´on, reinicio y reset 61 9.5.3.3. Implementaci´on La caracter´ıstica de verificaci´on de dispositivo es exclusiva de los nodos Servidores y consiste en enviar un paquete ECSE a cada uno de los nodos del sistema con una periodicidad establecida por la macro ECHO TIME INTERVAL TO SEND (5minutos). Despu´es de un tiempo de espera establecido por la macro ECHO TIME INTERVAL TO UPDATE (2minutos) el Server comprueba que dispositivos han contestado a la solicitud. Los dispositivos que no han respondido se consideran que han causado baja en el sistema y se notifica a todos los nodos Master de la red a trav´es de la trama broadcast ECRD. Este comando almacena en el campo de datos el ID del dispositivo que ha causado baja. El diagrama 9.40 describe el proceso completo. A continuaci´on se describe el funcionamiento del sistema de verificaci´on de estados de dispositivos en un sistema compuesto por un Servidor, dos Maestros y un Esclavo. Donde en el instante de tiempo que el nodo Servidor inicia el comando ECSE el dispositivo SLAVE no est´a operativo. SERVER: Nodo Servidor con identificador 0. MAS01: Nodo Maestro con identificador 1. SLAVE: Nodo Esclavo con identificador 2. MAS02: Nodo Maestro con identificador 3. El Servidor inicia el proceso de reconocimiento enviando un paquete ECSE al nodo SLAVE yMAC02. Dispositivos con los que no ha mantenido una comunicaci´on en los ´ultimos 5 minutos. Figura 9.36 y 9.37 Figura 9.36: TouCAN v2.0 - Trama ECSE Figura 9.37: TouCAN v2.0 - Trama ECSE 68 Cap´ıtulo 9. Desarrollo Package FrameView: Conjunto de clases que representan cada una de las diferentes tramas del protocolo. La principal responsabilidad de estas clases consiste en dar el formato adecuado al campo DATA antes de almacenar la informaci´on en disco. 9.6. TouCANSniffer 69 9.6.3. TouCANSnifferView TouCANSnifferView es una aplicaci´on web, compatible con la mayor´ıa de los navegadores HTML5, que permite visualizar las tramas generadas por el SupervisorSniffer en una interfaz gr´afica con una experiencia de usuario similar a una aplicaci´on de escritorio. A continuaci´on se describen las tecnologias utilizadas en el desarrollo de la aplicaci´on: Symfony PHP[21]: Es un framework dise˜nado para el desarrollo de aplicaciones web basado en el patr´on Modelo Vista Controlador MVC que separa la l´ogica de negocio de una aplicaci´on de la interfaz de usuario y el m´odulo encargado de gestionar los eventos. Doctrine[6]: Es un mapeador de objetos-relacional (ORM)[16] escrito en PHP que proporciona una capa de persistencia para objetos PHP. Permite convertir datos entre el sistema de tipos utilizado en un lenguage de programaci´on orientado a objetos y el utilizado en una base de datos relacional. Las tablas de la base de datos pasan a ser clases y los registros objetos. AngularJS[2]: Es un framework MVC[14] de JavaScript opensource para el desarrollo web en el lado cliente creado por Google. Permite crar aplicaciones SPA, Single Page Applications. Aplicaci´on web que se ejecuta en una ´unica p´agina, logrando una experiencia de usuario m´as cercana a una aplicaci´on de escritorio. BootStrap[3]: Es un framework de software libre, desarrollado por Twitter, para el dise˜no y desarrollo de aplicaciones web. Proporciona un conjunto de plantillas y elementos de dise˜no basado en HTML. MariaDB[13]: Sistema de gesti´on de base de datos derivado de MysSQL[15] con licencia GPL. La figura 9.45 corresponde a una captura de pantalla de la aplicaci´on TouCANSnifferView. En ella podemos encontrar dos zonas bien diferenciadas. En el lateral izquierdo se encuntra el men´u de filtros que permite mostrar/ocultar los registros seg´un el tipo de trama o dispositivo y en el ´area central se encuentran las tramas generadas por el nodo SupervisorSniffer. En este ejemplo, los registros en las posiciones tres, cuatro y cinco corresponden al tr´afico entre los nodos SERVER y SLAVE durante el proceso de solicitud de ID de este ´ultimo. 70 Cap´ıtulo 9. Desarrollo Figura 9.45: TouCAN v2.0 - Captura de pantalla TouCANSnifferView 9.6. TouCANSniffer 71 9.6.3.1. Estructura base de datos La base de datos est´a compuesta por cuatro tablas: importfilelog, register, device y frame. Almacenan los registros generados por SupervisorSniffer e informaci´on sobre las tramas del protocolo TouCAN v2.0 y los distintos dispositivos que conforman la red. La figura 9.46 muestra al diagrama Entidad Relaci´on de la base de datos. A continuaci´on se describe cada una de las tablas importfilelog: Esta tabla almacena informaci´on sobre cada una de las importaciones. register: Almacena las tramas generadas por SupervisorSniffer. device: Almacena informaci´on sobre los dispositivos que conforman la red. Los datos se obtienen del campo DATA de la trama BCID. frame: Contiene informaci´on sobre cada una de las tramas TouCAN v2.0. Figura 9.46: TouCAN v2.0 - Diagrama Entidad Relaci´on TouCANSnifferView 72 Cap´ıtulo 9. Desarrollo 9.6.3.2. Diagrama de clases La figura 9.47 describe las clases principales de la aplicaci´on TouCANSnifferView. Figura 9.47: TouCAN v2.0 - Diagrama de clases - TouCANSnifferView Package Entity: Cada una de estas clases corresponde con una tabla en la base de datos y es utilizada por la librer´ıa Doctrine[6] para insertar, actualizar, eliminar o consultar un registro. Package Repository: Conjunto de clases que facilitan las consultas de registros en la base de datos. Package Controller: Los puntos de entrada o URL de acceso a la aplicaci´on son definidos en estas clases. Package Import: Conjunto de clases responsable de importar el fichero de tramas generado por el SupervisorSniffer. Package Factory: Conjunto de clases que facilita la creaci´on de objetos. Cap´ıtulo 10 Pruebas En este cap´ıtulo se describen diferentes escenarios donde se ponen a prueba las mejoras introducidas en este TFG y se verifican que los cambios realizados no afectan a las caracter´ısticas ya existentes. Todos los escenarios est´an compuestos por una red de cuatro dispositivos: Servidor, Maestro, Esclavo y NodeSniffer. (Ver imagen: 10.1). En la verificaci´on de cada escenario se utilizar´a la herramienta TouCANSnifferView descrita en el cap´ıtulo 9 Desarrollo. Cada captura de la aplicaci´on TouCANSnifferView mostrar´a los registros filtrados por dispositivos y/o tramas para verificar cada una de las distintas funcionalidades de forma independiente. Figura 10.1: TouCAN v2.0 - Escenario Test - Sistema cuatro dispositivos 73 74 Cap´ıtulo 10. Pruebas 10.1. Escenario 1 - Asignaci´on Din´amica ID 10.1.1. Descripci´on Este escenario tiene por finalidad verificar la asignaci´on din´amica de ID en una red compuesta por tres nodos de tipo: Server, Master y Slave. Es importante destacar el orden en el que debe iniciar cada dispositivo para verificar las distintas situaciones que se producen durante el proceso. A continuaci´on se describe el orden en el que se iniciar´a los nodos y la funci´on del programa principal. Server: Atiende las peticiones de solicitud de ID. Y establece dos comunicaciones con cada uno de los nodos, una s´ıncrona y otra as´ıncrona. Master: Realiza una solicitud de ID y atiende a peticiones s´ıncroncas y as´ıncronas del nodo Server. Slave: Realiza una solicitud de ID y atiende a peticiones s´ıncroncas y as´ıncronas del nodo Server. 10.1.2. Resultados 10.1.2.1. Asignaci´on Din´amica ID La siguiente imagen 10.2 muestra el tr´afico correspondiente a la de solicitud de ID de los nodos MAS01 y SLAVE. En primer lugar, el Servidor atiende la petici´on del nodo maestro, asign´andole el identificador 1. Instantes m´as tarde, asigna el ID 2 al nodo SLAVE. La columna, DATA, contiene la informaci´on enviada por cada nodo en el campo DATA en las distintas tramas. Por ejemplo, los tres ´ultimos registros corresponden a la solicitud del nodo SLAVE. 1. En la solicitud de ID, el nodo almacena el nombre del dispositivo en el campo DATA. [SLAVE] 2. En la respuesta, el Servidor almacena el nombre del dispositivo y el identificador asignado. [SLAVE 2] 3. El tercer paquete corresponde a un paquete broadcast de confirmaci´on de ID. El campo data contiene el nombre del dispositivo [SLAVE] Figura 10.2: TouCAN v2.0 - TouCANSnifferView - Asignaci´on din´amica ID 10.1. Escenario 1 - Asignaci´on Din´amica ID 75 10.1.2.2. Petici´on S´ıncrona y As´ıncrona La figura 10.3 describe el tr´afico generado en las peticiones s´ıncronas y as´ıncronas entre el nodo Servidor y el resto de dispositivos. Los dos primeros registros corresponden al incio de una petici´on s´ıncrona y as´ıncrona respectivamente entre los nodos Server y MAS01. En la imagen se aprecia las distintas tramas de una petici´on as´ıncrona y el orden de cada una de ellas. Por ejemplo, despu´es del inico o finalizaci´on de una petici´on as´ıncrona siempre le sigue una trama de reconocimiento ACKN. (l´ıneas 4 y 12) Figura 10.3: TouCAN v2.0 - TouCANSnifferView - Petici´on S´ıncrona y As´ıncrona 76 Cap´ıtulo 10. Pruebas 10.2. Escenario 2 - Reinicio nodo Servidor 10.2.1. Descripci´on Una de las nuevas caracter´ısticas incorporadas a la librer´ıa consiste en recuperar la tabla de dispositivo despu´es de un reset. Este escenario fuerza el reinicio de un Server y la verificaci´on de la tabla de dispositivo despu´es de reiniciar el dispositivo. A continuaci´on se describe el programa principal de cada uno de los nodos. Servidor: Atiende las peticiones de solicitud de ID. No realiza peticiones s´ıncronas o as´ıncronas. Maestro: Realiza una solicitud de ID. Esclavo: Realiza una solicitud de ID. 10.2.2. Resultados La siguiente figura 10.4 muestra el intercambio de mensajes entre el Servidor y el resto de nodos en la red con el objetivo de recuperar las entradas de la tabla de dispositivos antes del reinicio. El servidor env´ıa dos paquetes de reconocimiento de dispositivos, BCDN, con un intervalo de tiempo entre cada uno. En la captura se aprecia como los nodos SLAVE y MAS01 responden enviando la trama RCDN. Figura 10.4: TouCAN v2.0 - TouCANSnifferView - Reinicio nodo Servidor 10.3. Escenario 3 - Master actualizar Tabla Dispositivos 77 10.3. Escenario 3 - Master actualizar Tabla Dispositivos 10.3.1. Descripci´on Los nodos Master actualizan la tabla de dispositivo a trav´es de la trama BCID que reciben de los procesos de confirmaci´on de ID que se generan en la red. Este mecanismo no asegura la actualizaci´on de la tabla en todo momento. La p´erdida de un paquete, la sobrecarca del microcontrolador o simplemente iniciar con posterioridad a otros nodos puede causar que la tabla de dispositivo quede obsoleta. Esta revisi´on proporciona al nodo Master un mecanismo que le permite actualizar la lista de nodos con la del Server y mantenerse actualizado en todo momento. En este escenario vamos a forzar que la tabla de dispositivo del nodo Master est´e obsoleta simplemente iniciando el dispositivo con posterioridad al Slave. A continuaci´on se describe las funcines del programa principal y el orden de inicio de cada uno de los nodos. Server: Atiende las peticiones de solicitud de ID. No realiza peticiones s´ıncronas o as´ıncronas. Slave: Realiza una solicitud de ID. Master: Realiza una solicitud de ID. 84 BIBLIOGRAF´ IA [13] MariaDB. [https://mariadb.org/]. [14] Model-View-Controller Pattern, art´ıculo en Wikipedia. [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]. [15] MySQL. [http://www.mysql.com/]. [16] Object Relational Mapping, ORM, art´ıculo en Wikipedia. [http://en.wikipedia.org/wiki/Object-relational mapping]. [17] Open Source, art´ıculo en Wikipedia. [Online; accedida 02-Septiembre2012][http://en.wikipedia.org/wiki/Open source]. [18] Plataforma Arduino. [http://arduino.cc]. [19] Principio de Responsabilidad ´ Unica. SRP. Art´ıculo en Wikipedia. [Online; accedida 01-Marzo2013][http://en.wikipedia.org/wiki/Single responsibility principle]. [20] Proceso Unificado, art´ıculo en Wikipedia. [Online; accedida 20-Enero2013][http://es.wikipedia.org/wiki/Proceso Unificado]. [21] Symfony Framework. [http://symfony.com/]. [22] Jos´e Antonio Lareo Dom´ıngez. Integraci´on de redes de microcontroladores distribuidos basados en bus CAN. Lado supervisor. 2012. [http://hdl.handle.net/10553/10146]. [23] Ra´ul Milla P´erez. P´agina oficial del proyecto ArCAN. [http://www.arcan.es/]. [24] John Wu Wu. Integraci´on de redes de microcontroladores distribuidos basados en bus CAN. Lado microcontrolador. 2012. [http://hdl.handle.net/10553/9860].