Desarrollo de una herramienta de minitorización y control de aplicaciones distribuidas en un entorno de integración continua

Debido a la creciente relevancia de la computación en la nube y de los sistemas distribuidos, cobran también creciente interés las herramientas que ayudan a los desarrolladores y administradores a desempeñar sus funciones con la mayor eficacia posible. Por ello el objetivo principal de este trabajo es el desarrollo de una herramienta capaz de crear y controlar un entorno de almacenamiento de claves distribuidas desde una máquina local e independiente, aumentando la productividad mediante la automatización de todas las tareas. La herramienta desarrollada tiene la capacidad necesaria para integrarse tanto en proyectos que se encuentren en marcha como para proyectos que aún no hayan comenzado y proveer una solución sencilla, eficaz, y, sobre todo, útil. A lo largo del trabajo se ha realizado una gran tarea de análisis para determinar cuáles serán, de entre las posibilidades existentes, las más apropiadas para su implementación, teniendo en cuenta las tecnologías líderes disponibles en el estado del arte. Ello ha requerido también la obtención de una mejor comprensión de su funcionamiento interno. Se han realizado diferentes diseños que se han analizado y discutido en detalle para encontrar la solución que mejor se adaptaba a los objetivos propuestos. Y finalmente se ha desarrollado una herramienta ligera y sencilla, pero con un gran potencial para la administración. ---ABSTRACT---Due to the growing relevance of cloud computing and distributed systems it seems interesting to take into account the importance of the administration tools that help developers and administrators fulfill their duties in the most efficient ways. Because of this motivation, the main objective of this project is the development of a tool capable of creating and controlling a distributed key storing environment from a local and independent machine, improving the productivity thanks to the automation of all the involved tasks. The developed tool is able to integrate itself into already running projects as well as in not-yet-started ones, providing a simple, efficient and overall useful solution. During this project big tasks of research and analysis have taken place in order to determine, from the existent possibilities, the most suitable for its implementation, taking into account the leading technologies in the sector, which are described in the state of the art section. This has required the acquisition of a better insight of their inner workings. Some different designs have been made and have been discussed in detail with the intention of finding the solution that best suits the proposed objectives. And finally a lightweight and simple tool has been developed, which presents a very big potential for administration tasks.

Caracterización de nanopartículas magnéticas y de oro para posibles aplicaciones biomédicas en diagnóstico y terapia

Los nanomateriales han adquirido recientemente un gran interés debido a la gran variedad de aplicaciones que pueden llegar a tener en el ámbito de la biomedicina. Este trabajo recoge las posibilidades tanto diagnósticas como terapéuticas que presentan dos modalidades de nanomateriales: nanopartículas de óxido de hierro y nanopartículas de oro. Para ello, en una primera aproximación se ha llevado a cabo la caracterización de las nanopartículas desde el punto de vista de la biocompatibilidad asociada a su tamaño y al tiempo de contacto o circulación en células y tejidos, ensayada tanto in vitro como in vivo así como la cinética de acumulación de dichas nanopartículas en el organismo vivo. Posteriormente se ha realizado la biofuncionalización de los dos tipos de nanopartículas para reconocer dianas moleculares específicas y poder ser utilizadas en el futuro en dos aplicaciones biomédicas diferentes: diagnóstico de enfermedad de Alzheimer mediante imagen de resonancia magnética y destrucción selectiva de células tumorales mediante hipertermia óptica. ABSTRACT Nanomaterials have recently gained a great interest due to the variety of applications that can have in the field of biomedicine. This work covers both diagnostic and therapeutic possibilities that present two types of nanomaterials: iron oxide nanoparticles and gold nanoparticles. Therefore, in a first approximation it has performed the characterizing of nanoparticles from the standpoint of biocompatibility associated with their size and time of contact or movement in cells and tissues, tested both in vitro and in vivo as well as the kinetics of accumulation of the nanoparticles into the living organism. Subsequently the biofunctionalization of two types of nanoparticles was made to recognize specific molecular targets and can be used in the future in two different biomedical applications: diagnosis of Alzheimer's disease by magnetic resonance imaging and selective destruction of tumor cells by optical hyperthermia.

Electro-motores de corrientes alternas: estudio teórico y principales aplicaciones

Si bien es verdad que existen algunos problemas de electricidad, donde las corrientes alternas no presentan satisfactorias soluciones y son posibles de emplear únicamente las continuas; por regla general los medios con que actualmente unas y otras cuentan, son tan comparables y tan iguales las ventajas e inconvenientes totales que en cada caso presenta sus uso que, ya que no imposible,es difícil tarea para el ingeniero adoptar razonadamente uno u otro sistema y sólo un detenido estudio del caso que ha de resolver pueden ayudarle en tan delicado asunto.

Principales maderas tropicales utilizadas en España: Características, tecnología y aplicaciones

Se describen las características de las principales maderas tropicales con uso en España. La descripción incluye el nombre científico, sinonimias, nombres vulgares, su distribución en el mundo y en España, la descripción del fuste y de las trozas, con sus defectos más característicos, la descripción de la madera, sus características físicas, mecánicas, resistentes y durables. También se incluye sus aspectos tecnológicos, en el sentido de indicar que aspectos deben considerarse a la hora de trabajar estas maderas. Por último se indican los usos más comunes de las distintas maderas, las ventajas e inconvenientes frente a otras maderas Las especies principales que se describen son las siguientes: Algarrobo blanco, Prosopis alba, Grisebach Andiroba, Carapa guianensis, Aubl. Balsamo, Myroxylon balsamun, Harms. Sandwith. Barba jolote, Pithecolobium arboreum (L), Urban. Bubinga, Guibourtia tessmanii Caoba, Swietenia macrophylla, King. Cedro, Cedrela odorata, L. Cenizaro, Pithecellobium saman, (Jacq.) Benth Chinchon, Guarea grandiflora, A. DC. Cocobolo, Dalbergia retusa, Hemsl Cristobal, Platysmicium polystachyum Elondo o tali, Erythrophleum ivorensis Espavé, Anacardium excelsum, Skeels Gonzalo Alves, Astronium graveolens, Jacquin. Guayabillo, Terminalia lucida, Hoff. Guapaque, Dialium guianense, (Aubl.) Sandwith. Guayacán, Guaiacum sanctum, L. Huesito Homalium racemosum, Jacq. Ipe, Tabebuia guayacan, Hemsl. Iroko, Milicia excelsa Sim Jatoba, Hymenaea courbaril L. Machiche, Lonchocarpus castilloi, Standley. Manil, Symphonia globulifera, L. Marupa, Simarouba glauca, DC. Melina, Gmelina arborea, Roxb. Mongoy, Guibourtia ehie J. Léonard Nance, Byrsonima crassifolia (L.), H.B.K. Nazareno, Peltogyne purpurea Nispero, Manilkara zapota, (L.) Van royen. Palo blanco, Cybitax donnell- smith , Seibert. Pino amarillo, Erblichia odorata Piojo, Tapirira guianensis, Aubl. Quaruba, Vochysia guatemalensis, Donnell Smith Quira, Platysmicium pinnatum. Redondo, Magnolia yoroconte, Dandy. Rosul, Dalbergia tucurensis, Donn-Smith. Sande, Brossimiun ssp San juan areno, Ilex ssp. Saqui-saqui, Bombacopsis quinatum, (Jacq.) Dugand Santa maría, Calophyllum brasílíense Camb. Sapelly, Entandrophragma cylindricum Sprague Tamboril, Enterolobium cyclocarpum, Gris Teca, Tectona grandis, L.F.. Ukola, Tieghemella africana Ururucana, Hieronyma alchorneoides, Allem

El rigor de la geometría reguladora: aplicaciones de la transgeometría de Pablo Palazuelo en el Dibujo Arquitectónico

En la presente comunicación se trata de enfocar esta exactitud geométrica requerida para la correcta ejecución del dibujo arquitectónico, estableciendo un análisis comparativo con la minuciosa metodología desarrollada por Pablo Palazuelo. De esta manera, se tratará también de determinar su posible aplicación docente en nuestras asignaturas gráficas, Dibujo Arquitectónico y su hermana Laboratorio de Informática Gráfica.

Desarrollo de aplicaciones basadas en Linux Embedded en una arquitectura basada en Cyclone V SoC (System on Chip) de Altera

We attempt to integrate and start up the set of necessary tools to deploy the design cycle of embedded systems based on Embedded Linux on a "Cyclone V SoC" made by Altera. First, we will analyze the available tools for designing the hardware system of the SoCkit development kit, made by Arrow, which has a "Cyclone V SoC" system (based on a "ARM Cortex-A9 MP Core" architecture). When designing the SoCkit board hardware, we will create a new peripheral to integrate it into the hardware system, so it can be used as any other existent resource of the SoCkit board previously configured. Next, we will analyze the tools to generate an Embedded Linux distribution adapted to the SoCkit board. In order to generate the Linux distribution we will use, on the one hand, a software package from Yocto recommended by Altera; on the other hand, the programs and tools of Altera, Embedded Development Suite. We will integrate all the components needed to build the Embedded Linux distribution, creating a complete and functional system which can be used for developing software applications. Finally, we will study the programs for developing and debugging applications in C or C++ language that will be executed in this hardware platform, then we will program a Linux application as an example to illustrate the use of SoCkit board resources. RESUMEN Se pretende integrar y poner en funcionamiento el conjunto de herramientas necesarias para desplegar el ciclo de diseño de sistemas embebidos basados en "Embedded Linux" sobre una "Cyclone V SoC" de Altera. En primer lugar, se analizarán las diversas herramientas disponibles para diseñar el sistema hardware de la tarjeta de desarrollo SoCkit, fabricada por Arrow, que dispone de un sistema "Cyclone V SoC" (basado en una arquitectura "ARM Cortex A9 MP Core"). En el diseño hardware de la SoCkit se creará un periférico propio y se integrará en el sistema, pudiendo ser utilizado como cualquier otro recurso de la tarjeta ya existente y configurado. A continuación, también se analizarán las herramientas para generar una distribución de "Embedded Linux" adaptado a la placa SoCkit. Para generar la distribución de Linux se utilizará, por una parte, un paquete software de Yocto recomendado por Altera y, por otra parte, las propias herramientas y programas de Altera. Se integrarán todos los componentes necesarios para construir la distribución Linux, creando un sistema completo y funcional que se pueda utilizar para el desarrollo de aplicaciones software. Por último, se estudiarán las herramientas para el diseño y depuración de aplicaciones en lenguaje C ó C++ que se ejecutarán en esta plataforma hardware. Se pretende desarrollar una aplicación de ejemplo para ilustrar el uso de los recursos más utilizados de la SoCkit.

Desarrollo de una solución SaaS para una Enterprise Store

En el marco del proyecto europeo FI-WARE, en el CoNWet Lab (laboratorio de la ETSI Informáticos de la UPM) se ha implementado la plataforma Web Wstore que es una implementación de referencia del Store Generic Enabler perteneciente a dicho proyecto. El objetivo de FI-WARE es crear la plataforma núcleo del Internet del Futuro (IoF) con la intención de incrementar la competitividad global europea en el mundo de las TI. El proyecto introduce una infraestructura innovadora para la creación y distribución de servicios digitales en internet. WStore ofrece a los proveedores de servicios la plataforma donde publicar sus ofertas y desde la cual los clientes podrán acceder ellas. Estos proveedores ofrecen servicios Web, aplicaciones, widgets y data sets del mismo modo que Google ofrece aplicaciones en la tienda online Google Play o Apple en el App Store. WStore está implementada actualmente como una plataforma Web, por lo que una organización que desee ofrecer el servicio de la store necesita instalar el software en un servidor propio y disponer de un dominio para ofrecer sus productos. El objetivo de este trabajo es migrar WStore a un entorno de computación en la nube de manera que con una única instancia se ofrezca el servicio a las organizaciones que deseen disponer de su propia plataforma, de la cual tendrán total control como si se encontrase en su propia infraestructura. Para esto se implementa una versión de WStore que será desplegada en una infraestructura cloud y ofrecida como Software as a Service. La implementación incluye una serie de módulos de código que se podrán añadir opcionalmente en el proceso de instalación si se desea que la instancia instalada sea Multitenant. Además, en este trabajo se estudian y prueban las herramientas que ofrece MongoDB para desplegar la plataforma Wstore Multitenant en una infraestructura cloud. Estas herramientas son replica sets y sharding que permiten desplegar una base de datos escalable y de alta disponibilidad. ---ABSTRACT---In the context of the European project FI-WARE, the CoNWeT Lab (IT Lab from ETSIINF UPM university) has been implemented the web platform WStore. WStore is a reference implementation of the Generic Enabler Store from FI-WARE project. The FI-WARE goal is to create the core platform of the Future Internet (IoF) with the intention of enhancing Europe's global competitiveness in IT technologies. FI-WARE introduces an innovative infrastructure for the creation and distribution of digital services over the Internet. WStore offers to service providers a platform to publicate offerings and where customers can access them. The providers offer web services, applications, widgets and data sets in the same way that Google offers online applications on Google Play or Apple on App Store plataforms. WStore is currently implemented as a web platform, so if an organization wants to offer the store service, it need to install the software on it’s own serves and have a domain to offer their products. The objective of this paper is to migrate WStore to a cloud computing environment where a single instance of the WStore is offered as a web service to organizations who want their own store. Customers (tenants) of the WStore web service will have total control over the software and WStore administration. The implementation includes several code modules that can be optionally added in the installation process to build a Multitenant instance. In addition, this paper review the tools that MongoDB provide for scalability and high availability (replica sets and sharding) with the purpose of deploying multi-tenant WStore on a cloud infrastructure.

Desarrollo sistemático de elementos composicionales para Mashup de aplicaciones

Este Trabajo fin de grado ha tomado como punto de partida el escenario y los casos de uso que han sido seleccionados para el demostrador ("live demo") del proyecto europeo de I+D+I FI-WARE para, a través del diseño y de la implementación del conjunto de widgets y operadores que forman parte de dicho demostrador, deducir los principios subyacentes al Desarrollo sistemático de los elementos composicionales que conforman un mashup de aplicaciones Web 2.0. En concreto, con el escenario escogido se quiere demostrar, en un contexto de Smart Cities, como puede monitorizarse el estado y la geolocalización de un conjunto de máquinas de vending y de los técnicos y reponedores que les dan soporte. Este trabajo fin de grado se ocupa, en concreto, de crear todos los componentes de interfaz necesarios para poder ofrecer un mashup de aplicación que ofrezca un cuadro de mando personalizable para llevar a cabo la monitorización y el control de máquinas de vending, técnicos y reponedores. Teniendo en cuenta el documento de casos de uso para ese escenario, se hizo una revisión de los diferentes widgets y operadores que había que diseñar y desarrollar. El conjunto inicial de widgets se mantuvo invariable, ya que las vistas que hay que mostrar deben ser las que se especifican en el documento anteriormente citado. No obstante, los operadores necesarios para el mashup han ido cambiando a lo largo del desarrollo como consecuencia de las necesidades de los tipos de datos tratados y de las características propias de la plataforma utilizada. El diseño del mashup se ha dividido en dos tipos de diseños distintos: Diseño de vistas: Es un disño de alto nivel donde se pueden observar las distintas vistas que vería el usuario en cada uno de los widgets (los operadores no tienen vista). Diseño de interacciones: Es un diseño de alto nivel donde se representa esquemáticamente el ujo de datos entre los elementos composicionales del mashup (tanto widgets como operadores). Al mismo tiempo que se planteaba el diseño del mashup, y como consecuencia de la experiencia ganada, se han podido ir realizando trabajos como la creación de la "Guía de desarrollo de widgets y operadores" y la "Guía de estilo para el desarrollo de widgets y operadores".Estos documentos, por su importancia, dan pie al título del presente trabajo ya que suponen una ayuda metodológica al desarrollo sistemático de elementos composicionales para mashup de aplicaciones. Durante ese periódo, simultaneamente, se pudieron encontrar y consultar diferentes fuentes de información que completan el "Estado del arte" y el documento de "Principios de diseño de aplicaciones composicionales orientadas a mashups" y se realizaron varias herramientas que facilitan la tarea del programador de crear un nuevo widget u operador desde cero. Entre estas últimas, destacan: una herramienta para crear y mantener la estructura de directorios y archivos de un widget y de un operador; y una herramienta que empaqueta todos los ficheros del widget u operador en un solo fichero WGT, dejándolo preparado para ser desplegado en la plataforma. La mayor parte del trabajo ha consistido en la implementación de los widgets y operadores. Los widgets implementados son los siguientes: Map Viewer. Issues List. Technicians List. Technicians Info. Los operadores implementados son los siguientes: Poi2Issue Issue2Poi Poi2vCard Vcard2Poi TechnicianSource IssuesSource También se han realizado tres tipos de tests: unitarios, de integracion y de sistema. Además se ha creado documentación de cada elemento composicional para el usuario. En dicha documentación se explica cuales son las funcionalidades de cada uno de los elementos composicionales y cuales son las capacidades de conexión con otros elementos. El resultado de mi trabajo puede observarse en: http://www.youtube.com/watch?v=r8 Vv ehJSw

Advanced system of planning and organization of classes at the university

This document is the result of a process of web development to create a tool that will allow to Cracow University of Technology consult, create and manage timetables. The technologies chosen for this purpose are Apache Tomcat Server, My SQL Community Server, JDBC driver, Java Servlets and JSPs for the server side. The client part counts on Javascript, jQuery, AJAX and CSS technologies to perform the dynamism. The document will justify the choice of these technologies and will explain some development tools that help in the integration and development of all this elements: specifically, NetBeans IDE and MySQL workbench have been used as helpful tools. After explaining all the elements involved in the development of the web application, the architecture and the code developed are explained through UML diagrams. Some implementation details related to security are also deeper explained through sequence diagrams. As the source code of the application is provided, an installation manual has been developed to run the project. In addition, as the platform is intended to be a beta that will be grown, some unimplemented ideas for future development are also exposed. Finally, some annexes with important files and scripts related to the initiation of the platform are attached. This project started through an existing tool that needed to be expanded. The main purpose of the project along its development has focused on setting the roots for a whole new platform that will replace the existing one. For this goal, it has been needed to make a deep inspection on the existing web technologies: a web server and a SQL database had to be chosen. Although the alternatives were a lot, Java technology for the server was finally selected because of the big community backwards, the easiness of modelling the language through UML diagrams and the fact of being free license software. Apache Tomcat is the open source server that can use Java Servlet and JSP technology. Related to the SQL database, MySQL Community Server is the most popular open-source SQL Server, with a big community after and quite a lot of tools to manage the server. JDBC is the driver needed to put in contact Java and MySQL. Once we chose the technologies that would be part of the platform, the development process started. After a detailed explanation of the development environment installation, we used UML use case diagrams to set the main tasks of the platform; UML class diagrams served to establish the existing relations between the classes generated; the architecture of the platform was represented through UML deployment diagrams; and Enhanced entity–relationship (EER) model were used to define the tables of the database and their relationships. Apart from the previous diagrams, some implementation issues were explained to make a better understanding of the developed code - UML sequence diagrams helped to explain this. Once the whole platform was properly defined and developed, the performance of the application has been shown: it has been proved that with the current state of the code, the platform covers the use cases that were set as the main target. Nevertheless, some requisites needed for the proper working of the platform have been specified. As the project is aimed to be grown, some ideas that could not be added to this beta have been explained in order not to be missed for future development. Finally, some annexes containing important configuration issues for the platform have been added after proper explanation, as well as an installation guide that will let a new developer get the project ready. In addition to this document some other files related to the project are provided: - Javadoc. The Javadoc containing the information of every Java class created is necessary for a better understanding of the source code. - database_model.mwb. This file contains the model of the database for MySQL Workbench. This model allows, among other things, generate the MySQL script for the creation of the tables. - ScheduleManager.war. The WAR file that will allow loading the developed application into Tomcat Server without using NetBeans. - ScheduleManager.zip. The source code exported from NetBeans project containing all Java packages, JSPs, Javascript files and CSS files that are part of the platform. - config.properties. The configuration file to properly get the names and credentials to use the database, also explained in Annex II. Example of config.properties file. - db_init_script.sql. The SQL query to initiate the database explained in Annex III. SQL statements for MySQL initialization. RESUMEN. Este proyecto tiene como punto de partida la necesidad de evolución de una herramienta web existente. El propósito principal del proyecto durante su desarrollo se ha centrado en establecer las bases de una completamente nueva plataforma que reemplazará a la existente. Para lograr esto, ha sido necesario realizar una profunda inspección en las tecnologías web existentes: un servidor web y una base de datos SQL debían ser elegidos. Aunque existen muchas alternativas, la tecnología Java ha resultado ser elegida debido a la gran comunidad de desarrolladores que tiene detrás, además de la facilidad que proporciona este lenguaje a la hora de modelarlo usando diagramas UML. Tampoco hay que olvidar que es una tecnología de uso libre de licencia. Apache Tomcat es el servidor de código libre que permite emplear Java Servlets y JSPs para hacer uso de la tecnología de Java. Respecto a la base de datos SQL, el servidor más popular de código libre es MySQL, y cuenta también con una gran comunidad detrás y buenas herramientas de modelado, creación y gestión de la bases de datos. JDBC es el driver que va a permitir comunicar las aplicaciones Java con MySQL. Tras elegir las tecnologías que formarían parte de esta nueva plataforma, el proceso de desarrollo tiene comienzo. Tras una extensa explicación de la instalación del entorno de desarrollo, se han usado diagramas de caso de UML para establecer cuáles son los objetivos principales de la plataforma; los diagramas de clases nos permiten realizar una organización del código java desarrollado de modo que sean fácilmente entendibles las relaciones entre las diferentes clases. La arquitectura de la plataforma queda definida a través de diagramas de despliegue. Por último, diagramas EER van a definir las relaciones entre las tablas creadas en la base de datos. Aparte de estos diagramas, algunos detalles de implementación se van a justificar para tener una mejor comprensión del código desarrollado. Diagramas de secuencia ayudarán en estas explicaciones. Una vez que toda la plataforma haya quedad debidamente definida y desarrollada, se va a realizar una demostración de la misma: se demostrará cómo los objetivos generales han sido alcanzados con el desarrollo actual del proyecto. No obstante, algunos requisitos han sido aclarados para que la plataforma trabaje adecuadamente. Como la intención del proyecto es crecer (no es una versión final), algunas ideas que se han podido llevar acabo han quedado descritas de manera que no se pierdan. Por último, algunos anexos que contienen información importante acerca de la plataforma se han añadido tras la correspondiente explicación de su utilidad, así como una guía de instalación que va a permitir a un nuevo desarrollador tener el proyecto preparado. Junto a este documento, ficheros conteniendo el proyecto desarrollado quedan adjuntos. Estos ficheros son: - Documentación Javadoc. Contiene la información de las clases Java que han sido creadas. - database_model.mwb. Este fichero contiene el modelo de la base de datos para MySQL Workbench. Esto permite, entre otras cosas, generar el script de iniciación de la base de datos para la creación de las tablas. - ScheduleManager.war. El fichero WAR que permite desplegar la plataforma en un servidor Apache Tomcat. - ScheduleManager.zip. El código fuente exportado directamente del proyecto de Netbeans. Contiene todos los paquetes de Java generados, ficheros JSPs, Javascript y CSS que forman parte de la plataforma. - config.properties. Ejemplo del fichero de configuración que permite obtener los nombres de la base de datos - db_init_script.sql. Las consultas SQL necesarias para la creación de la base de datos.

Clustering basado en redes bayesianas con predictoras continuas: aplicaciones en neurociencia

Desentrañar el funcionamiento del cerebro es uno de los principales desafíos a los que se enfrenta la ciencia actual. Un área de estudio que ha despertado muchas expectativas e interés es el análisis de la estructura cortical desde el punto de vista morfológico, de manera que se cree una simulación del cerebro a nivel molecular. Con ello se espera poder profundizar en el estudio de numerosas enfermedades neurológicas y patológicas. Con el desarrollo de este proyecto se persigue el estudio del soma y de las espinas desde el punto de vista de la neuromorfología teórica. Es común en el estado del arte que en el análisis de las características morfológicas de una neurona en tres dimensiones el soma sea ignorado o, en el mejor de los casos, que sea sustituido por una simple esfera. De hecho, el concepto de soma resulta abstracto porque no se dispone de una dfinición estricta y robusta que especifique exactamente donde finaliza y comienzan las dendritas. En este proyecto se alcanza por primera vez una definición matemática de soma para determinar qué es el soma. Con el fin de simular somas se ahonda en los atributos utilizados en el estado del arte. Estas propiedades, de índole genérica, no especifican una morfología única. Es por ello que se propone un método que agrupe propiedades locales y globales de la morfología. En disposición de las características se procede con la categorización del cuerpo celular en distintas clases a partir de un nuevo subtipo de red bayesiana dinámica adaptada al espacio. Con ello se discute la existencia de distintas clases de somas y se descubren las diferencias entre los somas piramidales de distintas capas del cerebro. A partir del modelo matemático se simulan por primera vez somas virtuales. Algunas morfologías de espinas han sido atribuidas a ciertos comportamientos cognitivos. Por ello resulta de interés dictaminar las clases existentes y relacionarlas con funciones de la actividad cerebral. La clasificación más extendida (Peters y Kaiserman-Abramof, 1970) presenta una definición ambigua y subjetiva dependiente de la interpretación de cada individuo y por tanto discutible. Este estudio se sustenta en un conjunto de descriptores extraídos mediante una técnica de análisis topológico local para representaciones 3D. Sobre estos datos se trata de alcanzar el conjunto de clases más adecuado en el que agrupar las espinas así como de describir cada grupo mediante reglas unívocas. A partir de los resultados, se discute la existencia de un continuo de espinas y las propiedades que caracterizan a cada subtipo de espina. ---ABSTRACT---Unravel how the brain works is one of the main challenges faced by current science. A field of study which has aroused great expectations and interest is the analysis of the cortical structure from a morphological point of view, so that a molecular level simulation of the brain is achieved. This is expected to deepen the study of many neurological and pathological diseases. This project seeks the study of the soma and spines from the theoretical neuromorphology point of view. In the state of the art it is common that when it comes to analyze the morphological characteristics of a three dimension neuron the soma is ignored or, in the best case, it is replaced by a simple sphere. In fact, the concept of soma is abstract because there is not a robust and strict definition on exactly where it ends and dendrites begin. In this project a mathematical definition is reached for the first time to determine what a soma is. With the aim to simulate somas the atributes applied in the state of the art are studied. These properties, generic in nature, do not specify a unique morphology. It is why it was proposed a method to group local and global morphology properties. In arrangement of the characteristics it was proceed with the categorization of the celular body into diferent classes by using a new subtype of dynamic Bayesian network adapted to space. From the result the existance of different classes of somas and diferences among pyramidal somas from distinct brain layers are discovered. From the mathematical model virtual somas were simulated for the first time. Some morphologies of spines have been attributed to certain cognitive behaviours. For this reason it is interesting to rule the existent classes and to relate them with their functions in the brain activity. The most extended classification (Peters y Kaiserman-Abramof, 1970) presents an ambiguous and subjective definition that relies on the interpretation of each individual and consequently it is arguable. This study was based on the set of descriptors extracted from a local topological analysis technique for 3D representations. On these data it was tried to reach the most suitable set of classes to group the spines as well as to describe each cluster by unambiguous rules. From these results, the existance of a continuum of spines and the properties that characterize each spine subtype were discussed .

Utilizando CORBA para distribuir aplicaciones intensivas en cálculo

Actualmente se están utilizando supercomputadores para resolver problemas intensivos en cálculo tales como las previsiones meteorológicas, el aprendizaje de redes neuronales artificiales o incluso aplicaciones lúdicas como el ajedrez. El uso de esta tecnología queda limitado a las grandes corporaciones con medios financieros suficientes como para abordar la adquisición de tales ordenadores. La distribución del cálculo entre varios ordenadores es una solución más barata para aquellos casos en los que la aplicación es susceptible de ser distribuida. De hecho, es la única solución para muchas empresas que no pueden adquirir supercomputadores y que sin embargo soportan aplicaciones que precisan de mucha potencia de cálculo (por ejemplo, el análisis de imágenes). En este artículo mostraremos cómo utilizando un middelware, CORBA (Common Object Request Broker Architecture), y una implementación concreta de este, DST (Distributed Smalltalk), es posible distribuir una aplicación entre varios ordenadores de una manera elegante y escalable y cómo el trabajo cooperativo de varios ordenadores disminuye significativamente el tiempo total de cómputo. Creemos que esta forma de distribución puede solucionar muchos de los problemas de tiempos de ejecución con los que se enfrentan actualmente las empresas de desarrollo software

Reactivo de Lugol: Historia de su descubrimiento y aplicaciones didácticas

Our paper is a brief historical study of aqueous solutions of potassium iodide and iodine. It also analyzes why, in Biology and Medicine, these solutions are known as Lugol reactive. Moreover, we study their use for educational purposes to deepen in various topics such as redox reactions and the relationship between solubility and bond types.

Obtención y Uso de Patrones para la Implementación de Funcionalidades de Usabilidad en Aplicaciones Web

La usabilidad es un atributo de calidad de un sistema software que llega a ser crítico en sistemas altamente interactivos. Desde el campo de la Interacción Persona-Ordenador se proponen recomendaciones que permiten alcanzar un nivel adecuado de usabilidad en un sistema. En la disciplina de la Ingeniería de Software se ha establecido que algunas de estas recomendaciones afectan a la funcionalidad principal de los sistemas y no solo a la interfaz de usuario. Este tipo de recomendaciones de usabilidad se deben tener en cuenta desde las primeras actividades y durante todo el proceso de desarrollo, así como se hace con atributos tales como la seguridad, la facilidad de mantenimiento o el rendimiento. Desde la Ingeniería de Software se han hecho estudios y propuestas para abordar la usabilidad en las primeras actividades del desarrollo. En particular en la educción de requisitos y diseño de la arquitectura. Estas propuestas son de un alto nivel de abstracción. En esta investigación se aborda la usabilidad en actividades avanzadas del proceso de desarrollo: el diseño detallado y la programación. El objetivo de este trabajo es obtener, formalizar y validar soluciones reutilizables para la usabilidad en estas actividades. En este estudio se seleccionan tres funcionalidades de usabilidad identificadas como de alto impacto en el diseño: Abortar Operación, Retroalimentación de Progreso y Preferencias. Para la obtención de elementos reutilizables se utiliza un método inductivo. Se parte de la construcción de aplicaciones web particulares y se induce una solución general. Durante la construcción de las aplicaciones se mantiene la trazabilidad de los elementos relacionados con cada funcionalidad de usabilidad. Al finalizar se realiza un análisis de elementos comunes, y los hallazgos se formalizan como patrones de diseño orientados a la implementación y patrones de programación en cada uno de los lenguajes utilizados: PHP, VB .NET y Java. Las soluciones formalizadas como patrones se validan usando la metodología de estudio de casos. Desarrolladores independientes utilizan los patrones para la inclusión de las tres funcionalidades de usabilidad en dos nuevas aplicaciones web. Como resultado, los desarrolladores pueden usar con éxito las soluciones propuestas para dos de las funcionalidades: Abortar Operación y Preferencias. La funcionalidad Retroalimentación de Progreso no puede ser implementada completamente. Se concluye que es posible obtener elementos reutilizables para la implementación de cada funcionalidad de usabilidad. Estos elementos incluyen: escenarios de aplicación, que son la combinación de casuísticas que generan las funcionalidades de usabilidad, responsabilidades comunes necesarias para cubrir los escenarios, componentes comunes para cumplir con las responsabilidades, elementos de diseño asociados a los componentes y el código que implementa el diseño. Formalizar las soluciones como patrones resulta útil para comunicar los hallazgos a otros desarrolladores y los patrones se mejoran a través de su utilización en nuevos desarrollos. La implementación de funcionalidades de usabilidad presenta características que condicionan su reutilización, en particular, el nivel de acoplamiento de la funcionalidad de usabilidad con las funcionalidades de la aplicación, y la complejidad interna de la solución. ABSTRACT Usability is a critical quality attribute of highly interactive software systems. The humancomputer interaction field proposes recommendations for achieving an acceptable system usability level. The discipline of software engineering has established that some of these recommendations affect not only the user interface but also the core system functionality. This type of usability recommendations must be taken into account as of the early activities and throughout the software development process as in the case of attributes like security, ease of maintenance or performance. Software engineering has conducted studies and put forward proposals for tackling usability in the early development activities, particularly requirements elicitation and architecture design. These proposals have a high level of abstraction. This research addresses usability in later activities of the development process: detailed design and programming. The goal of this research is to discover, specify and validate reusable usability solutions for detailed design and programming. Abort Operation, Feedback and Preferences, three usability functionalities identified as having a high impact on design, are selected for the study. An inductive method, whereby a general solution is induced from particular web applications built for the purpose, is used to discover reusable elements. During the construction of the applications, the traceability of the elements related to each usability functionality is maintained. At the end of the process, the common and possibly reusable elements are analysed. The findings are specified as implementation-oriented design patterns and programming patterns for each of the languages used: PHP, VB .NET and Java. The solutions specified as patterns are validated using the case study methodology. Independent developers use the patterns in order to build the three usability functionalities into two new web applications. As a result, the developers successfully use the proposed solutions for two of the functionalities: Abort Operation and Preferences. The Progress Feedback functionality cannot be fully implemented. We conclude that it is possible to discover reusable elements for implementing each usability functionality. These elements include: application scenarios, which are combinations of cases that generate usability functionalities, common responsibilities to cover the scenarios, common components to fulfil the responsibilities, design elements associated with the components and code implementing the design. It is useful to specify solutions as patterns in order to communicate findings to other developers, and patterns improve through further use in other development projects. Reusability depends on the features of usability functionality implementation, particularly the level of coupling of the usability functionality with the application functionalities and the internal complexity of the solution.

Caracterización de un robot para aplicaciones de mecanizado con requerimientos de tolerancias

El presente Trabajo fin Fin de Máster, versa sobre una caracterización preliminar del comportamiento de un robot de tipo industrial, configurado por 4 eslabones y 4 grados de libertad, y sometido a fuerzas de mecanizado en su extremo. El entorno de trabajo planteado es el de plantas de fabricación de piezas de aleaciones de aluminio para automoción. Este tipo de componentes parte de un primer proceso de fundición que saca la pieza en bruto. Para series medias y altas, en función de las propiedades mecánicas y plásticas requeridas y los costes de producción, la inyección a alta presión (HPDC) y la fundición a baja presión (LPC) son las dos tecnologías más usadas en esta primera fase. Para inyección a alta presión, las aleaciones de aluminio más empleadas son, en designación simbólica según norma EN 1706 (entre paréntesis su designación numérica); EN AC AlSi9Cu3(Fe) (EN AC 46000) , EN AC AlSi9Cu3(Fe)(Zn) (EN AC 46500), y EN AC AlSi12Cu1(Fe) (EN AC 47100). Para baja presión, EN AC AlSi7Mg0,3 (EN AC 42100). En los 3 primeros casos, los límites de Silicio permitidos pueden superan el 10%. En el cuarto caso, es inferior al 10% por lo que, a los efectos de ser sometidas a mecanizados, las piezas fabricadas en aleaciones con Si superior al 10%, se puede considerar que son equivalentes, diferenciándolas de la cuarta. Las tolerancias geométricas y dimensionales conseguibles directamente de fundición, recogidas en normas como ISO 8062 o DIN 1688-1, establecen límites para este proceso. Fuera de esos límites, las garantías en conseguir producciones con los objetivos de ppms aceptados en la actualidad por el mercado, obligan a ir a fases posteriores de mecanizado. Aquellas geometrías que, funcionalmente, necesitan disponer de unas tolerancias geométricas y/o dimensionales definidas acorde a ISO 1101, y no capaces por este proceso inicial de moldeado a presión, deben ser procesadas en una fase posterior en células de mecanizado. En este caso, las tolerancias alcanzables para procesos de arranque de viruta se recogen en normas como ISO 2768. Las células de mecanizado se componen, por lo general, de varios centros de control numérico interrelacionados y comunicados entre sí por robots que manipulan las piezas en proceso de uno a otro. Dichos robots, disponen en su extremo de una pinza utillada para poder coger y soltar las piezas en los útiles de mecanizado, las mesas de intercambio para cambiar la pieza de posición o en utillajes de equipos de medición y prueba, o en cintas de entrada o salida. La repetibilidad es alta, de centésimas incluso, definida según norma ISO 9283. El problema es que, estos rangos de repetibilidad sólo se garantizan si no se hacen esfuerzos o éstos son despreciables (caso de mover piezas). Aunque las inercias de mover piezas a altas velocidades hacen que la trayectoria intermedia tenga poca precisión, al inicio y al final (al coger y dejar pieza, p.e.) se hacen a velocidades relativamente bajas que hacen que el efecto de las fuerzas de inercia sean menores y que permiten garantizar la repetibilidad anteriormente indicada. No ocurre así si se quitara la garra y se intercambia con un cabezal motorizado con una herramienta como broca, mandrino, plato de cuchillas, fresas frontales o tangenciales… Las fuerzas ejercidas de mecanizado generarían unos pares en las uniones tan grandes y tan variables que el control del robot no sería capaz de responder (o no está preparado, en un principio) y generaría una desviación en la trayectoria, realizada a baja velocidad, que desencadenaría en un error de posición (ver norma ISO 5458) no asumible para la funcionalidad deseada. Se podría llegar al caso de que la tolerancia alcanzada por un pretendido proceso más exacto diera una dimensión peor que la que daría el proceso de fundición, en principio con mayor variabilidad dimensional en proceso (y por ende con mayor intervalo de tolerancia garantizable). De hecho, en los CNCs, la precisión es muy elevada, (pudiéndose despreciar en la mayoría de los casos) y no es la responsable de, por ejemplo la tolerancia de posición al taladrar un agujero. Factores como, temperatura de la sala y de la pieza, calidad constructiva de los utillajes y rigidez en el amarre, error en el giro de mesas y de colocación de pieza, si lleva agujeros previos o no, si la herramienta está bien equilibrada y el cono es el adecuado para el tipo de mecanizado… influyen más. Es interesante que, un elemento no específico tan común en una planta industrial, en el entorno anteriormente descrito, como es un robot, el cual no sería necesario añadir por disponer de él ya (y por lo tanto la inversión sería muy pequeña), puede mejorar la cadena de valor disminuyendo el costo de fabricación. Y si se pudiera conjugar que ese robot destinado a tareas de manipulación, en los muchos tiempos de espera que va a disfrutar mientras el CNC arranca viruta, pudiese coger un cabezal y apoyar ese mecanizado; sería doblemente interesante. Por lo tanto, se antoja sugestivo poder conocer su comportamiento e intentar explicar qué sería necesario para llevar esto a cabo, motivo de este trabajo. La arquitectura de robot seleccionada es de tipo SCARA. La búsqueda de un robot cómodo de modelar y de analizar cinemática y dinámicamente, sin limitaciones relevantes en la multifuncionalidad de trabajos solicitados, ha llevado a esta elección, frente a otras arquitecturas como por ejemplo los robots antropomórficos de 6 grados de libertad, muy populares a nivel industrial. Este robot dispone de 3 uniones, de las cuales 2 son de tipo par de revolución (1 grado de libertad cada una) y la tercera es de tipo corredera o par cilíndrico (2 grados de libertad). La primera unión, de tipo par de revolución, sirve para unir el suelo (considerado como eslabón número 1) con el eslabón número 2. La segunda unión, también de ese tipo, une el eslabón número 2 con el eslabón número 3. Estos 2 brazos, pueden describir un movimiento horizontal, en el plano X-Y. El tercer eslabón, está unido al eslabón número 4 por la unión de tipo corredera. El movimiento que puede describir es paralelo al eje Z. El robot es de 4 grados de libertad (4 motores). En relación a los posibles trabajos que puede realizar este tipo de robot, su versatilidad abarca tanto operaciones típicas de manipulación como operaciones de arranque de viruta. Uno de los mecanizados más usuales es el taladrado, por lo cual se elige éste para su modelización y análisis. Dentro del taladrado se elegirá para acotar las fuerzas, taladrado en macizo con broca de diámetro 9 mm. El robot se ha considerado por el momento que tenga comportamiento de sólido rígido, por ser el mayor efecto esperado el de los pares en las uniones. Para modelar el robot se utiliza el método de los sistemas multicuerpos. Dentro de este método existen diversos tipos de formulaciones (p.e. Denavit-Hartenberg). D-H genera una cantidad muy grande de ecuaciones e incógnitas. Esas incógnitas son de difícil comprensión y, para cada posición, hay que detenerse a pensar qué significado tienen. Se ha optado por la formulación de coordenadas naturales. Este sistema utiliza puntos y vectores unitarios para definir la posición de los distintos cuerpos, y permite compartir, cuando es posible y se quiere, para definir los pares cinemáticos y reducir al mismo tiempo el número de variables. Las incógnitas son intuitivas, las ecuaciones de restricción muy sencillas y se reduce considerablemente el número de ecuaciones e incógnitas. Sin embargo, las coordenadas naturales “puras” tienen 2 problemas. El primero, que 2 elementos con un ángulo de 0 o 180 grados, dan lugar a puntos singulares que pueden crear problemas en las ecuaciones de restricción y por lo tanto han de evitarse. El segundo, que tampoco inciden directamente sobre la definición o el origen de los movimientos. Por lo tanto, es muy conveniente complementar esta formulación con ángulos y distancias (coordenadas relativas). Esto da lugar a las coordenadas naturales mixtas, que es la formulación final elegida para este TFM. Las coordenadas naturales mixtas no tienen el problema de los puntos singulares. Y la ventaja más importante reside en su utilidad a la hora de aplicar fuerzas motrices, momentos o evaluar errores. Al incidir sobre la incógnita origen (ángulos o distancias) controla los motores de manera directa. El algoritmo, la simulación y la obtención de resultados se ha programado mediante Matlab. Para realizar el modelo en coordenadas naturales mixtas, es preciso modelar en 2 pasos el robot a estudio. El primer modelo se basa en coordenadas naturales. Para su validación, se plantea una trayectoria definida y se analiza cinemáticamente si el robot satisface el movimiento solicitado, manteniendo su integridad como sistema multicuerpo. Se cuantifican los puntos (en este caso inicial y final) que configuran el robot. Al tratarse de sólidos rígidos, cada eslabón queda definido por sus respectivos puntos inicial y final (que son los más interesantes para la cinemática y la dinámica) y por un vector unitario no colineal a esos 2 puntos. Los vectores unitarios se colocan en los lugares en los que se tenga un eje de rotación o cuando se desee obtener información de un ángulo. No son necesarios vectores unitarios para medir distancias. Tampoco tienen por qué coincidir los grados de libertad con el número de vectores unitarios. Las longitudes de cada eslabón quedan definidas como constantes geométricas. Se establecen las restricciones que definen la naturaleza del robot y las relaciones entre los diferentes elementos y su entorno. La trayectoria se genera por una nube de puntos continua, definidos en coordenadas independientes. Cada conjunto de coordenadas independientes define, en un instante concreto, una posición y postura de robot determinada. Para conocerla, es necesario saber qué coordenadas dependientes hay en ese instante, y se obtienen resolviendo por el método de Newton-Rhapson las ecuaciones de restricción en función de las coordenadas independientes. El motivo de hacerlo así es porque las coordenadas dependientes deben satisfacer las restricciones, cosa que no ocurre con las coordenadas independientes. Cuando la validez del modelo se ha probado (primera validación), se pasa al modelo 2. El modelo número 2, incorpora a las coordenadas naturales del modelo número 1, las coordenadas relativas en forma de ángulos en los pares de revolución (3 ángulos; ϕ1, ϕ 2 y ϕ3) y distancias en los pares prismáticos (1 distancia; s). Estas coordenadas relativas pasan a ser las nuevas coordenadas independientes (sustituyendo a las coordenadas independientes cartesianas del modelo primero, que eran coordenadas naturales). Es necesario revisar si el sistema de vectores unitarios del modelo 1 es suficiente o no. Para este caso concreto, se han necesitado añadir 1 vector unitario adicional con objeto de que los ángulos queden perfectamente determinados con las correspondientes ecuaciones de producto escalar y/o vectorial. Las restricciones habrán de ser incrementadas en, al menos, 4 ecuaciones; una por cada nueva incógnita. La validación del modelo número 2, tiene 2 fases. La primera, al igual que se hizo en el modelo número 1, a través del análisis cinemático del comportamiento con una trayectoria definida. Podrían obtenerse del modelo 2 en este análisis, velocidades y aceleraciones, pero no son necesarios. Tan sólo interesan los movimientos o desplazamientos finitos. Comprobada la coherencia de movimientos (segunda validación), se pasa a analizar cinemáticamente el comportamiento con trayectorias interpoladas. El análisis cinemático con trayectorias interpoladas, trabaja con un número mínimo de 3 puntos máster. En este caso se han elegido 3; punto inicial, punto intermedio y punto final. El número de interpolaciones con el que se actúa es de 50 interpolaciones en cada tramo (cada 2 puntos máster hay un tramo), resultando un total de 100 interpolaciones. El método de interpolación utilizado es el de splines cúbicas con condición de aceleración inicial y final constantes, que genera las coordenadas independientes de los puntos interpolados de cada tramo. Las coordenadas dependientes se obtienen resolviendo las ecuaciones de restricción no lineales con el método de Newton-Rhapson. El método de las splines cúbicas es muy continuo, por lo que si se desea modelar una trayectoria en el que haya al menos 2 movimientos claramente diferenciados, es preciso hacerlo en 2 tramos y unirlos posteriormente. Sería el caso en el que alguno de los motores se desee expresamente que esté parado durante el primer movimiento y otro distinto lo esté durante el segundo movimiento (y así sucesivamente). Obtenido el movimiento, se calculan, también mediante fórmulas de diferenciación numérica, las velocidades y aceleraciones independientes. El proceso es análogo al anteriormente explicado, recordando la condición impuesta de que la aceleración en el instante t= 0 y en instante t= final, se ha tomado como 0. Las velocidades y aceleraciones dependientes se calculan resolviendo las correspondientes derivadas de las ecuaciones de restricción. Se comprueba, de nuevo, en una tercera validación del modelo, la coherencia del movimiento interpolado. La dinámica inversa calcula, para un movimiento definido -conocidas la posición, velocidad y la aceleración en cada instante de tiempo-, y conocidas las fuerzas externas que actúan (por ejemplo el peso); qué fuerzas hay que aplicar en los motores (donde hay control) para que se obtenga el citado movimiento. En la dinámica inversa, cada instante del tiempo es independiente de los demás y tiene una posición, una velocidad y una aceleración y unas fuerzas conocidas. En este caso concreto, se desean aplicar, de momento, sólo las fuerzas debidas al peso, aunque se podrían haber incorporado fuerzas de otra naturaleza si se hubiese deseado. Las posiciones, velocidades y aceleraciones, proceden del cálculo cinemático. El efecto inercial de las fuerzas tenidas en cuenta (el peso) es calculado. Como resultado final del análisis dinámico inverso, se obtienen los pares que han de ejercer los cuatro motores para replicar el movimiento prescrito con las fuerzas que estaban actuando. La cuarta validación del modelo consiste en confirmar que el movimiento obtenido por aplicar los pares obtenidos en la dinámica inversa, coinciden con el obtenido en el análisis cinemático (movimiento teórico). Para ello, es necesario acudir a la dinámica directa. La dinámica directa se encarga de calcular el movimiento del robot, resultante de aplicar unos pares en motores y unas fuerzas en el robot. Por lo tanto, el movimiento real resultante, al no haber cambiado ninguna condición de las obtenidas en la dinámica inversa (pares de motor y fuerzas inerciales debidas al peso de los eslabones) ha de ser el mismo al movimiento teórico. Siendo así, se considera que el robot está listo para trabajar. Si se introduce una fuerza exterior de mecanizado no contemplada en la dinámica inversa y se asigna en los motores los mismos pares resultantes de la resolución del problema dinámico inverso, el movimiento real obtenido no es igual al movimiento teórico. El control de lazo cerrado se basa en ir comparando el movimiento real con el deseado e introducir las correcciones necesarias para minimizar o anular las diferencias. Se aplican ganancias en forma de correcciones en posición y/o velocidad para eliminar esas diferencias. Se evalúa el error de posición como la diferencia, en cada punto, entre el movimiento teórico deseado en el análisis cinemático y el movimiento real obtenido para cada fuerza de mecanizado y una ganancia concreta. Finalmente, se mapea el error de posición obtenido para cada fuerza de mecanizado y las diferentes ganancias previstas, graficando la mejor precisión que puede dar el robot para cada operación que se le requiere, y en qué condiciones. -------------- This Master´s Thesis deals with a preliminary characterization of the behaviour for an industrial robot, configured with 4 elements and 4 degrees of freedoms, and subjected to machining forces at its end. Proposed working conditions are those typical from manufacturing plants with aluminium alloys for automotive industry. This type of components comes from a first casting process that produces rough parts. For medium and high volumes, high pressure die casting (HPDC) and low pressure die casting (LPC) are the most used technologies in this first phase. For high pressure die casting processes, most used aluminium alloys are, in simbolic designation according EN 1706 standard (between brackets, its numerical designation); EN AC AlSi9Cu3(Fe) (EN AC 46000) , EN AC AlSi9Cu3(Fe)(Zn) (EN AC 46500), y EN AC AlSi12Cu1(Fe) (EN AC 47100). For low pressure, EN AC AlSi7Mg0,3 (EN AC 42100). For the 3 first alloys, Si allowed limits can exceed 10% content. Fourth alloy has admisible limits under 10% Si. That means, from the point of view of machining, that components made of alloys with Si content above 10% can be considered as equivalent, and the fourth one must be studied separately. Geometrical and dimensional tolerances directly achievables from casting, gathered in standards such as ISO 8062 or DIN 1688-1, establish a limit for this process. Out from those limits, guarantees to achieve batches with objetive ppms currently accepted by market, force to go to subsequent machining process. Those geometries that functionally require a geometrical and/or dimensional tolerance defined according ISO 1101, not capable with initial moulding process, must be obtained afterwards in a machining phase with machining cells. In this case, tolerances achievables with cutting processes are gathered in standards such as ISO 2768. In general terms, machining cells contain several CNCs that they are interrelated and connected by robots that handle parts in process among them. Those robots have at their end a gripper in order to take/remove parts in machining fixtures, in interchange tables to modify position of part, in measurement and control tooling devices, or in entrance/exit conveyors. Repeatibility for robot is tight, even few hundredths of mm, defined according ISO 9283. Problem is like this; those repeatibilty ranks are only guaranteed when there are no stresses or they are not significant (f.e. due to only movement of parts). Although inertias due to moving parts at a high speed make that intermediate paths have little accuracy, at the beginning and at the end of trajectories (f.e, when picking part or leaving it) movement is made with very slow speeds that make lower the effect of inertias forces and allow to achieve repeatibility before mentioned. It does not happens the same if gripper is removed and it is exchanged by an spindle with a machining tool such as a drilling tool, a pcd boring tool, a face or a tangential milling cutter… Forces due to machining would create such big and variable torques in joints that control from the robot would not be able to react (or it is not prepared in principle) and would produce a deviation in working trajectory, made at a low speed, that would trigger a position error (see ISO 5458 standard) not assumable for requested function. Then it could be possible that tolerance achieved by a more exact expected process would turn out into a worst dimension than the one that could be achieved with casting process, in principle with a larger dimensional variability in process (and hence with a larger tolerance range reachable). As a matter of fact, accuracy is very tight in CNC, (its influence can be ignored in most cases) and it is not the responsible of, for example position tolerance when drilling a hole. Factors as, room and part temperature, manufacturing quality of machining fixtures, stiffness at clamping system, rotating error in 4th axis and part positioning error, if there are previous holes, if machining tool is properly balanced, if shank is suitable for that machining type… have more influence. It is interesting to know that, a non specific element as common, at a manufacturing plant in the enviroment above described, as a robot (not needed to be added, therefore with an additional minimum investment), can improve value chain decreasing manufacturing costs. And when it would be possible to combine that the robot dedicated to handling works could support CNCs´ works in its many waiting time while CNCs cut, and could take an spindle and help to cut; it would be double interesting. So according to all this, it would be interesting to be able to know its behaviour and try to explain what would be necessary to make this possible, reason of this work. Selected robot architecture is SCARA type. The search for a robot easy to be modeled and kinematically and dinamically analyzed, without significant limits in the multifunctionality of requested operations, has lead to this choice. Due to that, other very popular architectures in the industry, f.e. 6 DOFs anthropomorphic robots, have been discarded. This robot has 3 joints, 2 of them are revolute joints (1 DOF each one) and the third one is a cylindrical joint (2 DOFs). The first joint, a revolute one, is used to join floor (body 1) with body 2. The second one, a revolute joint too, joins body 2 with body 3. These 2 bodies can move horizontally in X-Y plane. Body 3 is linked to body 4 with a cylindrical joint. Movement that can be made is paralell to Z axis. The robt has 4 degrees of freedom (4 motors). Regarding potential works that this type of robot can make, its versatility covers either typical handling operations or cutting operations. One of the most common machinings is to drill. That is the reason why it has been chosen for the model and analysis. Within drilling, in order to enclose spectrum force, a typical solid drilling with 9 mm diameter. The robot is considered, at the moment, to have a behaviour as rigid body, as biggest expected influence is the one due to torques at joints. In order to modelize robot, it is used multibodies system method. There are under this heading different sorts of formulations (f.e. Denavit-Hartenberg). D-H creates a great amount of equations and unknown quantities. Those unknown quatities are of a difficult understanding and, for each position, one must stop to think about which meaning they have. The choice made is therefore one of formulation in natural coordinates. This system uses points and unit vectors to define position of each different elements, and allow to share, when it is possible and wished, to define kinematic torques and reduce number of variables at the same time. Unknown quantities are intuitive, constrain equations are easy and number of equations and variables are strongly reduced. However, “pure” natural coordinates suffer 2 problems. The first one is that 2 elements with an angle of 0° or 180°, give rise to singular positions that can create problems in constrain equations and therefore they must be avoided. The second problem is that they do not work directly over the definition or the origin of movements. Given that, it is highly recommended to complement this formulation with angles and distances (relative coordinates). This leads to mixed natural coordinates, and they are the final formulation chosen for this MTh. Mixed natural coordinates have not the problem of singular positions. And the most important advantage lies in their usefulness when applying driving forces, torques or evaluating errors. As they influence directly over origin variable (angles or distances), they control motors directly. The algorithm, simulation and obtaining of results has been programmed with Matlab. To design the model in mixed natural coordinates, it is necessary to model the robot to be studied in 2 steps. The first model is based in natural coordinates. To validate it, it is raised a defined trajectory and it is kinematically analyzed if robot fulfils requested movement, keeping its integrity as multibody system. The points (in this case starting and ending points) that configure the robot are quantified. As the elements are considered as rigid bodies, each of them is defined by its respectively starting and ending point (those points are the most interesting ones from the point of view of kinematics and dynamics) and by a non-colinear unit vector to those points. Unit vectors are placed where there is a rotating axis or when it is needed information of an angle. Unit vectors are not needed to measure distances. Neither DOFs must coincide with the number of unit vectors. Lengths of each arm are defined as geometrical constants. The constrains that define the nature of the robot and relationships among different elements and its enviroment are set. Path is generated by a cloud of continuous points, defined in independent coordinates. Each group of independent coordinates define, in an specific instant, a defined position and posture for the robot. In order to know it, it is needed to know which dependent coordinates there are in that instant, and they are obtained solving the constraint equations with Newton-Rhapson method according to independent coordinates. The reason to make it like this is because dependent coordinates must meet constraints, and this is not the case with independent coordinates. When suitability of model is checked (first approval), it is given next step to model 2. Model 2 adds to natural coordinates from model 1, the relative coordinates in the shape of angles in revoluting torques (3 angles; ϕ1, ϕ 2 and ϕ3) and distances in prismatic torques (1 distance; s). These relative coordinates become the new independent coordinates (replacing to cartesian independent coordinates from model 1, that they were natural coordinates). It is needed to review if unit vector system from model 1 is enough or not . For this specific case, it was necessary to add 1 additional unit vector to define perfectly angles with their related equations of dot and/or cross product. Constrains must be increased in, at least, 4 equations; one per each new variable. The approval of model 2 has two phases. The first one, same as made with model 1, through kinematic analysis of behaviour with a defined path. During this analysis, it could be obtained from model 2, velocities and accelerations, but they are not needed. They are only interesting movements and finite displacements. Once that the consistence of movements has been checked (second approval), it comes when the behaviour with interpolated trajectories must be kinematically analyzed. Kinematic analysis with interpolated trajectories work with a minimum number of 3 master points. In this case, 3 points have been chosen; starting point, middle point and ending point. The number of interpolations has been of 50 ones in each strecht (each 2 master points there is an strecht), turning into a total of 100 interpolations. The interpolation method used is the cubic splines one with condition of constant acceleration both at the starting and at the ending point. This method creates the independent coordinates of interpolated points of each strecht. The dependent coordinates are achieved solving the non-linear constrain equations with Newton-Rhapson method. The method of cubic splines is very continuous, therefore when it is needed to design a trajectory in which there are at least 2 movements clearly differents, it is required to make it in 2 steps and join them later. That would be the case when any of the motors would keep stopped during the first movement, and another different motor would remain stopped during the second movement (and so on). Once that movement is obtained, they are calculated, also with numerical differenciation formulas, the independent velocities and accelerations. This process is analogous to the one before explained, reminding condition that acceleration when t=0 and t=end are 0. Dependent velocities and accelerations are calculated solving related derivatives of constrain equations. In a third approval of the model it is checked, again, consistence of interpolated movement. Inverse dynamics calculates, for a defined movement –knowing position, velocity and acceleration in each instant of time-, and knowing external forces that act (f.e. weights); which forces must be applied in motors (where there is control) in order to obtain requested movement. In inverse dynamics, each instant of time is independent of the others and it has a position, a velocity, an acceleration and known forces. In this specific case, it is intended to apply, at the moment, only forces due to the weight, though forces of another nature could have been added if it would have been preferred. The positions, velocities and accelerations, come from kinematic calculation. The inertial effect of forces taken into account (weight) is calculated. As final result of the inverse dynamic analysis, the are obtained torques that the 4 motors must apply to repeat requested movement with the forces that were acting. The fourth approval of the model consists on confirming that the achieved movement due to the use of the torques obtained in the inverse dynamics, are in accordance with movements from kinematic analysis (theoretical movement). For this, it is necessary to work with direct dynamics. Direct dynamic is in charge of calculating the movements of robot that results from applying torques at motors and forces at the robot. Therefore, the resultant real movement, as there was no change in any condition of the ones obtained at the inverse dynamics (motor torques and inertial forces due to weight of elements) must be the same than theoretical movement. When these results are achieved, it is considered that robot is ready to work. When a machining external force is introduced and it was not taken into account before during the inverse dynamics, and torques at motors considered are the ones of the inverse dynamics, the real movement obtained is not the same than the theoretical movement. Closed loop control is based on comparing real movement with expected movement and introducing required corrrections to minimize or cancel differences. They are applied gains in the way of corrections for position and/or tolerance to remove those differences. Position error is evaluated as the difference, in each point, between theoretical movemment (calculated in the kinematic analysis) and the real movement achieved for each machining force and for an specific gain. Finally, the position error obtained for each machining force and gains are mapped, giving a chart with the best accuracy that the robot can give for each operation that has been requested and which conditions must be provided.

Resolución de inecuaciones variacionales y aplicaciones

En esta comunicación se pretende dar una breve introducción a las inecuaciones variacionales, y exponer las líneas de trabajo que sobre este tema se desarrollan en el Departamento de Ecuaciones Funcionales de la Universidad de Santiago.Asimismo se resumen algunas contribu ciones publicadas o en curso de realización.