A model to develop a platform for personalised health applications

Antecedentes Europa vive una situación insostenible. Desde el 2008 se han reducido los recursos de los gobiernos a raíz de la crisis económica. El continente Europeo envejece con ritmo constante al punto que se prevé que en 2050 habrá sólo dos trabajadores por jubilado [54]. A esta situación se le añade el aumento de la incidencia de las enfermedades crónicas, relacionadas con el envejecimiento, cuyo coste puede alcanzar el 7% del PIB de un país [51]. Es necesario un cambio de paradigma. Una nueva manera de cuidar de la salud de las personas: sustentable, eficaz y preventiva más que curativa. Algunos estudios abogan por el cuidado personalizado de la salud (pHealth). En este modelo las prácticas médicas son adaptadas e individualizadas al paciente, desde la detección de los factores de riesgo hasta la personalización de los tratamientos basada en la respuesta del individuo [81]. El cuidado personalizado de la salud está asociado a menudo al uso de las tecnologías de la información y comunicación (TICs) que, con su desarrollo exponencial, ofrecen oportunidades interesantes para la mejora de la salud. El cambio de paradigma hacia el pHealth está lentamente ocurriendo, tanto en el ámbito de la investigación como en la industria, pero todavía no de manera significativa. Existen todavía muchas barreras relacionadas a la economía, a la política y la cultura. También existen barreras puramente tecnológicas, como la falta de sistemas de información interoperables [199]. A pesar de que los aspectos de interoperabilidad están evolucionando, todavía hace falta un diseño de referencia especialmente direccionado a la implementación y el despliegue en gran escala de sistemas basados en pHealth. La presente Tesis representa un intento de organizar la disciplina de la aplicación de las TICs al cuidado personalizado de la salud en un modelo de referencia, que permita la creación de plataformas de desarrollo de software para simplificar tareas comunes de desarrollo en este dominio. Preguntas de investigación RQ1 >Es posible definir un modelo, basado en técnicas de ingeniería del software, que represente el dominio del cuidado personalizado de la salud de una forma abstracta y representativa? RQ2 >Es posible construir una plataforma de desarrollo basada en este modelo? RQ3 >Esta plataforma ayuda a los desarrolladores a crear sistemas pHealth complejos e integrados? Métodos Para la descripción del modelo se adoptó el estándar ISO/IEC/IEEE 42010por ser lo suficientemente general y abstracto para el amplio enfoque de esta tesis [25]. El modelo está definido en varias partes: un modelo conceptual, expresado a través de mapas conceptuales que representan las partes interesadas (stakeholders), los artefactos y la información compartida; y escenarios y casos de uso para la descripción de sus funcionalidades. El modelo fue desarrollado de acuerdo a la información obtenida del análisis de la literatura, incluyendo 7 informes industriales y científicos, 9 estándares, 10 artículos en conferencias, 37 artículos en revistas, 25 páginas web y 5 libros. Basándose en el modelo se definieron los requisitos para la creación de la plataforma de desarrollo, enriquecidos por otros requisitos recolectados a través de una encuesta realizada a 11 ingenieros con experiencia en la rama. Para el desarrollo de la plataforma, se adoptó la metodología de integración continua [74] que permitió ejecutar tests automáticos en un servidor y también desplegar aplicaciones en una página web. En cuanto a la metodología utilizada para la validación se adoptó un marco para la formulación de teorías en la ingeniería del software [181]. Esto requiere el desarrollo de modelos y proposiciones que han de ser validados dentro de un ámbito de investigación definido, y que sirvan para guiar al investigador en la búsqueda de la evidencia necesaria para justificarla. La validación del modelo fue desarrollada mediante una encuesta online en tres rondas con un número creciente de invitados. El cuestionario fue enviado a 134 contactos y distribuido en algunos canales públicos como listas de correo y redes sociales. El objetivo era evaluar la legibilidad del modelo, su nivel de cobertura del dominio y su potencial utilidad en el diseño de sistemas derivados. El cuestionario incluía preguntas cuantitativas de tipo Likert y campos para recolección de comentarios. La plataforma de desarrollo fue validada en dos etapas. En la primera etapa se utilizó la plataforma en un experimento a pequeña escala, que consistió en una sesión de entrenamiento de 12 horas en la que 4 desarrolladores tuvieron que desarrollar algunos casos de uso y reunirse en un grupo focal para discutir su uso. La segunda etapa se realizó durante los tests de un proyecto en gran escala llamado HeartCycle [160]. En este proyecto un equipo de diseñadores y programadores desarrollaron tres aplicaciones en el campo de las enfermedades cardio-vasculares. Una de estas aplicaciones fue testeada en un ensayo clínico con pacientes reales. Al analizar el proyecto, el equipo de desarrollo se reunió en un grupo focal para identificar las ventajas y desventajas de la plataforma y su utilidad. Resultados Por lo que concierne el modelo que describe el dominio del pHealth, la parte conceptual incluye una descripción de los roles principales y las preocupaciones de los participantes, un modelo de los artefactos TIC que se usan comúnmente y un modelo para representar los datos típicos que son necesarios formalizar e intercambiar entre sistemas basados en pHealth. El modelo funcional incluye un conjunto de 18 escenarios, repartidos en: punto de vista de la persona asistida, punto de vista del cuidador, punto de vista del desarrollador, punto de vista de los proveedores de tecnologías y punto de vista de las autoridades; y un conjunto de 52 casos de uso repartidos en 6 categorías: actividades de la persona asistida, reacciones del sistema, actividades del cuidador, \engagement" del usuario, actividades del desarrollador y actividades de despliegue. Como resultado del cuestionario de validación del modelo, un total de 65 personas revisó el modelo proporcionando su nivel de acuerdo con las dimensiones evaluadas y un total de 248 comentarios sobre cómo mejorar el modelo. Los conocimientos de los participantes variaban desde la ingeniería del software (70%) hasta las especialidades médicas (15%), con declarado interés en eHealth (24%), mHealth (16%), Ambient Assisted Living (21%), medicina personalizada (5%), sistemas basados en pHealth (15%), informática médica (10%) e ingeniería biomédica (8%) con una media de 7.25_4.99 años de experiencia en estas áreas. Los resultados de la encuesta muestran que los expertos contactados consideran el modelo fácil de leer (media de 1.89_0.79 siendo 1 el valor más favorable y 5 el peor), suficientemente abstracto (1.99_0.88) y formal (2.13_0.77), con una cobertura suficiente del dominio (2.26_0.95), útil para describir el dominio (2.02_0.7) y para generar sistemas más específicos (2_0.75). Los expertos también reportan un interés parcial en utilizar el modelo en su trabajo (2.48_0.91). Gracias a sus comentarios, el modelo fue mejorado y enriquecido con conceptos que faltaban, aunque no se pudo demonstrar su mejora en las dimensiones evaluadas, dada la composición diferente de personas en las tres rondas de evaluación. Desde el modelo, se generó una plataforma de desarrollo llamada \pHealth Patient Platform (pHPP)". La plataforma desarrollada incluye librerías, herramientas de programación y desarrollo, un tutorial y una aplicación de ejemplo. Se definieron cuatro módulos principales de la arquitectura: el Data Collection Engine, que permite abstraer las fuentes de datos como sensores o servicios externos, mapeando los datos a bases de datos u ontologías, y permitiendo interacción basada en eventos; el GUI Engine, que abstrae la interfaz de usuario en un modelo de interacción basado en mensajes; y el Rule Engine, que proporciona a los desarrolladores un medio simple para programar la lógica de la aplicación en forma de reglas \if-then". Después de que la plataforma pHPP fue utilizada durante 5 años en el proyecto HeartCycle, 5 desarrolladores fueron reunidos en un grupo de discusión para analizar y evaluar la plataforma. De estas evaluaciones se concluye que la plataforma fue diseñada para encajar las necesidades de los ingenieros que trabajan en la rama, permitiendo la separación de problemas entre las distintas especialidades, y simplificando algunas tareas de desarrollo como el manejo de datos y la interacción asíncrona. A pesar de ello, se encontraron algunos defectos a causa de la inmadurez de algunas tecnologías empleadas, y la ausencia de algunas herramientas específicas para el dominio como el procesado de datos o algunos protocolos de comunicación relacionados con la salud. Dentro del proyecto HeartCycle la plataforma fue utilizada para el desarrollo de la aplicación \Guided Exercise", un sistema TIC para la rehabilitación de pacientes que han sufrido un infarto del miocardio. El sistema fue testeado en un ensayo clínico randomizado en el cual a 55 pacientes se les dio el sistema para su uso por 21 semanas. De los resultados técnicos del ensayo se puede concluir que, a pesar de algunos errores menores prontamente corregidos durante el estudio, la plataforma es estable y fiable. Conclusiones La investigación llevada a cabo en esta Tesis y los resultados obtenidos proporcionan las respuestas a las tres preguntas de investigación que motivaron este trabajo: RQ1 Se ha desarrollado un modelo para representar el dominio de los sistemas personalizados de salud. La evaluación hecha por los expertos de la rama concluye que el modelo representa el dominio con precisión y con un balance apropiado entre abstracción y detalle. RQ2 Se ha desarrollado, con éxito, una plataforma de desarrollo basada en el modelo. RQ3 Se ha demostrado que la plataforma es capaz de ayudar a los desarrolladores en la creación de software pHealth complejos. Las ventajas de la plataforma han sido demostradas en el ámbito de un proyecto de gran escala, aunque el enfoque genérico adoptado indica que la plataforma podría ofrecer beneficios también en otros contextos. Los resultados de estas evaluaciones ofrecen indicios de que, ambos, el modelo y la plataforma serán buenos candidatos para poderse convertir en una referencia para futuros desarrollos de sistemas pHealth. ABSTRACT Background Europe is living in an unsustainable situation. The economic crisis has been reducing governments' economic resources since 2008 and threatening social and health systems, while the proportion of older people in the European population continues to increase so that it is foreseen that in 2050 there will be only two workers per retiree [54]. To this situation it should be added the rise, strongly related to age, of chronic diseases the burden of which has been estimated to be up to the 7% of a country's gross domestic product [51]. There is a need for a paradigm shift, the need for a new way of caring for people's health, shifting the focus from curing conditions that have arisen to a sustainable and effective approach with the emphasis on prevention. Some advocate the adoption of personalised health care (pHealth), a model where medical practices are tailored to the patient's unique life, from the detection of risk factors to the customization of treatments based on each individual's response [81]. Personalised health is often associated to the use of Information and Communications Technology (ICT), that, with its exponential development, offers interesting opportunities for improving healthcare. The shift towards pHealth is slowly taking place, both in research and in industry, but the change is not significant yet. Many barriers still exist related to economy, politics and culture, while others are purely technological, like the lack of interoperable information systems [199]. Though interoperability aspects are evolving, there is still the need of a reference design, especially tackling implementation and large scale deployment of pHealth systems. This thesis contributes to organizing the subject of ICT systems for personalised health into a reference model that allows for the creation of software development platforms to ease common development issues in the domain. Research questions RQ1 Is it possible to define a model, based on software engineering techniques, for representing the personalised health domain in an abstract and representative way? RQ2 Is it possible to build a development platform based on this model? RQ3 Does the development platform help developers create complex integrated pHealth systems? Methods As method for describing the model, the ISO/IEC/IEEE 42010 framework [25] is adopted for its generality and high level of abstraction. The model is specified in different parts: a conceptual model, which makes use of concept maps, for representing stakeholders, artefacts and shared information, and in scenarios and use cases for the representation of the functionalities of pHealth systems. The model was derived from literature analysis, including 7 industrial and scientific reports, 9 electronic standards, 10 conference proceedings papers, 37 journal papers, 25 websites and 5 books. Based on the reference model, requirements were drawn for building the development platform enriched with a set of requirements gathered in a survey run among 11 experienced engineers. For developing the platform, the continuous integration methodology [74] was adopted which allowed to perform automatic tests on a server and also to deploy packaged releases on a web site. As a validation methodology, a theory building framework for SW engineering was adopted from [181]. The framework, chosen as a guide to find evidence for justifying the research questions, imposed the creation of theories based on models and propositions to be validated within a scope. The validation of the model was conducted as an on-line survey in three validation rounds, encompassing a growing number of participants. The survey was submitted to 134 experts of the field and on some public channels like relevant mailing lists and social networks. Its objective was to assess the model's readability, its level of coverage of the domain and its potential usefulness in the design of actual, derived systems. The questionnaires included quantitative Likert scale questions and free text inputs for comments. The development platform was validated in two scopes. As a small-scale experiment, the platform was used in a 12 hours training session where 4 developers had to perform an exercise consisting in developing a set of typical pHealth use cases At the end of the session, a focus group was held to identify benefits and drawbacks of the platform. The second validation was held as a test-case study in a large scale research project called HeartCycle the aim of which was to develop a closed-loop disease management system for heart failure and coronary heart disease patients [160]. During this project three applications were developed by a team of programmers and designers. One of these applications was tested in a clinical trial with actual patients. At the end of the project, the team was interviewed in a focus group to assess the role the platform had within the project. Results For what regards the model that describes the pHealth domain, its conceptual part includes a description of the main roles and concerns of pHealth stakeholders, a model of the ICT artefacts that are commonly adopted and a model representing the typical data that need to be formalized among pHealth systems. The functional model includes a set of 18 scenarios, divided into assisted person's view, caregiver's view, developer's view, technology and services providers' view and authority's view, and a set of 52 Use Cases grouped in 6 categories: assisted person's activities, system reactions, caregiver's activities, user engagement, developer's activities and deployer's activities. For what concerns the validation of the model, a total of 65 people participated in the online survey providing their level of agreement in all the assessed dimensions and a total of 248 comments on how to improve and complete the model. Participants' background spanned from engineering and software development (70%) to medical specialities (15%), with declared interest in the fields of eHealth (24%), mHealth (16%), Ambient Assisted Living (21%), Personalized Medicine (5%), Personal Health Systems (15%), Medical Informatics (10%) and Biomedical Engineering (8%) with an average of 7.25_4.99 years of experience in these fields. From the analysis of the answers it is possible to observe that the contacted experts considered the model easily readable (average of 1.89_0.79 being 1 the most favourable scoring and 5 the worst), sufficiently abstract (1.99_0.88) and formal (2.13_0.77) for its purpose, with a sufficient coverage of the domain (2.26_0.95), useful for describing the domain (2.02_0.7) and for generating more specific systems (2_0.75) and they reported a partial interest in using the model in their job (2.48_0.91). Thanks to their comments, the model was improved and enriched with concepts that were missing at the beginning, nonetheless it was not possible to prove an improvement among the iterations, due to the diversity of the participants in the three rounds. From the model, a development platform for the pHealth domain was generated called pHealth Patient Platform (pHPP). The platform includes a set of libraries, programming and deployment tools, a tutorial and a sample application. The main four modules of the architecture are: the Data Collection Engine, which allows abstracting sources of information like sensors or external services, mapping data to databases and ontologies, and allowing event-based interaction and filtering, the GUI Engine, which abstracts the user interface in a message-like interaction model, the Workow Engine, which allows programming the application's user interaction ows with graphical workows, and the Rule Engine, which gives developers a simple means for programming the application's logic in the form of \if-then" rules. After the 5 years experience of HeartCycle, partially programmed with pHPP, 5 developers were joined in a focus group to discuss the advantages and drawbacks of the platform. The view that emerged from the training course and the focus group was that the platform is well-suited to the needs of the engineers working in the field, it allowed the separation of concerns among the different specialities and it simplified some common development tasks like data management and asynchronous interaction. Nevertheless, some deficiencies were pointed out in terms of a lack of maturity of some technological choices, and for the absence of some domain-specific tools, e.g. for data processing or for health-related communication protocols. Within HeartCycle, the platform was used to develop part of the Guided Exercise system, a composition of ICT tools for the physical rehabilitation of patients who suffered from myocardial infarction. The system developed using the platform was tested in a randomized controlled clinical trial, in which 55 patients used the system for 21 weeks. The technical results of this trial showed that the system was stable and reliable. Some minor bugs were detected, but these were promptly corrected using the platform. This shows that the platform, as well as facilitating the development task, can be successfully used to produce reliable software. Conclusions The research work carried out in developing this thesis provides responses to the three three research questions that were the motivation for the work. RQ1 A model was developed representing the domain of personalised health systems, and the assessment of experts in the field was that it represents the domain accurately, with an appropriate balance between abstraction and detail. RQ2 A development platform based on the model was successfully developed. RQ3 The platform has been shown to assist developers create complex pHealth software. This was demonstrated within the scope of one large-scale project, but the generic approach adopted provides indications that it would offer benefits more widely. The results of these evaluations provide indications that both the model and the platform are good candidates for being a reference for future pHealth developments.

DCE@urLAB: a dynamic contrast-enhanced MRI pharmacokinetic analysis tool for preclinical data

Background DCE@urLAB is a software application for analysis of dynamic contrast-enhanced magnetic resonance imaging data (DCE-MRI). The tool incorporates a friendly graphical user interface (GUI) to interactively select and analyze a region of interest (ROI) within the image set, taking into account the tissue concentration of the contrast agent (CA) and its effect on pixel intensity. Results Pixel-wise model-based quantitative parameters are estimated by fitting DCE-MRI data to several pharmacokinetic models using the Levenberg-Marquardt algorithm (LMA). DCE@urLAB also includes the semi-quantitative parametric and heuristic analysis approaches commonly used in practice. This software application has been programmed in the Interactive Data Language (IDL) and tested both with publicly available simulated data and preclinical studies from tumor-bearing mouse brains. Conclusions A user-friendly solution for applying pharmacokinetic and non-quantitative analysis DCE-MRI in preclinical studies has been implemented and tested. The proposed tool has been specially designed for easy selection of multi-pixel ROIs. A public release of DCE@urLAB, together with the open source code and sample datasets, is available at http://www.die.upm.es/im/archives/DCEurLAB/ webcite.

Desarrollo de herramientas para la autoevaluación del Laboratorio de Procesado Digital de la Señal

Este proyecto tiene como objetivo el desarrollo de una herramienta que permita al alumno la autocorrección de prácticas de la asignatura de Procesado Digital de la Señal. La herramienta será diseñada por medio del GUI de Matlab, que permite la creación de interfaces gráficos de usuario para la interacción con el alumno, así él mismo podrá comprobar si los resultado obtenidos para el enunciado de la práctica facilitado son correctos. La evaluación del alumno se llevará a cabo pidiendo distintas respuestas sobre las prácticas y comparándolas posteriormente con los resultados correctos. El código invisible al usuario será el encargado de indicar si el resultado es correcto o no lo es. ABSTRACT. The aim of this project is to develop a tool for the students of Digital Signal Processing that help them self-correct their lab exercises. The tool will be designed using the Matlab GUI, which allows the creation of graphical user interfaces to interact with the student, who can check whether the results obtained are correct or not. The student will be asked about different results of the exercises and the answers will be compared with the correct results. A part of the tool hidden to the student will reveal to the lecturer the outcome of this comparison.

Implementación de sistema domótico con servidor Raspberry

Este proyecto consiste en el diseño e implementación un sistema domótico que puede ser instalado en una vivienda para controlar distintas variables ambientales y conseguir así la máxima comodidad de los habitantes de manera automática o manual según los gustos y necesidades de los usuarios. La característica principal de este sistema, es que cuenta con un funcionamiento distribuido donde entran en juego un servidor, encargado de tomar las decisiones generales para el comportamiento de la casa, y una serie de controladores esclavo cuya función es mantener constantes las variables ambientales con los valores fijados por el servidor. Así se consigue mantener la vivienda en una situación de bienestar constante para cualquier persona que se encuentre dentro. El sistema ha sido pensado de manera que se intenta reducir al máximo el cableado para facilitar su instalación por lo que la comunicación entre los distintos dispositivos se hace de manera inalámbrica por medio de un protocolo descrito en la norma IEEE 802.15.4 llamado ZigBee. Para ello se ha utilizado un módulo de comunicación wireless llamado Xbee, el cual permite la comunicación entre dos dispositivos. Para el control de dicho sistema distribuido se cuenta con una aplicación web, que mediante una interfaz gráfica permite al usuario controlar los distintos dispositivos dentro de la vivienda consiguiendo así controlar las variables ambientales a gusto del usuario. Dicha interfaz gráfica no depende de un software específico, sino que sólo es necesario un cliente http como podría ser Internet Explorer, Mozilla Firefox, Google Chrome, etc. Para integrar dicho sistema se ha usado un mini ordenador de bajo coste llamado RaspBerryPi, en el que se encuentra alojado un servidor Apache con el fin de gestionar y automatizar las variables ambientales. El control de los dipositivos encargados de modificar y estabilizar las variables ambientales se realiza mediante unos controladores genéricos implementados mediante mcontroladores 80C51F410, pertenecientes a la familia 80C51, y una serie de componentes y circuitería que permiten el correcto funcionamiento de éstos. Existen dos tipos de controladores distintos, los cuales son: Controlador Sensor: Encargados de las tomas de valores ambientales como puede ser la luz y la temperatura. Controladores Actuadores: Encargados de actuar sobre los dispositivos que modifican y estabilizan las variables ambientales como pueden ser la calefacción, tiras de leds de iluminación, persianas, alarmas, etc. El conjunto de la RaspBerryPi y los diferentes controladores forman el prototipo diseñado para este proyecto fin de carrera, el cual puede ser ampliado sencillamente para abarcar una amplia gama de posibilidades y funcionalidades dentro de la comodidad de una vivienda. ABSTRACT. The project described in this report consisted designing and implementing a home automation system that could be installed in a house in order to control environmental variables and thus get the maximum comfort of the inhabitant automatically or manually according to their tastes and needs. The main feature of this system consists in a distributed system, formed by a server which is responsible for making the main decisions of the actions performed inside the house. In addition, there are a series of slave controlers whose function consists in keeping the environmental variables within the values established by the server. Thus gets to keep the home in a situation of constant wellbeing to anyone who is inside. The system has been designed in order to reduce the amount of wire needed for the inter-connection of the devices, by means of wireless communication. The devices chosen for the solution are Xbee modules, which use the Zigbee protocol in order to comunicate one between each other. The Zigbee protocol is fully described in the IEEE 802.15.4 standard. A web application has been used to control the distributed system. This application allows users to control various devices inside the house and subsequently the different environmental variables. This implementation allows obtaining the maximum comfort by means of a very simple graphical interface. In addition, the Graphical User Interface (GUI) does not depend on any specific software. This means that it would only be necessary a http client (such as Internet Explorer, Mozilla Firefox, Google Chrome, etc.) for handling the application. The system has been integrated using a low-cost mini computer called RaspBerryPi.This computer has an Apache server allocated which allows to manage and to automatize the different environmental variables. Furthermore, for changing and stabilizing those variables, some generic controllers have been developed, based on mcontrollers 80C51F410. There have been developed mainly two different types of controllers: Sensor Controllers, responsible for measuring the different environmental values, such as light and temperature; and Actuator Controllers, which purpose is to modify and stabilize those environmental variables by actuating on the heating, the led lamps, the blinders, the alarm, etc. The combination of the RaspBerryPi and the different controllers conform the prototype designed during this project. Additionally, this solution could be easily expanded in order to intake further functionalities adapted to new needs that could arise in the future.

3D simulation of complex shading affecting PV systems taking benefit from the power of graphics cards developed for the video game industry

Shading reduces the power output of a photovoltaic (PV) system. The design engineering of PV systems requires modeling and evaluating shading losses. Some PV systems are affected by complex shading scenes whose resulting PV energy losses are very difficult to evaluate with current modeling tools. Several specialized PV design and simulation software include the possibility to evaluate shading losses. They generally possess a Graphical User Interface (GUI) through which the user can draw a 3D shading scene, and then evaluate its corresponding PV energy losses. The complexity of the objects that these tools can handle is relatively limited. We have created a software solution, 3DPV, which allows evaluating the energy losses induced by complex 3D scenes on PV generators. The 3D objects can be imported from specialized 3D modeling software or from a 3D object library. The shadows cast by this 3D scene on the PV generator are then directly evaluated from the Graphics Processing Unit (GPU). Thanks to the recent development of GPUs for the video game industry, the shadows can be evaluated with a very high spatial resolution that reaches well beyond the PV cell level, in very short calculation times. A PV simulation model then translates the geometrical shading into PV energy output losses. 3DPV has been implemented using WebGL, which allows it to run directly from a Web browser, without requiring any local installation from the user. This also allows taken full benefits from the information already available from Internet, such as the 3D object libraries. This contribution describes, step by step, the method that allows 3DPV to evaluate the PV energy losses caused by complex shading. We then illustrate the results of this methodology to several application cases that are encountered in the world of PV systems design. Keywords: 3D, modeling, simulation, GPU, shading, losses, shadow mapping, solar, photovoltaic, PV, WebGL

Interfaz gráfica de usuario para la detección de microcalcificaciones mediante análisis de mamografía digitalizada

The graphical user interface (GUI) are all graphic elements that help to communicate with a system. The design of a GUI allow to land the central idea of a draft information technology. Today technology has become one of the largest and most useful tools to automate and facilitate processes for that reason fit into any kind of productive sectors, for example, in the health sector. The CAD systems (Systems Computer Aided Diagnosis) are the type of technology used in the health sector, in order to automate online modular learning environment with a fast placed in service. In the present paper the use of a Learning Management Systems (LMS) as continuous education tool is proposed.

Optimización de algoritmos para procesado de imágenes con GPUs

El objetivo de este proyecto es evaluar la mejora de rendimiento que aporta la paralelización de algoritmos de procesamiento de imágenes, para su ejecución en una tarjeta gráfica. Para ello, una vez seleccionados los algoritmos a estudio, fueron desarrollados en lenguaje C++ bajo el paradigma secuencial. A continuación, tomando como base estas implementaciones, se paralelizaron siguiendo las directivas de la tecnología CUDA (Compute Unified Device Architecture) desarrollada por NVIDIA. Posteriormente, se desarrolló un interfaz gráfico de usuario en Visual C#, para una utilización más sencilla de la herramienta. Por último, se midió el rendimiento de cada uno de los algoritmos, en términos de tiempo de ejecución paralela y speedup, mediante el procesamiento de una serie de imágenes de distintos tamaños.---ABSTRACT---The aim of this Project is to evaluate the performance improvement provided by the parallelization of image processing algorithms, which will be executed on a graphics processing unit. In order to do this, once the algorithms to study were selected, each of them was developed in C++ under sequential paradigm. Then, based on these implementations, these algorithms were implemented using the compute unified device architecture (CUDA) programming model provided by NVIDIA. After that, a graphical user interface (GUI) was developed to increase application’s usability. Finally, performance of each algorithm was measured in terms of parallel execution time and speedup by processing a set of images of different sizes.

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.

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.

Resolving taxonomic uncertainty in vulnerable elasmobranchs : are the Madeira skate (Raja maderensis) and the thornback ray (Raja clavata) distinct species?

We are grateful to all those who helped with sample collection. This includes the MEDITS survey programme (IEO Mallorca) for Mediterranean samples. Portugal mainland samples were collected under the EU Data Collection Framework (DCF, PNAB). Azores specimens from the Department of Oceanography and Fisheries (DOP) of the University of the Azores (UAc) were collected under the project DEMERSAIS “Monitorização das espécies demersais dos Açores” financed by the Azorean government, and the project DEECON “Unravelling population connectivity for sustainable fisheries in the Deep Sea” project approved by the European Science Foundation (ESF) under the EUROCORES programme (proposal No 06-EuroDEEP-FP-008 & SFRH-EuroDEEP/0002/2007). This study was funded by the UK Natural Environment Research Council (NERC) Oceans 2025 Strategic Research Programme Theme 6 (Science for Sustainable Marine Resources). REB was supported by the Fisheries Society of the British Isles (FSBI), BSP was funded by the Fundação para a Ciência e a Tecnologia, SFRH/BPD/72351/2010 and JL was supported by The Alasdair Downes Marine Conservation Fund.

Plasmon analyses of Triticum (wheat) and Aegilops: PCR–single-strand conformational polymorphism (PCR-SSCP) analyses of organellar DNAs

To investigate phylogenetic relationships among plasmons in Triticum and Aegilops, PCR–single-strand conformational polymorphism (PCR-SSCP) analyses were made of 14.0-kb chloroplast (ct) and 13.7-kb mitochondrial (mt)DNA regions that were isolated from 46 alloplasmic wheat lines and one euplasmic line. These plasmons represent 31 species of the two genera. The ct and mtDNA regions included 10 and 9 structural genes, respectively. A total of 177 bands were detected, of which 40.6% were variable. The proportion of variable bands in ctDNA (51.1%) was higher than that of mtDNA (28.9%). The phylogenetic trees of plasmons, derived by two different models, indicate a common picture of plasmon divergence in the two genera and suggest three major groups of plasmons (Einkorn, Triticum, and Aegilops). Because of uniparental plasmon transmission, the maternal parents of all but one polyploid species were identified. Only one Aegilops species, Ae. speltoides, was included in the Triticum group, suggesting that this species is the plasmon and B and G genome donor of all polyploid wheats. ctDNA variations were more intimately correlated with vegetative characters, whereas mtDNA variations were more closely correlated with reproductive characters. Plasmon divergence among the diploids of the two genera largely paralleled genome divergence. The relative times of origin of the polyploid species were inferred from genetic distances from their putative maternal parents.

Structural requirements for antigen presentation by mouse CD1

The structural basis for the T cell response to glycolipid antigens (Ags) remains poorly understood. T lymphocytes autoreactive for mouse CD1 (mCD1.1) or reactive for the glycosphingolipid αgalactosylceramide (α-GalCer) presented by mCD1.1 have been described previously. In this paper it is shown that mutations at the top of the α helices and in the bottom of the Ag-binding groove can disrupt both mCD1.1 autoreactivity and α-GalCer recognition. The locations of the positions that affect T cell responses indicate that recognition of mCD1.1 is not likely to be unconventional or superantigen-like. Furthermore, the effects of the bottom of the pocket mutation suggest that the autoreactive response could require an autologous ligand, and they indicate that α-GalCer binds to the groove of mCD1.1, most likely with the shorter 18-carbon hydrophobic chain in the A′ pocket. Natural killer T cell hybridomas with identical T cell antigen receptor (TCR) α chains and different β chains respond differently to α-GalCer presented by mCD1.1 mutants. This finding indicates a role for TCR β in defining natural killer T cell specificity, despite the more restricted diversity of the α chains in these cells. Overall, the data are consistent with a mode of lipoglycan recognition similar to that proposed for glycopeptides, in which the TCR α and β chains survey a surface composed of both mCD1.1 and the carbohydrate portion of α-GalCer.

Complete genome sequence of an M1 strain of Streptococcus pyogenes

The 1,852,442-bp sequence of an M1 strain of Streptococcus pyogenes, a Gram-positive pathogen, has been determined and contains 1,752 predicted protein-encoding genes. Approximately one-third of these genes have no identifiable function, with the remainder falling into previously characterized categories of known microbial function. Consistent with the observation that S. pyogenes is responsible for a wider variety of human disease than any other bacterial species, more than 40 putative virulence-associated genes have been identified. Additional genes have been identified that encode proteins likely associated with microbial “molecular mimicry” of host characteristics and involved in rheumatic fever or acute glomerulonephritis. The complete or partial sequence of four different bacteriophage genomes is also present, with each containing genes for one or more previously undiscovered superantigen-like proteins. These prophage-associated genes encode at least six potential virulence factors, emphasizing the importance of bacteriophages in horizontal gene transfer and a possible mechanism for generating new strains with increased pathogenic potential.

Arabidopsis Sec21p and Sec23p Homologs. Probable Coat Proteins of Plant COP-Coated Vesicles1

Intracellular protein transport between the endoplasmic reticulum (ER) and the Golgi apparatus and within the Golgi apparatus is facilitated by COP (coat protein)-coated vesicles. Their existence in plant cells has not yet been demonstrated, although the GTP-binding proteins required for coat formation have been identified. We have generated antisera against glutathione-S-transferase-fusion proteins prepared with cDNAs encoding the Arabidopsis Sec21p and Sec23p homologs (AtSec21p and AtSec23p, respectively). The former is a constituent of the COPI vesicle coatomer, and the latter is part of the Sec23/24p dimeric complex of the COPII vesicle coat. Cauliflower (Brassica oleracea) inflorescence homogenates were probed with these antibodies and demonstrated the presence of AtSec21p and AtSec23p antigens in both the cytosol and membrane fractions of the cell. The membrane-associated forms of both antigens can be solubilized by treatments typical for extrinsic proteins. The amounts of the cytosolic antigens relative to the membrane-bound forms increase after cold treatment, and the two antigens belong to different protein complexes with molecular sizes comparable to the corresponding nonplant coat proteins. Sucrose-density-gradient centrifugation of microsomal cell membranes from cauliflower suggests that, although AtSec23p seems to be preferentially associated with ER membranes, AtSec21p appears to be bound to both the ER and the Golgi membranes. This could be in agreement with the notion that COPII vesicles are formed at the ER, whereas COPI vesicles can be made by both Golgi and ER membranes. Both AtSec21p and AtSec23p antigens were detected on membranes equilibrating at sucrose densities equivalent to those typical for in vitro-induced COP vesicles from animal and yeast systems. Therefore, a further purification of the putative plant COP vesicles was undertaken.

Identification and characterization of a melanin-concentrating hormone receptor

Melanin-concentrating hormone (MCH), a neuropeptide expressed in central and peripheral nervous systems, plays an important role in the control of feeding behaviors and energy metabolism. An orphan G protein-coupled receptor (SLC-1/GPR24) has recently been identified as a receptor for MCH (MCHR1). We report here the identification and characterization of a G protein-coupled receptor as the MCH receptor subtype 2 (MCHR2). MCHR2 has higher protein sequence homology to MCHR1 than any other G protein-coupled receptor. The expression of MCHR2 has been detected in many regions of the brain. In contrast to MCHR1, which is intronless in the coding region and is located at the chromosomal locus 22q13.3, the MCHR2 gene has multiple exons and is mapped to locus 6q21. MCHR2 is specifically activated by nanomolar concentrations of MCH, binds to MCH with high affinity, and signals through Gq protein. This discovery is important for a full understanding of MCH biology and the development of potential therapeutics for diseases involving MCH, including obesity.