Integration of embedded data processing algorithms inside PAMELA devices

PAMELA (Phased Array Monitoring for Enhanced Life Assessment) SHMTM System is an integrated embedded ultrasonic guided waves based system consisting of several electronic devices and one system manager controller. The data collected by all PAMELA devices in the system must be transmitted to the controller, who will be responsible for carrying out the advanced signal processing to obtain SHM maps. PAMELA devices consist of hardware based on a Virtex 5 FPGA with a PowerPC 440 running an embedded Linux distribution. Therefore, PAMELA devices, in addition to the capability of performing tests and transmitting the collected data to the controller, have the capability of perform local data processing or pre-processing (reduction, normalization, pattern recognition, feature extraction, etc.). Local data processing decreases the data traffic over the network and allows CPU load of the external computer to be reduced. Even it is possible that PAMELA devices are running autonomously performing scheduled tests, and only communicates with the controller in case of detection of structural damages or when programmed. Each PAMELA device integrates a software management application (SMA) that allows to the developer downloading his own algorithm code and adding the new data processing algorithm to the device. The development of the SMA is done in a virtual machine with an Ubuntu Linux distribution including all necessary software tools to perform the entire cycle of development. Eclipse IDE (Integrated Development Environment) is used to develop the SMA project and to write the code of each data processing algorithm. This paper presents the developed software architecture and describes the necessary steps to add new data processing algorithms to SMA in order to increase the processing capabilities of PAMELA devices.An example of basic damage index estimation using delay and sum algorithm is provided.

CompactRIO: advanced data acquisition systems integration in CODAC Core System

Las herramientas de configuración basadas en lenguajes de alto nivel como LabVIEW permiten el desarrollo de sistemas de adquisición de datos basados en hardware reconfigurable FPGA muy complejos en un breve periodo de tiempo. La estandarización del ciclo de diseño hardware/software y la utilización de herramientas como EPICS facilita su integración con la plataforma de adquisición y control ITER CODAC CORE SYSTEM (CCS) basada en Linux. En este proyecto se propondrá una metodología que simplificará el ciclo completo de integración de plataformas novedosas, como cRIO, en las que el funcionamiento del hardware de adquisición puede ser modificado por el usuario para que éste se amolde a sus requisitos específicos. El objetivo principal de este proyecto fin de master es realizar la integración de un sistema cRIO NI9159 y diferentes módulos de E/S analógica y digital en EPICS y en CODAC CORE SYSTEM (CCS). Este último consiste en un conjunto de herramientas software que simplifican la integración de los sistemas de instrumentación y control del experimento ITER. Para cumplir el objetivo se realizarán las siguientes tareas: • Desarrollo de un sistema de adquisición de datos basado en FPGA con la plataforma hardware CompactRIO. En esta tarea se realizará la configuración del sistema y la implementación en LabVIEW para FPGA del hardware necesario para comunicarse con los módulos: NI9205, NI9264, NI9401.NI9477, NI9426, NI9425 y NI9476 • Implementación de un driver software utilizando la metodología de AsynDriver para integración del cRIO con EPICS. Esta tarea requiere definir todos los records necesarios que exige EPICS y crear las interfaces adecuadas que permitirán comunicarse con el hardware. • Implementar la descripción del sistema cRIO y del driver EPICS en el sistema de descripción de plantas de ITER llamado SDD. Esto automatiza la creación de las aplicaciones de EPICS que se denominan IOCs. SUMMARY The configuration tools based in high-level programing languages like LabVIEW allows the development of high complex data acquisition systems based on reconfigurable hardware FPGA in a short time period. The standardization of the hardware/software design cycle and the use of tools like EPICS ease the integration with the data acquisition and control platform of ITER, the CODAC Core System based on Linux. In this project a methodology is proposed in order to simplify the full integration cycle of new platforms like CompactRIO (cRIO), in which the data acquisition functionality can be reconfigured by the user to fits its concrete requirements. The main objective of this MSc final project is to develop the integration of a cRIO NI-9159 and its different analog and digital Input/Output modules with EPICS in a CCS. The CCS consists of a set of software tools that simplifies the integration of instrumentation and control systems in the International Thermonuclear Reactor (ITER) experiment. To achieve such goal the following tasks are carried out: • Development of a DAQ system based on FPGA using the cRIO hardware platform. This task comprehends the configuration of the system and the implementation of the mandatory hardware to communicate to the I/O adapter modules NI9205, NI9264, NI9401, NI9477, NI9426, NI9425 y NI9476 using LabVIEW for FPGA. • Implementation of a software driver using the asynDriver methodology to integrate such cRIO system with EPICS. This task requires the definition of the necessary EPICS records and the creation of the appropriate interfaces that allow the communication with the hardware. • Develop the cRIO system’s description and the EPICS driver in the ITER plant description tool named SDD. This development will automate the creation of EPICS applications, called IOCs.

Monitorización de sistemas en alta disponibilidad

El objetivo del proyecto es implantar un sistema de monitorización, con la peculiaridad de encontrarse en alta disponibilidad, esto es, que el servicio (la monitorización de una infraestructura) se preste forma continua y no se vea interrumpido. Dado que el propósito del sistema es monitorizar activamente una infraestructura, ha sido necesario desplegar una infraestructura, además del sistema de monitorización. La infraestructura en cuestión está compuesta por un servidor de documentación, un servidor de base de datos, un servidor de aplicaciones y un servidor web. El sistema de monitorización se ha desplegado en la misma red de área local de esta infraestructura y monitoriza que los servicios prestados por los componentes de esta infraestructura se encuentren operativos y funcionando adecuadamente. Así pues, se tendría un sistema de monitorización local funcional. No obstante, el proyecto plantea un sistema escalable, que esté preparado para el crecimiento de la infraestructura y continúe siendo eficiente. Para ello, sistema de monitorización se encuentre dividido por dos componentes:  Sonda delegada: monitoriza localmente los activos de la infraestructura a monitorizar, es el escenario anteriormente descrito.  Sonda maestra: recibe los resultados de la monitorización realizada, este sistema puede estar desplegado en otra red distinta a la sonda delegada. Este enfoque no solo es escalable, sino también es fiel a la realidad, pues puede darse el caso de que las sondas pertenezcan a distintas infraestructuras e inclusive, distintas organizaciones, y se comuniquen a través de internet, mediante un mecanismo confiable a ser posible. El proyecto plantea que ambas sondas se encuentren en alta disponibilidad (en adelante HA, referente a high availability), y que cada sonda está compuesta por dos equipos (nodos, en adelante). Como se analizará en posteriores capítulos, existen diversas configuraciones que permiten implantar un sistema en HA, la configuración escogida para el proyecto es Activo – Pasivo(los detalles de esta configuración también se explican en posteriores capítulos). Para finalizar, se estudiara la posibilidad de ofrecer respuestas activas en ciertas situaciones y configuraciones adicionales sobre el sistema de monitorización base. Por otro lado, para la implantación del proyecto se ha usado software de código abierto para la virtualización de la infraestructura (Virtual Box y GNS3), los sistemas operativos base (Linux), el sistema de monitorización(Nagios Core) así como el software que implementa la HA (corosync y pacemaker).---ABSTRACT---The aim of the Project is to implement a monitoring system, with the peculiarity of being deployed in high availability, what it is that the service (monitoring infrastructure) is provided continuously and not interrupted. As the purpose of the system is monitoring infrastructure actively, an infrastructure has been deployed, and also the monitoring system. The infrastructure monitored is composed of a documentation server, a server database, an application server and a Web server. The monitoring system has been also deployed on the same LAN of this infrastructure and monitors the services provided by the components of this infrastructure are operational and working as expected. This is a local monitoring system functional. However, the project also proposes a scalable system that is ready for growth of infrastructure and efficient. This is the reason of divide the system in two components:  Slave Component: monitors locally the infrastructure assets to be monitored, this is the scenario described above.  Master Component: get the results from the monitoring, provided by the Slave Component. This system can be deployed in a different network than the slave component. This approach is not only scalable but also a real scenario, as may be the case that the Components belongs to different infrastructures and even, different organizations, also this components can communicate over the Internet, through a reliable mechanism if possible. The project proposes that both Components are deployed in high availability (HA onwards concerning high availability), each Component is composed of two servers (nodes, hereafter). As will be discussed in later chapters, there are several settings available to deploy a system in HA, the configuration chosen for the project is Active - Passive (details of this configuration are also explained in later chapters). Finally the possibility of offering active responses in certain situations and additional settings on the monitoring system will be discussed. On the other hand, for the implementation of the project, open source software has been used, for virtualization infrastructure (Virtual Box and GNS3), code-based operating systems (Linux), the monitoring system (Nagios core), as well as the software that implements the HA (corosync and pacemaker).

Sistema de gestión de un banco de tiempo

RESUMEN El presente documento aborda la problemática surgida en torno al desarrollo de una plataforma para gestión de bancos de tiempo mediante tecnología LAMP (Linux + Apache + MySql + PHP). Se mostrarán los resultados del análisis de requisitos, la implementación, la puesta en práctica desde el año 2005, asi como conclusiones y líneas futuras. Para finalizar la documentación, se adjunta una guía para la creación de un banco de tiempo. ABSTRACT This document explains the solution to develop a time bank management platform, using LAMP technology (Linux + Apache + MySql + PHP). This will be focus on the result of the analysis, the implementation, the real implementation working since 2005, conclusions and future working lines. A guide to set up a time bank is attached at the end of the documentation.

Distribución multicast de vídeo en directo sobre la red móvil LTE

En la última década, la telefonía móvil ha evolucionado a una extraordinaria velocidad, permitiéndonos acceder a funcionalidades características de los PC pero con la ventaja de poseer una movilidad total. Con la aparición de la tecnología Long Term Evolution (LTE), comúnmente conocida como 4G, se ha conseguido desarrollar un sistema que se ha mejorado notablemente las prestaciones proporcionando alta velocidad y eficiencia a los ya masivamente utilizados smartphones. Gracias a este exponencial incremento del ancho de banda disponible, los usuarios hoy en día no se conforman sólo con navegar por páginas Web, sino que cada vez muestran un mayor interés en poder explotar al máximo los recursos multimedia, dando lugar a servicios como el streaming de vídeo. De este modo, a raíz del proyecto LTExtreme centrado en el análisis y la propuesta de optimización para servicios de streaming multimedia multicast/unicast sobre la tecnología LTE, surge este trabajo en el cual se pretende extender dicho análisis a la multidifusión de vídeo en directo. El proyecto se basa en la implementación de la arquitectura propuesta por el organismo 3GPP para dar este servicio, considerándose como una solución eficiente en la que se combina el protocolo de transporte multicast FLUTE (File Delivery over Unidirectional Transport) con la tecnología DASH (Dynamic Adaptative Streaming over HTTP). La arquitectura se ha implementado mediante la creación y configuración de una maqueta de laboratorio gracias a la herramienta de virtualización Virtual Networks over linuX (VNX). Un escenario simplificado de la red móvil LTE junto con el servidor de contenidos y varios clientes móviles, pudiendo realizar simulaciones de una emisión de vídeo en directo, y a su vez analizar los resultados obtenidos, así como la calidad de servicio percibida. Concretamente, se realizará un análisis de los problemas asociados a los casos de uso tratados, tanto de la emisión de un único vídeo como una de duración infinita, asemejándose a lo que supondría la emisión de la programación televisiva para un determinado canal. Por último, se plantearán ideas surgidas a raíz de los resultados obtenidos de dichos estudios y que puedan tener futuro y ser aplicables al mundo real.

PCCMuTe v2.2: una herramienta para medir el consumo de energía en sistemas empotrados

Este Proyecto Fin de Grado (PFG) recoge el trabajo de depuración realizado sobre el prototipo PCCMuTe v2.2, un sistema empotrado que dispone de la instrumentación necesaria para medir el consumo de potencia/energía en cada uno de sus dominios de tensión, y posteriormente digitalizar y enviar los resultados al procesador que se encuentra en su interior. Su uso permite la obtención de información en tiempo real sobre el consumo del hardware de la placa, en especial del procesador, pudiendo relacionar la potencia consumida con el software ejecutado. El proyecto está orientado a medir el consumo de energía derivado de la decodificación de vídeo. El software utilizado para controlar el hardware se basa en Linux. En este proyecto se distinguen principalmente dos actividades, depuración hardware y depuración software. Los resultados muestran avances en la depuración hardware hasta obtener un prototipo en completo funcionamiento. Los avances en el apartado del software habilitan las comunicaciones SPI, necesarias para la transmisión de los resultados de consumo al procesador. En la fase final de este PFG se hace uso de una aplicación previamente desarrollada por miembros del GDEM con la que se obtienen los primeros datos de consumo, pero por falta de tiempo estos resultados no pueden ser verificados. Por la misma razón no ha sido posible diseñar y codificar una nueva aplicación que mejore la forma en la que se obtienen esos datos. ABSTRACT. This bachelor final project includes the debugging work done on the prototype PCCMuTe v2.2, an embedded system with the necessary instrumentation to measure the power/ energy consumption in each of its voltage domains, scan and send the results to its processor. The purpose of this device is to obtain real-time information about the hardware power consumption, especially from the processor, being able to relate the power consumed with the software executed. The project aims to measure the energy consumption of video decoding. The software used to control the hardware is based on Linux. In this project there are two main activities: hardware and software debugging. The results show advances in hardware debugging, and finally a fully functioning prototype is obtained. Advances in software debugging enable SPI communications, used to transmit the consumption data to the processor. In the last part of this final bachelor project an application previously coded by other members of the GDEM is used to obtain the first data. The results can not finally be verified because of the lack of time. For the same reason it is not possible to design and code a new application that improves the way the data is obtained.

Supervisión de un sistema de tiempo real distribuido

En el presente proyecto se propone la definición e implementación de un subsistema de monitorización para un sistema de tiempo real distribuido. Este monitor supervisará el estado de todos los componentes software y hardware del sistema original, y permitirá el arranque y parada de cada componente individualmente o del subsistema completo. Constará de dos componentes básicos: un supervisor local para cada subsistema, y un supervisor central con interfaz gráfica. El supervisor local es un componente software asociado a cada subsistema que realizará las funciones de monitorización, arranque/parada de los componentes y envío de informes al supervisor central. Atenderá además a los comandos de arranque y parada provenientes del supervisor central. El supervisor central recibirá los informes de estado de cada uno de los supervisores locales y permitirá el arranque y parada de los subsistemas. Contará con un interfaz gráfico a modo de posición de control. El sistema será desarrollado íntegramente (salvo la posición gráfica) en ADA95, y podrá ejecutarse en cualquiera de las distribuciones Linux más extendidas. En el contexto de Ingeniería de Software, se seguirá un desarrollo en cascada, aportándose los requisitos, el diseño, la codificación y un plan de pruebas. Abstract In this project, the definition and implementation of a monitoring system is proposed for a previously defined real-time distributed system. This supervisory system will monitor the status of each subsystem and its software and hardware components. This new system will also be able to start and stop each individual component and start or stop the entire system. It will consist of two basic components: a local supervisor for each subsystem, and a central supervisor with a graphical unit interface (GUI). The local supervisor will be a software component attached to each original subsystem, which will perform functions such as components monitoring, start and stop the associated subsystem, and sending reports to the central supervisor. It also will attend the start and stop commands from the central supervisor. The central supervisor will receive status reports from each of the local supervisors and will allow starting and stopping the subsystems. It will offer a graphical interface to be used as a main control panel. The system will be developed in ADA 95 (except the graphical position), and should work on any of the most common Linux distributions. In the context of Software Engineering, the project will be developed following a waterfall life cycle. Reports on the stages of requirements, design, coding and testing plan shall be provided.

Implementación de efectos de audio en la tarjeta Raspberry Pi B+

Este proyecto consiste en el diseño e implementación de un procesador digital de efectos de audio en tiempo real orientado a instrumentos eléctricos tales como guitarras, bajos, teclados, etc. El procesador está basado en la tarjeta Raspberry Pi B+, ordenador de placa reducida de bajo coste, desarrollado en Reino unido y cuyo lanzamiento tuvo lugar en el año 2012. En primer lugar, ha sido necesario lograr que la tarjeta asuma la funcionalidad de un procesador de audio en tiempo real. Para ello se ha instalado un sistema operativo Linux orientado a Raspberry (Raspbian) y se ha hecho uso de Pure Data (Pd): lenguaje de programación gráfico que fue desarrollado en los años 90 por Miller Puckette con intención de ser enfocado a la creación de eventos multimedia y de música por computador. El papel que desempeña Pd es de capa intermedia entre el hardware y el software ya que se encarga de tomar bloques de N muestras del convertidor analógico/digital y encaminarlas a través del flujo de señal diseñado gráficamente. En segundo lugar, se han implementado diferentes efectos de audio de distintas características. Así pues, se encuentran efectos basados en retardos, filtros digitales y procesadores de dinámica. Concretamente, los efectos implementados son los siguientes: delay, flanger, vibrato, reverberador de Schroeder, filtros (paso bajo, paso alto y paso banda), ecualizador paramétrico y compresor y expansor de dinámica. Estos efectos han sido implementados en lenguaje C de acuerdo con la API de Pd. Con esto se ha conseguido obtener un objeto por cada efecto, el cual es “instanciado” en Pd pudiendo ejecutarlo en tiempo real. En este proyecto se expone la problemática que supone cada paso del diseño proponiendo soluciones válidas. Además se incluye una guía paso a paso para configurar la tarjeta y lograr realizar un bypass de señal y un efecto simple partiendo desde cero. ABSTRACT. This project involves the design and implementation of a digital real-time audio processor for electrical instruments (guitars, basses, keyboards, etc.). The processor is based on the Raspberry Pi B + card: low cost computer, developed in UK in 2012. First, it was necessary to make the cards assume the functionality of a real time audio processor. A Linux operating system called Raspberry (Raspbian) was installed. In this Project is used Pure Data (Pd): a graphical programming language developed in the 90s by Miller Puckette intending to be focused on creating multimedia and computer music events. The role of Pd is an intermediate layer between the hardware and the software. It is responsible for taking blocks of N samples of the analog/digital converter and route it through the signal flow. Secondly, it is necessary to implemented the different audio effects. There are delays based effects, digital filter and dynamics effects. Specifically, the implemented effects are: delay, flanger, vibrato, Schroeder reverb, filters (lowpass, highpass and bandpass), parametric equalizer and compressor and expander dynamics. These effects have been implemented in C language according to the Pd API. As a result, it has been obtained an object for each effect, which is instantiated in Pd. In this Project, the problems of every step are exposed with his corresponding solution. It is inlcuded a step-by-step guide to configure the card and achieve perform a bypass signal process and a simple effect.

Localización y mapeo visual monocular para robot móvil terrestre aplicado a la inspección ultrasónica aeronáutica

En el ámbito de la robótica de servicio, actualmente no existe una solución automatizada para la inspección ultrasónica de las partes de material compuesto de una aeronave durante las operaciones de mantenimiento que realiza la aerolínea. El desarrollo de las nuevas técnicas de acoplamiento acústico en seco en el método de inspección no destructiva por ultrasonidos, está conduciendo a posibilitar su uso con soluciones de menor coste respecto a las técnicas tradicionales, sin perder eficacia para detectar las deficiencias en las estructuras de material compuesto. Aunque existen aplicaciones de esta técnica con soluciones manuales, utilizadas en las fases de desarrollo y fabricación del material compuesto, o con soluciones por control remoto en sectores diferentes al aeronáutico para componentes metálicos, sin embargo, no existen con soluciones automatizadas para la inspección no destructiva por ultrasonidos de las zonas del avión fabricadas en material compuesto una vez la aeronave ha sido entregada a la aerolínea. El objetivo de este trabajo fin de master es evaluar el sistema de localización, basado en visión por ordenador, de una solución robotizada aplicada la inspección ultrasónica estructural de aeronaves en servicio por parte de las propias aerolíneas, utilizando las nuevas técnicas de acoplamiento acústico en seco, buscando la ventaja de reducir los tiempos y los costes en las operaciones de mantenimiento. Se propone como solución un robot móvil autónomo de pequeño tamaño, con control de posición global basado en técnicas de SLAM Visual Monocular, utilizando marcadores visuales externos para delimitar el área de inspección. Se ha supuesto la inspección de elementos de la aeronave cuya superficie se pueda considerar plana y horizontal, como son las superficies del estabilizador horizontal o del ala. Este supuesto es completamente aceptable en zonas acotadas de estos componentes, y de cara al objetivo del proyecto, no le resta generalidad. El robot móvil propuesto es un vehículo terrestre triciclo, de dos grados de libertad, con un sistema de visión monocular completo embarcado, incluyendo el hardware de procesamiento de visión y control de trayectoria. Las dos ruedas delanteras son motrices y la tercera rueda, loca, sirve únicamente de apoyo. La dirección, de tipo diferencial, permite al robot girar sin necesidad de desplazamiento, al conseguirse por diferencia de velocidad entre la rueda motriz derecha e izquierda. El sistema de inspección ultrasónica embarcado está compuesto por el hardware de procesamiento y registro de señal, y una rueda-sensor situada coaxialmente al eje de las ruedas motrices, y centrada entre estas, de modo que la medida de inspección se realiza en el centro de rotación del robot. El control visual propuesto se realiza mediante una estrategia “ver y mover” basada en posición, ejecutándose de forma secuencial la extracción de características visuales de la imagen, el cálculo de la localización global del robot mediante SLAM visual y el movimiento de éste mediante un algoritmo de control de posición-orientación respecto a referencias de paso de la trayectoria. La trayectoria se planifica a partir del mapa de marcas visuales que delimitan el área de inspección, proporcionado también por SLAM visual. Para validar la solución propuesta se ha optado por desarrollar un prototipo físico tanto del robot como de los marcadores visuales externos, a los que se someterán a una prueba de validación como alternativa a utilizar un entorno simulado por software, consistente en el reconocimiento del área de trabajo, planeamiento de la trayectoria y recorrido de la misma, de forma autónoma, registrando el posicionamiento real del robot móvil junto con el posicionamiento proporcionado por el sistema de localización SLAM. El motivo de optar por un prototipo es validar la solución ante efectos físicos que son muy complicados de modelar en un entorno de simulación, derivados de las limitaciones constructivas de los sistemas de visión, como distorsiones ópticas o saturación de los sensores, y de las limitaciones constructivas de la mecánica del robot móvil que afectan al modelo cinemático, como son el deslizamiento de las ruedas o la fluctuación de potencia de los motores eléctricos. El prototipo de marcador visual externo utilizado para la prueba de validación, ha sido un símbolo plano vertical, en blanco y negro, que consta de un borde negro rectangular dentro del cual se incluye una serie de marcas cuadradas de color negro, cuya disposición es diferente para cada marcador, lo que permite su identificación. El prototipo de robot móvil utilizado para la prueba de validación, ha sido denominado VINDUSTOR: “VIsual controlled Non-Destructive UltraSonic inspecTOR”. Su estructura mecánica ha sido desarrollada a partir de la plataforma comercial de robótica educacional LEGO© MINDSTORMS NXT 2.0, que incluye los dos servomotores utilizados para accionar las dos ruedas motrices, su controlador, las ruedas delanteras y la rueda loca trasera. La estructura mecánica ha sido especialmente diseñada con piezas LEGO© para embarcar un ordenador PC portátil de tamaño pequeño, utilizado para el procesamiento visual y el control de movimiento, y el sistema de captación visual compuesto por dos cámaras web de bajo coste, colocadas una en posición delantera y otra en posición trasera, con el fin de aumentar el ángulo de visión. El peso total del prototipo no alcanza los 2 Kg, siendo sus dimensiones máximas 20 cm de largo, 25 cm de ancho y 26 cm de alto. El prototipo de robot móvil dispone de un control de tipo visual. La estrategia de control es de tipo “ver y mover” dinámico, en la que se realiza un bucle externo, de forma secuencial, la extracción de características en la imagen, la estimación de la localización del robot y el cálculo del control, y en un bucle interno, el control de los servomotores. La estrategia de adquisición de imágenes está basada en un sistema monocular de cámaras embarcadas. La estrategia de interpretación de imágenes está basada en posición tridimensional, en la que los objetivos de control se definen en el espacio de trabajo y no en la imagen. La ley de control está basada en postura, relacionando la velocidad del robot con el error en la posición respecto a las referencias de paso de una trayectoria. La trayectoria es generada a partir del mapa de marcadores visuales externo. En todo momento, la localización del robot respecto a un sistema de referencia externo y el mapa de marcadores, es realizado mediante técnicas de SLAM visual. La auto-localización de un robot móvil dentro de un entorno desconocido a priori constituye uno de los desafíos más importantes en la robótica, habiéndose conseguido su solución en las últimas décadas, con una formulación como un problema numérico y con implementaciones en casos que van desde robots aéreos a robots en entornos cerrados, existiendo numerosos estudios y publicaciones al respecto. La primera técnica de localización y mapeo simultáneo SLAM fue desarrollada en 1989, más como un concepto que como un algoritmo único, ya que su objetivo es gestionar un mapa del entorno constituido por posiciones de puntos de interés, obtenidos únicamente a partir de los datos de localización recogidos por los sensores, y obtener la pose del robot respecto al entorno, en un proceso limitado por el ruido de los sensores, tanto en la detección del entorno como en la odometría del robot, empleándose técnicas probabilísticas aumentar la precisión en la estimación. Atendiendo al algoritmo probabilístico utilizado, las técnicas SLAM pueden clasificarse en las basadas en Filtros de Kalman, en Filtros de Partículas y en su combinación. Los Filtros de Kalman consideran distribuciones de probabilidad gaussiana tanto en las medidas de los sensores como en las medidas indirectas obtenidas a partir de ellos, de modo que utilizan un conjunto de ecuaciones para estimar el estado de un proceso, minimizando la media del error cuadrático, incluso cuando el modelo del sistema no se conoce con precisión, siendo el más utilizado el Filtro de Kalman Extendido a modelos nolineales. Los Filtros de Partículas consideran distribuciones de probabilidad en las medidas de los sensores sin modelo, representándose mediante un conjunto de muestras aleatorias o partículas, de modo que utilizan el método Montecarlo secuencial para estimar la pose del robot y el mapa a partir de ellas de forma iterativa, siendo el más utilizado el Rao-Backwell, que permite obtener un estimador optimizado mediante el criterio del error cuadrático medio. Entre las técnicas que combinan ambos tipos de filtros probabilísticos destaca el FastSLAM, un algoritmo que estima la localización del robot con un Filtro de Partículas y la posición de los puntos de interés mediante el Filtro de Kalman Extendido. Las técnicas SLAM puede utilizar cualquier tipo de sensor que proporcionen información de localización, como Laser, Sonar, Ultrasonidos o Visión. Los sensores basados en visión pueden obtener las medidas de distancia mediante técnicas de visión estereoscópica o mediante técnica de visión monocular. La utilización de sensores basados en visión tiene como ventajas, proporcionar información global a través de las imágenes, no sólo medida de distancia, sino también información adicional como texturas o patrones, y la asequibilidad del hardware frente a otros sensores. Sin embargo, su principal inconveniente es el alto coste computacional necesario para los complejos algoritmos de detección, descripción, correspondencia y reconstrucción tridimensional, requeridos para la obtención de la medida de distancia a los múltiples puntos de interés procesados. Los principales inconvenientes del SLAM son el alto coste computacional, cuando se utiliza un número elevado de características visuales, y su consistencia ante errores, derivados del ruido en los sensores, del modelado y del tratamiento de las distribuciones de probabilidad, que pueden producir el fallo del filtro. Dado que el SLAM basado en el Filtro de Kalman Extendido es una las técnicas más utilizadas, se ha seleccionado en primer lugar cómo solución para el sistema de localización del robot, realizando una implementación en la que las medidas de los sensores y el movimiento del robot son simulados por software, antes de materializarla en el prototipo. La simulación se ha realizado considerando una disposición de ocho marcadores visuales que en todo momento proporcionan ocho medidas de distancia con ruido aleatorio equivalente al error del sensor visual real, y un modelo cinemático del robot que considera deslizamiento de las ruedas mediante ruido aleatorio. Durante la simulación, los resultados han mostrado que la localización estimada por el algoritmo SLAM-EKF presenta tendencia a corregir la localización obtenida mediante la odometría, pero no en suficiente cuantía para dar un resultado aceptable, sin conseguir una convergencia a una solución suficientemente cercana a la localización simulada del robot y los marcadores. La conclusión obtenida tras la simulación ha sido que el algoritmo SLAMEKF proporciona inadecuada convergencia de precisión, debido a la alta incertidumbre en la odometría y a la alta incertidumbre en las medidas de posición de los marcadores proporcionadas por el sensor visual. Tras estos resultados, se ha buscado una solución alternativa. Partiendo de la idea subyacente en los Filtros de Partículas, se ha planteado sustituir las distribuciones de probabilidad gaussianas consideradas por el Filtro de Kalman Extendido, por distribuciones equi-probables que derivan en funciones binarias que representan intervalos de probabilidad no-nula. La aplicación de Filtro supone la superposición de todas las funciones de probabilidad no-nula disponibles, de modo que el resultado es el intervalo donde existe alguna probabilidad de la medida. Cómo la efectividad de este filtro aumenta con el número disponible de medidas, se ha propuesto obtener una medida de la localización del robot a partir de cada pareja de medidas disponibles de posición de los marcadores, haciendo uso de la Trilateración. SLAM mediante Trilateración Estadística (SLAM-ST) es como se ha denominado a esta solución propuesta en este trabajo fin de master. Al igual que con el algoritmo SLAM-EKF, ha sido realizada una implementación del algoritmo SLAM-ST en la que las medidas de los sensores y el movimiento del robot son simulados, antes de materializarla en el prototipo. La simulación se ha realizado en las mismas condiciones y con las mismas consideraciones, para comparar con los resultados obtenidos con el algoritmo SLAM-EKF. Durante la simulación, los resultados han mostrado que la localización estimada por el algoritmo SLAM-ST presenta mayor tendencia que el algoritmo SLAM-EKF a corregir la localización obtenida mediante la odometría, de modo que se alcanza una convergencia a una solución suficientemente cercana a la localización simulada del robot y los marcadores. Las conclusiones obtenidas tras la simulación han sido que, en condiciones de alta incertidumbre en la odometría y en la medida de posición de los marcadores respecto al robot, el algoritmo SLAM-ST proporciona mejores resultado que el algoritmo SLAM-EKF, y que la precisión conseguida sugiere la viabilidad de la implementación en el prototipo. La implementación del algoritmo SLAM-ST en el prototipo ha sido realizada en conjunción con la implementación del Sensor Visual Monocular, el Modelo de Odometría y el Control de Trayectoria. El Sensor Visual Monocular es el elemento del sistema SLAM encargado de proporcionar la posición con respecto al robot de los marcadores visuales externos, a partir de las imágenes obtenidas por las cámaras, mediante técnicas de procesamiento de imagen que permiten detectar e identificar los marcadores visuales que se hallen presentes en la imagen capturada, así como obtener las características visuales a partir de las cuales inferir la posición del marcador visual respecto a la cámara, mediante reconstrucción tridimensional monocular, basada en el conocimiento a-priori del tamaño real del mismo. Para tal fin, se ha utilizado el modelo matemático de cámara pin-hole, y se ha considerado las distorsiones de la cámara real mediante la calibración del sensor, en vez de utilizar la calibración de la imagen, tras comprobar el alto coste computacional que requiere la corrección de la imagen capturada, de modo que la corrección se realiza sobre las características visuales extraídas y no sobre la imagen completa. El Modelo de Odometría es el elemento del sistema SLAM encargado de proporcionar la estimación de movimiento incremental del robot en base a la información proporcionada por los sensores de odometría, típicamente los encoders de las ruedas. Por la tipología del robot utilizado en el prototipo, se ha utilizado un modelo cinemático de un robot tipo uniciclo y un modelo de odometría de un robot móvil de dos ruedas tipo diferencial, en el que la traslación y la rotación se determinan por la diferencia de velocidad de las ruedas motrices, considerando que no existe deslizamiento entre la rueda y el suelo. Sin embargo, el deslizamiento en las ruedas aparece como consecuencia de causas externas que se producen de manera inconstante durante el movimiento del robot que provocan insuficiente contacto de la rueda con el suelo por efectos dinámicos. Para mantener la validez del modelo de odometría en todas estas situaciones que producen deslizamiento, se ha considerado un modelo de incertidumbre basado en un ensayo representativo de las situaciones más habituales de deslizamiento. El Control de Trayectoria es el elemento encargado de proporcionar las órdenes de movimiento al robot móvil. El control implementado en el prototipo está basado en postura, utilizando como entrada la desviación en la posición y orientación respecto a una referencia de paso de la trayectoria. La localización del robot utilizada es siempre de la estimación proporcionada por el sistema SLAM y la trayectoria es planeada a partir del conocimiento del mapa de marcas visuales que limitan el espacio de trabajo, mapa proporcionado por el sistema SLAM. Las limitaciones del sensor visual embarcado en la velocidad de estabilización de la imagen capturada han conducido a que el control se haya implementado con la estrategia “mirar parado”, en la que la captación de imágenes se realiza en posición estática. Para evaluar el sistema de localización basado en visión del prototipo, se ha diseñado una prueba de validación que obtenga una medida cuantitativa de su comportamiento. La prueba consiste en la realización de forma completamente autónoma de la detección del espacio de trabajo, la planificación de una trayectoria de inspección que lo transite completamente, y la ejecución del recorrido de la misma, registrando simultáneamente la localización real del robot móvil junto con la localización proporcionada por el sistema SLAM Visual Monocular. Se han realizado varias ejecuciones de prueba de validación, siempre en las mismas condiciones iniciales de posición de marcadores visuales y localización del robot móvil, comprobando la repetitividad del ensayo. Los resultados presentados corresponden a la consideración de las medidas más pesimistas obtenidas tras el procesamiento del conjunto de medidas de todos los ensayos. Los resultados revelan que, considerando todo el espacio de trabajo, el error de posición, diferencia entre los valores de proporcionados por el sistema SLAM y los valores medidos de posición real, se encuentra en el entorno de la veintena de centímetros. Además, los valores de incertidumbre proporcionados por el sistema SLAM son, en todos los casos, superiores a este error. Estos resultados conducen a concluir que el sistema de localización basado en SLAM Visual, mediante un algoritmo de Trilateración Estadística, usando un sensor visual monocular y marcadores visuales externos, funciona, proporcionando la localización del robot móvil con respecto al sistema de referencia global inicial y un mapa de su situación de los marcadores visuales, con precisión limitada, pero con incertidumbre conservativa, al estar en todo momento el error real de localización por debajo del error estimado. Sin embargo, los resultados de precisión del sistema de localización no son suficientemente altos para cumplir con los requerimientos como solución robotizada aplicada a la inspección ultrasónica estructural de aeronaves en servicio. En este sentido, los resultados sugieren que la posible continuación de este trabajo en el futuro debe centrarse en la mejora de la precisión de localización del robot móvil, con líneas de trabajo encaminadas a mejorar el comportamiento dinámico del prototipo, en mejorar la precisión de las medidas de posición proporcionadas por el sensor visual y en optimizar el resultado del algoritmo SLAM. Algunas de estas líneas futuras podrían ser la utilización de plataformas robóticas de desarrollo alternativas, la exploración de técnicas de visión por computador complementarias, como la odometría visual, la visión omnidireccional, la visión estereoscópica o las técnicas de reconstrucción tridimensional densa a partir de captura monocular, y el análisis de algoritmos SLAM alternativos condicionado a disponer de una sustancial mejora de precisión en el modelo de odometría y en las medidas de posición de los marcadores.

Estimación del consumo de potencia en un terminal portátil multimedia basada en la PMU del procesador

Este proyecto se incluye en una línea de trabajo que tiene como objetivo final la optimización de la energía consumida por un dispositivo portátil multimedia mediante la aplicación de técnicas de control realimentado, a partir de una modificación dinámica de la frecuencia de trabajo del procesador y de su tensión de alimentación. La modificación de frecuencia y tensión se realiza a partir de la información de realimentación acerca de la potencia consumida por el dispositivo, lo que supone un problema ya que no suele ser posible la monitorización del consumo de potencia en dispositivos de estas características. Este es el motivo por el que se recurre a la estimación del consumo de potencia, utilizando para ello un modelo de predicción. A partir del número de veces que se producen ciertos eventos en el procesador del dispositivo, el modelo de predicción es capaz de obtener una estimación de la potencia consumida por dicho dispositivo. El trabajo llevado a cabo en este proyecto se centra en la implementación de un modelo de estimación de potencia en el kernel de Linux. La razón por la que la estimación se implementa en el sistema operativo es, en primer lugar para lograr un acceso directo a los contadores del procesador. En segundo lugar, para facilitar la modificación de frecuencia y tensión, una vez obtenida la estimación de potencia, ya que esta también se realiza desde el sistema operativo. Otro motivo para implementar la estimación en el sistema operativo, es que la estimación debe ser independiente de las aplicaciones de usuario. Además, el proceso de estimación se realiza de forma periódica, lo que sería difícil de lograr si no se trabajase desde el sistema operativo. Es imprescindible que la estimación se haga de forma periódica ya que al ser dinámica la modificación de frecuencia y tensión que se pretende implementar, se necesita conocer el consumo de potencia del dispositivo en todo momento. Cabe destacar también, que los algoritmos de control se tienen que diseñar sobre un patrón periódico de actuación. El modelo de estimación de potencia funciona de manera específica para el perfil de consumo generado por una única aplicación determinada, que en este caso es un decodificador de vídeo. Sin embargo, es necesario que funcione de la forma más precisa posible para cada una de las frecuencias de trabajo del procesador, y para el mayor número posible de secuencias de vídeo. Esto es debido a que las sucesivas estimaciones de potencia se pretenden utilizar para llevar a cabo la modificación dinámica de frecuencia, por lo que el modelo debe ser capaz de continuar realizando las estimaciones independientemente de la frecuencia con la que esté trabajando el dispositivo. Para valorar la precisión del modelo de estimación se toman medidas de la potencia consumida por el dispositivo a las distintas frecuencias de trabajo durante la ejecución del decodificador de vídeo. Estas medidas se comparan con las estimaciones de potencia obtenidas durante esas mismas ejecuciones, obteniendo de esta forma el error de predicción cometido por el modelo y realizando las modificaciones y ajustes oportunos en el mismo. ABSTRACT. This project is included in a work line which tries to optimize consumption of handheld multimedia devices by the application of feedback control techniques, from a dynamic modification of the processor work frequency and its voltage. The frequency and voltage modification is performed depending on the feedback information about the device power consumption. This is a problem because normally it is not possible to monitor the power consumption on this kind of devices. This is the reason why a power consumption estimation is used instead, which is obtained from a prediction model. Using the number of times some events occur on the device processor, the prediction model is able to obtain a power consumption estimation of this device. The work done in this project focuses on the implementation of a power estimation model in the Linux kernel. The main reason to implement the estimation in the operating system is to achieve a direct access to the processor counters. The second reason is to facilitate the frequency and voltage modification, because this modification is also done from the operating system. Another reason to implement the estimation in the operating system is because the estimation must be done apart of the user applications. Moreover, the estimation process is done periodically, what is difficult to obtain outside the operating system. It is necessary to make the estimation in a periodic way because the frequency and voltage modification is going to be dynamic, so it needs to know the device power consumption at every time. Also, it is important to say that the control algorithms have to be designed over a periodic pattern of action. The power estimation model works specifically for the consumption profile generated by a single application, which in this case is a video decoder. Nevertheless, it is necessary that the model works as accurate as possible for each frequency available on the processor, and for the greatest number of video sequences. This is because the power estimations are going to be used to modify dynamically the frequency, so the model must be able to work independently of the device frequency. To value the estimation model precision, some measurements of the device power consumption are taken at different frequencies during the video decoder execution. These measurements are compared with the power estimations obtained during that execution, getting the prediction error committed by the model, and if it is necessary, making modifications and settings on this model.

Virtualización de laboratorios

Para empezar, se ha hecho un análisis de las diferentes posibilidades que se podían implementar para poder conseguir el objetivo del trabajo. El resultado final debe ser, disponer de máquinas para que el sistema operativo fuese independiente del hardware que se tiene instalado en él . Para ello, se decide montar un sistema operativo de base en todos los equipos del laboratorio, que tenga las necesidades mínimas que se necesitan, las cuales son una interfaz gráfica y conexión de red. Hay que intentar reducir el consumo de recursos al máximo con este sistema operativo mínimo para que el rendimiento de las máquinas sea lo más fluido posible para los usuarios. El sistema elegido fue Linux con su distribución Ubuntu [ubu, http] con los módulos mínimos que permita funcionar el software necesario. Una vez se instala el sistema operativo anfitrión, se instala el escritorio Xfce [ubu2, http], que es el más ligero de Ubuntu, pero que proporciona buen rendimiento. Después, se procedió a instalar un software de virtualización en cada equipo. En este caso se decidió, por las buenas prestaciones que ofrecía, que fuera VirtualBox [vir2,http] de Oracle. Sobre éste software se crean tantas máquinas virtuales (con sistema operativo Windows) como asignaturas diferentes se cursan en el laboratorio donde se trabaje. Con esto, se consigue que al arrancar el programa los alumnos pudieran escoger qué máquina arrancar y lo que es más importante, se permite realizar cualquier cambio en el hardware (exceptuando el disco duro porque borraría todo lo que se tuviera guardado). Además de no tener que volver a reinstalar el sistema operativo nuevamente, se consigue la abstracción del software y hardware. También se decide que, para tener un respaldo de las máquinas virtuales que se tengan creadas en VirtualBox, se utiliza un servidor NAS. Uno de los motivos de utilizar dicho servidor fue por aprovechar una infraestructura ya creada. Un servidor NAS da la posibilidad de recuperar cualquier archivo (máquina virtual) cuando haga falta porque haya alguna máquina virtual corrupta en algún equipo, o en varios. Este tipo de servidor tiene la gran ventaja de ser multicast, es decir, permite solicitudes simultáneas. ABSTRACT For starters, there has been an analysis of the different possibilities that could be implemented to achieve the objective of the work. This objective was to have machines for the operating system to be independent of the hardware we have installed on it. Therefore, we decided to create an operating system based on all computers in the laboratory, taking the minimum needs we need. This is a graphical interface and network connection. We must try to reduce the consumption of resources to the maximum for the performance of the machines is as fluid as possible for users. The system was chosen with its Ubuntu Linux distribution with minimum modules that allow us to run software that is necessary for us. Once the base is installed, we install the Xfce desktop, which is the lightest of Ubuntu, but which provided good performance. Then we proceeded to install a virtualization software on each computer. In this case we decided, for good performance that gave us, it was Oracle VirtualBox. About this software create many virtual machines (Windows operating system) as different subjects are studied in the laboratory where we are. With that, we got it at program startup students could choose which machine start and what is more important, allowed us to make any changes to the hardware (except the hard drive because it would erase all we have). Besides not having to reinstall the operating system again, we get the software and hardware abstraction. We also decided that in order to have a backup of our virtual machines that we created in VirtualBox, we use a NAS server. One reason to use that server was to leverage their existing network infrastructure. A NAS server gives us the ability to retrieve any file (image) when we do need because there is some corrupt virtual machine in a team, or several. This is possible because this type of server allows multicast connection.

Análisis de reflectores en MatLab

Sabor, Software de Análisis de BOcinas y Reflectores, es una herramienta didáctica la cual es utilizada en los laboratorios de la escuela para realizar prácticas de la asignatura Antenas y Compatibilidad Electromagnética, esta herramienta da a los alumnos una visión gráfica de lo que se enseña en clase de teoría de lo que son los campos en las aperturas de los reflectores. El proyector pretende sustituir al primer Sabor , ya que se queda obsoleto debido al sistema operativo, ya que funciona solo para Windows XP y con ordenadores de 32 bits, y también realizar mejoras y corregir errores de la versión anterior. El proyecto se ha desarrollado en Matlab que es un software matemático con grandes ventajas en cuanto a cálculo, desarrollo gráfico, y a la creación de nuevos algoritmos en su propio lenguaje y además está disponible para las plataformas Unix, Windows, Mac OSX y GNU/Linux. El objetivo del proyecto ha sido implementar, al igual que las versiones anteriores, cinco tipos de reflectores, como son: Parabólico, Offset, Cassegrain y los dos Dobles Offset, Cassegrain y Gregorian, y han sido analizados con un alimentador ideal ,cos-q, y por último los resultados obtenidos se han comparado con las versiones anteriores de Sabor, como son Sabor 3.0 y el primer Sabor. El proyecto consta de partes muy bien diferencias como son :  La interpretación correctas de las formulas que se han utilizado para la realización de este proyecto ,dichas formulas han sido las dadas por el proyecto fin de carrera titulado Sabor3.0 de Francisco Egea Castejón.  GUIDE, the graphical user interface development environment, con el que se creó: GUI, graphical user interface, que es la parte de Matlab dedicada a crear interfaces de usuario , herramienta utilizada para crear nuestras distintas ventanas dedicadas para la obtención de datos para analizar los distintos reflectores y para mostrar por pantalla los distintos resultados.  Programación Orientada a Objetos de Matlab y sus distintas propiedades como son la herencia lo cual es muy útil para ocupar menos memoria ya que con un único método podemos realizar distintos cálculos con los distintos reflectores, objetos, solo cambiando las propiedades de cada objeto  Y por último ha sido la realización de validación de los resultados con la ayuda de las versiones anteriores de Sabor, que están detallados en el capítulo 5 y la unión con bocinas del proyecto fin de carrera Análisis de Bocinas en Matlab de Javier Montero. Por otra parte tenemos las mejoras realizadas a las antiguas versiones como son: realización de registros que el usuario puede guardar y cargar con las distintas variables, también se ha realizado un fichero .txt en el que consta la amplitud del campo con su respectiva theta para que el usuario pueda visualizarlo en cualquier plataforma gráfica de datos como por ejemplo exel. ABSTRACT. Sabor, Software de Análisis de BOcinas y Reflectores, is a teaching tool, which is used to do laboratory practice in the subject of Antennas y Compatibilidad Electromagnética, this tool gives students a graphic view of the knowledge that are given in theory class in regard to aperture field of reflectors. This project intend to replace the first Sabor, because it is outdated, due to the operating system, because Sabor works only with Widows XP and computer with 32 bits, and to make improves and correct errors that were detected in the last version of Sabor too. This project has been carried out in Matlab, which is a mathematical software with high-level language for numerical computation, visualization and application development, and furthermore it is available to different platforms such as Unix, Windows ,Mac OSX and GNU/Linux This project has focused on implementing, the same as last versions, five kind of reflectors, such as : Parabolic, Offset, Cassegrain and two offset dual reflector Cassegrain y Gregorian ,and these were analysed with a cos-q ideal feed, and finally the results were checked with the versions of Sabor, as well as Sabor 3.0 and the first Sabor. This project consist of four parts:  The correct interpretation of the formulas , which were used to do this project, from the final project Sabor3.0 by Francisco Egea Castejón.  GUIDE, the graphical user interface development environment, tool that was used to create : GUI, graphical user interface, part of Matlab dedicated to create user interface.  Object Oriented Programming of Matlab and different properties like inheritance, that is very useful for saving memory space because with only one method we can analyse different kind of reflectors, object, only change the properties of the object.  At finally, the results were contrasted with the results from the previous versions and the link reflectors with horns from the final project Análisis de Bocinas en Matlab by Javier Montero. On the other hand, we have the improvements such as: registers and .txt file. The registers are used by user to save and load different variables and .txt file is useful because it allows to the user plotting in different platforms for example exel.

Sistema domótico controlado por mensajería instantánea Whatsapp para personas con discapacidad

El presente PFC tiene como objetivo el desarrollo de un gestor domótico basado en el dictado de voz de la red social WhatsApp. Dicho gestor no solo sustituirá el concepto dañino de que la integración de la domótica hoy en día es cara e inservible sino que acercará a aquellas personas con una discapacidad a tener una mejora en la calidad de vida. Estas personas, con un simple comando de voz a su aplicación WhatsApp de su terminal móvil, podrán activar o desactivar todos los elementos domóticos que su vivienda tenga instalados, “activar lámpara”, “encender Horno”, “abrir Puerta”… Todo a un muy bajo precio y utilizando tecnologías OpenSource El objetivo principal de este PFC es ayudar a la gente con una discapacidad a tener mejor calidad de vida, haciéndose independiente en las labores del hogar, ya que será el hogar quien haga las labores. La accesibilidad de este servicio, es por tanto, la mayor de las metas. Para conseguir accesibilidad para todas las personas, se necesita un servicio barato y de fácil aprendizaje. Se elige la red social WhatsApp como interprete, ya que no necesita de formación al ser una aplicación usada mayoritariamente en España y por la capacidad del dictado de voz, y se eligen las tecnologías OpenSource por ser la gran mayoría de ellas gratuitas o de pago solo el hardware. La utilización de la Red social WhatsApp se justifica por sí sola, en septiembre de 2015 se registraron 900 millones de usuarios. Este dato es fruto, también, de la reciente adquisición por parte de Facebook y hace que cumpla el primer requisito de accesibilidad para el servicio domotico que se presenta. Desde hace casi 5 años existe una API liberada de WhatsApp, que la comunidad OpenSource ha utilizado, para crear sus propios clientes o aplicaciones de envío de mensajes, usando la infraestructura de la red social. La empresa no lo aprueba abiertamente, pero la liberación de la API fue legal y su uso también lo es. Por otra parte la empresa se reserva el derecho de bloquear cuentas por el uso fraudulento de su infraestructura. Las tecnologías OpenSource utilizadas han sido, distribuciones Linux (Raspbian) y lenguajes de programación PHP, Python y BASHSCRIPT, todo cubierto por la comunidad, ofreciendo soporte y escalabilidad. Es por ello que se utiliza, como matriz y gestor domotico central, una RaspberryPI. Los servicios que el gestor ofrece en su primera versión incluyen el control domotico de la iluminación eléctrica general o personal, el control de todo tipo de electrodomésticos, el control de accesos para la puerta principal de entrada y el control de medios audiovisuales. ABSTRACT. This final thesis aims to develop a domotic manager based on the speech recognition capacity implemented in the social network, WhatsApp. This Manager not only banish the wrong idea about how expensive and useless is a domotic installation, this manager will give an opportunity to handicapped people to improve their quality of life. These people, with a simple voice command to their own WhatsApp, could enable or disable all the domotics devices installed in their living places. “On Lamp”, “ON Oven”, “Open Door”… This service reduce considerably the budgets because the use of OpenSource Technologies. The main achievement of this thesis is help handicapped people improving their quality of life, making independent from the housework. The house will do the work. The accessibility is, by the way, the goal to achieve. To get accessibility to a width range, we need a cheap, easy to learn and easy to use service. The social Network WhatsApp is one part of the answer, this app does not need explanation because is used all over the world, moreover, integrates the speech recognition capacity. The OpenSource technologies is the other part of the answer due to the low costs or, even, the free costs of their implementations. The use of the social network WhatsApp is explained by itself. In September 2015 were registered around 900 million users, of course, the recent acquisition by Facebook has helped in this astronomic number and match the first law of this service about the accessibility. Since five years exists, in the internet, a free WhatsApp API. The OpenSource community has used this API to develop their own messaging apps or desktop-clients, using the WhatsApp infrastructure. The company does not approve officially, however le API freedom is legal and the use of the API is legal too. On the other hand, the company can block accounts who makes a fraudulent use of his infrastructure. OpenSource technologies used in this thesis are: Linux distributions (Raspbian) and programming languages PHP, Python and BASHCSRIPT, all of these technologies are covered by the community offering support and scalability. Due to that, it is used a RaspberryPI as the Central Domotic Manager. The domotic services that currently this manager achieve are: Domotic lighting control, electronic devices control, access control to the main door and Media Control.

Análisis de las herramientas ORCC y Vivado HLS para la Síntesis de Modelos de Flujo de Datos RVC-CAL

En este Proyecto Fin de Grado se ha realizado un estudio de cómo generar, a partir de modelos de flujo de datos en RVC-CAL (Reconfigurable Video Coding – CAL Actor Language), modelos VHDL (Versatile Hardware Description Language) mediante Vivado HLS (Vivado High Level Synthesis), incluida en las herramientas disponibles en Vivado de Xilinx. Una vez conseguido el modelo VHDL resultante, la intención es que mediante las herramientas de Xilinx se programe en una FPGA (Field Programmable Gate Array) o el dispositivo Zynq también desarrollado por Xilinx. RVC-CAL es un lenguaje de flujo de datos que describe la funcionalidad de bloques funcionales, denominados actores. Las funcionalidades que desarrolla un actor se definen como acciones, las cuales pueden ser diferentes en un mismo actor. Los actores pueden comunicarse entre sí y formar una red de actores o network. Con Vivado HLS podemos obtener un diseño VHDL a partir de un modelo en lenguaje C. Por lo que la generación de modelos en VHDL a partir de otros en RVC-CAL, requiere una fase previa en la que los modelos en RVC-CAL serán compilados para conseguir su equivalente en lenguaje C. El compilador ORCC (Open RVC-CAL Compiler) es la herramienta que nos permite lograr diseños en lenguaje C partiendo de modelos en RVC-CAL. ORCC no crea directamente el código ejecutable, sino que genera un código fuente disponible para ser compilado por otra herramienta, en el caso de este proyecto, el compilador GCC (Gnu C Compiler) de Linux. En resumen en este proyecto nos encontramos con tres puntos de estudio bien diferenciados, los cuales son: 1. Partimos de modelos de flujo de datos en RVC-CAL, los cuales son compilados por ORCC para alcanzar su traducción en lenguaje C. 2. Una vez conseguidos los diseños equivalentes en lenguaje C, son sintetizados en Vivado HLS para conseguir los modelos en VHDL. 3. Los modelos VHDL resultantes serian manipulados por las herramientas de Xilinx para producir el bitstream que sea programado en una FPGA o en el dispositivo Zynq. En el estudio del segundo punto, nos encontramos con una serie de elementos conflictivos que afectan a la síntesis en Vivado HLS de los diseños en lenguaje C generados por ORCC. Estos elementos están relacionados con la manera que se encuentra estructurada la especificación en C generada por ORCC y que Vivado HLS no puede soportar en determinados momentos de la síntesis. De esta manera se ha propuesto una transformación “manual” de los diseños generados por ORCC que afecto lo menos posible a los modelos originales para poder realizar la síntesis con Vivado HLS y crear el fichero VHDL correcto. De esta forma este documento se estructura siguiendo el modelo de un trabajo de investigación. En primer lugar, se exponen las motivaciones y objetivos que apoyan y se esperan lograr en este trabajo. Seguidamente, se pone de manifiesto un análisis del estado del arte de los elementos necesarios para el desarrollo del mismo, proporcionando los conceptos básicos para la correcta comprensión y estudio del documento. Se realiza una descripción de los lenguajes RVC-CAL y VHDL, además de una introducción de las herramientas ORCC y Vivado, analizando las bondades y características principales de ambas. Una vez conocido el comportamiento de ambas herramientas, se describen las soluciones desarrolladas en nuestro estudio de la síntesis de modelos en RVC-CAL, poniéndose de manifiesto los puntos conflictivos anteriormente señalados que Vivado HLS no puede soportar en la síntesis de los diseños en lenguaje C generados por el compilador ORCC. A continuación se presentan las soluciones propuestas a estos errores acontecidos durante la síntesis, con las cuales se pretende alcanzar una especificación en C más óptima para una correcta síntesis en Vivado HLS y alcanzar de esta forma los modelos VHDL adecuados. Por último, como resultado final de este trabajo se extraen un conjunto de conclusiones sobre todos los análisis y desarrollos acontecidos en el mismo. Al mismo tiempo se proponen una serie de líneas futuras de trabajo con las que se podría continuar el estudio y completar la investigación desarrollada en este documento. ABSTRACT. In this Project it has made a study of how to generate, from data flow models in RVC-CAL (Reconfigurable Video Coding - Actor CAL Language), VHDL models (Versatile Hardware Description Language) by Vivado HLS (Vivado High Level Synthesis), included in the tools available in Vivado of Xilinx. Once achieved the resulting VHDL model, the intention is that by the Xilinx tools programmed in FPGA or Zynq device also developed by Xilinx. RVC-CAL is a dataflow language that describes the functionality of functional blocks, called actors. The functionalities developed by an actor are defined as actions, which may be different in the same actor. Actors can communicate with each other and form a network of actors. With Vivado HLS we can get a VHDL design from a model in C. So the generation of models in VHDL from others in RVC-CAL requires a preliminary phase in which the models RVC-CAL will be compiled to get its equivalent in C. The compiler ORCC (Open RVC-CAL Compiler) is the tool that allows us to achieve designs in C language models based on RVC-CAL. ORCC not directly create the executable code but generates an available source code to be compiled by another tool, in the case of this project, the GCC compiler (GNU C Compiler) of Linux. In short, in this project we find three well-defined points of study, which are: 1. We start from data flow models in RVC-CAL, which are compiled by ORCC to achieve its translation in C. 2. Once you realize the equivalent designs in C, they are synthesized in Vivado HLS for VHDL models. 3. The resulting models VHDL would be manipulated by Xilinx tools to produce the bitstream that is programmed into an FPGA or Zynq device. In the study of the second point, we find a number of conflicting elements that affect the synthesis Vivado HLS designs in C generated by ORCC. These elements are related to the way it is structured specification in C generated ORCC and Vivado HLS cannot hold at certain times of the synthesis. Thus it has proposed a "manual" transformation of designs generated by ORCC that affected as little as possible to the original in order to perform the synthesis Vivado HLS and create the correct file VHDL models. Thus this document is structured along the lines of a research. First, the motivations and objectives that support and hope to reach in this work are presented. Then it shows an analysis the state of the art of the elements necessary for its development, providing the basics for a correct understanding and study of the document. A description of the RVC-CAL and VHDL languages is made, in addition an introduction of the ORCC and Vivado tools, analyzing the advantages and main features of both. Once you know the behavior of both tools, the solutions developed in our study of the synthesis of RVC-CAL models, introducing the conflicting points mentioned above are described that Vivado HLS cannot stand in the synthesis of design in C language generated by ORCC compiler. Below the proposed solutions to these errors occurred during synthesis, with which it is intended to achieve optimum C specification for proper synthesis Vivado HLS and thus create the appropriate VHDL models are presented. Finally, as the end result of this work a set of conclusions on all analyzes and developments occurred in the same are removed. At the same time a series of future lines of work which could continue to study and complete the research developed in this document are proposed.

Technology independent honeynet description language

Several languages have been proposed for the task of describing networks of systems, either to help on managing, simulate or deploy testbeds for testing purposes. However, there is no one specifically designed to describe the honeynets, covering the specific characteristics in terms of applications and tools included in the honeypot systems that make the honeynet. In this paper, the requirements of honeynet description are studied and a survey of existing description languages is presented, concluding that a CIM (Common Information Model) match the basic requirements. Thus, a CIM like technology independent honeynet description language (TIHDL) is proposed. The language is defined being independent of the platform where the honeynet will be deployed later, and it can be translated, either using model-driven techniques or other translation mechanisms, into the description languages of honeynet deployment platforms and tools. This approach gives flexibility to allow the use of a combination of heterogeneous deployment platforms. Besides, a flexible virtual honeynet generation tool (HoneyGen) based on the approach and description language proposed and capable of deploying honeynets over VNX (Virtual Networks over LinuX) and Honeyd platforms is presented for validation purposes.